Algodoo

Thanks. I didn't know that. I won't be fixing these guys anytime soon.

FYI Langton's ant

You forgot to synchronize your cardinal grammeters.

This is a boring scene. Maybe it will come in handy to someone who needs a counterweight for their mechanism. I wanted to show a progression of thought between successive designs. I couldn't find designs "B" or "C" on the web although maybe they would be "obvious to someone versed in the art".

If you magnify the brick wall one click using the texture tool, then the domino brick size will match the wall brick size.

If Algodoo had been around in 1914 we might have averted a world war.

This scene doesn't work at all for me. I reset Algodoo and it still doesn't work. It apparently works on vinodrai's PC. Maybe my PC is too slow or old or something. If anybody else reads this comment, then please let us know below whether it works for you or not.

Thanks. I don't know. Good idea. I concur. I will look into it.

Very concise coding. Way above average.

I did the following to eliminate flickering:
in _Create: timeToLive := 0.042;
in postStep: (e)=>{}
in update:
(e)=>{
sim.running ? {_Create} : {}
}

Nice work. Good visually and easy to use.

Coding Math: Episode 26 - 2D and 3D Coordinate Rotation

@rjoseph
Other users have been successful at using AlgoSound. Please don't add any more comments to any of my scenes as none of the comments that you added to any of my scenes (to date) have been useful and they are wasting my and other user's time. Don't expect me to respond to any of your comments.

Thanks.

I reread your comment in the original scene and now understand what you are saying. I did look for zero length spring straight line motion mechanisms, but didn't find any. I then thought about adding a zero length spring to a scissor mechanism and came up with this scene. The zero length spring in this scene could be replaced with the four bar spring mechanism in the previous scene, but I wanted to keep things simple so I "cheated" by using an Algodoo zero length spring.

Q: Does a "zero length spring" exist in real life?
A: My recollection is that a zero length spring can be made (an extension spring with a pre-tension = k*L), but it's not common. Many times a zero length spring is approximated using a pulley, cable, and spring, but that's hard to show in Algodoo because of rope weight and strength.

Sometimes it's easier to calculate using energy instead of forces. The 5 N load is lifted 8 meters, so that's 40 Joules. The spring energy required to do that is 0.5*k*x^2. Solving for k, k = 2*PE/x^2. For the right case, PE=40, x=4, and k=5. For the left case, PE=40, x=8, and k=1.25. I'm thinking that the 0.05 N/m increase in the left k is to overcome autoBend=true in the rope hinges plus friction between the rope and pulley surface.

Well done.:tup:

It does not make sense to change code on a scene that works fine, but that didn't stop me from playing around.

In console:
scene.my.raPulleys := [];
scene.my.updateLevel := (level)=>{
n := string.length(scene.my.raPulleys);
Scene.my.xFor(0­, n-1, (i)=>{
g := scene.entityByID(scene.my.raPulleys(i));
g._curr­­entLevel = scene.my.level;
eval("g.pos = g._activePos" + scene.my.level)
});
};

in pulley onSpawn:
scene.my.raPulleys = scene.my.raPulleys ++ [entityID]

in pulley update:
(e)=>{}

in "SUCCESS" box onKey:
keys.isDown("up") || keys.isDown("down") ? {
scene.my.updateLevel(scene.my.level)
}:{};

in layer1 circle:
... scene.my.updateLevel(scene.my.level) ....

To make edits:

1. Extract .phz images into the Textures folder using 7-Zip.
2. Open .phz and save as .phn.
3. Do multi-line search and replace using Notepad++.
4. Open .phn and save as .phz.

It's a fair amount of work for no noticeable change. I posted it here in case anybody wants to make big search and replace changes to a .phz.

This scene works flawlessly and is fun to play. I expected more downloads. One more good rating might get it into the "Highlighted Scenes" row that it deserves.

Q: Do you know of any real life garage doors that use that technique?
A: No.

Q: The scene is interesting and very well made.
A: Thanks.

Q: My only suggestion would be to make it move faster.
A: I posted a new scene that is faster. Rope slows this scene down too much.

Thanks. That brings up some interesting possibilities. I could create a remote digital keypad that will prevent unauthorized use of this scene.

Yes.

Kilinich uses the Ray casting algorithm. The first surface in polygon.surfaces is the outside surface. The other surfaces are holes.

It may make sense to find a radius to the farthest point on the polygon and store this value in the polygon. You only need to do that one time. After that, check to see if the polygon is in the bounding circle before you determine if the point is inside the polygon.

If you are doing polygons, you may as well do circles and boxes while you are at it.

Thanks.

Q: How does your code detect the line intersections and where does the ray start?
A: It's Kilinich's code. It works as follows:

count := 0
foreach side in polygon:
. . . . if ray_intersects_segment(P,side) then
. . . . . . . . count = count + 1
if is_odd(count) then
. . . . . . . . return inside
. . . . else
. . . . . . . . return outside

See Ray-casting algorithm

Kilinich calculates the mouse position relative to the non-rotated polygon. He then subtracts the new mouse position from each line segment end point. If the new endpoints are above and below zero, and the new line segment is to the right of zero, then add one to the count. If the final count is odd then inside polygon.

Q: Where does the ray start?
A: The ray starts from zero (which is the mouse position after translation).

P.S. I just noticed I did a similar scene 4 years ago with Mouseover Code Injector. My approach at the time was to divide the polygon into triangles made from the polygon center and line segment end points and then check to see if the mouse position was inside any triangle.

Checked it out. Good. Thanks.

Nice work. Works well at 60 Hz but the logic fails at higher simulation frequency. Kilinich, Xray, and I have all made scenes dealing with detecting when an object is not being hit by a laser (onStopHitByLaser event, onLaserStop event, and onNotHitByLaser). I will add a response scene that counts the number of lasers that hit an object in case that helps.

Deleted a bunch of code in this comment because that code is now in a response scene.

I ran into the same problem so I experimented with the code until I could get it to work at the full range of sim.frequency and simulation speed. I suspect Kilinich's code is efficient and works well, but I had a hard time understanding it.

The behavior that I recall seeing is that Algodoo may not calculate lasers every frame, but if it checks one laser during a frame it will check them all. Reporting a laser count every frame may report a zero or may report the actual count.

P.S. My new story is that a laser hit is detected once per frame but only if there is at least one tic during the frame period.

Q:"Example of laser hit count code." Isn't that describing one of your other scenes?
A: Yes, but it also describes the code in this scene. So this scene has all the necessary info without being directed to another scene.

Q: The printed diagrams that you copied and pasted from the Web (I assume) show A and B as input designations which is different from the logic gates in the scene. Same thing for outputs. Was that intentional?
A: Yes, I chose z and x because they are next to each other on the keyboard and I figured that user would be able to generalize the diagrams and figure it out. Now I'm thinking that clickable lasers may make better inputs.