The big picture
- Server-authoritative. Clients send intent through validated net events and callbacks. The server computes results.
- Headless. ug-core never draws. Players see results through UI resources that listen to events and statebags.
- Read-heavy data replicates through statebags: loaded state, death state, job, gang, session.
Boot sequence
ug-core boots in a thread, so modules can wait on the database.1
Booting
The banner prints. ug-core discovers modules from
ug_module entries in its manifest and validates each module.lua.2
Configured
config/core.lua, config/guard.lua and config/modules.lua load. Enabled modules are resolved, dependencies checked, cycles rejected, and each enabled module’s config is generated and loaded.3
Initializing
ug-core waits for oxmysql (at most 30 seconds), checks the database version and runs migrations. Then, module by module in dependency order: migrations, shared and server files,
Init.4
Starting
Every module’s
Start runs.5
Ready
Connections are accepted. The summary line prints:
ug-core v1.0.0 ready in 61 ms. 10 modules enabled.Stopping, then Stopped. Modules that already ran Init get their Stop in reverse order.
How your resource reaches UgCore
@ug-core/import.lua loads part of ug-core into your resource and proxies the rest:
Callbacks and net events cost no export call per request. Central state such as Guard scores and the global request budget stays in ug-core. See Importing UgCore.
Modules
Every feature beyond the core is a module inmodules/<name>/:
modules/accounts
module.lua
config.schema.lua
sql
v1.0.0.sql
server
api.lua
client
api.lua
shared
enums.lua
LoadResourceFile and never listed in the manifest, so clients never download it.
identity, players and permissions are required. Everything else is optional. See Modules.
Layout of the resource
ug-core
fxmanifest.lua
import.lua
import
core
shared
server
client
modules
locales
types
config