100+ Female Poses Troubleshooting

Almost every report about this pack comes down to one of two things: the pack is an asset pack, not a player-facing resource, or a dictionary name was guessed instead of read.

What the pack can and cannot tell you

Before you start diagnosing, know how little the resource says out loud. It contains three Lua-visible things:

File	What it does
fxmanifest.lua	Streams stream/, loads clips.lua on the client and server.lua on the server
clips.lua	A data table. Sets Config.Clips and nothing else — no functions, no events, no commands
server.lua	One print. Nothing else

So the pack's entire diagnostic output is this single line in the server console at start-up:

[redmorrow] Female animation pack started.

If you see that line, the resource started and its stream/ folder is being served. There is no client-side logging, no error message and no chat feedback, because there is no client logic to produce any. Everything below is diagnosed from your code and the server console.

There is no menu, and the command does nothing

This is the most common report, and it is not a fault.

There is no menu, no key binding and no command in this build. The pack ships clips.lua, server.lua, fxmanifest.lua and 104 .ycd files. There is no client.lua and no html/ folder, so nothing registers a key, opens an interface or listens for a chat command. Pressing keys in game will never do anything on its own.

The resource's own README.md is stale

The bundled README.md, and the comment header at the top of clips.lua, both describe an in-game menu, a /redmorrow command, exports['redmorrow']:Play(), a Config.ForceBody option and the files config.lua, client.lua and html/. None of those exist in this build — the files are not in the download and the code that would use them was not shipped.

They were written against a build that had them. Read clips.lua itself as the authority for what is in the pack, and these docs for how to drive it.

What you get is 99 playable clips and a table listing their dictionary and clip names. To make a player able to use them you need exactly one of:

Route	What you do
Your own client script	A few lines of RequestAnimDict + TaskPlayAnim. See Playing a pose
An emote resource	Add the dict/clip pairs to its list. See Integrating

If you wanted a pack that arrives with a menu, a command and exports already built, the 30+ Female Poses pack has all three. This one does not, and no setting turns them on.

The resource will not start

Two causes, and the server console names both.

An asset-pack error.

Your server licence key does not have asset packs enabled. The manifest declares dependency '/assetpacks', which is a Cfx.re entitlement check rather than a resource dependency. The pack streams 104 .ycd files, so the requirement is genuine.

Enable asset packs for your key in the Cfx.re portal. Nothing in the resource can work around this, and no other setting matters until it passes.

The ensure line does not match the folder on disk.

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

The download is rm_100_female_pose.zip, so by default the folder is rm_100_female_pose and the line is:

ensure rm_100_female_pose

The README.md tells you to rename the folder to redmorrow and use ensure redmorrow. That works too. Either is fine — the one rule is that the ensure line matches the folder name you actually have.

Renaming the folder does not break the dictionaries

The dictionary names (redmorrow@pose67@f and so on) are baked inside the .ycd files and are completely independent of the resource name. Rename the folder, and every dictionary name stays exactly as it is in the animation list.

The .ycd files themselves are a different matter — an RDR2 dictionary stores its own name, so renaming a .ycd only makes the file name and the internal name disagree, and that clip becomes unreachable. Leave them alone.

See Installation for the full first-start sequence.

Nothing happens when I try to play a pose

The character stands there, and nothing is printed anywhere.

A clip requested from a dictionary that never loaded fails silently. TaskPlayAnim does not throw, does not warn and does not return anything useful — the task is simply never given. This is the single most common bug in hand-written pose code, and it always looks like "the pack is broken".

Wait for the load, with a timeout, and say so when it expires:

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

RequestAnimDict(dict)

local deadline = GetGameTimer() + 5000
while not HasAnimDictLoaded(dict) do
    if GetGameTimer() > deadline then
        print(('[poses] dictionary "%s" never loaded'):format(dict))
        return
    end
    Wait(0)
end

TaskPlayAnim(PlayerPedId(), dict, clip, 4.0, -4.0, -1, 1, 0.0, false, 0, false, 0, false)

