Decorators
@model(modelName, abstract?)
CLIENT SERVER
Register the following class as Object Management of the specified model
@model("prop_crate_11e")
class Crate extends BaseEntity {}You can also pass a table of models:
@model({ "prop_crate_11e", "prop_boxpile_07d" })
class Crate extends BaseEntity {}Model Constructors SERVER
SERVEROn the server, passing multiple models generates model-specific constructors. This allows explicit control over which model is used when creating the entity:
-- ✅ Explicit constructors
new Crate.prop_crate_11e(...)
new Crate.prop_boxpile_07d(...)
-- ✖️ Invalid: no model provided
new Crate(...)Abstract parameter SERVER
SERVERPassing abstract = true marks the class as abstract.
Useful for logic-only objects or custom entity types, for example, NPC spawn zones or render/unrender managers:
utility_objectify, from the provided model name generates the model and its corresponding object, while keeping full entity lifecycle management.
Client logic works automatically, no special setup needed.
@vehicle(modelName)
CLIENT SERVER
Register the following class as Object Management of the specified model. can be used only on classes that extends BaseEntityOneSync
You can also pass a table of models:
Model Constructors SERVER
SERVERAre supported like @model(modelName, abstract?)
@ped(modelName)
CLIENT SERVER
Register the following class as Object Management of the specified model. can be used only on classes that extends BaseEntityOneSync
You can also pass a table of models:
Model Constructors SERVER
SERVERAre supported like @model(modelName, abstract?)
@object(modelName)
CLIENT SERVER
Register the following class as Object Management of the specified model. can be used only on classes that extends BaseEntityOneSync
You can also pass a table of models:
Model Constructors SERVER
SERVERAre supported like @model(modelName, abstract?)
OneSync only supports up to 80 locally created entities at once, and the base game already uses a large share of that limit. Because of this, relying on this kind of entity decorator isn’t very reliable. Unless you specifically require this type of entity, i strongly recommend using UtilityNet entities as usual (with @model(modelName, abstract?))
@plugin(pluginName)
CLIENT SERVER
Registers a Object Management to be loaded alongside a main class. Plugins allow you to modularize logic.
@state(key, value?)
CLIENT SERVER
Watches for changes to a specific self.state key on the object.
Executes the decorated method whenever the key changes.
You can specify a value to only trigger on specific state changes:
The load parameter is a boolean indicating if that function was called from a state change or from the initial state loading, this can be useful to reuse and differentiate logic/code
load: true = the function was called why the entity loaded/rendered and so the value as not changed
load: false = the function was called by a state change
@event("eventName", ignoreRendering?)
CLIENT SERVER
Registers a listener for a net event and binds it to the object.
If ignoreRendering is not set, the event handler will only run when the object is fully loadedAreObjectScriptsFullyLoaded(obj)
Set ignoreRendering = true to disable rendering checks:
@rpc(return?)
CLIENT SERVER
Marks a function as callable from the server side.
If the function uses the lua return keyword or the return argument is set to true,
it will register a callback and return the value to the caller.
is the same of
this decorator can be used also on normal functions (not entity)
@srpc(return?)
SERVER
Same as @rpc(return?) but register only if IsServer is true,
useful when writing shared code and you want to register the RPC only on the server without doing manual if checks
@crpc(return?)
CLIENT
Same as @rpc(return?) but register only if IsClient is true,
useful when writing shared code and you want to register the RPC only on the client without doing manual if checks
Last updated