🌉 RS Bridge — Enhanced Ready Universal Framework & Provider Compatibility Layer

RS Bridge is my universal compatibility layer for RealitySucksRP resources, built for the modern FiveM GTA V Enhanced ecosystem.

Instead of forcing every resource to contain separate Qbox, QBCore, ESX, inventory, banking, vehicle, medical, target, fuel, and key integrations, rs_bridge provides one clean API between the resource and the server ecosystem.

Build once. Let the bridge handle the provider. ⚡

⚡ FiveM GTA V Enhanced Ready

RS Bridge is designed around the current FiveM ecosystem and my ongoing GTA V Enhanced migration.

✅ FiveM GTA V Enhanced focused
✅ OneSync-friendly architecture
✅ Modern provider abstraction
✅ Reduced legacy framework coupling
✅ Clean lifecycle handling
✅ Framework-neutral APIs
✅ Built for current RS resources
✅ Designed for future integrations

Enhanced compatibility and framework compatibility are treated separately, allowing resources to stay clean while the bridge handles the server-side ecosystem.

🧩 Multi-Framework Support

RS Bridge supports multiple framework environments without requiring every RS resource to contain duplicate framework logic.

🥇 Qbox

My primary modern path.

✅ Qbox-first architecture
✅ Player data support
✅ Group/job access
✅ Multi-job and multi-gang aware architecture
✅ Modern Qbox ecosystem support
✅ Works naturally with ox-based resources

🔵 QBCore

✅ Player data
✅ Money operations
✅ Jobs and gangs
✅ Callbacks
✅ Usable items
✅ Vehicle integrations
✅ Permission compatibility

🟠 ESX

✅ Player access
✅ Money handling
✅ Jobs/groups
✅ Callback compatibility
✅ Provider adapters

⚙️ Standalone

Framework-independent functionality can also operate through standalone/custom providers where supported.

🧠 More Than Framework Detection

RS Bridge does not simply ask:

“Is this Qbox, QBCore, or ESX?”

It can independently decide which resource owns each capability.

For example:

Framework      → Qbox
Inventory      → ox_inventory
Target         → ox_target
Fuel           → ox_fuel
Vehicle Keys   → qbx_vehiclekeys
Vehicles       → qbx_vehicles
Garage         → qbx_garages
Medical        → qbx_medical
Banking        → rs-banking
Cash           → inventory item

Another server could use a completely different combination.

That is the purpose of RS Bridge. 🌉

🎒 Inventory Provider Support

Inventory is treated as its own provider, separate from the framework.

This makes it possible for a server to use combinations such as:

⚡ Qbox + ox_inventory
🔵 QBCore + ox_inventory
📦 QBCore + another supported inventory
🟠 ESX + compatible inventory provider
🛠️ Custom inventory adapters

RS resources can call the same bridge inventory API regardless of the provider underneath.

💵 Dedicated Cash Provider

One important difference in RS Bridge is that cash is not assumed to belong to the framework or inventory.

Cash can be configured through its own provider.

Supported architecture includes:

🎒 Inventory-item cash
💵 Framework cash
🔌 Custom cash provider

For example, my modern setup can use:

Qbox + ox_inventory + physical cash item

while another server can continue using normal framework cash.

Resources do not need to know the difference.

🏦 Banking Provider Architecture

Banking is also separated from framework detection.

This allows integrations with:

🏦 RS Banking
💳 Framework banking
🏢 Business accounts
💸 Player payments
🧾 Transaction systems
🔌 Custom banking providers

Neutral banking operations can include:

Get Bank Balance
Add Bank Money
Remove Bank Money
Charge Player
Credit Player
Transfer / Provider Routing

This lets vehicle shops, phones, garages, businesses, housing, and other resources share the same financial integration layer.

🎯 Target Provider Support

RS Bridge can isolate target-system logic from the resource itself.

Designed for integrations such as:

🎯 ox_target
🎯 qb-target
🎯 Other supported/custom target providers

A resource can ask the bridge to create an interaction instead of hardcoding a specific target resource.

⛽ Fuel Integration

Fuel systems can be handled as a separate provider.

This allows RS vehicle resources to work with different fuel ecosystems without embedding every fuel resource directly into their code.

Useful for:

🚗 Garages
🚙 Vehicle shops
🏁 Racing
🛠️ Mechanics
🚚 Job vehicles

🔑 Vehicle Key Integration

Vehicle keys are abstracted from the consuming resource.

RS Bridge can route vehicle ownership/key actions through the configured provider.

Designed for environments using systems such as:

🔑 Qbox vehicle keys
🔑 QBCore vehicle keys
🔑 Custom vehicle-key resources

🚘 Vehicle & Garage Providers

Vehicle persistence and garage systems are treated independently.

This provides a cleaner foundation for:

🚗 Owned vehicle lookup
🅿️ Garage systems
📍 Vehicle locations
🔄 Vehicle state
🔑 Ownership
🏢 Job/fleet vehicles
🚓 Emergency fleets

Perfect for integrating the larger RealitySucksRP vehicle ecosystem.

