Hi. If you're working with others, please use SetTimerByEvent instead. Using function name means that if anyone changes the name of a function, it will break the code. SetTimerByEvent will automatically update to reflect function name changes. SetTimerByFunctionName is still good for some purposes - such as debugging or gameplay scripting, where you can make the function name a variable and edit it in runtime, to execute different functions during play. Also it is unsafe to use return values from functions after a time. They are only guaranteed to be valid on the same frame ( video time 1:01) E.g. Cast to ThirdPersonCharacter -> Delay(1.0) has a chance that within the 1 second (or any time at all really) the garbage collection will have cleaned up the return value of the cast node, resulting in the reference being lost. This is a potential issue regardless of timer method used.
Hi, Can you elaborate or point to a source describing this issue of the return values being unsafe? Probably some steps to reproduce. I am just curious to read about it and test it out.
The events are a nuisance if you're not in the event graph and trying to have timers in functions instead. It's incredibly annoying that it's limited to events only when you want to tidy up blueprint spaghetti - this is why I prefer the C++ timers (which also let me pass parameters easily without having to mess around too much)
This video changed my life., I don't know how I was doing anything before I started using them. One question though, is it ok to just pause the timers instead of invalidating if the functions are just gonna get called again within a few seconds or would a bunch of paused timers be bad?
Hi. If you're working with others, please use SetTimerByEvent instead. Using function name means that if anyone changes the name of a function, it will break the code. SetTimerByEvent will automatically update to reflect function name changes. SetTimerByFunctionName is still good for some purposes - such as debugging or gameplay scripting, where you can make the function name a variable and edit it in runtime, to execute different functions during play.
Also it is unsafe to use return values from functions after a time. They are only guaranteed to be valid on the same frame ( video time 1:01) E.g. Cast to ThirdPersonCharacter -> Delay(1.0) has a chance that within the 1 second (or any time at all really) the garbage collection will have cleaned up the return value of the cast node, resulting in the reference being lost. This is a potential issue regardless of timer method used.
Hi, Can you elaborate or point to a source describing this issue of the return values being unsafe? Probably some steps to reproduce. I am just curious to read about it and test it out.
The events are a nuisance if you're not in the event graph and trying to have timers in functions instead. It's incredibly annoying that it's limited to events only when you want to tidy up blueprint spaghetti - this is why I prefer the C++ timers (which also let me pass parameters easily without having to mess around too much)
This video changed my life., I don't know how I was doing anything before I started using them. One question though, is it ok to just pause the timers instead of invalidating if the functions are just gonna get called again within a few seconds or would a bunch of paused timers be bad?
thanks, really helped me
Thank you
Is it impossible to make these timers work when pause is on? If not, is there any alternative?
thanks bro
Why aren't timers precise? Which other feature can I use for precision? Timeline?