esx-overextended/esx_multicharacter

1. What this repo is

- A single FiveM resource for ESX Legacy that implements a multicharacter login/selection flow.

- It runs as an in-game resource, not as a standalone app: the main boundaries are client Lua, server Lua, and a NUI frontend (html/).

2. Resource packaging

- fxmanifest.lua is the integration point that declares the resource’s Lua scripts, UI files, and shared assets.

- config.lua centralizes feature settings such as the default slot count and likely behavior flags that affect both client and server logic.

3. Server-side subsystem

- server/main.lua is the core authoritative layer for character state, player setup, and persistence coordination.

- server/commands.lua adds administrative operations for character-slot management, so slot changes can be applied per player rather than only globally.

4. Client-side subsystem

- client/main.lua handles the player-facing flow: opening the character selector, reacting to server events, and controlling the local UI/spawn transition.

- In this kind of resource, the client is the presentation and input boundary; it does not own persistence decisions.

5. NUI / browser UI boundary

- html/ui.html, html/css/main.css, and html/js/app.js implement the character selection interface rendered inside FiveM’s NUI browser.

- The UI is separate from Lua runtime logic and communicates with the client via NUI messages/callbacks, making it the visual layer for selecting/creating/deleting characters.

6. Data flow for login and character selection

- On player connect, the server determines how many slots a user has and loads their available characters.

- That character list is sent to the client, then into the NUI frontend for display.

- When the player selects or creates a character, the UI → client → server path is used to confirm the choice and continue the ESX spawn/load sequence.

7. Persistence model

- The README states characters are stored in the users table using identifiers like char#:license.

- esx_multicharacter.sql provides the database-side setup required by the resource, and character deletion is handled so it does not require manual cleanup of every dependent table entry.

8. Administration and slot control

- The resource supports both global and per-player character counts.

- Commands such as setslots, remslots, enablechar, and disablechar are the operational boundary for changing character availability without editing code.

9. Localization

- There are two translation layers: Lua locales under locales/ and frontend locales under html/locales/.

- This means both the server/client messages and the browser UI text are localized independently, which matters for architecture because strings are not hardcoded in a single place.

10. External dependencies and runtime context

- The repo is tightly coupled to the FiveM runtime and the ESX framework, with a database backing store for player records.

- No separate backend service is present; the resource itself is the full application boundary, coordinating database access, game events, and UI.

11. Project hygiene / tooling

- .github/workflows/lint.yml shows the repository includes CI linting, likely for Lua/JS/resource quality checks.

- The rest of the repo is intentionally small and self-contained, which makes the architecture easy to diagram as one resource with three main execution surfaces: server, client, and NUI.