Czinczar's Player Resources Signals

TEMPLATE NAME: Czinczar's PRS
CORE VERSION: 1.10.3
TEMPLATE VERSION: 1.0.0

BUG TRACKER: link to your bug tracker
TEMPLATE DESCRIPTION:

PRS stands for Player Resources Signals. PRS uses the player resources system built by Manticore to send signals (similar to broadcasting events) from the server to the client(s). The current supported types of data that can be sent are : string, number, player, vector3, coreobject.

Guaranteed Delivery
PRS stands on the shoulders of Manticore as it uses the already existing player resources system and the resourceChangedEvent that comes with it. Thus, every signal sent used PRS is guaranteed to be delivered.

No Duplicate Deliveries
The resourceChangedEvent only fires once, thus assuring that the signal/event is only sent/received once and that there are no duplicates.

Send More Data Per Event
I have tested sending 3k of data to all bots without any issue. I don't know what the real limit is.

Send More Events Per Second
I haven't seen any rate limit so far. Multiple server scripts sending signals every 0.1 seconds didn't create any error.

Performance
Haven't seen any hit on performance. Performance is directly dependent on the size and type of data that is going to be sent. Server and client both need to make some calculations, and it is a bit heavier client side. PRS needs to be extensively tested in a live server on a real game with other things going on.

New API
API is very easy to use. Once required, users need only to call API.SignalToPlayer() or API.SignalToAllPlayers() . It is very similar to the classic Core events system.

TEMPLATE ROADMAP:

  • more supported types of data

TEMPLATE VERSION NOTES:

1.0.0 - Initial release

MEDIA:

ADDITIONAL INFO:
PRS comes with 2 scripts :

  • "PRS API Server Script", which must stay in your project content (don't place it in your hierarchy) and must be required as an asset reference custom property in the server script where you want to use PRS. Example :
    local PRSAPI = require(script:GetCustomProperty("PRSAPI"))

  • "PRS Client Script" which must always stay in your hierarchy inside a client context.

Once this is done, using PRS is easy :

  • To send an event to one player, use this in a server script : PRSAPI.SignalToPlayer(string signalName, player playerTarget, [...])
    Where signalName is the name of the signal/event which the client will listen to, and playerTarget is the target player who should be receiving the data. Then after that you can pass any number of parameters as long as they are of the supported types.

  • To send an event to all players, use this in a server script :
    PRSAPI.SignalToAllPlayers(string signalName, [...])
    This is used the same way, but the playerTarget is obviously not required.

  • The last step is to have a client script with a classic Core event listener with the same event name. Example :

function HandlerFunction([...])
      --process the data received from the server
end
Events.Connect("SIGNAL_NAME", HandlerFunction)

IMPORTANT THINGS TO KNOW

  • Since PRS uses player resources, make sure none of the player resources created by PRS get saved in persistent player storage. All player resources created by PRS have a name that start with "PRS", so make sure to exclude these. If you don't, not only PRS might not function properly next time the player joins the game, but you will clog player storage space with useless data.

  • Since PRS creates a lot of player resources, make sure to exclude all player resources that start with "PRS" from any player:GetResources() call. Otherwise it might take a while to retrieve all player resources.

1 Like

Using resource names is a very clever solution, but I think it suffers from a memory leak. What happens if, after an intense game session of several hours, Player: GetResources () is called?

That's a good remark. I will add this to the "IMPORTANT THINGS TO KNOW". Thanks.

This is a really cleaver approach to the Events limitation. I'll implement it in my upcoming game to broadcast some low-priority events and see how it works. Thanks for sharing!

PD: Not sure if you missed it but there isn't a Bug Tracker link. Do you want any reports here, in the CC comments or do you have a Github project for this?

Thanks.

For now, you can post any reports here.