Algodoo

Looking good.

Thanks.

pnvv,

I can do that in design mode, but I don't know how to do it when the simulation is running.

Some animation frames missing. Every image used in the animation must be displayed somewhere (you can put them off to the side) when the scene is saved or else the images don't get saved in the .phz.

Yes, that scene is now working correctly. No need to change the code, but the following alternate code also works:

cost := math.toInt((10 * (sim.time)) % 17);
texture = ["frame_00000.png", "frame_00001.png", "frame_00002.png", "frame_00003.png", "frame_00004.png", "frame_00005.png", "frame_00006.png", "frame_00007.png", "frame_00008.png", "frame_00009.png", "frame_00010.png", "frame_00011.png", "frame_00012.png", "frame_00013.png", "frame_00014.png", "frame_00015.png", "frame_00016.png"](cost)

or this:

cost := math.toInt((10 * (sim.time)) % 17);
cost > 9 ? {
texture = "frame_000" + cost + ".png"
} : {
texture = "frame_0000" + cost + ".png"
}

Nice scene. The only time I would use the system clock is is if I were to make a real clock in Algodoo. Other than that, system time has no meaning in Algodoo.

Nice work but needs brakes. Also you could select everything on the vehicle then do 'controller > mirror key > r' to make the vehicle reversible.

Good work. I gave this a high rating because, after trying to do something similar, I can appreciate the thought and effort that went into making this scene.

Thanks.

Thanks. Yes.

Nice work.

A prismatic joint is to linear motion the same way a hinge or axle is to rotary motion. It might be used to guide a cylinder in engine. In other words it could guide a slider in a slider-crank mechanism.

Thanks guys.

DrBalk,

I see FRA32 did a good job answering your questions. Regarding "the makeIce-function i can find by unzip later and analyse it", there are a few other ways to see it:

1. Save the scene in Algodoo with a .phn extension and the open up the .phn file with a word processor.
2. Enter "scene.my.makeIce" in the console window.
3. In this scene, if you zoom out, you will see the scene.my.makeIce function text in a small box on the left. You will notice that the script to generate the text is 'text = {"scene.my.makeIce := " + scene.my.makeIce}'. I had made that box to make it easier to copy the function text.

Hey, this doesn't work when you add a connecting rod to the slider. The connecting rod doesn't seem to have the ability to hang on. Using a stiff spring as a connecting rod works OK. Looks like I will have to try to improve this. Good thing I noticed this after the high ratings.

lololoer,

I ran the scene in the link, but I don't understand what you are getting at. It looks like the rail is unglued and the hinge with the bend constant is missing. The slider still goes in a straight line but its angle is not constrained.

Statement(S): If you unglue the rail the box with the hinge will not follow it.
Response(R): True. The rail, along with the hinge joining the slider and rail, determine only the angle of the slider.

S: Your code only works if the rail is glued to the background.
R: False. You can unglue the rail and connect it to the background or anything else using two hinges and it will work OK.

I noticed that the hinge connecting the rail and slider was missing in your example scene. You may have inadvertently deleted it.

Nice work. I suggest not spawning the blue, non-prime, squares but moving anyway so that you end up with the same pattern but without the blue background. That way Algodoo can maintain less objects.

Very cool. I downloaded the .jar and ran it. It only took about 7 seconds to generate the pattern. I can now see the diagonals and there appears to be dark vertical line below the origin. Also, on the average, it looks like the density is fairly uniform.

This is a good scene, but your scene is messing up Algodoo on my PC. I've had to reset Algodoo on my PC several times in the past few weeks and I've traced it down to this scene. What is happening is "scene.my.for" is defined in the onSpawn script as "scene.my.for = (n, i, action)" instead of "scene.my.for := (n, i, action)". This causes the definition of the "for" function in the configuration file to be overwritten in the .cfg file. I wouldn't expect Algodoo to do that, but it does. Once the .cfg file is changed, any scenes that use the "for" function are broken. To fix this problem, change "scene.my.for = (n, i, action)" to "scene.my.for := (n, i, action)", and then resave your scene. You should also reset Algodoo on your PC. ":=" is used to initialize functions or variables. "=" is used to change definitions or values after the function or variable is defined. Please comment when the scene is fixed.

Nicely done. I was wondering about what prime numbers would look like on a spiral, but I wasn't sure what kind of spiral to try. Now I get to see what it looks like without having to do any work.

When you figure out the prime series, they will name it after you. You probably have as good of a chance of figuring it out as anybody else. Regarding the series of differences, that's an interesting approach. I did a similar thing where I was looking at the ratio of number of prime numbers to the total number of numbers as the square spiral progressed.

Regarding "I swear that it might be possible.": No, it isn't, but very cool machine anyways. The system can't automatically increase its energy unless it gets some from outside (solar, wind, human push ...). This scene is mainly a demonstration of the inaccuracy of Algodoo at a 60 Hz time step. Increase the frequency to 1200 Hz for more accurate results.

Use the "show plot" menu to plot 10 seconds of hill climbing (position(x) vs. time) at 60 Hz. Then hit undo, change the frequency to 1200 Hz, and start the simulation. You will end up with both plots on the same graph. The 60 Hz plot will have a slope of 0.030 m/s. The 1200 Hz plot will have a slope of 0 m/s.

Regarding "a lot of math", analyzing the system from an energy standpoint is usually easier than evaluating forces, torques, tensions, and angular velocities.

When the car goes uphill (at 60 Hz), it increases its potential energy. Where does this energy come from? I'm thinking that it's powered by Algodoo rounding errors.

P.S. I think that you are a smart and creative guy and I hope that my response increases your thirst for experimenting and analyzing instead of damping your spirit. I'm your first subscriber.

Worms rule!

Nice work.

If I understand it correctly, you don't believe the law of Conservation of Energy applies in this case since an Algodoo scene shows otherwise. I think FRA32 got it right, Algodoo has calculation errors. Usually they cancel out, but in this scene there must be some bias. Think about it. If you have 222 bodies with 223 constraints running at 60 Hz, then Algodoo is running at least 13380 calculations a second, each one with an error of up to 0.0166 seconds. If you make a simple scene of a circle falling 1 meter onto a plane and use script to time the fall, then you will find the time will differ from the exact value by at most 1/sim.frequency. The 1200 Hz timed fall will be much more accurate than the 60 Hz timed fall, but in no case will the number be exact. I think the same applies here. The car will go slower (in real and Algodoo time) at 1200 Hz than at 60 Hz, but in no case will the car stop.

Stop whining and make more stuff.

You could use a real Sprocket and Chain.

I got beat by a worm. How humiliating. Looks like I need more practice. Nice work.

Nice work.