Hey,
In the content examples map “Blueprint Communications” you will find a Crank handle, Chain and Lever near the end, examples of devices using information from their rotation/movement to communicate a state to another.
In this example I have made use of the Crank design, but I am curious as I wish to find a way to Remove the Event Tick procedures from this blueprint, mainly because each door/crank is constantly having its information refreshed every tick, which to me seems very demanding and will probably cause some serious lag issues later on.
Any ideas how or what I could replace the Event Tick with but be able to keep the mouse dependant rotation of the crank handle?
**I understand that the interpolation requires the ability to refresh, to perform updates,
Just I want to be sure that I’m not missing another possible avenue to help limit my reliance on the Event Tick…
I’m probably being overly worried with the optimization this early, but I’d rather be aware of my cost earlier rather than later
I dont think it would cause any performance issues if you enable/disable the tick with another event using a Gate - i.e. press of a button or an overlap event.
Try a gate. Have it start closed and open it when you want it to run and start a loop. You just have what you want to happen loop through the gate. When you get to you end result you close the gate to stop the loop.
You say enable/Disable the tick, are you literal about or do you mean just culling the Ticks path before it gets complex?
Thanks for the information, I will give it a go and post results up later, I think I understand the process of the Gate, so it shouldn’t take too long, Im just forgetting some of the principles of Coding, like setting variables at EventBeginPlay, took me so long to remember that could be done
Does this do the same thing as EventTick, as the Timeline is looping perpetually checking to see if the gate opens? So the cost difference would be the same as using EventTick?
**Hey Guys,
so this is what I came up with based on your advice, Again very simple, so It feels wrong
I’m guessing this is what you meant, I can’t think of any other way to get the event to fire without EventTick, but I’m assuming if all the event tick is doing when Idle is being denied by the gate that is a near unnoticeable cost on performance**
pattym and i suggested the same thing. And yes, your Gate setup is correct. What i see from your screenshots Timeline wouldnt work to Set a variable though.
And PattyM I see what your saying, that is quite an interesting setup you have there, any idea how it would vary in efficiency in comparison to my own?
I’m guessing not too much, but considering its forever looping in the gate checking that may save a little bit If I could avoid it.
Im assuming that the custom even could be replaced with the Trigger Overlap, and also the condition could be the end overlap trigger?
( Sorry code can get quite overwhelming to me quickly )
Sorry about all the SPECIFIC questions, I know they are hard if not impossible to answer, I just want a stronger understanding of the performance costs, and some clever techniques to limit the cost, like the ones you both suggested
You can yea, something like this for example. (not as crazy as the first one) You have to remember that a tick is every frame and in a lot of cases we don’t actually need something to update every tick. Removing the tick completely means you have a little more control as to how frequently the loop is triggered. 0.1 is a good delay (10 updates a second) compared to 30-60 (depending on the users machine) for most things.
Just do some testing and see what works best for what your trying to achieve. Also remember you only get 1 tick node per blueprint.
Another thing that you should think about is creating chain reactions. Does everything really need to happen at the same time? The thing that causes low FPS is of course having to much to calculate each frame/tick. Splitting this up across frames can even out the load. Sometimes things do of course need to happen at the same time but it’s still trial and error.
