Extending Players

BDSC supports dynamic, runtime-safe extension of player objects with custom data and methods. This lets you build modular logic without touching the core.


Add Data

Adds custom data to the player. Optionally replicated to the client.

Example

player:add_data("stats", { health = 100, stamina = 50 }, true)

Parameters

  • stats – key name for the data entry.

  • { health = 100, stamina = 50 } – table to store.

  • true – replicate to client (optional).


Add Methods

Attach custom methods that can later be executed via run_method.

Example

player:add_method("stats", "get_health", function(self)
    local stats = self:get_data("stats")
    return stats and stats.health or 0
end)

Usage


Update Data

Modify an existing data block and optionally sync it.

Example


Remove Data

Removes a data key.

Example


Sync Data

Force a sync of all replicated data to the client.

Example


Dump All Data

Logs all currently stored player data.

Example


Here’s a concise section explaining how the on_save and on_destroy methods work when registered via namespaces:


Lifecycle Hooks

BDSC supports namespace-specific lifecycle methods that automatically run when certain player events occur.

These methods are defined under a specific namespace using add_method and are called internally during key moments in the player's lifecycle.

Supported Hooks

Hook Name
Description

on_save

Called when player:save() is triggered (e.g., on disconnect or manually).

on_destroy

Called when player:destroy() is triggered (e.g., on player drop).

How It Works

When a lifecycle event runs, BDSC will automatically check each namespace for these methods and call them in order.

Example

You do not need to manually call these - BDSC will handle them as long as they are added under a namespace using add_method(namespace, "on_save" | "on_destroy", fn).

Avoid long-running operations inside these hooks — keep them lightweight for stability.


Missing Method Safety

Calling a non-existent method will return nil.

Example


No Internal Access

Only the meta table is exposed. All other functionality data, methods, syncing - must be accessed via the public API.

Direct access to _extensions._data, _extensions._methods, or other internals is not possible and never required.


Quick Example

Below is a minimal, self-contained example that demonstrates how to create a player object and extend it externally using basic commands.

This includes:

  • Adding a stats data block

  • Defining custom methods (like get_health)

  • Syncing data to the client

  • Simulating damage

  • Handling save logic

Tip: Every player object supports runtime extension. You can safely add new data or methods at any point — even after creation.

Last updated