100+ Female Poses FAQ

The questions this pack raises most often, starting with the one everybody asks after unzipping it.

Before you buy

How many poses are there really?

99.

clips.lua holds 105 rows and six of them are commented out — pose78, pose87, pose93, redmorrow_p23, pose29 and pose35. That leaves 99 live entries, one short of the hundred the name promises.

Nothing is missing from your download. All 104 .ycd files are in stream/, including the ones belonging to the commented-out rows, so re-enabling any of them is a matter of deleting two dashes. Every live entry has its dictionary present — zero broken rows.

The full list is on the animation list.

Is it a script or an asset pack?

An asset pack, plus a reference table telling you what is in it.

That is the whole resource:

File	What it is
stream/	104 .ycd animation dictionaries, 452 KB total
clips.lua	A data table. 105 rows, 99 of them live. No logic
server.lua	One line. It prints a start-up message
fxmanifest.lua	Declares the two scripts and dependency '/assetpacks'
README.md	The author's notes, written for a different build

Does it include a menu, a command or exports?

No. There is no client.lua, no config.lua and no html/ folder in this build, so there is nothing to open, nothing to type and nothing to call.

This is the one real difference between this pack and its sibling:

	100+ Female Poses	30+ Female Poses
Streamed .ycd dictionaries	Yes	Yes
In-game menu	No	Yes
Chat command	No	Yes
Exports	No	Yes
Config options	No	Yes
Works as an asset pack	Yes	Yes

A player cannot play a pose out of the box

Install this pack on its own and the dictionaries stream correctly, but no key and no command will do anything, because nothing in the resource listens for one. You supply the playback — either an emote resource you already run, or a few lines of your own client code. Both routes are covered under Using it.

Do I need a framework?

No. VORP, RSG, RedEM:RP or none at all — the resource never looks for one.

Do I need a database?

No. There is no SQL, nothing is saved, and the only server-side code is a single print.

Do I need an emote system?

Not strictly, but you do need something to play the clips.

Your options are an emote resource — RedM Emotes or whatever you already run — or roughly ten lines of your own client script. If you have neither and want neither, this pack will stream 452 KB to every player and do nothing visible.

What do I actually need?

A RedM server	Any build supporting fx_version 'cerulean' and lua54 'yes'
Asset packs on your licence key	Required. The manifest declares dependency '/assetpacks'
A way to play clips	Required. An emote resource, or your own script
Framework	Not required
Database	Not required

What is dependency '/assetpacks'?

A Cfx.re entitlement check tied to your server licence key. If asset packs are not enabled for that key, the resource refuses to start and nothing inside the resource can work around it.

The requirement is genuine here — the pack streams files, which is exactly what the entitlement governs.

Are there male versions?

No. Every one of the 99 entries carries bodies = { female = '…' } and nothing else. No male dictionary ships anywhere in the pack, and no male .ycd is hiding in stream/.

Does it work on FiveM?

No. These are RDR2 .ycd dictionaries and the manifest declares game 'rdr3'. The animations do not exist in GTA V.

Using it

I unzipped it and there is no menu. What do I do?

Pick one of the two routes.

1. Install the pack so the dictionaries stream. Drop the folder in resources and add one line to server.cfg:

   ensure rm_100_female_pose

2. Decide who plays the clips. Either hand the dict and clip pairs from the animation list to your emote resource, or add your own client script.

3. Test exactly one pose first, before you copy 99 rows anywhere. redmorrow@pose5@f / pose5 is a good one — it is a plain 1.967 s loop with no naming surprises.

Playing a pose walks through both routes in full.

What does the minimum client code look like?

Three natives, in this order:

local dict = 'redmorrow@pose5@f'
local clip = 'pose5'

RequestAnimDict(dict)
while not HasAnimDictLoaded(dict) do Wait(0) end

-- RDR3's TaskPlayAnim takes THIRTEEN arguments
TaskPlayAnim(PlayerPedId(), dict, clip, 4.0, -4.0, -1, 1, 0.0, false, 0, false, 0, false)

A duration of -1 lets the clip loop for as long as you leave it alone. Stop it with ClearPedTasks or ClearPedSecondaryTask.

