Multicharacter Selector Troubleshooting

Turn debug on before anything else. Set ConfigSelector.Debug = true in config_selector.lua and restart, or type /selectordebug in game. Almost every symptom below has a console line behind it, and the line usually names the fix.

Nothing in this resource is escrowed — every .lua file is readable and editable — so when a console line points at a file, you can open it and look.

The selection screen does not open, or opens with the wrong weather

Both symptoms are weathersync, and which one you get tells you which half is wrong.

StartSwapCharacters() in client/client.lua stages the screen every time it opens, and it calls three weathersync exports unprotected:

exports.weathersync:setSyncEnabled(false)
exports.weathersync:setMyWeather(options.weather.type, options.weather.transition, options.weather.snow)
exports.weathersync:setMyTime(options.time.hour, 0, 0, options.time.transition, true)

If weathersync is missing, or starts after vorp_character, that call throws and the screen never finishes staging. You get a spinner, a loaded ped and no interface.

The scene's own environment pass is the polite half. SelectorScene.ApplyEnvironment checks the resource state first and gives up quietly:

[vorp_character] weathersync is not running, skipping environment

That line means the screen opened and the sky simply did not change.

Order in server.cfg:

ensure oxmysql
ensure vorp_core
ensure vorp_menu
ensure vorp_inputs
ensure weathersync
ensure vorp_character

There is no dependency block in the manifest

A missing requirement surfaces as a Lua load error in the server console, not as a friendly message naming what is absent. Read the first error on start, not the last.

The camera goes black

ConfigSelector.Scene.dof.enabled = false

Depth of field ships off for exactly this reason. On some builds and some locations the blur planes collapse and the frame goes black rather than soft. If you switched it on and the camera went dark, switch it back.

The planes are nearStart 0.2, nearEnd 1.4, farStart 4.5, farEnd 9.0 with strength 1.0. Widening them is worth a try before giving up on the effect, but false is the supported answer.

A character or partner floats or sinks

Three separate causes, in the order they are worth checking.

A height read off the ground

spawn.z is the ped's origin, roughly 0.9 m above the feet — not foot level. A z value taken from the ground sinks the character by about that much, and a z taken from a ped's head floats it.

The resource places with SetEntityCoordsNoOffset throughout. SetEntityCoords lifts a ped by that same amount, which is the other half of the same confusion.

A raw clip carrying its own height

Scenario poses are placed, grounded and looped by the engine and cannot float. Raw clips are played directly on the ped and bring the height of the set they were authored on. See three kinds of pose, and why the difference matters.

This is not corrected automatically, and the reason is worth knowing: moving a ped cancels its current task, so nudging a posed ped downwards would stop the pose. The resource measures instead and asks you to write the number down.

With debug on, show the pose and read the console:

[vorp_character] KIT_EMOTE_GREET_FANCY_BOW_1 sits 0.128m off the ground; add that to clipOffsets to fix it

/selectordump gives the same thing as a verdict and a line ready to paste:

  VERDICT                FLOATING 0.13m ABOVE the ground
  FIX                    ["KIT_EMOTE_GREET_FANCY_BOW_1"] = 0.128,

It goes in ConfigSelector.Partner.clipOffsets, which already ships two worked examples:

clipOffsets = {
    ["KIT_EMOTE_GREET_FANCY_BOW_1"] = 0.128,
    ["MP_LOBBY_SCENARIO_06"]        = 0.116,
},

Positive lowers the ped	A reported 0.128 is written as 0.128
"dict/anim"	Pins one clip in one dictionary
"anim"	Any dictionary. Scenarios and kit emotes have no dict, so they use this form

/selectoroverlay draws the ground height, the gap and which clips are playing on screen every frame, which is faster than reading the console while you adjust.

Nothing you want to debug

ConfigSelector.ScenariosOnly = true

Hides every non-scenario pose, solo and partner, everywhere. The remaining poses are grounded by the engine and cannot float. It is a blunt instrument and it is also the fix that always works.

A duo pose marked needsProp expects furniture

Set ConfigSelector.Partner.allowPropPoses = false to hide the poses written for a bench, rail or campfire, rather than chasing the height of a character sitting on nothing.

A pose plays and then stops

Three different things look identical on screen.

What you are seeing	Why
A short action, a pause, the same action again	A kit emote. They are one-shot and replayed on repeatMs, 5000 to 9000 ms in the shipped rows. A missing or long repeatMs is the gap
A clip that plays once and leaves the ped standing	A raw clip whose flag does not loop. RDR3's TaskPlayAnim takes thirteen arguments and its flag values are not GTA V's, so a flag copied from a FiveM script is a coin toss. The shipped rows use flag = 1
A pose that dies the instant you touch the character	Moving a ped cancels its task

