How fivem-scripts/airports works
1. Repository role
- This is a FiveM resource named airports that lets players travel between two in-game locations: Los Santos International Airport and Sandy Shores Airfield.
- The architecture is lightweight and game-runtime focused: almost all behavior runs inside the FiveM client/server scripting environment using Lua.
2. Runtime boundary
- The resource is split into client-side scripts and a server-side script, with fxmanifest.lua acting as the resource manifest that tells FiveM what to load.
- There is no sign of a separate web backend, database, or external API integration; the system is self-contained inside the FiveM server.
3. Core client subsystem
- client/client.lua is the main client entry point for gameplay logic.
- It likely handles player interactions, polling/detecting location or proximity, and wiring the airport travel feature into the game world.
- In architecture terms, this is the interaction and orchestration layer on the player machine.
4. Airport location data
- client/airports.lua appears to hold airport definitions and related constants such as coordinates, markers, or route endpoints.
- This file is the resource’s static world-data layer, separating location metadata from gameplay flow.
5. UI/menu subsystem
- client/menu.lua is the likely bridge to NativeUILua, which is listed as a requirement.
- It represents the presentation layer for choosing destinations or triggering travel actions.
- The menu sits on the client boundary, since UI and player input are handled locally.
6. Spawn/travel flow
- client/spawn.lua suggests responsibility for moving the player to the selected destination and managing spawn or teleport behavior.
- This is the execution layer of the travel action: once the player chooses an airport, this module performs the relocation and any related state changes on the client.
7. Server-side coordination
- server/server.lua is the only server script in the tree.
- It likely validates or coordinates travel requests, and may integrate with optional frameworks such as Essentialmode or venomous-freemode if those are present.
- Architecturally, the server side is small and probably exists to support shared state, permissions, or framework compatibility rather than heavy logic.
8. Configuration boundary
- config.lua is the resource’s primary tuning point.
- This is where deployment-specific settings likely live: enabling/disabling features, defining prices or conditions, or selecting framework behavior.
- It separates gameplay policy from the runtime code.
9. Dependencies and integration points
- The main external dependency is NativeUILua, which provides the menu/UI layer.
- Essentialmode and venomous-freemode are optional integration points, meaning the resource can run standalone but can also adapt to common FiveM server ecosystems.
- These dependencies influence how the resource fits into a broader server stack, but they do not appear to introduce separate services.
10. Data flow at a high level
- Player approaches or uses the airport feature on the client.
- The client reads airport definitions, opens the NativeUI menu, and the player selects a destination.
- The travel/spawn module applies the movement locally, and the server script can participate if framework hooks or validation are needed.
- The result is a simple client-driven action with optional server coordination.
11. Operational model
- Installation is just resource deployment plus start airports in server.cfg, which reinforces that this is a standard FiveM modular resource.
- There is no evidence of persistence, scheduled jobs, message queues, or networked microservices.
- For an architecture diagram, this should be shown as a single resource boundary with client-side UI/gameplay logic and a minimal server-side support component.
12. What is most important to diagram
- Show the FiveM runtime as the host platform.
- Inside it, split the resource into:
- Client data/config
- Client UI/menu
- Client spawn/travel logic
- Server coordination
- Connect the client UI to the travel action, and show optional links from server logic to framework integrations.
Main entry points: client.lua Client Logic · server.lua Server Logic · config.lua Config · menu.lua Menu
Components 12
FiveM Runtime
Host game platform that loads the resource and runs client/server scripts.
- FiveM · Game runtime that loads the airports resource.
airports Resource
Self-contained travel resource for the two airport locations.
- airports · Airport travel resource boundary.
- Manifest · Declares scripts and dependencies for FiveM.
fxmanifest.lua - Config · Deployment and gameplay tuning point.
config.lua - Client Logic · Main client entry point for interaction and flow control.
client/client.lua - Airport Data · Airport definitions, coordinates, and travel metadata.
client/airports.lua - Menu · NativeUI-backed destination selection and input bridge.
client/menu.lua - Spawn Travel · Moves the player to the chosen destination.
client/spawn.lua - Server Logic · Minimal server-side support for validation or framework hooks.
server/server.lua
External Integrations
Optional and required ecosystem components used by the resource.
- NativeUILua · Menu library used for client presentation.
- Essentialmode · Optional server ecosystem integration.
- venomous-freemode · Optional server ecosystem integration.
Connections 15
- FiveM → airports: loads · FiveM loads the resource as a modular script package.
- airports → Manifest: declared by · Manifest defines what the resource loads.
- airports → Config: tuned by · Configuration controls runtime behavior.
- airports → Client Logic: client side · Primary gameplay logic runs on the client.
- airports → Server Logic: server side · Small server coordination component.
- Client Logic → Airport Data: reads · Client logic uses airport metadata.
- Client Logic → Menu: opens · Client logic triggers the destination menu.
- Client Logic → Spawn Travel: invokes · Client logic hands off travel execution.
- Menu → NativeUILua: uses · Menu presentation is built on NativeUILua.
- Menu → Spawn Travel: selects destination · Menu choice drives the travel action.
- Spawn Travel → Airport Data: targets · Spawn logic uses airport endpoints and coordinates.
- Server Logic → Essentialmode: optional · Server script may integrate with Essentialmode.
- Server Logic → venomous-freemode: optional · Server script may integrate with venomous-freemode.
- Config → Client Logic: configures · Client behavior is parameterized by config.
- Config → Server Logic: configures · Server behavior may also be parameterized by config.