Put a timeout on that wait

A clip requested from a dictionary that never loaded fails silently — no console error, no warning, the character simply stands there. An unbounded while not HasAnimDictLoaded(dict) do Wait(0) end turns that into a thread that spins forever and tells you nothing. Count your attempts and print the dictionary name when you give up.

Which argument is the flag word?

The seventh. RDR3's flag values are not GTA V's, so a number copied out of a FiveM resource will not do what its name suggests there. The platform notes under RedM cover the values; do not assume a FiveM cheat-sheet applies.

Do the poses move the character?

No. All 99 entries carry rootMotion = false. Nothing here walks, turns or slides the character off its mark, which is what you want from a pose pack.

Are they loops or one-shots?

Every single one is mode = 'loop'. There are no once and no hold entries in this build.

That means a pose holds indefinitely once started, and it is your code that decides when to clear it.

Why is a pose only 0.033 seconds long?

Because it is one frame at 30 fps — a genuinely static pose. Eight entries are single frames like that. Looped, a one-frame clip is a pose held forever, which is precisely the point.

The rest run from 0.1 s up to 89 s, with the long ones being slow idles that have a little movement in them. The full breakdown is under durations.

The duration field is metadata only

Nothing in the pack reads it — there is no code to read it. The numbers are what the author recorded in clips.lua. If a clip looks longer or shorter than the table says in game, trust the game, and ask GET_ANIM_DURATION for the real figure.

How do I work out a pose's dictionary?

Read it out of clips.lua. Do not build it from the id.

Most rows follow redmorrow@<id>@f, but seven do not:

ID	Dictionary
regard5	redmorrow@regard6@f
pose1	redmorrow@regard7@f
pose4	redmorrow@regard8@f
hatsdown_clip	redmorrow@pose7@f
pose28	redmorrow@pose27@f
pose47	redmorrow@pose46@f
pose47_pose47	redmorrow@pose47@f

Code that concatenates 'redmorrow@' .. id .. '@f' is right 92 times and silently wrong seven times. pose47_pose47 is the one people miss — its clip is pose47 and follows the pattern, only its id does not. See the seven ids that do not match their dictionary.

How heavy is it?

452 KB of animation data and one print on start-up. There are no loops, no event handlers and no database queries, so it cannot cost you server performance.

Client-side, the first play of any pose streams its dictionary and may stutter once. Every play after that is instant.

Compatibility

Will the poses work on a male character model?

The clip will play. It was authored for a female skeleton, so whether the result looks right is a judgement call you should make on your own server with your own models before you offer it to players.

There is no male variant to fall back to, and no setting that would substitute one.

Will it clash with another animation pack?

Only if that pack uses the same dictionary names. Everything here lives under the redmorrow@…@f prefix.

The sibling 30+ Female Poses pack uses redmorrow_com@ instead, so the two can run side by side with no collisions — different folders, different prefixes, different files.

What can clash is two resources posing the same character at once. Starting an animation clears the ped's tasks, so an emote menu and your own pose script will cancel each other. Stop one deliberately before starting the other. Animation Basics goes into that.

Can I add the poses to my emote menu?

Yes, and for most servers that is the easiest route. Every emote system needs the same two values — the dictionary and the clip — and both are in the animation list.

For RedM Emotes specifically, see three ways to add an emote.

Copy the pairs, do not generate them

This is the same trap as above, and it bites hardest here: a loop that inserts 99 emotes by building the dictionary from the id produces seven rows that look fine in your menu and do nothing in game.

Can another resource read Config.Clips?

No. Config.Clips is a global inside the redmorrow resource, and CFX gives every resource its own Lua state. Your script cannot see it, and there are no exports to hand it over.

Two ways around that:

• Copy the table into your own resource and maintain your copy.
• Add your own client script to this resource, which puts you in the same Lua state as clips.lua. Remember that a new .lua file is not covered by this build's escrow_ignore.

Integrating covers both.

Will it survive a server restart or a resource restart?

The dictionaries are streamed assets, so they come back with the resource. Anything about who was posing and which pose they had is state your own code owns — the pack stores nothing.