With the timeout in place the failure stops being silent, and you can tell the two halves apart:

Test	Result	Means
DoesAnimDictExist(dict)	false	The dictionary is not streamed. The resource is not started, or the name is wrong
DoesAnimDictExist(dict)	true, but the timeout fires	It exists but has not streamed in yet. Give it longer, or pre-request it
Dictionary loads, nothing plays	—	The clip name is wrong for that dictionary

Work through it in this order:

1. Is the line [redmorrow] Female animation pack started. in the server console, with no red errors after it?

2. Is the ensure line in server.cfg, spelled the same as the folder?

3. Did you refresh after copying the folder in? A new resource is not picked up without it.

4. Are the dict and clip values copied out of clips.lua or the animation list, rather than typed or built from the id?

5. Is the dictionary actually in stream/ under that exact name?

Copy the pair, do not type it

redmorrow@pose67@f has two @ symbols, a lowercase prefix and a @f suffix. A missing @f is the most common typo, and it produces exactly the symptom above — silence.

exports['redmorrow'] is nil

There are no exports. clips.lua is a data file; it declares no functions and calls no exports of its own. Any call of the form

exports['redmorrow']:Play('pose67')     -- errors: attempt to index a nil value
exports['redmorrow']:GetClips()         -- same

will fail, whatever you name the folder. Those two lines come from the stale comment header in clips.lua, not from shipped code.

Config.Clips is not readable from another resource

CFX gives every resource its own Lua state, so the Config global that clips.lua sets exists only inside this resource. Another resource cannot see it, and there is no export to hand it over.

To work with the list you have two choices:

• Copy the table into your own resource and maintain it there.
• Add your own client script to this resource, listed after clips.lua in client_scripts, so it shares the state and can read Config.Clips directly.

Both are written out in Integrating.

If you want a drop-in export surface, the 30+ Female Poses pack has one. This pack does not.

A dictionary I built from the id does not exist

Seven of the 99 entries have a dictionary that does not follow the redmorrow@<id>@f pattern. Code that assembles the name as 'redmorrow@' .. id .. '@f' works for 92 poses and fails silently on these:

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

pose47_pose47 is the only row in the pack whose clip name differs from its id, and it is the one a generator misses: its clip is pose47, which does follow the pattern, so building from the clip works and building from the id does not. The other six keep id = clip and move only the dictionary.

The fix is not to patch these seven — it is to stop deriving the dictionary at all. clips.lua carries both names on every row and ships readable (escrow_ignore covers it), so read the pair rather than constructing it. See the mismatch table.

A pose in the README does nothing

The README.md table lists 105 poses. Six of those rows are commented out in clips.lua:

Commented-out row	Its dictionary
pose78	redmorrow@pose78@f
pose87	redmorrow@pose87@f
pose93	redmorrow@pose93@f
redmorrow_p23	redmorrow@redmorrow_p3@f
pose29	redmorrow@pose26@f
pose35	redmorrow@pose35@f

That leaves 99 live entries out of 105 rows. The product is named "100+" and 99 play — the real number is 99, the same way the sibling 30-pose pack contains 29.

Nothing is missing from your download. All 104 .ycd files are in stream/, every live clip has its dictionary, and five of those dictionaries belong to the commented-out rows and are simply unreferenced. Re-enabling a row means deleting the leading -- from its line in clips.lua and restarting the resource; the asset is already there.

Why pose29 is not in the orphan list

pose29's dictionary is redmorrow@pose26@f, which the live pose26 entry still uses. The five genuinely unreferenced files are redmorrow@pose35@f, redmorrow@pose78@f, redmorrow@pose87@f, redmorrow@pose93@f and redmorrow@redmorrow_p3@f.

Details of the table's shape are in The clips.lua table.

The pose ends immediately

You are passing a finite duration, or a flag that plays the clip once.