The third is the one that catches builders out. In the Scene Creator, pressing Place or Here on a slot whose stand-in is mid-pose cancels the clip; the editor re-applies it, which resets a held frame or a phase you had set.

Position first, pose second

Never capture a position while a pose is running. Set the slot's spawn and heading, confirm it, and then pick the pose.

The Scene Creator is stuck with no mouse or keyboard

F9

ConfigCreator.EscapeKey, RawKeys.F9 by default. It is read as a raw Windows key code rather than a game control, so it still works when the panel has NUI focus and chat cannot be opened.

F9 deliberately only fires while the editor is open — closing it at any other time would also release the selection screen's focus.

If F9 does nothing, type this in the F8 console:

scenecreatorclose

It answers with editor closed and focus released.

F9 needs IsRawKeyPressed on your build

If the native is missing, the resource says so once on start and tells you the only remaining exits are the panel's close button and the console command. If you saw that line, do not wait for F9 to save you.

Before you close it, two commands are worth running while it is still broken. /scenedump prints the editor's mode, focus, camera and whether the adjuster is active. /scenekeys watches for 10 seconds and prints, for every editor key you press, whether the control, disabled and raw read paths see it.

The Scene Creator will not open

1. Is ConfigCreator.Enabled true and ConfigCreator.Command set? If either is missing the command is never registered, so it is not that it refuses — it does not exist.

2. Is your character's VORP group in ConfigCreator.AdminGroups? Default { "admin" }. A refusal here is a notification reading You are not allowed to use the scene creator, and every save is re-checked on the server regardless of what the panel let you do.

3. Is the character selection screen still up? This is the usual answer. The editor refuses while the selector owns the camera and NUI focus, and the refusal goes only to the F8 console:

   [vorp_character:creator] close the character selector first

   Nothing appears on screen, which is why it reads as a command that did nothing. Spawn in first.

A new scene does not show up for players

1. Is the chip beside its name switched LIVE? A saved scene that is not live is not in the rotation.

2. Is ConfigCreator.ApplyToSelector true? With false, database scenes never reach the selector at all and only count once pasted into config_scenes.lua.

3. Run /scenedebug. It validates the loaded scene and lists its problems. An invalid scene is skipped silently in the rotation, and this is where it tells you why.

4. Open the screen a few more times. The server picks one location at random per open. 13 ship — 11 in Config.SpawnPosition and 2 in ConfigScenes.List — so one new live scene is roughly a 1 in 14 chance per open.

No restart is needed, and that is by design: the server broadcasts vorp_character:creator:scenes and the client applies it through SceneRuntime.Apply. If you are restarting the resource to see a scene, something above is wrong rather than slow.

ReplaceConfigScenes is false

Live scenes are added to the 13 shipped locations, not substituted for them. Set ConfigCreator.ReplaceConfigScenes = true to make your own scenes the whole rotation. It needs ApplyToSelector, and it is ignored while no scene is enabled, so you cannot lock yourself out of every location.

Props vanished from an exported scene

Working as designed. The Export tab and the database do not carry the same things.

	Database — Save and LIVE	config_scenes.lua — Export tab
Cameras, character slots, poses, weather, time, music	Yes	Yes
Props, wagons, NPCs	Yes	No
Camera travel	Yes	No
Reaches players	At once, no restart	After a restart

A scene with props, wagons, NPCs or a camera travel path has to stay saved and LIVE. Export it as well if you want the camera work in a file, but the database row is the real scene.

A scene that is both LIVE and pasted into config_scenes.lua appears twice

It is counted once from each source, so it comes up twice as often as everything else in the rotation.

Players cannot find each other in the partner search

Both players need the character selection screen open. The candidate list is built from exactly the set of players who are currently on that screen, minus yourself, and nothing else — not from everyone online.

A player who presses Play leaves that set immediately. So does a disconnect, which also cancels their pending requests.

Other refusals and what they mean:

The name was there and the send failed	They left the screen between the list being drawn and your pressing send
A request vanished on its own	Partner.requestTimeout, 60 seconds, swept every 5 seconds
A send is refused outright	That character is already paired. Each character can have one partner — unpair first
No panel at all on P	ConfigSelector.Partner.enabled is false

The pose editor says you are not allowed

There are two refusals and they are not the same problem.

Message	Means
you are not allowed to use the pose editor	Group and ace. Add your VORP group to ConfigSelector.Partner.editor.groups, default { "admin" }, or give yourself the ace in editor.ace, default command, which txAdmin admins already have. ace = false means groups only
the pose editor is turned off in config_selector.lua	editor.enabled is false. No permission will help

