What Are Plugins?
Plugins in BDSC are a clean way to extend the player object with custom logic either:
Internally, via the
/plugins/
folder inside the core resourceExternally, from any other resource using the BDSC API
They hook into the core’s player lifecycle and attach your logic to each player object as they’re created.
How Do They Work?
When a player connects, BDSC creates a player object containing their boii_utils
user account.
It then runs the internal load()
method on that object.
During this phase, all registered plugin extensions are executed.
Each plugin receives the player object and attaches its logic using add_extension()
.
This allows your plugin to inject:
New synced or server-only data
Custom methods
Lifecycle hooks (
on_load
,on_save
,on_unload
)
Your plugin doesn’t override or wrap the core player. It becomes part of it.
Internal Plugins
Internal plugins live inside the /plugins/
folder of your BDSC-based resource.
These can include their own modules, logic, and UI components, effectively acting like mini-resources.
Note: Files within plugin folders are lazy loaded for example:
"plugins/**/server/*.lua"
they do not account for file load order, consider this if its a requirement for your plugin.
Structure Example
Plugin UI Support
FiveM only allows a single ui_page
per resource, which makes it impossible for each plugin to have its own independent UI page.
To solve this, BDSC includes a custom UI loader system that acts as a unified entry point for all plugin-based UIs.
How it works:
Each plugin can include its own UI files inside a ui/
folder. Instead of defining a separate ui_page
, plugins just register their UI assets in the shared core/ui/manifest.json
file. BDSC’s loader will then handle injecting all CSS/JS files as needed.
How to use it:
Place your plugin’s UI files under
plugins/myplugin/ui/
.Add your CSS/JS paths to
core/ui/manifest.json
.
Example manifest entry:
This allows you to modularize UI logic per plugin, while still working within FiveM’s UI limitations.
Extending The Player
plugins/example/player/class.lua
plugins/example/player/class.lua
plugins/example/init.lua
plugins/example/init.lua
External Plugins
External plugins live in any other resource.
They use the exported bdsc.get()
function to hook into the core lifecycle.
Use this pattern for marketplace plugins or modular systems that must stay outside the core.
Minimal Example
Create your class file the same as you would for an internal plugin:
Somewhere in your server side code add the following, ensuring to path to your class file correctly.
Why This Is Good
This plugin system makes your logic:
Modular – Each plugin is fully self-contained, with its own UI, data, methods, and lifecycle logic.
Portable – External plugins can live in any resource and still integrate cleanly with the core.
Composable – Multiple plugins can stack together without interfering with each other.
Integrated – All plugins run at the right time during the player lifecycle (
on_load
,on_save
,on_unload
).
Use internal plugins for logic that belongs in your core repo. Use external plugins for marketplace drops, private releases, or premium addons.
This keeps your project clean, scalable, and developer-friendly.
Last updated