Algodoo

No... stop... don't...

I said sometimes it's better, which means it's better if it's the other guy's files and not mine that are deleted.

Christer's Links:

Torque
HP

Nicely done. That was sort of exciting.

Thanks. Now that you see how it's done, maybe you can write a Poly2stl utility for people with 3D printers or a dxf2Poly utility for people who want to import something from CAD.

Nice work.

Feel free to use anything I make.

I considered all your suggestions and didn't do any of them.

Thanks. Fixed.

Yes, I'm fairly certain I got the idea from one of your scenes.

Nice improvement, but now I realize that the knob I made is not working as intended. My intention was to have a knob whose gain was dependent on the speed it was rotated, but that isn't happening since 1 revolution of the knob has the same effect regardless of how fast it is turned. I will change my knob to do what I had originally intended. This knob will most likely still be an improvement since the user will know what to expect.

Nicely done. Easy to play. Should be fun for all ages.

Thanks for the feedback both good and bad. I reset Algodoo and I can't force a crash. By crash I assume Algodoo gives a message and closes the scene unexpectedly. Any info as to what was done immediately before the crash might be helpful.

Xray,

Q: Am I not using it correctly?
A: No. "Click me" will always do the same thing unless you change the code in the onClick event. "OK" should send your input text to the magenta box.

Does this scene really crash or is the fact that the inputbox is deleted after use interpreted as a crash?

Hey. Somebody down-rated this. I guess after 7 days they finally figured out it was a joke (or else they just think the scene is broken). See April Fools' Day.

I agree with everything you said except #2

"Because you do not disable the tools with app.gui.playmode = sim.running"

because I do set app.gui.playmode = true in onSpawn and return it to the initial value in onDie, but letters "T" and "M" still require (2) hits. It may make sense for me to just forget about in box editing and just use the Algodoo widget.

Uses scene.my.length, not scene.my.lenght

In spring (not endpoints) postStep event:

maxVel := 1;
scene.my.length > length ? {
length = length + maxVel / sim.frequency
} : {
length = length - maxVel / sim.frequency
}

I did try it, and I know it works. The most probable cause of it not working for you is a spelling error. Here's more detail:

1. In the console, set scene.my.length := 1;
2. In your circles that get hit by the laser, change scene.my.lenght to scene.my.length.
3. Alt left click the spring to select just the spring and not the endpoints.
4. Right click the spring to get the script menu.
5. Copy the following code into the spring postStep:
maxVel := 1;
scene.my.length > length ? {
length = length + maxVel / sim.frequency
} : {
length = length - maxVel / sim.frequency
}
6. Right click the piston.
7. Click "Show plot".
8. Run the scene.

Interesting engine. For every piston there is another piston 180 degrees out of phase with it, but there is still quite a bit of vibration. I wonder if the vibration can be minimized by re-ordering the pistons. Good work at any rate.

Xray,

My understanding was that XO3-DAN-FR wished to control the spring. In many cases, I don't trust direct manipulation of object position or velocity. Braking the piston wastes energy whereas controlling the actuator (spring) should be more efficient. I didn't try your code until you questioned mine, but when I tried your code and plotted the speed, it made a weird trace. I believe your code is regulating the speed, but the trace doesn't show it correctly. So, how is my code better? Its not. Yours is shorter, simpler, phunletable, in one place, doesn't dither when at zero velocity, doesn't cause the piston to overshoot or undershoot, and gets the job done. I just took a different approach.

Works nicely for me if I slow down the simulation speed, otherwise my responses are not fast enough to get good control.

Rayon X,

Merci de prendre le temps de vérifier mon code .

I appreciate and agree with your comment, but I'm not sure what, if anything, I'm going to do about it.

Yes. Very good. Lots of power.

I did some adjusting, but since this encoder has almost 10X the counts per revolution as the older one, it has less margin of operation than the other one. The flickering may have been due to stray beams. I set maxRays to 1. A signal wheel will spin whenever the signal is a "1", which can happen even if the encoder is stopped.

Thanks.

Everything works great except the playback is a little offset from the original.

Regarding the playback offset, this is what I did:

_loop ? {(Scene.entityByGeomID(_geomID)).follow = true } : {};

For more details, see Turbo Encabulator.

Very cool. I've been following Joerg's videos for a few years now. He is very inventive and entertaining.

I've found that, with a little extra effort, you can get the horse and car to show up at the same time. The horse has one front hoof on the steering wheel and the other waving out the window, with it's mane is blowing in the breeze.

"I'm going to catch that horse if I can ... ...we'll be friends for life
She'll be just like a wife ... I'm going to catch that horse if I can" ... la la la la ...

Thanks.