Algodoo

Thanks

Excellent scene for the following reasons:
1. I've haven't seen a 2D puzzle like this before.
2. I think kids will enjoy it. Especially those who like building stuff.
3. It could be used as a test to see at what age kids acquire this skill.
4. The game can be used to help kids acquire this skill.

I think short instructions for kids may be good. Maybe "Touch (or click on) the knob that you think can be pushed towards the middle of the box." or "Touch (or click on) each knob and see what happens"

Nice work.

Xray,


Yes, I think a capacitor (E = 0.5CV^2) is like a spring (E = 0.5kx^2) and an inductor (E = 0.5Li^2) is like a flywheel (E = Iw^2).


JakubKubo,

I assumed there were cars out there that already had this feature but did not know which ones. Thanks for the info. I also noticed a weakness in my system in that the red car can back up and force the blue car to back up and hit a third car. Maybe you can fix this in your spare time.

FRA32,

Good explanation. I never thought about it in those terms. Thanks. I found System equivalence interesting.

Thanks.

See description for pi bouncing balls for a description and formula.

Strv-7,

I noticed that and had checked it out.

Nice coding and demonstration. Check "Improve arrow stability" or increase sim.frequency for more stable or accurate force values.

Very nice. It needs a "You are here." pointer.

Stated Problem: My concern is that if I double the size of a button in one dimension, then the border for the wider dimension will be twice as thick.

Solution: Change the size of the buttons, save the buttons in scene, and then reload the scene. The button borders will all be the same size.

P.S.: Thanks for the suggestion. I may be able to use it elsewhere. I probably should have mentioned that the buttons re-scale on re-load. There may be other functions of the controls that only work upon re-loading. So if the controls don't work as expected, then try reloading the scene.

Thanks for the feedback guys. Please let me know if it still explodes. It does not explode on my system.

Canyonero

Thanks guys. It's good to hear from you.

Here is a suggestion in pseudo-code that may or may not help:

Get a word by capturing keystrokes the same way that it is done in your "Guess Your Animal" game.
To feed font-man:
wordList := string.str2list("theWord").
targetPos := [-7.0, 19.0]
For i = 0 to string.length(wordList) - 1
<tab>letter := wordList(i)
<tab>letterPos := targetPos + [2.35 * i,0]
<tab>spitLetter(letter,letterPos)

Got it. I don't take it personally if you don't use my suggestions and suspect that you don't take it personally when I don't use your suggestions. Tight code is not as important as new ideas and proper functioning. Your scene is different, amusing, and works as advertised.

Well done. I'll give you a real 10 instead of just saying 10/10.

I moved all the axles back and it works much better now. Thanks. I did some experiments trying to move axles to a separate layer, but was unsuccessful.

I rated this scene a 6 because that's the score I got. Good job. I like the game.

Thanks.

Regarding "Press 2 to pick a course", the postStep code in the box on layer 1 does not work for me. If I copy and paste the box to layer 0, then course selection works as expected. Is anybody else experiencing course selection problems? I can't get any postStep code to work on Layer 1 (even after resetting Algodoo).

Hey there are no comments, no ratings, no high score postings. Does this scene work OK?

Works good now. I didn't think to look or notice that the gear was dimmed.

Thanks for the feedback faytree.

Nice work.

Here are a few thoughts regarding this scene (probably all stuff you already know):
1. If the predicted polygons have color := [1, 0, 0, 0], drawBorder := true, and opaqueBorders := true, then the predicted polys will be "frames".
2. Different color polys will help with associating future polys with the respective source.
3. I expected higher frequencies to result in more accurate predictions, but I'm not sure that's the case.

faytree,
I just noticed that my initial response is a specific solution (acceleration = [0.0,9.8]) while your approach is more general and should work in any gravity. Your approach also handles internal energy sources (thrusters). I will update this scene for a more general solution. Feel free to use anything in this scene.

P.S. So I just realized that the spawned objects on layer1 are not moving, providing a snapshot of the future position. This means that my adding velocity and angular velocity to the spawned object has no effect. Density also has no effect on the spawned object, so I removed those (3) properties. I also had tried gluing spawned objects to the background but that slowed things down big time. I have this feeling that I'm rediscovering things that you had already figured out.

Thanks.

Nice work.

2520

Xray,
Thanks for bringing that to my attention. I will need to figure out a way to do that.

JakubKubo,
No code. The up/down keys are assigned to the gear hinges on each side of the game. They are hidden by (2) large black boxes, (1) on each side of the game. Pull the boxes away and you will see rack and pinion steering for the ball bar.