[logic nodes] add a tickbox to the translate object node to automatically multiply the translation amount by delta time, to compensate for different framerates

[ItsCubeTime]

[ItsCubeTime]

Something else that would be quite cool (thats on the same topic) is that I think there could be nodes "multiply by delta time" for vectors, floats & ints to allow for shorter node graphs - considering that delta time is almost always just used to multiply by some other value.

[knowledgenude]

Some considerations on that:

Delta time in the node afaik isn't related to the framerate, but to the display frequency. It can be used avoid players with higher frequency in monitor to move faster than other players and have advantage over that.

There is a value for the real delta time that is influenced by the framerate (iron.system.Time.realDelta).

I'm not trying to say what is better to do, just sharing my opinion... But if you have stuttering that drops the fps to 1, you will move 60x faster and you will trespass wall/ground just because this single stuttering. In this case would not be better to simple stay with the default delta time, right? Yes... Or you will have to clamp velocities just to avoid that 1 second frame drop and manually handle cases of low frame rate. One idea here would be to just clamp real delta depending on how fast you move the object :)

In some cases one would need to use the real delta like for animated things, so how to go? If we add a checkbox for each delta the things will go wrong...

And i not mentioned there is not the real delta avaiable in the node, so maybe should open a pr for that and document it...

Also sorry for intruding on that, not related to the issue. You would notice a big improvement in collisions if you use set velocity instead of translate because BulletPhysics would handle the things better to avoid your object entering walls/etc. the behavior of entering walls increases the faster you translate the object.

[ItsCubeTime]

Thanks for your thoughts :)

If we add a checkbox for each delta the things will go wrong...

Was this a typo or what do you mean would go wrong? Sounds like the most reasonable solution to me

Also sorry for intruding on that, not related to the issue. You would notice a big improvement in collisions if you use set velocity instead of translate because BulletPhysics would handle the things better to avoid your object entering walls/etc. the behavior of entering walls increases the faster you translate the object. Ah well this is not an issue in my case. The other about real delta vs the delta currently explosed through logic nodes does sound like one however!

I would love some background on this if you feel like sharing. I always thought that nodes such as "on update" updated one time before each frame to the screen? If I understood you correctly, this is not really the case, but the game logic and rendering runs in parallel? On parallel threads or?

[knowledgenude]

Was this a typo or what do you mean would go wrong? Sounds like the most reasonable solution to me

I mean that this could be the solution for this case, but i mentioned other cases where another delta should be used or even be clamped, so locking it inside the checkbox would be pointless and having many delta options inside the node would overbloat it in my view, but i see your suggestions are generally good, so if you decide it worth a checkbox there, then a pr will come :)

I would love some background on this if you feel like sharing. I always thought that nodes such as "on update" updated one time before each frame to the screen? If I understood you correctly, this is not really the case, but the game logic and rendering runs in parallel? On parallel threads or?

It's not because of the update rate, it is because Bullet Physics apply its "physics law" to the objects, while translate method don't have it. I don't know physics but is something like that: when a body is applying some force into a wall, that wall will apply the same force in the body but in the opposite direction, making the object don't enter it.

Compare both methods in this example and see how translated object is entering the wall. Also you could increase the speed to see a even worst behavior.

Another advantage of using Set Velocity is that you don't need to care about delta, because bullet will make that for you (i guess). In case you want to apply some acceleration, so the increment of speed over time should be multiplied by delta.

[MoritzBrueckner]

If I understood you correctly, this is not really the case, but the game logic and rendering runs in parallel? On parallel threads or?

There are two different game loops, one for rendering and one for logic updates (there can be even more loops). As far as I know there is no threading involved, instead the execution is handled by Kha's own scheduler. Iron's delta time is calculated in the render loop here.

What @knowledgenude probably means is that using forces to move objects is handled by the physics engine whereas simply setting the transformation just teleports the object and does not interact well with Bullet physics because of that.