It works better with higher torque. The script seems to apply braking in a sort of wave when the RPM goes above maxRPM. So if there is more torque, the waves happen less often and smoother braking is achieved.
Could you make my scene "Transformer Worm Game" automated? So the worm switches its forms on its own and knows where to do it and how to get over the obstacles.
Also you could just draw an object and set its collision to the layers you want in your script, then just look at its collideSet number in its script menu.
The housing is the only really unbalanced part, and since it only moves at half of the engine's RPM its vibrations are not a huge problem. Also there could be "plugs" of high-density material installed in the ported side to counterbalance the solid side. They would simply be holes drilled in the valve and filled with tungsten or lead.
Scaled circle gears are also noisy in terms of input vs. output. Since circles have more curvature than the angle the teeth collide at, they jerk at each tooth and make a rough output. The polygons are more accurately shaped compared to the motion of the teeth.
Because I need linear gear racks too. Also Kilinich's gear generator does not work in grid sizes nor does it have odd tooth numbers. And it cant do racks. So its not helpful.
I could make a multilayer one, which is like this except copied multiple times on different collision layers and then all glued together. I am going to make a mini version that is also mobile.
@ngphil lethalsquirrel didn't build any part of this engine... he just resized mine and made it a scene response. If you want to see the REAL master, go take a look at the actual original scene, that I actually made.
Well, I was originally going to build a factory thing powered by a spawn engine, but then after I looked more into this engine it seemed to be better. Also I am going to make one that is much larger than this, just for the purpose of the factory (although I am still too lazy to build the factory)
Well, nothing in algodoo is COMPLETELY correct, the program allows for some slight error to improve performance. This tiny error is what makes the squares fall over after 5 seconds.
How it works: On the up-stroke, the piston's airFrictionMult = 0. On the down-stroke, the piston's airFrictionMult = (a very large number), causing this to move the car. Larger pistons make more power because they have higher resistance for their shape. But, adding in the velocityDamping, the density now matters. VelocityDamping is basically how much it resists movement. Its kinda like inertia but it can be adjusted in 3 dimensions: x-velocity (left and right), y-velocity (up and down) and angular velocity (rotation). I used this to stabilize my floating car scene.
Well, theres a small circle inside that sets its own angular velocity to 0. Using the rotate tool can change the angle without changing the angular veocity. When you flip it, its supposed to return to an upright position. Thats the stabilizer doing its job: Keeping the car from flipping.
Its almost impossible to make a car go over 400 m/s and have it still be like a car. Of course it will have some plane-like technologies because planes ARE made to go 400 m/s and much faster than that also. Plus I wanted to simplify it so I used dynamic suspension. The red balls are just to measure how much upward force the levitation jets need to apply, theyre not wheels and they even have 0 friction, not too useful for a wheel lol.
I am going to make a 2-axis VelMeter that works with a "negative" velocity, that is, just moving down or left. Up and right are positive velocity, and thats why this sensor doesnt work moving left, because I cant get the absolute value.