Algodoo

Thecareditior,

Q: Pretty smart huh?
A: Yes. I was thinking of writing script so that the second car automatically follows the first, but I think rope may be the simplest solution.

P.S. If you make a response scene to this that uses invisible rope and name it "Automatic Car Following System(ACFS)" then most people will assume you used script. Don't worry about others reading this since most users download scenes without viewing them or checking comments first.

Excellent first scene.

You could use the green bar pos and angle properties along with the tracer relPoint property to determine the actual tracer position. The tracer can store its color, size, fadeTime, and relPoint properties (without using Scene.my. variables) on the green bar before being killed. The new tracer can be initialized using properties stored on the green bar. Any subsequent tracer changes can be stored on the green bar. The only Scene.my. variable required would be Scene.my.clearTracer.

Look at the hinge code in the original Gumby scene.

Feel free to embellish the scene with roads, buildings, obstacles, or any other ideas you have.

Nicely done. I had to pull it apart and read Wikipedia to figure out how it works. The fact that it runs over such a wide sim.frequency range indicates that it is well built.

I don't think this is caused by stick-slip because there is no difference between static friction and sliding friction in Algodoo. You will have to dig deeper to get the answer.

650

... OR wait long enough and you will fix it. That works for me.

Real world physics.

Close, but you are not quite there yet. The tracer moves a little bit each time you clear the trail. Put the tracer on the circle cake and then clear the trail and you will see what I mean.

You might be there, but I see a potential problem. You create the new tracer before deleting the old and both tracers have the clearTracer code in them. Algodoo deletes the old tracer first, but is this guaranteed to happen all the time? Also, if the circle's code is run in two consecutive sim periods, then the tracer is lost forever. If you move the circle's code from postStep to onHitByLaser, then you might see what I mean. Another way to see it is to set the sim speed to 0.01 and click "Clear Trail" repeatedly. This is not a problem for this particular scene, but it may cause problems when this concept is applied elsewhere.

If you replace

Scene.my.clearTracer = true

with

scene.removeEntity(Scene.entityByID(_tracerEntityI­D))

then the problem (that you don't see but is really there) will go away.

P.S. An easy way to check it before and after the change is to place "scene.my.clearTrail = true" in the onHitByLaser event of the circle and then add a laser to the scene that is activated by a keypress.

Q: What went wrong?
A: I'm not sure. The code you stated above works OK for me when in the postStep event. The only thing I can think of is that when the removeEntity line of code is copied from the web page to postStep it does not copy correctly. If I copy the removeEntity line of code from the web page to Notepad, I can see that an additional character shows up.

P.S. I tried the laser test mentioned above on your scene and Algodoo crashes. Algodoo does not crash if the code is in the postStep event.

Looks like you are covering all of the bases. One particular word from your answer above would be a sufficient answer.

Yes. Works well. I tried a variation that is interesting, but is not as easy to implement as yours.

In Circle postStep:

scene.my.clearTrail ? {
scene.my.clearTrail = false;
myTracer := (readable(scene.my.newTracer));
tracerPos := pos + myTracer.relPoint(0) * [math.cos(angle), math.sin(angle)] + myTracer.relPoint(1) * [-1.0 * math.sin(angle), math.cos(angle)];
tracerID := scene.my.newTracer.entityID;
cloneEntityTo(entityByID(tracerID), tracerPos);
removeEntity(entityByID(tracerID))
} : {}

in tracer onSpawn:

scene.my.newTracer = entity

The only problem with this is that scene.my.newTracer has to be initially set to the present tracer in order for the scene to start working. This can be done by saving and reopening the scene.

Your scene is better than this because it doesn't require an explanation.

I've been looking at the Wankel engines of lethalsquirl, Gent, and The Linkage and have the following comments:

1. The scenes all work well but the engines seem limited by the time between successive calculations. All engines go faster at higher sim.frequency.
2. The Linkage's stretched timing wheel hinge is done the best. It uses bend, bendConstant, bendTarget, and motorTorque to maintain the timing angle. Using autoBrake sometimes doesn't work (even with +inf motorTorque) because there is a chance for slippage. I'm not sure what Gent's doing with his stretched timing wheel hinge. It works well, but it has a high hingeConstant and is turning backwards.
3. Gent and lethalsquirl have some loose hydrocarbons because when I "Zoom to scene" I get lost in the ozone.
4. I will make a scene that will show how to make the timing angle adjustable. Maybe it will help optimize the engines.

Kilinich,

Q: Why in postStep?
A: I had a reason, but it's long forgotten. I'll assume that your suggested method is more efficient and use it unless I hear otherwise.

Thanks for the feedback.

Xray,

Q: Is there elasticity in the stretched hinge that would cause phase lead or lag between the two wheels under varying load?
A: Yes, this is set by the bendConstant property of the hinge. In this case I set it to +inf.

Q: If that could happen ...
A: I will test for lag and post results in this comment.

P.S. The average lag is zero if bendConstant = +inf. The variation in the lag is relatively small and can be reduced with higher sim.frequency or slower motor speeds.

Elegant.

Xray,

Q: Does the parachute shape have any functional value?
A: Yes, the part of the circle that is removed is the part of the large gear that would interfere with the smaller gear in operation. If it wasn't removed, then the gears would jam.

Gent,
You may be right, show me in a scene where a scaled inner gear outperforms this design. Generally speaking, circles outperform polygons, but it may boil down to the number of collisions that have to be calculated per unit time. If you view normal forces, then you will see that this design generates one collision at a time and that there is little free play between the gear teeth. I'm not sure the same can be said for a scaled down inner circle gear.

Near perfect. Works well, but I have some questions about your magnet construction. According to my calculations, the average diameter of the coils is 0.823 meters. Are you sure it's not 658 turns around a 0.5 meter iron core? Also, I hope you provided cooling for those coils since the maximum rated current for 14 gauge wire when used for power transmission (meaning tightly wound) is 5.9 amps.

Nicely done. Works well.

Yes, better.

It must be possible. This scene proves it.

I can't quite figure it out. My best guess is that you maximized, minimized, or minusized something with script.

These are all good ideas. I choose not to do any of them. Feel free to improve and repost.

Cassette tapes typically run at 1.875 inches per second. The driven reel is driven fast enough so that it reels up the tape faster than the capstan and pinch roller are supplying it (even when just starting, which is the worst case). The driven reel has a slip clutch that allows for overdriving. Since the tape moves at a constant speed, the area of the circles representing the tape on the driver and the driven spools should increase or decrease their areas at a fixed rate. The angular velocity of the reels should be the tape speed divided by the reel (circle) radius ((in/s)/(in/radian) = radians/sec).

P.S. "Play" is described above. For FF and RW, the driver reel tape circle radius grows at a constant rate. The driven reel tape circle area is the total tape area (which is constant) minus the driver reel circle area. The driver angular velocity is fixed. The driven angular velocity is the tape speed (driver angular velocity * driver radius) divided by the driven radius.

Yes, it does look realistic. The only thing I noticed is the tape changes from brown to black when going from reel to reel. Also, there are probably only a few of us that remember "Realistic" (Radio Shack) cassette tapes.

Awesome. I was amazed at how cool the smashed copter looked (not that I'm a bad driver ).

Regarding smoke:

If you replace "density = 0" with "Scene.RemoveEntity(entity)" in your smoke script then you won't get all the "ERROR - Body::IsBad" errors in the console. Another approach is to just use v2.1.0 (since it is now free) and set the timeToLive property of spawned smoke.