Don't have an account yet? Then register once and completely free of charge and use our wide range of topics, features and great options. As a registered member on our site, you can use all functions to actively participate in community life. Write posts, open topics, upload your pictures, put your videos online, talk to other members and help us to constantly improve our project and grow together! So, what are you waiting for? Become a part of us today!
Login or registerTo get support for a technical issue such as installing the software, to query a purchase that you've made/would like to make, or anything other than using our software, please visit our Customer Service Desk:
Open a Ticket
They don't use delta time in the physics extensions for some reason (even though it's possible) - There is no way to make sure the physics simulates the same way with frame rate changes until they add this "feature".
Please login to see this link. - for any Clickteam programmers reading this thread 
It is possible as shown in this example article.
Using delta time for physics is never a good idea. Even the Unity engine which seems to revolve around a (flawed) variable timestep paradigm, still runs its physics on a fixed timestep. With variable timestep objects could easily go through walls and glitch out as their movement is extrapolated inconsistently. "Real" physics is kludgy and non-deterministic as it is, why make it worse?
Checking "machine independent speed" in the application settings will run multiple updates to catch up when the drawing is slow. This gives you the best of both worlds --- your game will run on a fixed timestep, but it'll keep a similar speed when the framerate drops, it'll just look chunkier.
You can set an alterable value to pvelocity, and check the alterable value so you can check it for individual instances.
Don’t have an account yet? Register yourself now and be a part of our community!
Almightyzentaco (Fusion 2.5 Tutorials)
Captain Quail (Firefly Tutorials)