🏥 Medical Provider Support

Medical functionality can also be routed through the bridge.

Designed for operations including:

❤️ Player status
🚑 Revive
🩹 Healing
💉 Partial healing
🏥 Medical-resource integration

Qbox environments can use modern medical-provider APIs without forcing the same implementation onto QBCore or ESX servers.

👮 Group, Job & Permission Support

RS Bridge provides a common permission layer for resources that need controlled access.

Useful for:

👮 Police
🚑 EMS
🔧 Mechanics
🏢 Businesses
👑 Boss menus
📦 Restricted storage
🚗 Job garages
🚪 Protected interactions

Qbox group-grade handling is supported without throwing away its modern multi-group capabilities.

🛡️ ACE Permission Integration

RS Bridge uses a framework-neutral permission direction with FiveM ACE permissions available for administrative and privileged functionality.

This reduces reliance on deprecated framework-specific permission systems.

Perfect for:

🛡️ Admin tools
⚙️ Developer commands
🔧 Management systems
🔒 Restricted functionality

🔄 Framework Lifecycle Handling

Player loading and unloading can vary between frameworks.

RS Bridge normalizes lifecycle behavior so consuming resources can react consistently when players:

👤 Load
🚪 Unload
🔁 Switch characters
🔄 Reconnect
❌ Disconnect

This helps prevent stale caches and framework-specific cleanup bugs.

📞 Callback Compatibility

The callback layer is designed to normalize differences between frameworks.

✅ Qbox callback routing
✅ QBCore callback compatibility
✅ ESX callback support
✅ Multiple return values preserved
✅ Cleaner error handling

Resources can use a consistent bridge callback contract instead of maintaining several independent implementations.

📦 Usable Item Support

RS Bridge can provide a unified usable-item layer for compatible frameworks/providers.

Ideal for items such as:

📱 Phones
🚁 Drones
🧰 Repair kits
🍔 Consumables
🔑 Keys
📦 Custom RS items

🔌 Provider-Based Architecture

The biggest advantage of RS Bridge is modularity.

Each system can be selected independently:

Framework
Inventory
Cash
Banking
Target
Fuel
Keys
Vehicles
Garage
Medical
Housing
Properties
Permissions

Changing one provider does not mean rewriting every RS resource.

🧟 Perfect for Normal RP & Zombie Servers

RS Bridge powers both sides of my RealitySucksRP ecosystem.

🌆 Normal roleplay resources
🧟 Zombie apocalypse resources
🚘 Vehicle systems
📱 Phones
🏦 Banking
🏠 Housing
🔫 Survival resources
🎯 Interactive systems
🚑 Medical resources
🛠️ Future RS releases

The presentation may change between normal RP and apocalypse resources, but the compatibility layer can remain consistent underneath.

📱 Built for the RS Ecosystem

RS Bridge is designed to become the common compatibility contract behind resources such as:

📱 RS Phone
🧟 RS Zombie Phone
🏦 RS Banking
🚘 RS Garage
🧟 RS Zombie Garage
🏎️ RS Vehicle Shop
🧟 RS Zombie Vehicle Shop
🔧 RS LS Customs
🧟 RS Zombie LS Customs
👻 RS Ghost Hunts
☣️ RS Zombie Core
…and future RealitySucksRP resources.

🛠️ Developer-Friendly API

Instead of writing:

if Qbox...
elseif QBCore...
elseif ESX...

throughout a resource, developers can call a common RS Bridge function.

That results in:

✅ Cleaner source code
✅ Easier maintenance
✅ Faster framework updates
✅ Easier provider replacement
✅ Less duplicate code
✅ Easier debugging
✅ Better commercial compatibility

🌟 Why RS Bridge?

🌉 One compatibility layer for the RS ecosystem
⚡ FiveM GTA V Enhanced focused
🥇 Qbox-first
🔵 QBCore supported
🟠 ESX supported
⚙️ Standalone/custom-provider architecture
🎒 Inventory abstraction
💵 Independent cash provider
🏦 Banking abstraction
🎯 Target integration
⛽ Fuel integration
🔑 Vehicle key integration
🚘 Vehicle and garage integration
🏥 Medical integration
👮 Job/group support
🛡️ ACE permission support
🔄 Lifecycle normalization
📞 Callback abstraction
📦 Usable-item support
🧩 Modular provider selection
🔌 Designed for future adapters

✅ Recommended Modern Setup

For a modern FiveM Enhanced server, my preferred stack is:

⚡ Qbox
🎒 ox_inventory
🎯 ox_target
🧰 ox_lib
🌉 rs_bridge

But RS Bridge exists specifically so my resources are not locked to only that combination.

🌉 One Bridge. Multiple Frameworks. Multiple Providers.

RS Bridge gives RealitySucksRP resources one consistent language to communicate with the rest of your server.

Whether your server runs Qbox, QBCore, ESX, ox_inventory, framework cash, physical cash items, custom banking, different vehicle systems, or future provider combinations, the goal is simple:

Keep the resource clean. Let RS Bridge handle compatibility.