Custom events offer a way to manage your own events in a similar way to public variable events. However, the key thing is that they are easier to use and also manage events on a local level as well as remotely.
Custom events are never handled on JIP. That is, all events broadcast before a player joins are not handled, since they would be out-of-date. For state-changes, which you would want synced on JIP, use the standard 1 publicVariable
and 1 addPublicVariableEventHandler
commands instead.
1 addPublicVariableEventHandler
).Ensure that you use OFPEC tags in the naming of events, such as "MYTAG_barrelsExploded" if your tag was "MYTAG". This will prevent receipt of unexpected events from other users of the custom events system.
CBA has a number of events that it routinely raises and any script can add a handler and deal with them.
1 sideChat
is a command that only has an effect on clients, so rather than check whether we are on a client in the handler, it is best to only add handlers on client machines:1 if (not isDedicated) then
2 {
3 ["mySideChat", { (_this select 0) sideChat (_this select 1) }] call CBA_fnc_addEventHandler;
4 };
Later, we want everyone to see a 1 sideChat
message:1 ["mySideChat", [player, "Hello, noobs!"]] call CBA_fnc_globalEvent;
There is no requirement to pass parameters with the event. If no parameters are passed, then the receiving handler will not be passed _this.
Since we only want to create the vehicle on the server, it makes sense to only add a handler on the server:1 if (isServer) then
2 {
3 ["mySummonUAZ", { "uaz" createVehicle (getMarkerPos "base") }] call CBA_fnc_addEventHandler;
4 };
Later, the player wants to create a UAZ (perhaps via an action) and runs:1 ["mySummonUAZ"] call CBA_fnc_globalEvent;
By broadcasting a global-, rather than remote-, event, CBA guarantees that the server handles it, even if we are running as the MP host.