RivalityFX Docsrivalityfx.com ↗

Creating for RivalityFX

RivalityFX isn't just a server you run — it's a platform you create for. Every kind of content is a standalone resource that plugs into a stable, versioned SDK contract, so you can build it without touching the core, ship it on its own, and give it away or sell it.

This is the creator's entry point. Pick what you want to make:

You want to create…It is…Start here
A game modeA PvP ruleset (teams, rounds, win conditions) registered as a plain-data descriptorGame modes →
A mapA battleground for the shared map pool, or one bundled exclusively with a modeMaps (battlegrounds) →
Ped skinsCharacter models grouped into a cosmetic packSkins & cosmetics →
OutfitsStreamed clothing on the freemode rig — same hitbox as everyone, sharper lookAuthoring an outfit pack →
Weapon wrapsWeapon tints — the same pack system, a different item kindSkins & cosmetics →
A splashLoad-screen art — an image, a video, or a full animated NUI bundle — shown at random while players connectLoad screens →

How creation works

Three ideas hold across every content type:

  1. A creation is its own resource. A mode, a cosmetic pack, an arena pack — each lives in its own folder under a bracketed group ([modes]/, [packs]/, …) and is switched on with a single ensure in server.cfg. It carries its own config and assets, so it travels as a unit.

  2. You register against the SDK, not the engine. Modes, packs, battlegrounds, and splashes are plain-data descriptors handed to the sdk resource (exports.sdk:registerMode / registerPack / registerBattleground / registerSplash); the engine, customization, and the loadscreen consume them. Because a descriptor is data — validated against a versioned apiVersion contract, serializable, carrying no arbitrary code — it is safe to distribute and to load.

  3. The floor is zero code. The simplest mode is a structure + a declarative rules block; the simplest skin pack is a list of model ids. You only drop to imperative Lua (a tick, a driver, hooks) when the declarative surface genuinely runs out.

The golden rule underpins all of it: one scene = one mode = one routing bucket, so two matches — or two different creations — can never interfere. See the introduction.

Distributing & selling what you make

"Mettre à disposition" is a first-class concern, not an afterthought. Because every creation is a self-contained, versioned resource, you can ship it three ways:

  • Free / open — the example packs ship MIT (cosmetic_pack_base, battleground_pack_base, mode_duel, splash_pack_base, splash_pack_aurora). Copy one, change the data, share the folder.
  • Standalone paid — a cosmetic pack declares a sku (a Tebex package id) and becomes a one-off purchase. The store/webhook map the sku → ownership; the in-game menu shows a Buy CTA.
  • VIP-included — a pack marked access='vip' unlocks with the subscription.

The last two are the per-player cosmetic model — a sku/VIP entitlement gates an item for the buyer. Resources without per-player ownership — modes, maps, and splash packs — sell as the resource itself: the operator installs it and it's live for everyone, the way any premium FiveM resource is distributed. (A splash's sku/access fields are reserved for a future per-player layer.)

Crucially, monetization is cosmetic-only — never pay-to-win. You sell looks (ped skins, outfits, weapon wraps, splash art) and privileges (VIP perks), not weapons or match advantages. The whole sale model, the Tebex pipeline, and what VIP grants are on the operator side: Selling VIP & packs.

A creation can also ship a presentation block — hero art + info/buy links the in-game unlock panel renders — and serve its thumbnails from a CDN, so a paid pack presents richly without bloating its descriptor.

The catalogue of contracts

Each creation type has its own SDK contract and reference: