24+ Dances Troubleshooting

Reports about this pack fall into two groups. Either the resource never started, in which case the server console names the reason in one of three recognisable lines, or it started and a dance is being asked for with a name or a flag the game will not accept, which fails without printing anything at all.

Find out which group you are in before changing anything: look for the start-up line first.

What the resource can tell you

rm_dance_24 is an asset pack. Only three things in it are Lua-visible:

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 a single line in the server console at start-up:

[redmorrow_dance_24] Dance animation pack started.

If that line is there with no red errors after it, the resource started and the eight .ycd dictionaries in stream/ are being served to clients. There is no client-side logging, no chat feedback and no error message anywhere, because there is no client logic to produce any. Everything past that line is diagnosed from the server console and from your code.

The start-up line says redmorrow_dance_24, but the folder is rm_dance_24

Both are right, and the difference confuses people into renaming things.

In CFX the resource name is the directory name. The name 'redmorrow_dance_24' line in fxmanifest.lua is metadata and renames nothing — it only decides what the author's own print writes. The folder ships as rm_dance_24, so the server.cfg line is ensure rm_dance_24, and LoadResourceFile takes rm_dance_24 as well.

Writing ensure redmorrow_dance_24 matches no folder on disk and fails.

You lack the required entitlement to use rm_dance_24

The resource is Asset Escrow protected, and the server key does not belong to the account that owns it.

An escrowed resource runs only on a server whose sv_licenseKey in server.cfg belongs to the Cfx.re account that bought the resource. A key generated under a different account cannot start it, however the files got onto the server.

Check
Which Cfx.re account paid at checkout	Sign in at portal.cfx.re and look under Assets > Granted Assets — rm_dance_24 is listed there for the owning account only
Which account generated sv_licenseKey	Keys are per-account. A key from a partner's or a host's account is a different account
Whether the asset was transferred	If the server key has to stay as it is, the asset must be transferred to that account instead

Nothing in the resource works around this, and no setting in clips.lua is read before the check runs. Use a server key from the buying account, or have the asset transferred to the account that owns the key.

This is a separate check from asset packs

fxmanifest.lua also declares dependency '/assetpacks', which is a Cfx.re licence-key entitlement check rather than a dependency on another resource. The pack streams 8 .ycd files, so the requirement is genuine, and without the entitlement the resource refuses to start.

Escrow ownership and asset-pack entitlement are two different things to get right on the same key. Both have to pass before any dance exists in the game.

Failed to verify protected resource

The protected files are damaged or were edited. Escrow refuses to start a protected file whose contents no longer match what was published.

The three usual causes, in the order they happen:

1. An FTP upload in ASCII mode. ASCII mode rewrites line endings, which corrupts binary and protected files. Upload in binary mode. This is the single most common cause, and it typically damages several files at once.

2. An edit to a protected file. server.lua, everything in stream/ and the .fxap file are protected. Opening and re-saving one is enough to break verification, even with no visible change.

3. A half-finished download or a mixed folder. Files from two versions in one folder fail the same way. Replace the whole folder rather than copying files over an existing one.

Download the resource again from Granted Assets on portal.cfx.re, delete the old folder outright, upload the fresh one in binary mode, then restart rm_dance_24.

What you are allowed to edit

