Algodoo

Thanks for the link to the paper. Mori-d does some impressive work.

I noticed that my code extractor is very slow for big files. I'm working on a faster version.

Nice work. Works flawlessly. Very clean graphics and coding. Good video.

S: "I saved the scene."
R: Did you save it to the same directory that has the Algodoo config.cfg file and did you name it "scene.phn"?

When the text panel pops up it's done. Maybe it didn't find scene.phn.

Regarding the file location, it is now "Algodoo/scenes/" it was "Algodoo/". I initially thought that Algodoo could only read and write from the "Algodoo/" folder.

Regarding the file name, it is still "scene.phn" for the following reasons:
1. If I used a user supplied filename, then I would need to create my own filename input dialog and it would not be as good as Algodoo's filename input dialog.
2. Scenes are stored as "scene.phn" in the .phz file. I can easily open a .phz with 7-Zip and copy scene.phn to "Algodoo/scenes/".
3. If a user made a .phn scene with the same name as a .phz scene he might get the two mixed up and make changes to the wrong scene.

I'm impressed with how well this scene is laid out, how well it works, and how clean the code is. Excellent job. If you would like more realistic gears, then check out Spur Gear Generator II or Mechanical Toolbox.

Amazing and seamless.

Pedro,

Don't create variables in the console other than "scene.my." variables. Otherwise, the variables stay in your (and probably others that look at your scene) configuration file indefinitely. Once the _Main function is executed in the console, resetting Algodoo is about the only way to get rid of it. The _Main function that's polluting my config file doesn't even work. Algodoo assigns new entityIDs every time you start a scene so the old entityID that you saved is meaningless. You might have noticed that if you had tested your scene after uploading it. Search "root scope" or "global scope" in the forum to learn more. See Xray's SCENE.MY.VARIABLE DEMONSTRATION scene and hiscomment.

Examining the code using either of my Code Extractors shows:

scene.my.SpringLength = 0.316271;

Scene.addPolygon {
    onCollide := (e)=>{
        scene.my.SpringLength = 0.10000000
    };
    pos := [-8.5651327e-006, -0.0054667774];
};
Scene.addSpring {
    length := {
        scene.my.SpringLength
�­�   };
};

The polygon is the saw blade and the spring is the brake bar spring. The spring acts as an actuator by getting shorter upon finger contact with the saw blade.

Nice work.
⭐⭐⭐⭐⭐

I suspect that it runs well at 100 Hz because it has a spring powered engine as opposed to a spawn engine. In fact, I only see (2) onCollide scripts. I see most of the code is driven by lasers. Nice work on the code. I think spawn engines might be limited by the number of collisions per tick.

Thanks for the feedback. I agree with your analysis but make no promises to fix anything. I suspect that somebody could make a purely mechanical scrolling textbox better than this. Rack and pinion drive comes to mind.

Regarding lines of code, I've reduced the lines of code from 938 to 571 by eliminating code that allowed the scrolling textbox to run in design mode. The textbox is now more responsive. Since the scrolling textbox uses previously designed standard GUI components, only 33 additional lines of code were required for this scene. The _showText function in the display textbox does does almost all of the work.

Thanks. I yanked the racks and pinions out of an old Zeke's Peak arcade game.

Thanks. I still haven't found the best way to predict the amount of text to put into the text box when the textScale and box size are fixed.

Don't blame it on that guy, he's just a model. I said "... you kick ...". At any rate, it's probably not a good idea. A better idea would be to throw foam "rocks". That way you would at least have a head start when running away.

So can tricking (or kicking)the elderly without hurting them be considered elderly abuse? Most likely, once you consider the anguish they would probably experience when they see a fake rock being thrown at them. Better to target middle aged people to avoid elderly and child abuse.

Hi. I'm Charlie. I was playing Algodoo on grandpa's computer when a fire started in the kitchen when I was trying to dry my T-shirt on the stove (I spilt milk on it). I clicked the fire alarm button but the fireman never came. Grandma and grandpa are very mad.

I like the concept but the accuracy of the results was not as accurate as I had expected.

Suggestions:
1. Get rid of the clouds.
2. Use a Roberval Balance with pans below the beam for samples and pans above the beam for counterweights.
3. Increase the simulation frequency to 120.
4. Provide the equation for calculating the density of the "gold".
5. Provide a statement about the expected accuracy of the experiment.

Thanks. Done.

Yes. This is before I made "real" gears. For an interesting effect, select all gears and set their angle to zero.

You are right, the shoe and rock idea are too obnoxious. I will blame the initial idea on my watching too many violent cartoons when younger.

Q: How do you count CLOC?
A: See Code Extractor II or Code Extractor.

Q: Less CLOC = more compact code?
A: Yes.

Nice designing and coding but the scene is way too slow. The scene takes 30 seconds to load on my PC. Piece movement is too slow to be of much use. You might consider breaking the scene up into (2) scenes: (1) with chess instruction and customization and (1) with just the chess board and pieces. I don't know why Algodoo is considering 10142 narrow collision tests for this scene when everything is glued down.

P.S. Another option would be to replace the objects in the instructions with images and to provide sample tiles instead of sample boards. I tried this and now the scene loads in 2 seconds instead of 30 and the scene is very responsive.

I agree. I will consider it.

Thanks and welcome to Algobox.

Thanks.

Interesting. I haven't experimented with minus densities before.

OK. This is awesome. Very well done.
⭐⭐⭐⭐⭐

Awesome.
⭐⭐⭐⭐⭐

⭐⭐⭐⭐⭐