Comparison between floats (for velocity clamping) not leading to expected result

A bit of background
I’m trying to create a (playable) spaceship with somewhat arcadeish flight mechanics. I’m not using physics for this. When the player accelerates or decelerates, rather than directly setting the new speed it sets a target velocity, and attempts to accel/decel towards it based on a preset rate of acceleration.

I.e., I’m currently flying at 800 cm/s. I set my target to 1500 cm/s. Each tick it will calculate an increased velocity based on the acceleration rate of 50 cm/s until it reaches 1500 cm/s.

Now, here’s the problem
I’ve added a little check so that if during acceleration or deceleration it moves past the target velocity (in the relevant direction), rather than going back and forth trying to match target velocity, it’ll clamp at “Target Velocity”. For some reason though, probably some silly error on my account, it never seems to clamp. The “Current Velocity”>“Target Velocity” (and its relevant counterpart) never seems to execute the true part. Adding a Print String there yields nothing printed to screen. “Current Velocity” just seems to oscillate around Target Velocity (both above and below).

Can anyone see where I’m going wrong here?

Blueprint

Note
The “Get Acceleration Direction Float” is simply:
“Target Velocity” - “Current Velocity” fed through a Sign node.

In the case of “Get Acceleration Direction Verbose”, it is pretty much the same thing, with the output converted to an enum for increased readability.

Hey,
Taking a quick look at the picture didn’t led me to any issue. But if what you want is to clamp the value, why don’t you just add a clamp node between you sum node and the set “current velocity” node?
It’ll get the result of the sum operation and clamp it between the limits you preffer.
Maybe i’m missing something, sorry if that’s the case.

Thanks for answering.

Can’t do a pure clamp as what I want to clamp to depends on the “Acceleration Direction”. Basically, if I am accelerating, I want to make sure that it doesn’t accelerate to speeds above Target Velocity. If I am decelerating, I don’t want it to decelerate to speeds below Target Velocity.

EDIT: Uploaded a video which, hopefully, better explains what I am trying to achieve. Video is still processing at the time of upload, so HD versions might not be available yet.

The debug info in the bottom right corner shows the current values of the “Current Velocity” and “Target Velocity” variables. As you can see, it sets a new “Target Velocity” when I add thrust. The ship accelerates/decelerates towards the “Target Velocity”. A few seconds into the video I set a new “Target Velocity” of 1500 cm/s. Ideally, once the ship completes its acceleration up to the 1500 cm/s, it should stay completely stable at 1500. As you can see in the video, reaches approx. 1500 and seems to oscillate between values slightly above and slightly below 1500 cm/s. It seems to never apply the limits I tried to set up in the above blueprint. As mentioned earlier, the > and < comparisons seem to never evaluate to True for some reason.

Hmm, well you could still use the clamp node but with its clamping values connected to a select node. This can make them vary from one value to another based for example in a boolean var. So you could make a check in the select node to see if you’re accelerating or decelerating and get the correct values for both cases.

Still in the video it looks like it tries to clamp but because the acceleration/deceleration process happens before the clamp it stays at 1.x or 0.x above or below your current clamping values.

So if you still want to use your method instead of the clamp+select nodes, if i were you i would change the order of your node flow. The second commentary box (mean all the indes inside) i’d put them the first in the process. And the from the False pin of both branch nodes (the ones checking to make the clamp) i’d connect them to the “set Current Velocity” node. This way it’ll only add to that variable when it’s not on its limit clamped values otherwise it’ll just stays at the “Target Velocity”

Both methods should work ^^. Let me know how it goes.

Indeed, you are correct. I did manage to solve it earlier today and, well, forgot to reply until now.

For clarity to those who might be interested, here’s the reason it is happening (which is pretty much what Meguido said in his post): the reason it was happening is because the two “Get Acceleration Direction *” nodes calculates the direction at the point it is invoked. The acceleration direction calculation node that is executed first (the float variant) gives the correct direction, as it calculates the direction before I add the extra acceleration velocity to “Current Velocity” (which is how it should be done). However, the second acceleration direction calculation node (the verbose variant) is invoked AFTER I’ve added the extra velocity. This means it calculates acceleration direction from the wrong numbers.

Not sure what is the most efficient method of doing this - using multiple select/clamp nodes that Meguido suggested, the method I used, or a different one - but for the moment I focused just on getting it working and as such this is likely not the most efficient one. Essentially, I added an extra variable (“New Velocity”) that I replaced “Current Velocity” with where relevant. Here’s a shot of the corrected and now working blueprint function.