Hello. My username is 4EHE and I recently have been working on a very complicated motor to put into a washing machine model. Here is what it is looking like currently: robloxapp-20200711-1753024.wmv (1.4 MB)
-I have it physically set up with 32 AlignPosition Constraints and depending on which one is enabled, they determine the orientation of the rotor on the axis which it is spinning upon
-I have scripted it so that a numbervalue (going up to 32) determines which of the constraints are enabled at what time. (Numbervalue is being used so that a seperate script can see which intended position the motor is in)
-The other script (the script that reads the numbervalue and actually makes the change) is activated whenever the value of the numbervalue changes.
The number value is being changed by a while true do loop, which greatly limits its frequency and thus
the rotational velocity of the rotor.
-My goal is to get it up to a much higher rpm than I am currently able to do.
~How can I do this?
~How could I make my scripting more efficient?
To my knowledge, you can not go faster than the ~.03 seconds the while loop runs at. There are other options such as Heartbeat, Stepped, and if you are doing it from a local script, renderstepped.
Heartbeat, RenderStepped, and Stepped run every frame.
And here’s the image that you might see passed around when rendering is brought up.
Any callback passed to the listener for RunService.Heartbeat will run on a new thread unless you yield within the callback, in which case it will re-use the thread (same thing with RenderStepped? Don’t know) , don’t yield and you can still do
local i = 0
game:GetService("RunService").Heartbeat:Connect(function()
i += 1
print(i)
end)
Running expensive operations within RenderStepped will delay the rendering of the frame. If you’re doing something that you think could continue into the next frame, definitely use Heartbeat.
You should really only be using RenderStepped for camera related stuff (ViewportFrames, custom camera, having something positioned based on camera, etc.) that needs the quick response time.
The obvious question here is–with all the ways you can spin something in Roblox–why would you make a washing machine turn using discrete align position controls? Are you trying to get Roblox physics to simulate a synchronous motor for acedemic reasons, or do you just want the thing to spin?
The short answer to your question, as asked, is NO, the 60Hz rate of Stepped is as fast as your changes will be processed, and if you update the properties multiple times in the loop (without a yield), only the last change will matter.
To go faster, your only option is to skip poles. And even then, the Align constraints use PD controllers, which take time to converge on their target, so if you skip too many poles you might find your motor having phase lag at first, then possibly even reversing direction or getting stuck vibrating.
Unfortunately that is exactly what happens. I made a 16 pole version of the motor and still can not rotate it very quickly. I found that I can go much faster using Heartbeat but when using that method the frequency is no longer controllable. Like many amazing projects, this one has to be scrapped because Roblox is too primitive to support realistic systems.
You could possibly put a for loop inside of RenderStepped or something, and maybe get faster loop, but I am not sure, and if you set the for loop to large number, it might crash the script. It might also go behind and be inconsistent.
It’s not that Roblox is primitive–the physics solver is actually quite state of the art–it’s just that ultimately, it’s a discrete time-step simulation without continuous collision detection (typical for game engines), designed for a world that gets rendered at 60 FPS. There really isn’t a lot of need for simulation of things happening at frequencies, because it won’t look any different than something that is in the 0-30 Hz bandwidth available. Beyond about 1200 rpm, you won’t clearly be able to tell what direction something is turning, and something turnin at 12000 rpm will look just like something at 1200 rpm. So when you need to accurately depict something like the shaft angle of a high-speed motor, you normally just compute it as a function of time, not try to physically simulate it.
Put another way, if you want to do a good physical simulation of a high-frequency system, in a time-stepped manner, your simulation rate should be much greater than the highest frequency present in the system. Game engines are not a good fit for this, they have different priorities.
