I’m setting up a simple function that determines how long the left mouse button has been held down, and it works perfectly except that Get Input Key Time Down starts around -16.8 then counts backwards to 0, then counts upward normally (time acts like time should, except it starts at -16.8).
I have quite a few other things going on in my blueprint, and this function is in my PlayerCharacter class (being cast from PlayerController). Is this something that could be affected by sequences or frame loss or something? This is the only time I call this function in my entire project.
It starts from zero for me. Must be sth specific to your case. Try watching necessary values by right-clicking on the variable in the graph and selecting “watch this value”.
http://i.imgur.com/Ybc7KcL.jpg This is the area where I’m calling the node. It’s being hooked in via Event Tick → Sequence.
I did some quick debug testing and found that if the stuff in this image is the only thing plugged into the Event Tick, it starts at 0. The more things I add to the sequence (even if they’re added after), the more negative my start value goes. I don’t have anything plugged into Delta Seconds on the event tick node as I didn’t think it was necessary, but now I’m not sure.
Does delta seconds give you a negative value at the start?
As a workaround you could substitute the get input key time down with:
branch is charging attack, if true set time held down = time held down + delta seconds
You will need a time held down reset though
Probably not as efficient as a get input key time down, but it may work until you solve the negative time problem
Good luck!
Btw i suggest you to look at the “clamp float” function
I think this is the way I need to handle it anyways because the InputKeyTimeDown asks for a Key value, which is easily specified in the dropdown menu, but if a player wants to remap that button it won’t update without abstracting that value to a variable. I haven’t given it much thought yet, but it didn’t seem easily apparent that you can take an input and assign it to a variable for that purpose.
So in other words, I think your process might be better for more than one reason I’ll test it in a few minutes.
While it still bothers me that the GetInputKeyTimeDown node had such a major issue when plugged into an event tick sequence with 4 sequence events, your alternate route worked perfectly.
And +1 because it lets me keep the key press info abstracted to cover key re-mappings! Thanks for the help!
I’ll test it in a few minutes.