Should I fire an event every heartbeat?

In one script on the client, in a heartbeat event, I am setting an attribute once per heartbeat SetAttribute()

In a separate script, still on the client I am detecting a GetAttributeSignalChanged event.

Is this ok, considering its all happening on the client, and the original source of the change to the attribute is in a Heartbeat?

Or would this cause issues?

I was wanting the script with the heartbeat to handle input vectors, and allow any other client script to ‘hook’ into the event, by checking if the attribute changed.

EDIT * I have a scenario, where I need to know how long a jump button has been held. So I set an attribute when the jump is true or false, but if the jump is true, I also set a attribute with the number of ticks it has been true, updating that once per heartbeat. I havent noticed any problems with that, but the jump is rarely just held down.

Now I am needing to know when a movement key is held and for how long, but not only when held, but also how long it has been released, so this would result in a tick update for the ‘un changed’ state of the movement, so it would update that attribute every heartbeat, regardless if the key was down or not.

1 Like

Unless you’re running into performance issues, I think your hooked method should be good enough for checking the input vectors/keys pressed down.

However, if you have too many scripts hooking into the event it could cause issues later down the line with the event listeners being fired every heartbeat, and depending on how expensive the code is you may want to add code that only checks and sets the attribute when necessary (for example, if the player has no control of their character you could pause the attribute getting and setting)

In my opinion, if you’re handling all the input logic on the client without the server needing to know about it I would store the input data in a Rodux store, and update that then you can get all the data from one place

I haven’t seen any performance issues so far, at least not in studio, in a live experience though, who knows.

I am mainly hooking into this with a basic movement system that can handle flight and custom swimming, then an additional system can hook into it that controls ‘vehicles’ things you might ride or drive, such as riding a dragon or sailing a boat. There shouldn’t ever be any more that those two systems hooking into it. So I guess I will go with this solution until a problem pops up.

Thanks for the reply.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.