What It Can & Can't Build
The kinds of features myRP.build generates well, and what's out of scope by design.
myRP.build writes code resources for the ox_overextended stack. Knowing where that line is saves you from prompts that can't succeed.
What it builds
Complete, self-contained ox_overextended resources, including:
- Server, client, and shared Lua — the full logic of a feature.
fxmanifest.lua—fx_version 'cerulean'with the ox dependencies the resource actually uses.config.lua— the knobs (coords, prices, cooldowns, item names) pulled out so you can tweak them.- SQL schema when a feature needs to persist data — and it applies it to your database for you.
- NUI (HTML/CSS/JS) when a feature needs a custom interface beyond ox_lib's menus and dialogs.
Everything is server-authoritative by default — money, items, and state are validated on the server, so clients can't bypass them.
ox_overextended only
Every generation targets the Overextended ecosystem — ox_core, ox_lib, ox_inventory, ox_target, oxmysql. It will never generate ESX, QBCore, or QBox code, and never uses mysql-async. This is by design; see the Overview.
What's out of scope
myRP.build generates code, not game assets or other people's frameworks. It does not create:
- Maps or MLO interiors — it can write logic that uses a location, but it doesn't build the 3D space.
- 3D models, vehicles, clothing, or audio — streamed assets are not code; bring your own.
- Other frameworks — no ESX/QBCore/QBox ports or bridges.
- Anti-cheat systems.
Two things worth knowing:
- Custom items aren't auto-registered. If a feature uses a new inventory item, the generated code will reference it, but you add the item to ox_inventory's item data yourself. See Database & Items.
- It won't produce an empty resource. If a request can't be built, the app tells you why in a sentence rather than generating a stub.
If you're unsure whether something is in range, the fastest answer is to describe it and see — and refine from there.