escrow_ignore leaves clips.lua, README.md, CHANGELOG.md, LICENSE.md and docs/*.md out of escrow, so those stay readable and editable. Editing clips.lua never causes a verification error. Which fields are safe to change is on The clips.lua table.

Couldn't find resource rm_dance_24

FXServer is looking for a folder it cannot see. Three things to check, cheapest first.

A doubled folder level from unzipping. This is the usual one. Many unzip tools create a container folder of their own, leaving the manifest two levels down:

resources/rm_dance_24/rm_dance_24/fxmanifest.lua     wrong
resources/rm_dance_24/fxmanifest.lua                 right

The rule is that fxmanifest.lua sits directly inside the folder named in the ensure line. Strip any extra level, and any version suffix the archive added such as rm_dance_24-1.0.0.

A folder name that does not match the ensure line. Keep the folder lowercase and without spaces, and keep the two spellings identical:

ensure rm_dance_24

A resource inside a bracketed group folder — resources/[animations]/rm_dance_24 — still uses the plain name in ensure. The group folder is not part of it.

No refresh after copying the folder in. A newly added resource is not picked up until the server rescans:

refresh
ensure rm_dance_24

The full first-start sequence is on Installation.

Nothing happens when a dance plays

The character stands there. Nothing is printed in the server console or in F8.

A clip requested from a dictionary that never loaded fails silently. TaskPlayAnim does not throw, does not warn, and returns nothing useful — the task is never given at all. This is the most common bug in hand-written dance code, and it always looks like the pack is broken.

Wait for the load, with a timeout, and print when the timeout expires:

local dict = 'redmorrow_dance_24@dance'
local clip = 'samba_dancing'

if not DoesAnimDictExist(dict) then
    print(('[dance] dictionary "%s" is not streamed'):format(dict))
    return
end

RequestAnimDict(dict)

local deadline = GetGameTimer() + 5000
while not HasAnimDictLoaded(dict) do
    if GetGameTimer() > deadline then
        print(('[dance] 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 the two halves of the problem come 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 and has not streamed in yet. Give it longer, or pre-request it
The dictionary loads, nothing plays	—	The clip name is not in that dictionary

Then work through it in this order:

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

2. Is ensure rm_dance_24 in server.cfg, spelled the same as the folder on disk?

3. Did you refresh after copying the folder in?

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

5. For one of the three bonus dances, are you using its own dnac@... dictionary rather than the main one? See the bonus dances.

6. Did you restart your emote menu after editing its config?

Copy the pair, do not retype it

redmorrow_dance_24@dance@f has two @ symbols and a @f suffix. A dropped @f, or a typo anywhere in the string, produces exactly the symptom above — silence. The resource's own clips.lua carries the dictionary and the clip name on every row and stays readable, so read the pair instead of assembling it.

There is no menu, no command and no keybind

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

The whole resource is clips.lua (a data table), server.lua (one print), fxmanifest.lua and eight .ycd files. There is no client.lua, no config.lua and no html/ folder, so nothing registers a key, opens an interface or listens for a chat command. No setting turns a front end on, because there is no front end to turn on.

What you get is 27 playable dances and a table naming their dictionary and clip. To put them in front of a player you need exactly one of:

Route	What you do
An emote resource you already run	Add the dict/clip pairs to its list. See Emote menus
Your own client script	A few lines of RequestAnimDict and TaskPlayAnim. See Playing a dance

For RedM Emotes specifically, the three ways of adding an entry are described under three ways to add an emote.

The sibling 100+ Female Poses pack is built the same way — assets only. The 30+ Female Poses pack is the one that does ship a menu, a command and exports; this pack does not, and nothing in it can be switched into that shape.

Config.Clips is nil in my resource

Expected. CFX gives every resource its own Lua state, so the Config global that clips.lua sets exists only inside rm_dance_24. Another resource cannot see it, and the pack declares no exports and no events to hand it over.

Two ways round it:

Approach	When to use it
Copy the rows into your own resource	You are going to rename labels and categories anyway
Load the file and read it in a sandbox	You want the pack's list to stay the source of truth

The second works because clips.lua is covered by escrow_ignore and therefore still readable on disk:

-- Returns rm_dance_24's Config.Clips, or an empty table.
local function getDanceClips()
    local src = LoadResourceFile('rm_dance_24', 'clips.lua')
    if not src then return {} end
    local env = { Config = {} }
    local chunk = load(src, '@rm_dance_24/clips.lua', 't', env)
    if not chunk or not pcall(chunk) then return {} end
    return env.Config.Clips or {}
end

If this returns an empty table, LoadResourceFile got nil: the first argument is the folder name, so it has to be rm_dance_24 and not the manifest's redmorrow_dance_24. Change it if the folder was renamed on your server.

The dance looks wrong on a female character

The male dictionary is playing. Every dance ships in two versions, and the female one is a separate dictionary.

The female dictionary is always the male name plus @f, with identical clip names inside — there are no exceptions in this pack:

Body	Main 24 dances
Male	redmorrow_dance_24@dance
Female	redmorrow_dance_24@dance@f

The three bonus dances each carry their own pair, so the @f goes on the end of their own dictionary name: dnac@chicken_dance@f, dnac@jazz_dancing@f, dnac@dancing_twerk@f.

Both versions play on either body, because an animation targets the skeleton rather than the model. The mismatched one lands visibly off around the arms and hips. Picking between them in code means reading the ped type, and there is one trap in it:

-- true when the ped uses the female body.
-- GET_META_PED_TYPE: 0 = male, 1 = female. Compare the NUMBER — 0 is truthy in Lua.
-- Falls back to IS_PED_MALE, which RedM may return as 0/1 rather than a boolean.
local function isFemale(ped)
    if GetMetaPedType then
        local ok, t = pcall(GetMetaPedType, ped)
        if ok and t == 1 then return true end
        if ok and t == 0 then return false end
    end
    local male = IsPedMale(ped)
    return not (male == true or (type(male) == 'number' and male ~= 0))
end

Testing GetMetaPedType(ped) as a boolean reports every ped as female, because 0 is truthy in Lua. That is the usual reason male characters get the @f dictionary.

If your emote menu cannot store two dictionaries for one entry, add each dance twice — "Samba (M)" and "Samba (F)" — or settle for the male version for everyone. More on both in Emote menus.

The dance stops immediately

Either the flag plays the clip once, or the clip is very short, and sometimes both.

All 27 rows ship as mode = 'loop' for a reason. To loop, pass 1 as the flags argument and -1 as the duration:

-- argument 6 is the duration, -1 means no time limit
-- argument 7 is the flags word, 1 is LOOPING
TaskPlayAnim(PlayerPedId(), dict, clip, 4.0, -4.0, -1, 1, 0.0, false, 0, false, 0, false)

With flag 0 the clip plays once and ends. On a short dance that looks identical to nothing happening.

breakdance_1990_2 is half a second long

At 0.5 s it is the only dance in the pack under a second — the next shortest is 2.033 s. Played once it is over almost before it is drawn, and looped it reads as a fast repeating twitch rather than a dance. Look at it on screen before putting it in a menu. The full spread of lengths is on the dance list.

mode and duration are metadata — nothing reads them

clips.lua is a table, not a player. mode = 'loop', duration and rootMotion describe how each clip is meant to be used; they are notes to whoever writes the playback code. Setting mode = 'once' on a row changes nothing by itself.

The duration figures were written by the author rather than measured from the .ycd. If a dance looks longer or shorter than the table says, trust the game — GET_ANIM_DURATION gives the real figure.

RDR3 flag values are not GTA V's

TaskPlayAnim in RDR3 takes thirteen arguments, and its flag values are not GTA V's. A flag word copied out of a FiveM script does not mean the same thing here, which is why a dance copied from a GTA V snippet plays once, plays wrong, or does not play.

RDR3 eScriptedAnimFlags:

Flag	Value
LOOPING	1
HOLD_LAST_FRAME	2
NOT_INTERRUPTABLE	4
UPPERBODY	8
SECONDARY	16
ABORT_ON_PED_MOVEMENT	32

Use	Flags
Loop the dance (what every row suggests)	1
Play once	0
Play once and hold the last frame	2
Loop, upper body only, the player can walk	1 + 8 + 16 = 25

The mode field maps to flags as 'loop' = 1, 'hold' = 2, 'once' = 0. Background on the platform differences is in the RedM platform notes.

The dance stops when the player moves

Normal. These are full-body animations: the movement task and the dance task want the same bones, and the last task issued wins.

If you want the player to keep walking, play the dance in the secondary task slot on the upper body only — flags 1 + 8 + 16 = 25:

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

That layers the dance over the walk cycle rather than replacing it. The trade is that only the upper body dances, so a clip whose character is in the legs loses most of its shape. Try it per dance rather than switching the whole list over.

Two things to know when you use it:

• Stop it with ClearPedSecondaryTask(ped) as well. A secondary task is not cleared by stopping the primary one.
• Nothing in this pack sets walk or flags on a row. The header comment in clips.lua documents both keys as optional, and no row uses them, so the choice is entirely yours at playback time.

Stopping a dance cleanly

StopAnimTask(ped, dict, clip, 2.0) stops that one clip — the last argument is the blend-out speed and must be greater than 0, or the call does nothing. ClearPedTasks(ped, true, false) stops everything at once. Release the dictionary with RemoveAnimDict(dict) when you are finished with it, for example in onResourceStop.

Two dances behave like the same one

You are keying on the clip name, and one clip name is used twice.

jazz_dancing is a clip name in two different dictionaries, belonging to two different dances:

ID	Dictionary (male)	Clip	Length
jazz_dancing	redmorrow_dance_24@dance	jazz_dancing	5.433 s
jazz_dancing_2	dnac@jazz_dancing	jazz_dancing	2.033 s

A menu whose rows are keyed on the clip name alone collides here: one entry overwrites the other, or both resolve to whichever was registered last. Key on the id, or on the dictionary and clip together.

jazz_dancing_2 is also the only row in the pack whose id differs from its clip. Every other one of the 27 rows has id == clip, which is exactly why code that derives the clip from the id works 26 times and fails silently on this one. Read both fields off the row instead of deriving either. Details are in the warning on the dance list.

My menu shows one group of 24 and three groups of one

The category field in clips.lua is lopsided, and a menu built straight from it inherits that shape:

Category	Rows
dance	24
Chicken Dance	1
Jazz Dancing	1
Dancing Twerk	1

The capitalisation is inconsistent between them as well — one lowercase group and three in title case. Rewriting the field is explicitly allowed: label, category, mode and walk are yours to change, while dict and clip are not, because they have to match the names stored inside the .ycd files. See what you may change.

Editing clips.lua does not edit your emote menu. The two lists are separate — change the names in your menu's own config too.

Players still see the old version after an update

Three layers cache, and they clear in this order:

1. The resource. restart rm_dance_24 in the server console, or restart the server. Replacing files on disk changes nothing until the resource reloads.

2. The server's file list. If you added or removed files rather than overwriting them, refresh before the restart so FXServer rescans the folder.

3. The player's RedM cache. Ask them to clear it. A client that already downloaded a .ycd under the same name keeps using its copy.

A dictionary that kept its name but changed contents is the case that needs step 3 — nothing on the server can force a client to re-fetch it.

When you update, replace the whole folder rather than copying files over the old one, and copy your clips.lua edits into the new file afterwards. Files from two versions in one folder fail escrow verification, which looks like a different problem entirely.

A stutter the first time a dance plays

The dictionary streaming in. stream/ is 4.0 MB across 8 files, and the two main dictionaries are about 1.9 MB each, so the first request for one is a real download on a cold client.

Later plays of the same dance are instant. If the very first play has to be smooth, call RequestAnimDict ahead of time — when a dance menu opens, for instance — and leave the dictionary loaded until you are done.

There is no server-side cost to investigate. The resource runs no loops and no threads, and measures 0.00 ms on both client and server; server.lua is a single print, with no events and no database queries. Players download the animation files once and the files are cached after that, and a dictionary only occupies memory when something plays it.

Still stuck

Collect this before opening a ticket. The first four answer most questions on their own:

1. Your server build number, shown at the top of the server console.

2. The server console output from when the resource started — the [redmorrow_dance_24] line, or the error that replaced it, copied as text rather than described.

3. The F8 client console on the machine where the dance failed.

4. Your Tebex transaction ID, which starts with tbx- and is in your receipt e-mail. Needed for anything about entitlement, escrow or downloads.

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

6. The exact dict and clip strings you are using, copied from your code rather than retyped, and the result of DoesAnimDictExist(dict) for that dictionary.

7. Which emote resource you are integrating with, if any, and whether a plain test script works where the menu does not.

Then open a ticket on Discord.

If the playback code itself is new ground, start with Animation Basics and the RedM platform notes.