Installing RedM Guidebook

Three steps, and only the last one differs by framework.

1. Add it to server.cfg, after your framework:

   ensure rm_guidebook

2. Grant yourself staff:

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

3. Read the page for your framework.

Not sure which framework you are on? Install nothing yet, start the resource, and read the first line it prints:

[rm_guidebook] framework: VORP Core

That is what the resource itself detected, and it is the answer that matters — it probes what is actually running, not what is in your config.

1. server.cfg

Put it after your framework. The bridge probes at start-up rather than at load, so it binds correctly either way, but the wrong order gives you a confusing first line in the console and no reason to trust it.

There is no framework dependency in the manifest, on purpose

Naming one would stop the resource starting on the other three. The manifest declares only dependency 'oxmysql'.

oxmysql is required and is the only library this resource needs. If your framework runs, you already have it.

2. The database

Nothing to do. The three tables are created on first start if they are missing, and the almanac writes itself a welcome chapter so it is not empty the first time someone opens it.

Table	Holds
rm_guidebook_chapters	Chapters
rm_guidebook_entries	Entries and their text
rm_guidebook_signposts	Signposts in the world

If you would rather see the schema before it lands, or your database user cannot create tables at runtime, run install/schema.sql yourself first. Every statement in it is CREATE TABLE IF NOT EXISTS, so running it again after an update is safe — it never drops and never alters.

To stop the welcome chapter being written on a fresh database, set this before the first start:

-- local/overrides.lua
RmGuidebook.Local = { seed = { demo = false } }

Full schema in Database.

3. Staff

Staff is who may open the press — the authoring overlay — and who may write, strike and hand pages out. It is checked on the server every time the press is opened and again on every verb the overlay sends, so a client that lies to itself about being staff still gets nowhere.

The ACE works on every framework and on none:

add_ace group.admin rm_guidebook.press allow

Three independent checks run and any one passing is enough: that ACE, your framework's own group names (admin, superadmin, owner by default), and — on frameworks that answer permissions rather than groups — the framework's permission call.

add_ace alone is not enough

The commonest cause of "the press is not yours to run" is the principal, not the ace. Both lines are needed:

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

The console (source 0) always clears the check, so the resource can be driven from rcon or a scheduled task. Turn that off with staff = { allowConsole = false } if you would rather it could not.

Which checks apply to your framework, and how to let a moderator write without letting them strike, is in Permissions & job gates.

4. Try it

Press F7, or type /almanac. Then /press to write something.

If the key does nothing, check the game's own key settings — it is a real mapping and a player may already have F7 bound to something else. The command always works, and trying it is how you tell "the key is not bound" apart from "the almanac will not open".

Want something to look at first? /almanac_demo fills the almanac with a worked example — six chapters, fifteen entries and seven signposts across six towns. /almanac_demo clear takes it away again.

5. Settings

You never edit config/. Write what you want to change into local/overrides.lua; an update will not touch it.

RmGuidebook.Local = {
    overlay = { title = 'The Blackwater Gazette' },
    keys    = { open = 'F9' },
    log     = { webhook = 'https://discord.com/api/webhooks/...' },
}

Every setting is listed in Configuration.

Standalone servers: turn the job gate off

There are no jobs on a standalone server, 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, so installing a framework later lets you switch it back on with your gates exactly as you left them.

Coming from another guidebook

If this server previously ran the FiveM guidebook resource whose tables are named rcore_guidebook_*, and those tables are still in the same database:

/almanac_migrate

It copies the categories, pages and points across, reshaping them into chapters, entries and signposts. It never overwrites — a slug already in the almanac is left alone — so running it twice is safe, and you can run it, look at the result, strike what you do not want and run it again.

Two things do not survive the crossing, because they have no equivalent in RedM:

	Why
Blip sprites	The old resource stored FiveM sprite numbers; RedM addresses blips by name. Every migrated signpost gets blip_poi and you pick a real one in the press
Marker types	Same reason. Everything becomes a cylinder

Everything else — titles, order, hidden flags, job permissions, page text, positions, colours, sizes, draw distances, and which page a point opens — comes across as written.

Verifying the install

Run this and read the four blocks it prints:

/almanac_debug

It reports what bound, what the database holds, what the overlay and the wire look like, what the caller may do — and then a list of everything that is perfectly legal but almost certainly not what you meant.

Next

• Commands & keys — what each one does and who may run it
• The press — writing your first chapter
• Permissions & job gates — limiting a page to a job