I would like to record the number of frames from the start of an event to the end, no animation for now.
On a side note, trying to understand how the frame skip works after hitting pause in the menu. Something like playing while using frame skip would be nice.
Also wanted to mention I am the greatest of newbs so forgive me if my question is elementary.
in the BP containing your event, I’d just add an INT variable, increase it by one in your event using ++ or +1… the final value of your INT variable will be the number of frames
you could use PrintString to show the result on screen
HydroWin,
One way to do it, would be to set up a blueprint, that when the event occurred would start counting frames. Remember there is a call to event tick for a blueprint for each frame. So a simple method would be to just increment a counter for each call to the Event Tick. You would also want to have a bool that fed into a branch node, to act as a trigger, for when the Event started so you could start counting, and flip the bool to false, when the event was done, then have the count dumped out to the log via a Print node. Again this is very simplistic, but would do what you are looking for.
Hope this helps,
This method sounds ingenious but wouldn’t that effect the performance? I’m planning on having this happen across multiple events.
Or do you think it won’t have that big a hit on performance if I connect the event tick to a sequence and then to all the events I plan on having?
Hmm but how does one know how fast it is incrementing? Does it increase per frame by default?
Here is a screenshot of how I am imagining your answer.
“++” only works if you activate it. You have to “get” Intvar and connect it to ++ input, and place that ++ after Gamepad Left Trigger. In your case the Intvar won’t increase.
And if you want the framerate, you have to hook that up to Event Tick, as per @jayice 's sugestion. E.g., set a gate: when Gamepad Left Trigger is pressed — open the gate, when unpressed — close. And feed Tick to the Enter exec pin.
One more thing, you should realize that framerates may be different at any given time. So if you want to build your event/animation upon the framerate, you should think twice.
In terms of performance, there will be a negligable impact. Using the tick, is not inherently going to sacrifice performance, it’s how much work you do during the tick, that impacts performance. Just checking a few booleans to see what event is active, and incrementing a counter will be negligible at worst, and at best, there will be no impact at all.
So what you will be doing, or how I would code it, is that I would have one blueprint, that is external to all the code that starts/stops the events. Then hook up how you wish to notify (I would just use a function call) the recording BP for the particular event. Create one bool per event type, and when the event fires, notify the recording blueprint, and tell it the type of event, so that the bool for the event will return true. In the code that sets the bool in the recording blueprint, enable the tick at that point.
Now the tick processing will start firiring, allowing you to start the counter for that bool. When the event is done, call again to the recording to have it turn off the counting for that bool, dump out the information you wish. AFTER the bool is turned off, OR all the bools together, if it is false, then disable the tick as well.
Hence the recording blueprint, will not impact performance at all, unless there is an active event that is having the frames counted for it.
Hope this helps,
Ohhhh I see, thanks for the detailed description. I have something that seems to work now from @jayice wise words.
Can you elaborate a little on the building event/animation on the framerate? I think what will eventually happen is I will place a delay node in the place of animation that will be timed on frames and when the time comes, add a sequence to have both animation and delay run at the same time or something like that.
My word, how are you this great?!
Anyway, I think I got what I was looking for based on your answer.
I didn’t make it into its separate function just yet to make it easy on my brain but I set a variable to increment by 1 that’s attached to the event tick node. I then set that variable to 0 when my other event is pressed changing the variable back to 0 and finally calling it after releasing the button.
I took a couple screenshots so you can melt your eyes and shake your head in disappointment at it but so far it seems to work. Might not perform well but I’ll eventually make everything cleaner once I at least get everything working.
But for now I’m making spaghetti blueprints, thanks again for the help I appreciate it!
I wish I was that great! lol, far from it. , it looks like the code should do what you want. A couple of points. (and the points are all just nit picky, but it’s good to train yourself to do it, without thinking about it)
- In the event graph, use the increment node, instead of the add node. This way you will bypass needing to do the set. Note on the increment node, that the input is a Diamond pin, meaning that it’s a reference being passed, hence the node actually is incrementing and setting the variable reference.
- For something like a counter, use Integers instead of floats. While processors have advanced a long way, the CPU still is faster at working with integers than it is floats.
After looking at your code, it would seem that you are actually after the period of time that the keypad button was held down, not really after the number of frames. In order to generate this in a different fashion. Just take the same accumulator (it’s already a float, and should stay a float), and add to it the Delta Seconds that is passed from the Tick call. The rest of your code should not have to change. Then when your getting the message displayed, it truely will be the amount of time the button was held down, and you will not need to bother with the “Framerate to Seconds” call etc.
In terms of having this all in a function. I was really thinking in terms of having it in another blueprint. The reason for this, is that when starting to get performance/event/counter information, it’s easy to start adding to it, and it begins to grow quickly, and then it’s all over the place in the actual product, making it more of a pain in the butt to remove later on. If it’s all contained in a external piece of code ( in this case a blueprint), only the calls to the blueprint need to be located, and removed from the product. Far less error prone.
Hope this helps,
I wish I was that great! lol, far from it. , it looks like the code should do what you want. A couple of points. (and the points are all just nit picky, but it’s good to train yourself to do it, without thinking about it)
- In the event graph, use the increment node, instead of the add node. This way you will bypass needing to do the set. Note on the increment node, that the input is a Diamond pin, meaning that it’s a reference being passed, hence the node actually is incrementing and setting the variable reference.
- For something like a counter, use Integers instead of floats. While processors have advanced a long way, the CPU still is faster at working with integers than it is floats.
After looking at your code, it would seem that you are actually after the period of time that the keypad button was held down, not really after the number of frames. In order to generate this in a different fashion. Just take the same accumulator (it’s already a float, and should stay a float), and add to it the Delta Seconds that is passed from the Tick call. The rest of your code should not have to change. Then when your getting the message displayed, it truely will be the amount of time the button was held down, and you will not need to bother with the “Framerate to Seconds” call etc.
In terms of having this all in a function. I was really thinking in terms of having it in another blueprint. The reason for this, is that when starting to get performance/event/counter information, it’s easy to start adding to it, and it begins to grow quickly, and then it’s all over the place in the actual product, making it more of a pain to remove later on. If it’s all contained in a external piece of code ( in this case a blueprint), only the calls to the blueprint need to be located, and removed from the product. Far less error prone.
Hope this helps,
I meant that frame rate can change drastically depending on various circumstances. If I just launch a game in the editor, I get 200 fps, but if I drag one blueprint window to the second display, fps drops to 100-120. If I launch a standalone game I may get 400-500 fps. And that’s the same computer.
Now imagine people launching your projects on computers with different performance; some will have 120 fps, some 30.
So if you base your animation on the framerate, sometimes it may be over in two seconds, sometimes in eight. I don’t think that’s what you would want.
Ok I see what you mean now, yes that is something I realllllllllly don’t want. But the thing is, I went into the general settings and used the fixed frame rate, I’m guessing that doesn’t help with your scenarios?
Your answering a lot of my questions and more just keep coming up in my head lol. Is there a way for me to give you points for giving insight? I wish there was a discussion on this somewhere, I can’t find one.
Fixed frame rate works if your machine can do more than the fixed number. If it can’t, fps will still be lower, and that can disrupt the flow.
The level of detail your providing is too great for me but I think I understand. I used the increment node instead of the extra nodes I had and it’s looking muuuuuuch cleaner.
And here I thought all number variable types were equal in performance, silly me.
Also I do want the number of frames that passed, unless the period of time is the same thing? I’m also not sure how to write if the number of frames is under 10 then do something else in a different way without using the framerate to seconds node.
I get what you mean by having it in another blueprint, I will focus on making it more readable soon, things like using increments definitely made it less confusing for sure!
Ahhh! Thank you, thanks makes sense! I’m guessing that’s why some gaming companies “suggest” better performing PCs?
This throw a wrench in the blueprint but how does one keep the frame rate static for everyone without punishing the users with better performing PCs? It’s like I’d have to make an entirely separate blueprint in case the person playing isn’t at or above 60fps.
Sorry for continuing to bring more up, this should really be a forum.
Consider using something else as a base. Timers, Timelines, Skeletal mesh animations, etc.
I see, I see. Rather than relying on the PCs hardware, I should focus on using something more concrete like the PCs clock? Thank you for your knowledge! I will use this to propel myself forward!
If the framerate is all that important to you, remember that the tick event is being called once per frame, hence your Dash Frame Count is already the frame count.
To get the number of seconds, create a float variable, and use it as an accumulator, adding in the delta seconds that is passed in to the event tick.
So your Dash Frame Count, now holds the number of frames, the accumulator holds the total time. You can then of course, divide the frame count into the accumulator, to get an average time for each frame. You can as well, keep a high and low value from the delta seconds, or any gradiant there of, so that you can also check to see if the Delta Seconds, is falling close to the median, or to an average etc. No matter what you do, you can get the values that you are looking for, without having to hard code the “60” into that FrameRate to Seconds node.
Hope this helps
just to mention that, depending on what you are aiming to achieve… there is very likely to be a way to notify the end of your event, rather than trying to time the length of your event exactly… this would be much easier, performance efficient and framerate independent