Algodoo

Thanks for the feedback.

Nice work on the scene and video.

Nice work. Very nice ride but I was unable to pop a wheelie.

FRA32,

Thanks for posting this scene. I was thinking about class creation recently, read the "How to make a new class?" thread in the forum, and then gave up. I like how the scene works but I don't like the changes it makes to the config.cfg file. After seeing that the config file was violated, I revisited the forum and see that Kilinich stated "Unfortunately, Algodoo could not serialize and save it, so you should be aware, all internal objects will be stored (and run) in root scope.". In other words the methods and variables (like add, get, entry0, entry1...) become root methods and variables in every scene opened after opening this scene.

See Re: How to make a new class?.

Thanks.

Nice work.

xRay,

I agree. Here's an idea that might work (but is probably more trouble than it's worth):
1. Create a startAlgoSound utility that starts AlgoSound minimized if it isn't already running.
2. Create a batch file that runs Algodoo and startAlgoSound.
3. Associate .phz files with the batch file.

The startAlgoSound utility could read the .phz file and start AlgoSound only if "scene.my.playSound" is found in the zipped scene.phn file.

I might experiment with this, but don't expect anything soon.

Another approach would be to put runVbAlgoSound.bat (or pyAlgoSound_05.py)in the startup folder, but I would consider that overkill since the program would always be running.

If you feel like it, you can try this:

1. Modify runVbAlgoSound.bat to look something like this:

@echo off
cd "C:\Program Files (x86)\Algodoo"
start Algodoo.exe
cd "C:\Users\Xray\Documents\Algodoo\AlgoSound"
cscript //d %~dp0\vbAlgoSound_05.vbs
exit

2. Put a shortcut to runVbAlgoSound.bat on the desktop.
3. Open the shortcut properties, select Change Icon..., Browse, and then click on Algodoo.exe. The Algodoo icon will then become available for selection.
4. Rename the shortcut to AlgoSound.
5. Double-click the shortcut. AlgoSound and Algodoo will open simultaneously.

Thanks.

Thanks.

Anonymously Anonymous,

Thanks for your feedback. I agree. I made this scene before I found out that there may be some level of immunity if you survive. See COVID-19 Simulation II for a scene that takes immunity into account.

I like your method, it is simple, direct, and doesn't require scripting. See Real Bending for an Engineering view of bending.

Nice work. I enjoy the videos.

Nice work as usual.

Below are some observations and suggestions:

1. Arch Example: Algodoo bricks above arch are longer than real bricks.
2. Beam example: Algodoo shaking frequency is twice real life shaking frequency.
3. The file size is 5,517 KB. The size can be reduced substantially (to 463 KB in my test) by doing the following:

Extract the zipped texture files in ALGODOO reality TEST.phz to Algodoo\textures.
Save ALGODOO reality TEST.phz as a ALGODOO reality TEST_01.phn.
Compress the added Algodoo\textures\images to .jpg files.
Open ALGODOO reality TEST_01.phn with a text editor.
Replace ".png" with ".jpg".
Save ALGODOO reality TEST_01.phn in the text editor.
Open ALGODOO reality TEST_01.phn with Algodoo.
Save ALGODOO reality TEST_01.phn as ALGODOO reality TEST_01.phz.
Delete all the recently added images in Algodoo\textures.

The process above typically takes me less than 5 minutes and can reduce the file size substantially.

I agree, Algodoo does look like the real thing. Nice concept. I think this may be the first scene where a real model and Algodoo are shown side by side. What application do you use for video editing?

Thanks Xray.

Q: Do you like video editing too?
A: I don't know, because I haven't really done any. I did like the part of the video where the Algodoo model overlaid the real world example.

Odd Squad,

Q: whats the number that changes how long people stay recovered?
A: fluRecoveredTime. The balls stay recovered (blue) for the fluRecoveredTime which is initialized to some random value between 100 and 200 days for each ball but can be changed using the "Coronavirus Settings" GUI. Balls in the recovered state have some chance of reinfection set by the chanceOfReinfection parameter.

I tried making a wall climber by using a Klann linkage but found out that the leg would be engaged for more than half of the climb cycle so I couldn't have one leg engaged and another released at the same time. It was then that I had a greater appreciation of your mechanism. Shortly after I came up with a simpler solution which I posted as a response to this scene. I hope you are not insulted by my scene. It's just me trying to find the simplest solution to the problem.

Yep, this is awesome. I would have given it a 10 just for the GUI.

So how did you figure out the addBrowser thing? The widget does not save with the scene. And when scene.addWebBrowser didn't work how did you know to ask God?

The GUI can be scalable if you set textScale = 0.029 * size(1) / 0.28125 in your code.

Thanks.

Thanks for the comment and rating.

I connected my Plot Widget to your Dyno. Check out the hinge._output code. Let me know if you prefer that I don't use your scene and I will delete my response scene.

I need to turn the motor off after the test. I will take this scene off-line while I fix it.

P.S.: The motor now turns off after the test but the motor may still break at high RPM. The chart now updates during the test. This can be turned on or off with the _liveUpdate parameter in the hinge.

The Linkage,

Setting hinge._liveUpdate to false will reduce lag since it will make just one plot at the end as opposed to constant updating. I suspect that Algodoo's plot uses exponential smoothing which is equivalent to a low pass filter. I think your averaging method is faster and more accurate. I liked your flashing cursor on the GUI input so I updated my GUI textbox to include a flashing cursor on the second click (first click highlights everything). Check out the text boxes on COVID-19 Simulation II.

Nice work. I tried counting with one laser by remembering the last entityID hit and only increment the hit count if there is a new entity. That failed when two balls rolling by were touching each other. I then tried only counting if the other entityID did not match either of the last two entities hit. This didn't work about 1% of the time and would never work if there were only two balls. I then tried putting in a delay between hit checks and that didn't work. So I like your approach a can't think of any better way. The only suggestion I would make is to put the laser counter and the collision counter on the same slide and put the counter displays side by side.

Suggestions:
1. Put all the balls to the left of both counters at the start.
2. Set maxRays = 1 for both lasers (or else you may get ~1% counting errors).

The following code worked for me with just one laser:
_eID := 0;
onLaserHit := (e)=>{
eID := e.geom.entityID;
eID != _eID ? {
my.scene.hits2 = my.scene.hits2 + 1;
_eID = eID
} : {}
};
maxRays := 1;

Looks good.

Nice scene. It's straightforward without distractions. I think younger kids will enjoy it.