Every one of the 99 entries ships as mode = 'loop', and for good reason: this is a pose pack, not an action pack. Look at the lengths in the duration table — eight clips are 0.033 s, which is a single frame at 30 fps. Played once, a one-frame clip is over before the next frame is drawn. Ten more are 0.1 s, and 26 are 1.967 s.

To hold a pose, pass -1 as the duration argument so the task runs until something stops it:

-- argument 6 is the duration in milliseconds; -1 means no time limit
TaskPlayAnim(PlayerPedId(), dict, clip, 4.0, -4.0, -1, 1, 0.0, false, 0, false, 0, false)

Then stop it deliberately when you are done:

ClearPedTasks(PlayerPedId())            -- full-body pose
ClearPedSecondaryTask(PlayerPedId())    -- a pose layered over movement

RDR3 flag values are not GTA V's

TaskPlayAnim in RDR3 takes thirteen arguments, and its flag words do not mean what the same numbers mean in GTA V. Copying a flag value out of a FiveM snippet is a reliable way to get a pose that plays wrong or not at all. Start from the 13-argument call above and read the RedM platform notes before you change the flag.

mode and duration are metadata, nothing reads them

clips.lua is a table, not a player. The mode = 'loop', duration and rootMotion fields describe how each clip is meant to be used — they are a note to whoever writes the playback code. Nothing in the pack reads them, so setting mode = 'once' on a row changes nothing by itself.

The duration figures were also written by the author rather than read out of the .ycd. If a clip looks longer or shorter than the table says, trust the game; GET_ANIM_DURATION gives you the real figure.

The pose plays but the character stays put

That is correct behaviour. All 99 entries are rootMotion = false — no pose in this pack moves, walks or turns the character. They are stationary poses, authored in place, which is why they loop cleanly.

If the character appears to slide while the pose plays, the movement is not coming from the clip:

Cause	What to do
The ped still has momentum from running	Let it come to a stop before starting the pose
You layered the pose over a movement task	Use ClearPedTasks first, or accept the blend
The ped is on a slope or on a moving entity	Expected; the clip does not fight physics
Another script is issuing a task	Stop that animation first — the last task wins

It looks wrong on a male character

This is a female-only pack. Every row carries bodies = { female = '<dict>' } and nothing else; no male variant ships anywhere in the download, and the dictionaries all end in @f.

The clips will play on a male ped — animations target the skeleton, not the model — but they were authored for female proportions, and arms, hips and hat positions usually land visibly off. There is no male dictionary to switch to, and no option that corrects it. If you gate poses by character gender, gate them on your own side.

My emote menu does not list them

The pack does not write itself into another resource's config or database. It streams assets; adding them to a menu is your step.

Add the dict and clip pairs from the animation list to your emote resource's own list — for RedM Emotes that is described under three ways to add an emote. The general shape is in Integrating.

It works in a test script but not in the emote menu. Either the emote system holds different dict/clip values than the ones in clips.lua, or it started before this pack did. Compare the strings character by character first — a missing @f fails identically in both places.

A stutter the first time a pose plays

The dictionary streaming in. The whole stream/ folder is 452 KB across 104 files, so each individual load is small, but the first request for a given dictionary still has to fetch it.

Later plays of the same pose are instant. If the very first play has to be smooth, call RequestAnimDict ahead of time — when a photo-mode opens, for instance — and leave the dictionary loaded.

There is no server-side cost to investigate: server.lua is a single print, with no events, no database queries and no ticks.

Still stuck

Collect this before asking for help:

1. Your server console output from when the resource started, including the [redmorrow] line or the error that replaced it.

2. The exact ensure line from server.cfg, and the exact folder name on disk.

3. The exact dict and clip strings you are using, copied from your code rather than retyped.

4. The result of DoesAnimDictExist(dict) on the client for that dictionary — true or false.

5. The snippet that plays the pose, including whether you wait for HasAnimDictLoaded.

6. Which emote resource you are integrating with, if any.

Then open a ticket on Discord.

Background reading, if the pose code itself is new ground: Animation Basics and the RedM platform notes.