Algodoo

Thanks for all the great scenes. I'm glad I was (am) one of your subscribers. Good luck on your new venture. You can still post scenes if you change your mind, but I can't guarantee that they won't be buried in spam.

We feel your pain.

Like Xray said.

Q: If we were to run your test code on, say ten, different computers, would the results be the same?
A: No, since the results are not always the same on one computer.

There is probably a way to calculate the theoretical minimum time.

One way to cheat is to increase the simulation speed.

Q: How can you get a time of 360 when the Remaining Time timer times out after 60 seconds?
A: Pause while swinging.

I concur. Marble races and Algowhateverathons can be directed to a specific section for that purpose. This can be accomplished with code that does it automatically on the upload page by looking for key words. Another option would be to have a batch file that could run a SQL statement nightly to redirect marble races to the correct section.

Braking Time:

PE = 28.7 Joules
F = 2.5 Newtons
d = PE/F = 11.48 meters

d = 0.5 * a * t^2
t =(2 * d / a)^0.5

m = 2 kg
a = F/m
a = 1.25 m/s^2

t = (2 * 11.48 / 1.25)^0.5
bt = 4.29 seconds

Non-Braking Time:

period = 3.9 seconds
number of periods = 2.25

nbt = 3.9 * 2.25
nbt = 8.78

Total Time:
tt = bt + nbt
tt = 4.29 + 8.78
tt = 13.07

This is the minimum stop time. This time does not account for air resistance during braking, or the last braking pulse, which would tend to increase this time slightly.

Good, except I don't think thyming is a real word

Looks good.

Nice work.

Awesome.

Nice work.

I rearranged the math as follows:

d1 := math.vec.dist(scene.my.s,pos);
d2 := math.vec.dist(scene.my.s2,pos);
a1 := (sim.time * 10 - d1) * scene.my.a;
a2 := (sim.time * 10 - d2) * scene.my.a;
c1 := 0.5*(sin(a1) + 1);
c2 := 0.5*(sin(a2) + 1);
color = [0, 1, 0, c1 + c2 - scene.my.b]

but the scene ran slightly slower.

I posted the math here to help users understand how the math works.

That is the bearliest car that I've ever seen in Algodoo

Like Xray said.

Nice work.

Ok, this is awesome.

P.S. You need one more general instruction included in the scene: "Draw stuff in the white area, increment the frame, repeat...". Also you should turn off gravity.

Nice work. I added it to my favorites.

This is my take on the situation:

Although I'm not a big Algo-whatever-thon fan (or marble, gun, or bomb fan for that matter), I agree with Ultragamer564 on this one. This scene is offensive to a certain group of people and it's inappropriate for one of the leaders of Algodoo to create it.

Regarding "algodoo isn't MADE for camps and that dumb stuff", users can make whatever they want with Algodoo.

I can sense Xray's frustration in this scene. I can understand why somebody who takes a fair amount of time and effort in making good scenes would be annoyed by someone who cranks out 700 low grade scenes in 4 months.

I agree that this scene is fairly low on the offensiveness scale. I think that it is a useful scene from the standpoint of promoting a discussion about AlgoWhateverathons. I suspect that you are a leader whether you want to be or not based on the following facts:
1. You are at, or near, the top of the list for the number of good quality scenes.
2. You have made more comments than anybody else in Algobox.
3. You have the second highest number of subscribers.

We feel your pain, but I don't understand why you deleted most of your scenes. Why punish everybody for the actions of a few?

I had to look at this a little while.
This is my interpretation (for marble race fans who might have a hard time understanding this scene):

There are 3 axes (@ 0, 60, and 120°):
1. Fill left container (0°).
2. Empty right container (60°).
3. Transfer water from left container to right container (120°).

There are two chart labels:
1. 0 to 5 for the left container water volume.
2. 0 to 3 for the right container water volume.

Kilinich,

Have you tried out any 3D physics engines or applications? If so, is there any one that you like?

I tried a trial version of SpaceClaim with Dynamics for SpaceClaim. It worked well, just like in the video, but costs about $7000. I was looking for something along the lines of a 3D Algodoo for a little less dough.

Nicely done.

I would expect the clutch to release when key pressed and engage when key up, but no big deal.

P.S. I guess that wouldn't work unless the truck had neutral.

Now I'm not saying that anybody should do this, but here's an idea:

Idea deleted because it was too diabolical.

In Algoryx and SpaceClaim's defense, SpaceClaim is a very advanced and easy to use CAD package and I don't know of any other CAD packages that include a physics engine. To be able to create a design and simulate it's operation very accurately before actually making the product has the potential of saving big bucks.

Nice work!

Well done.

Good idea!

Perfect? Well, that's a bold statement. Maybe near perfect. Get rid of the clouds and get past the 64 tooth limit by using Kilinich's xFor function.

_xFor := (n1, n2, code)=>{
n2 > n1 ? {
m := (n1 + n2) / 2;
_xFor(n1, m, code);
_xFor(m + 1, n2, code)
} : {code(n1)}
};