Zero Server Entities.
One GlobalState Key.
rde_mechanic replaces per-player network events entirely with a single GlobalState key. Mechanic peds are proximity-loaded, client-side only, zero CNetObj overhead — and the tuning menu covers all 60+ GTA Online mod types with server-validated pricing that can't be spoofed.
Overview
Admins spawn NPC mechanic peds anywhere — players interact via ox_target to repair or fully tune. Positions sync via GlobalState and peds proximity-load client-side. No ox_core dependency required for the core system — only used optionally for group-based admin checks.
Why this over generic mechanic scripts
| Generic Mechanic Scripts | rde_mechanic |
|---|---|
| Sync method | Network events per player → GlobalState, instant |
| Ped loading | Always loaded → proximity-based LOD |
| Server entities | 1 per ped → zero, client-side local peds |
| Price validation | Client-side → server-side, exploit-proof |
| ox_core | Required → optional, works without it |
Quick Start
ensure oxmysql
ensure ox_lib
ensure ox_inventory
ensure ox_target
ensure rde_mechanic
-- optional
ensure ox_core
add_ace group.admin rde.mechanic.admin allow
The rde_mechanics table auto-creates on first start. In-game as admin: /mechanics → Create Mechanic — spawns at your current position.
How It Works — GlobalState Sync
Admin creates mechanic
→ Server: DB insert → BroadcastMechanics() → GlobalState updated
→ All clients: proximity loop sees new ID on next tick
→ Nearby clients: SpawnMechanic() → local ped + blip + ox_target
→ Far clients: ID noted, ped spawns when player gets close
Player joins server
→ Proximity loop starts
→ GlobalState.rde_mechanics already populated — no event needed
Server stores data only — zero entities, zero network peds. Client proximity loop reads GlobalState every tick and handles all spawning independently.
Tuning Menu
All 60+ GTA Online mod types organized in 7 categories: engine, brakes, transmission, suspension, armor, turbo, body parts, wheels (15 types + 190 sport variants), paint (primary/secondary/pearlescent/wheel/interior/dashboard), neon, window tint, livery, interior mods, extras, and vehicle weapons (MG, Missiles, Flamethrower, Minigun, Railgun, Laser).
Configuration
Config.Performance = {
renderDistance = 150.0, -- spawn ped within this range
despawnDistance = 200.0, -- despawn beyond this (hysteresis)
maxVisibleMechanics = 20,
}
Config.Security = {
maxPurchasesPerMinute = 15,
validatePricesServerSide = true, -- never disable this
}
Performance
| Mechanic Peds | Client Impact | Server Impact |
|---|---|---|
| 50 | Negligible (only nearby spawned) | < 0.01ms |
| 100 | < 0.5% FPS | < 0.02ms |
Common Pitfalls
Mechanic spawns but immediately despawns
Player is outside renderDistance but the hysteresis gap to despawnDistance is too small.
Fix: ensure renderDistance is meaningfully less than despawnDistance (default 150/200 gives a 50m buffer).
Repair animation plays but vehicle stays broken
If the buyer isn't the vehicle owner, the server relays applyRepair to the owner's client — both players must be in the same session.
Fix: check F8 for network errors if the owner is offline or in a different session.
FAQ
Is ox_core required?
No — it's optional, used only for group-based admin checking. ACE permissions work standalone.
Does the tuning menu close after every purchase?
No — the session persists, so players can buy multiple mods without reopening the menu each time.
Changelog
GlobalState sync replaces per-player events entirely, proximity loading, zero server entities, late-join zero-event support.
Initial release — animated repairs, full tuning menu, vehicle weapons, MySQL persistence, EN/DE.