30+ Dances Troubleshooting

Reports about this pack fall into two groups, and they are diagnosed in opposite directions.

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 anywhere.

Work out which group you are in before changing anything. The complication specific to this pack is that a healthy start looks like silence, so the absence of a message proves nothing on its own.

What the resource can tell you

Nothing. That is not a figure of speech.

redmorrow2 has no scripts of any kind. This is the whole resource:

Path	Escrow	What it does
fxmanifest.lua	open	Declares game 'rdr3', lua54 'yes', escrow_ignore and dependency '/assetpacks'. No client_scripts, no server_scripts
stream/	protected	2 .ycd files, 2.9 MB — [email protected] (1.44 MB) and redmorrow2@[email protected] (1.43 MB)
clips.lua	open	A data table of 34 rows. The manifest never loads it
README.md, CHANGELOG.md, docs/*.md	open	Documentation

Three consequences follow, and between them they explain most of the tickets on this pack:

• The pack prints no start-up line of its own. There is no server.lua to print one.
• clips.lua is never loaded. Config.Clips does not exist at runtime, on the client or on the server, and clients never download the file. It is a reference document that happens to be valid Lua.
• stream/ still works. CFX picks up a stream/ folder automatically without a manifest entry, which is why a resource with no scripts at all delivers 34 working dances.

So every diagnosis below is made from the ordinary FXServer console output and from your code. There is no client-side logging, no chat feedback and no error message from the pack, because there is no pack-side logic to produce any.

The folder and the manifest name agree

The folder ships as redmorrow2 and fxmanifest.lua declares name 'redmorrow2'. Both spellings are the same, so ensure redmorrow2 is correct, and LoadResourceFile takes redmorrow2 as well.

You lack the required entitlement to use redmorrow2

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 — redmorrow2 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. The check runs before anything in the folder is read, and there is no setting to change — clips.lua is not even loaded on a healthy start, let alone a failed one. Use a server key from the buying account, or have the asset transferred to the account that owns the key.

Asset packs are a second check on the same key

fxmanifest.lua declares dependency '/assetpacks', which is a Cfx.re licence-key entitlement check rather than a dependency on another resource. The pack streams 2 .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. Full first-run sequence on Installation.

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.

In this pack the protected set is small — stream/ and the .fxap file, and nothing else. 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 with two 1.4 MB .ycd files it usually damages both at once.

2. An edit to a protected file. Opening and re-saving a .ycd is enough to break verification, even with no visible change. Never edit stream/ or the .fxap file.

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 redmorrow2.

The .fxap file is in your download, not in the dev copy

.fxap is added when the asset is published, so a customer download contains it and a development copy does not. If you compared your folder against a listing that has no .fxap, nothing is wrong — leave the file alone.

What you are allowed to edit

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

Couldn't find resource redmorrow2

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/redmorrow2/redmorrow2/fxmanifest.lua     wrong
resources/redmorrow2/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 redmorrow2-1.0.0.

A folder name that does not match the ensure line. Keep the folder lowercase and without spaces:

ensure redmorrow2

A resource inside a bracketed group folder — resources/[animations]/redmorrow2 — 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 redmorrow2

The console shows nothing when the resource starts

Expected, and not a fault. There is nothing to print.

The pack has no server.lua and no client script, so the only line the server console produces is FXServer's own:

Started resource redmorrow2

That line, with no red errors after it, is a healthy start. The two .ycd dictionaries in stream/ are now being served to joining clients.

Nothing happens in game yet, and that is also correct

A successful start is invisible from inside the game. There is no key to press and no command to type. Until an emote menu or your own code calls TaskPlayAnim, the two dictionaries sit on the client unused. See There is no menu, no command and no keybind.

If you want positive confirmation rather than an absence of errors, ask the game instead of the console. From F8 on a client, inside your own resource:

print(DoesAnimDictExist('redmorrow2@dance'), DoesAnimDictExist('redmorrow2@dance@f'))

Two true values mean the stream reached that client, which is the thing you actually wanted to know.

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 = 'redmorrow2@dance'
local clip = 'moonwalk'

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 Started resource redmorrow2 in the server console, with no red errors after it? Remember that the pack adds no line of its own.

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

3. Did you refresh after copying the folder in?

4. Is the dictionary spelled redmorrow2@dance — singular dance, not redmorrow2@dances?

5. Is the clip name copied out of clips.lua or the dance list, rather than typed out from a label?

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

There are only two dictionary strings to get right

redmorrow2@dance and redmorrow2@dance@f. All 34 dances live in those two, under identical clip names, with no per-dance dictionaries and no exceptions — see Two dictionaries, that is all.

The female one has two @ symbols. A dropped @f, or a typo anywhere in either string, produces exactly the symptom above: silence.

Config.Clips is nil in my resource

Expected, and for a different reason than on other animation packs.

fxmanifest.lua has no client_scripts and no server_scripts entry at all, so clips.lua is never loaded — not into the pack's own Lua state, and not into anyone else's. Config.Clips does not exist at runtime anywhere on the server, and clients never download the file. The pack also declares no exports and no events, so there is nothing to ask.

Two ways round it:

Approach	When to use it
Copy the 34 rows into your own resource	You are going to rename labels and categories anyway
Load the file from disk 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. LoadResourceFile is server-side, so read it on the server and send it to clients over an event:

-- Server side. Returns redmorrow2's Config.Clips, or an empty table.
local function getDanceClips()
    local src = LoadResourceFile('redmorrow2', 'clips.lua')
    if not src then return {} end
    local env = { Config = {} }
    local chunk = load(src, '@redmorrow2/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. Here that is redmorrow2, which is also the manifest name, so the two cannot disagree — change it only if the folder was renamed on your server. The full server-to-client pattern is on Scripting the pack.

Do not put a client_scripts line into fxmanifest.lua to fix this

The manifest is not escrow-protected, so an edit will not trip verification — but it will not help either. Loading clips.lua inside redmorrow2 sets Config.Clips in that resource's Lua state only, and CFX gives every resource its own state, so your code still cannot see it. It also makes clients download a 10 KB table they have no use for. Read it from disk instead.

There is no menu, no command and no keybind

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

The whole resource is fxmanifest.lua, two .ycd files, a data table and some Markdown. There is no client.lua, no server.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 34 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 Scripting the pack

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.

My menu shows one undifferentiated list of 34

The category field is flat. Every one of the 34 rows carries category = 'dance', so a menu built straight from that field gets a single list of 34 entries with no grouping.

The breakdance / hip hop / party split exists only as prose in the resource's own server owner guide. It is not a field you can read. It is, however, exact and complete — 20 + 6 + 8 = 34, and every clip is in exactly one group — so it is worth applying by hand.

Either rewrite category in clips.lua, or group them in your menu's own config. label, category, mode and walk are yours to change; dict and clip are not, because they have to match the names stored inside the .ycd files. See what you may change, and the per-group tables on the dance list.

Editing clips.lua does not edit your emote menu. The two lists are separate, and in this pack the first one is not even loaded — change the names in your menu's own config too.

A floor move snaps to the ground

The blend-in is too fast for a clip that starts lying or sitting on the floor.

Six moves begin on the ground rather than standing, and clips.lua gives each of them blendIn = 2.0 — roughly half a second — instead of the 4.0 everything else uses:

ID	Name	Length
crossleg_freeze	Crossleg Freeze	2.033 s
flair_1	Flair (1)	1 s
breakdance_footwork_1	Breakdance Footwork 1	3.167 s
breakdance_footwork_3	Breakdance Footwork 3	4.567 s
breakdance_footwork_to_freeze	Breakdance Footwork To Freeze	3.667 s
breakdance_footwork_to_idle	Breakdance Footwork To Idle	9.6 s

All six are in the breakdance group. A lower blend-in number is a slower blend, so the character eases down instead of snapping to the floor:

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

In code, read the field off the row and fall back to 4.0:

TaskPlayAnim(ped, dict, entry.clip, entry.blendIn or 4.0, -4.0, -1, 1, 0.0, false, 0, false, 0, false)

If your emote menu exposes a blend-in setting, use 2.0 for these six and leave the rest at 4.0. If it does not, they still play — they arrive hard instead. More on Floor moves.

blendIn is the only optional field this pack uses

The clips.lua format also allows walk and flags per row. No row in this pack sets either, so every playback decision beyond the blend-in is yours.

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.

Body	Dictionary
Male	redmorrow2@dance
Female	redmorrow2@dance@f

The female dictionary is the male name plus @f, with identical clip names inside. All 34 dances are in both, and there are no exceptions anywhere in the pack.

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, because 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 end up on the @f dictionary. Full version on Scripting the pack.

If your emote menu cannot store two dictionaries for one entry, add each dance twice — "Moonwalk (M)" and "Moonwalk (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 34 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.

Four dances run under a second and a half

flair_1 at 1 s is the shortest in the pack, followed by moonwalk at 1.033 s, wave_hip_hop_dance_1 at 1.167 s and breakdance_ready at 1.433 s. Played once they are over almost before they are drawn, and looped they read as a repeating beat rather than as something with a beginning and an end.

Look at those four on screen before putting them in a menu. For contrast the median is 4.133 s and bellydancing runs 25.367 s. The full spread is on the dance list.

mode and duration are metadata — nothing reads them

clips.lua is a table, and in this pack it is a table nobody loads. 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 the GTA V ones

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.

TaskPlayAnim(ped, dict, clip, blendIn, blendOut, duration, flags, startPhase,
             phaseControlled, ikFlags, p10, taskFilter, p12)

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, and walk = true adds 8 + 16. 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.

Check first whether a copied flag word contains ABORT_ON_PED_MOVEMENT (32), which stops the clip deliberately the moment the ped moves. No row in this pack asks for it, so if it is in your flags it came from somewhere else.

Upper-body play is the wrong answer on this particular pack

The usual fix is to play the dance in the secondary task slot on the upper body only, flags 1 + 8 + 16 = 25, so it layers over the walk cycle instead of replacing it.

These 34 moves are full-body, breakdance especially — twenty of them are breakdance. A move whose whole character is in the legs and the floor contact loses its shape entirely when only the spine and arms play, and flair_1, headspin_start or any of the seven freezes look broken rather than layered. If you use 25 at all, use it per dance after looking at it, not across the list.

Two things to know if you do 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, so the choice is entirely yours at playback time and no row is marked as suitable.

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.

Only part of the dance plays

The legs are idle, the arms are moving, and the whole thing reads as a glitch. That is flags 25 doing exactly what it says on a clip that cannot survive it.

UPPERBODY (8) plays the spine and arms only, and SECONDARY (16) layers it over whatever the ped is already doing. On a wave or a tut that is a reasonable trade. On a breakdance footwork sequence or a freeze there is nothing left, because the move is the lower body — and flair_1, crossleg_freeze and the four breakdance_footwork_* clips additionally expect to start on the ground, so the standing lower body fights the pose.

Drop back to flags 1 and the dance plays in full:

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

If a GTA V flag word was copied in, recheck it against the table in RDR3 flag values are not the GTA V ones. A value that happens to include 8 or 16 produces this symptom without anyone intending to ask for upper-body play.

Players still see the old version after an update

Three layers cache, and they clear in this order:

1. The resource. restart redmorrow2 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, and with only two dictionary names in this pack every update is that case. Nothing on the server can force a client to re-fetch a file it believes it already has.

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 2.9 MB across two files, about 1.4 MB each, so the first request for one is a real download on a cold client.

Later plays of any dance from the same dictionary are instant, and since all 34 share two dictionaries, one play warms the whole pack for that body. 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 scripts at all, so it measures 0.00 ms on both the client and the server: no loops, no threads, no events, no database queries. Players download about 3 MB of animation files once and the files are cached after that, and a dictionary only occupies memory when something plays it.

Can it conflict with the other dance pack?

No. redmorrow2 and rm_dance_24 use different dictionary names — redmorrow2@dance against redmorrow_dance_24@dance and the dnac@ ones — so both can run on the same server with nothing to reconcile. The sibling pack is documented at 24+ Dances.

If you run both, note that the two clips.lua files are loaded differently: rm_dance_24 loads its own as a client script, this one is never loaded at all. Code written against one does not transfer unchanged to the other.

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 Started resource redmorrow2 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 dictionary and clip strings you are using, copied from your code rather than retyped, and the result of DoesAnimDictExist(dict) for that dictionary.

7. The full flags argument you passed to TaskPlayAnim, as a number.

8. 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.

Licensing questions — which servers may run the pack, what you may edit, what you may not redistribute — are answered in the customer guide inside your download, under What you may and may not do. Bring your transaction ID for anything that needs checking against your account.

If the playback code itself is new ground, start with Animation Basics, then Scripting the pack and the RedM platform notes. Shorter answers are on the FAQ.