RedM Guidebook Frameworks

The bridge probes at start-up and prints what it found:

[rm_guidebook] framework: VORP Core

That line is the answer that matters — it reports what is actually running, not what is in your config.

Detection order

Order	Test	Result
0	bridge.framework is not 'auto'	That value is used; the probe is skipped entirely
1	vorp_core is started	vorp
2	rsg-core is started	rsg
3	redem_roleplay is started	redemrp
4	Nothing answered	standalone

It takes the first that is started

If your framework starts after this resource it will not be found. Put ensure rm_guidebook after your framework — or name it, which skips the probe:

RmGuidebook.Local = { bridge = { framework = 'vorp' } }

If it is named and still lands on standalone, the adapter's bind() failed — the framework is running but its export did not answer. The console says so with the reason.

What actually differs

	VORP	RSG	RedEM:RP	Standalone
Detected by	vorp_core	rsg-core	redem_roleplay	nothing
Staff: ACE	✅	✅	✅	✅
Staff: groups	✅ both tables	❌ none exist	✅ admin, superadmin	❌
Staff: permission call	❌	✅ god, admin	❌	❌
Job list from	registry + characters	RSGCore.Shared.Jobs	your jobs table	your jobs table
Notices	Core.NotifyRightTip	ox_lib, then RSGCore.Functions.Notify	ShowSimpleRightText	overlay only

VORP Core

Nothing to install beyond the three steps. vorp_core is the only thing that has to be running.

Staff

VORP keeps a group in two places and they routinely disagree

Set with	Written to
/addGroup	the user row — applies to every character
/addGroupChar	the character row — that character only

Both are read here. Either one saying admin is enough. If you are not being recognised, that mismatch is almost always why.

Jobs in the access picker

Merged from two places:

• VORP's job registry — whatever your scripts registered through Core.RegisterJobs, which is also what config/jobs.lua in vorp_core declares. Grade labels come across with it.
• The characters table — every distinct job anyone actually holds. A job nobody registered still shows up on players, and gating on it is usually exactly what you want. Those get plain numbers for grade labels, because there are none to read.

Notices

RmGuidebook.Local = { bridge = { notice = 'framework' } }

Lines then arrive through Core.NotifyRightTip.

Why the built-in toast is the default

VORP's right-hand tip carries no tone of its own, so a refusal and a receipt look identical. The overlay's toast colours them differently.

Keep clonePlayer-style cloning in mind

The player's job and grade are read client-side from LocalPlayer.state.Character, and a job change is heard through a state-bag handler rather than a polling loop — so a promotion applies without a restart.

RSG Core

Nothing to install beyond the three steps.

Staff

RSG has no group column — it answers permissions instead — so of the three checks, two apply.

add_ace group.admin rm_guidebook.press allow

add_principal identifier.license:XXXXXXXX rsgcore.god
add_principal identifier.license:XXXXXXXX rsgcore.admin

Both god and admin are accepted, so an owner who granted only the higher one is not locked out. The staff.groups list does nothing here, and leaving it at its default is harmless.

Jobs

Straight from RSGCore.Shared.Jobs, with the label of each grade.

RSG keys its grades by string

['0'], ['1'] — and a numeric key [0] is a common mistake that makes the grade vanish from RSG itself as well as from here. The adapter converts string keys to numbers on the way in, so what you see in the picker is what RSG has.

Notices

ox_lib is tried first, because that is what every RSG documentation page draws with and RSG ships it. RSGCore.Functions.Notify is tried second — absent from the documentation but present on several community builds. If neither answers, the line falls back to the overlay rather than being lost.

Hot restarts are safe

RSG hands out a new core table when it restarts, and a resource holding the old one silently stops working. Both adapters listen for RSGCore:Client:UpdateObject and RSGCore:Server:UpdateObject and re-bind, so restarting rsg-core while this is running is fine.

RedEM:RP

Nothing to install beyond the three steps.

Staff

The framework keeps one group per player in its permissions table. Its own values are user, mod, admin and superadmin. Two of those are recognised by default; mod is not, on the grounds that a moderator is not automatically an editor.

RmGuidebook.Local = { staff = { groups = { 'admin', 'superadmin', 'mod' } } }

Jobs

There is no registry, so your jobs table is where the labels come from entirely:

RmGuidebook.Local = {
    jobs = {
        police = { label = "Sheriff's office", grades = { [0] = 'Deputy', [1] = 'Sheriff' } },
        doctor = { label = 'Doctor',           grades = { [0] = 'Nurse',  [1] = 'Doctor'  } },
    },
}

Worth writing out the handful of jobs your server actually gates on.

Notices

One of RedEM:RP's own notify helpers goes nowhere

RedEM.Functions.NotifyRight fires an event called redem_roleplay:NotifyRight, and nothing anywhere in the framework registers a handler for it. Every line sent through it is silently dropped. Nothing in this resource uses it.

Setting notice = 'framework' draws through redem_roleplay:ShowSimpleRightText instead, which is registered in the framework's own cl_notification.lua and works on every build seen.

Builds vary

RedEM:RP is forked more than most, and player objects in the wild carry both GetJob() and .job depending on the build. The adapter tries the method and falls back to the property, so both work.

If your fork renamed both, the job gate will simply never match and everything else carries on working — set access = { enabled = false } and report the names your build uses.

Standalone

The resource runs perfectly well with no framework at all. The almanac, the press, the signposts, the search and the directions all work exactly as they do everywhere else.

[rm_guidebook] framework: standalone
[rm_guidebook] No framework answered, so the almanac is running standalone.

oxmysql is still required — the almanac lives in the database.

Staff

ACEs, and nothing else. There are no groups to read and no permission call to ask.

add_ace group.admin rm_guidebook.press allow
add_principal identifier.license:XXXXXXXXXXXXXXXX group.admin

Turn the job gate off

This is the one thing worth changing, and it matters

There are no jobs, so every job-gated record is closed to everyone. That is the correct answer to "may this player, who has no job, read a leaf limited to the sheriff" — but as a default it means a gate switched on by accident hides a chapter from the whole server with no way to notice.

RmGuidebook.Local = { access = { enabled = false } }

The blocks are kept, not erased. The press still shows the access controls, with a note that they are currently doing nothing.

Adding a framework later

Nothing here is written in a way that has to be undone. Install the framework, start it before this resource, and the bridge finds it on the next restart — the almanac, its chapters and its signposts are untouched. Turn access back on when your jobs exist.

Something else entirely

Anything unrecognised falls back to standalone, which uses ACEs for staff and the characters table for the job list. That is enough for most custom cores.

For proper integration, an adapter is one file and four functions — see Adding a framework. Open Source customers can add it directly; escrow customers should ask on Discord, and it can ship as an adapter in a future update.