I have things stuck to event tick that are waiting for something to happen, it keeps checking whether it has happened.
Once it has happened it then is allowed to start but obviously it is an event tick so it will keep happening a lot.
I’ve been making my own gates that shut as soon as the condition was true. But it still lets in up to 4 ticks.
Is there a proper way to make something definitely only happen once after checking with event tick ?
It would be such a life saver.
Thank you.
I suppose it really depends on specifically what you are trying to do. Sometimes checking a condition every Tick is the thing to do. You might be able to use Blueprint interfaces to avoid having the Tick event. Also you could use timers so you aren’t doing the test every frame.
For state that changes quickly from frame to frame, testing in Tick is likely the simplest way to go.
Theres 2 examples that are bugging up for me.
Both for online:
Now it is going like turn 1 2 1 2 instead of doing it once.
Unfortunately I don’t know a lot about UE4 networking. However, in both of these cases, it seems that you’d be better using reliable RPC to communicate to the server. No Timers or testing would be needed in this case.
For example, with the chat message, the player’s client sends the server a ChatMessage reliable event (Run on Server). The server can then play the sound at the player’s location.
Have a look at A Crash Course in Blueprint Replication. Hopefully that’ll help some.
yeah that’s the idea, but the server wont play any sounds at all, it has to be on player controller or the UI blueprint.
Already seen the link, but thanks anyway.
Yes, RPC calls are between a replicated actor on the client and the authoritative actor on the server. For the player, this typically means the player controller.
I’m unsure on the how to play a sound in a multiplayer game, but it’s possible that you might be able to use the Multicast event from the server to inform all the clients about the sound. (Proper sound replication probably deserves a different question anyways).
As for your original question, for multiplayer games, leveraging RPC calls will likely eliminate the testing you are doing in Tick.
From your description in the comments, it sounds like you’re putting too much smarts on the client.
The client doesn’t need to check anything. It should just do what it’s told.
For example, if the client guesses a word, it should send that guess to the server, and do nothing else.
If the server finds that the word is correct, then it sends out a “word was correct” event (presumably to everyone.)
The clients, in response to that event, update whatever state they need to update.
Same thing for chat – send the chat message to the server, and do nothing else.
Then, on the server, when receiving the chat message, broadcast it to everyone.
When the client receives the broadcast “client X said thing Y” message, then display it, and play a sound.
“word was correct” event, thats why I am checking for that signal on tick.
Sound does not play for the client when it is on gamestate or player controller, only for the host. This is why I made the UI check for if it should play the sound or not.
You could add a boolean bWordIsCorrect that is flagged as OnRepNotify. A matching OnRepNotify event is created automatically, to which you can react by playing a sound (on the client).
Whenever the client makes a guess, the server checks whether it is correct and if so, sets the boolean to true. This will cause the event to trigger back on the client and your sound will be played.
Thanks , RepNotfiy works surprisingly well! 
Danny,
If it’s going to play the sound no matter, then don’t associate the sound to the “event”, just play the sound, then do what ever needs done, to get the server updated, and set yourself up for the “event” to come back as true or false. Just decouple the two actions.
Hope this helps