If you hold one of these dictionaries in your own resource, release it in your own onResourceStop. An animation left playing from a dictionary that has been unloaded underneath it is the usual cause of a frozen or T-posing character.

Editing it

Can I edit the list?

Yes. escrow_ignore covers clips.lua and README.md, so clips.lua ships readable and editable and stays that way.

Safe to edit	Leave alone
label — nothing reads it yet, but your own menu will	dict — must match the name inside the .ycd
category — the same	clip — must match the clip name inside the dictionary
duration, mode, rootMotion — metadata for your code	stream/*.ycd — binary assets

Each row carries exactly these fields: id, label, dict, clip, category, duration, mode, rootMotion and bodies. The comment header documents walk and flags as well, but no row in this build actually has them.

How do I re-enable the six commented-out poses?

Delete the leading -- from the row. The asset is already on disk, so that is the whole job.

Row	Its dictionary	Status in stream/
pose78	redmorrow@pose78@f	Present, unused
pose87	redmorrow@pose87@f	Present, unused
pose93	redmorrow@pose93@f	Present, unused
pose35	redmorrow@pose35@f	Present, unused
redmorrow_p23	redmorrow@redmorrow_p3@f	Present, unused
pose29	redmorrow@pose26@f	Present, shared with the live pose26

Those are the only five .ycd files in the pack that belong to no live entry — pose29 is not among them because it borrows pose26's dictionary, which is in use already.

Nobody disabled them on your behalf for a technical reason you can see from outside the pack, so judge each one in game and keep what you like.

Can I rename the resource folder?

Yes. In CFX the resource name is the directory name, and the name 'redmorrow' line in fxmanifest.lua is metadata that renames nothing.

The only rule is that your ensure line matches the folder on disk. The download is rm_100_female_pose.zip, so out of the box that is:

ensure rm_100_female_pose

Rename the folder to redmorrow as the README suggests and ensure redmorrow is correct instead. Both work. The dictionary names are baked into the .ycd files as redmorrow@…@f and have nothing to do with the folder name, so no pose cares either way.

Can I rename the .ycd files?

No. An RDR2 dictionary stores its own name inside the file. Renaming it only makes the file name and the dictionary name disagree, and that pose stops loading.

Why does the README mention a menu, exports and a config.lua?

Because it was written for a build that had them, and it was not trimmed back for this one.

The file list at the bottom of README.md promises config.lua, client.lua and html/. The comment header in clips.lua goes further and documents a /redmorrow command, exports['redmorrow']:Play(), exports['redmorrow']:GetClips() and a Config.ForceBody option for falling back to the other body type.

None of that exists in version 1.0.0

Not as a bug, and not as something you can switch on — those files are simply not in the zip. Read the README for the animation table and the .ycd notes, which are accurate, and treat everything it says about a menu, commands, exports or configuration as describing a different build. This documentation describes what shipped.

What does escrow protect?

Less than you might expect. escrow_ignore lists clips.lua and README.md, which is every text file in the pack that matters — so there is no protected Lua here to speak of.

The .ycd files in stream/ are assets rather than Lua, so escrow does not apply to them at all. That is a packaging fact, not a licence: what you may do with the animations is a separate question.

Can I use the animations in my own paid script?

Check the licence that came with your download before you do, and ask if it is not clear.

This build does not ship a licence file of its own — the only statement inside the resource is the closing line of README.md, which says to use only animations you made or have the rights to. The terms that apply to you are the ones attached to the product you bought, not anything this page could paraphrase. For anything involving redistribution, bundling or resale, ask on the RedMorrow Discord and get an answer in writing.

What happens to my edits when the pack updates?

They are overwritten, unless you move them first. Because the pack is assets plus one data file, an update means replacing stream/ and clips.lua wholesale.

Keep a copy of your edited clips.lua outside the resource folder, and diff it against the new one rather than pasting it back blind — a new version may have re-enabled rows or added poses your copy does not know about.

---

Still stuck? Troubleshooting sorts the common symptoms by cause. If that does not cover it, bring your server console output and the result of DoesAnimDictExist('redmorrow@pose5@f') to the RedMorrow Discord.