Both are checked when you open the editor and again on every save, so an editor that opened and then refuses to save is a group that changed under you, not a bug.

The editor also needs a character that actually has a partner showing on screen. Open the F8 console, type partneredit, close F8.

Edits to the pose lists appear to do nothing

Four things can quietly outrank animations.lua.

partner_poses.json wins

Saves from the pose editor live in partner_poses.json in the resource folder, and they are applied on load whether or not the editor is open, overwriting the attach on every entry they match. If you see this on join, the file is in charge and your edits to animations.lua are being replaced:

[vorp_character:poseeditor] 7 duo pose(s) set with the pose editor

Entries are matched by label. Rename a pose's label in animations.lua and its saved row stops matching, which looks exactly like a lost save. To hand control back to the file, remove that entry from the JSON — or the whole file — and restart.

Each save also prints its attach line in F8, ready to paste into animations.lua if you would rather keep the numbers there. See the pose editor.

ScenariosOnly is hiding it

A new emote or kitemote row will not appear anywhere while ConfigSelector.ScenariosOnly = true.

Animations.source is not reading your list

ConfigSelector.Animations.source defaults to "merged".

source	Players get
"slot"	Only the scenarios the location defines for that position. Animations.list is never read
"global"	Only Animations.list
"merged"	The location's scenarios first, then Animations.list

perLocation is filtering it

ConfigSelector.Animations.perLocation restricts the list per location, for example [3] = { "smoke", "lobby_02" }. A row you added is absent at that location and present everywhere else. The location's own scenarios are always kept regardless.

The panel looks stale after an edit

CEF caches the page's files by URL. Raise the ?v= number on the tag you touched, in html/index.html:

scale.js?v=46    style.css?v=46    creator.css?v=46    app.js?v=49    creator.js?v=46

Those are the numbers that ship. Change app.js and raise its number only; the others do not need to move.

A new file under html/ also needs a line in the manifest

client_scripts and server_scripts use client/*.lua and server/*.lua, so a new Lua file in either folder loads on its own. The files block is not a wildcard — every page asset is listed one by one, and an unlisted file 404s in the panel with nothing in the server console.

Keys do nothing while the panel has focus

This one is for extending the resource rather than running it.

While the NUI page has focus, IsControlPressed stops reporting. That is RedM behaviour, not a bug in the resource, and it is why a hand-rolled key check works in the world and dies the moment a panel opens.

Read path	Under NUI focus
IsControlPressed	Stops reporting
IsDisabledControlPressed	Still reports held keys
IsRawKeyPressed with the Windows codes in RawKeys	Always works

The Scene Creator calls DisableAllControlActions(0) in its fly, place and adjust modes — its own keys are also game keys, Tab and Space among them — and then reads the disabled and raw paths. shared/redm_keys.lua holds RedMKeys control hashes, RawKeys Windows codes and RedMAxes.

/scenekeys

watches for 10 seconds and prints each key as control / disabled / raw. Any one column reading yes is enough. A raw column stuck on - means the build has no IsRawKeyPressed, and F9 will not rescue you either.

RegisterNUICallback adds a handler rather than replacing one

Register the same name twice and both run. Two halves of a callback firing per click is almost always this. More in the developer API.

Still stuck

Turn logging on first:

ConfigSelector.Debug = true

or in game:

/selectordebug

/selectordebug switches the client and the server together. Changing the server half needs the admin group; from the server console, run selectordebug on instead, which skips the check.

Then collect what matches the symptom:

Run	Prints
/selectordump	Config, scene, settings, characters, partner, Scene Creator and natives — the one to send if you send only one
/selectornatives	Which scene natives your build exposes, and which pose path was chosen
/selectoroverlay	Ground height, foot gap and playing clips, on screen, per frame
/scenedebug	Validates the scene open in the editor and lists its problems
/scenedump	The editor's mode, focus and camera
/scenekeys	Which read path sees each editor key, for 10 seconds
/scenegizmo	What the screen projection native returns on your build

And send these with it:

Send
F8 client console	From opening the screen to the problem, not just the last line
Server console on start	Including any oxmysql error and the first Lua error, which names the missing requirement
Your server.cfg ensure order	weathersync, vorp_core and oxmysql relative to vorp_character
config_selector.lua, config_scenecreator.lua, animations.lua	With any webhook URL removed
partner_poses.json	If it exists
Your RedM server build	Developed and tested on b1491
What you expected and what happened

Support: discord.gg/w4Ew4k3Exn

See also configuration for what every key does, the Scene Creator for the editor itself, and the FAQ.