Algodoo

Yes, Emil must have known that I was going to develop AlgoSound and put e.soundGain in Algodoo just for me. See AlgoSound for details.

I think that might be John Henry's great granddaughter.

Nice work. I used a black background for better visibility and used Selection>Follow for the box. The tracer died after 543 seconds on my computer.

They are approximately the same area. You can be very sure that they are NOT the same area. The scene title, description, and the statement in the scene are all lies since they are not exactly the same area.

Yes, I could do it like in your "Fishing Game V2", but if the grasshopper is between mouths, the fish may flip back and forth indefinitely.

Nice effect.

Thanks Xray.

Thanks Xray. The scene looks simple, but it took me quite a while and a lot of iterations before I got this scene the way I liked. I find that I get more interested in stools as I get older.

I'm impressed. Correct me if I'm wrong, but this is a totally new and unique game. Nicely done, visually and code wise.

Nice presentation. Works well. I can see that there is a lot of support mechanism that is not being shown. At 559 objects, this is quite an endeavor.

Q: I wish I knew what's causing my config file to become corrupted!
A: Rename the config.cfg file to oldConfig.cfg and start Algodoo. Algodoo will reset automatically and you can compare the new config.cfg file to oldConfig.cfg. The problem then becomes finding which downloaded scene caused the change. I downloaded your "Flipping Mirrors game", compared config files, and can see new variables beginning with "my.". I don't believe that was causing your problem though.

@The Linkage

Nice mod with the closed and ground springs. The springs were the only thing (other than that (1) visible hinge) that I thought could be improved but I didn't say anything because I thought it was nit picking.

Good.

Thanks Xray,

1 m = 1 inch.
1 N = 1 pound.

Gravity is off, so I don't have to worry about body forces.

I played with this for a while. Regarding lag, the scene works good normally but lags excessively if the circles are glued to the background. I made a response scene. Let me know if you are not OK with that and I will remove it.

P.S. I really liked this scene and rated accordingly.

Statement: The addition of the colored tracers really help tracing where all the points in this chaotic cloud originate from!
Response: That's what I though until I read your explanation a second time and realized that the points all go back to the exact spot they originated from. The info that the tracers do give is the point's original color.

S: I always give my scenes a white background, yours are always black.
R: I originally went black in order to minimize UV from CCFL tubes on user's faces. I no longer believe it matters much but continue to do it out of habit (and a black default scene).

I think your scene may provide the formula for world peace. Have each resident of a country visit 15 other countries. Spend enough time in each country to know the people and learn the customs. Eventually come back to your original home. That way the residents of a country will be less complacent when the rulers of the country decide to bomb other countries.

I see you found some use for my Shrink Ray.

Thanks for the info and video link. That was very interesting. Regarding "two dashpots that were mostly used to dampen two negative effects of the capstan drive", I suspect that the dashpots were on tape tensioning arms, since the capstan drive is a rotary device, while dashpots are linear devices.

I think that Airpel-AB Air Bearing Cylinders, which are made from the same company that makes glass dashpots with graphite pistons, are also interesting.

Q: By the way, with all the calculator scenes in the Algodoo archives, why upload another one?
A: That's because I was more interested in the GUI than the calculator operation. So what if the calculator doesn't work too well? Don't those buttons look cool? Bad calculator results are mostly the fault of Algodoo and the user and have nothing to do with me.

I started with How to Make a Calculator in C# Windows Form Application Part-1, converting C# to Thyme, and it got too complex, so I took the easy way out. Maybe somebody can fix the insides and post a response.

P.S. Thanks for checking out the scene and posting the errors.

Nice work.

S: If you could make the display emulate a real LED or LCD calculator display, then that would add some realism to the scene.
R: If realism is the goal, then Kilinich's Calculator is the best I've seen.

I looked into the BASIC version of "Guess The Animal". Regarding "The game requires a lot of reads and writes to/from disc with each action", in the code that I viewed there was just array manipulation. I would advise against using any file manipulation and suggest using a "scene.my." array. Check the Algodoo forum for array manipulation functions.

Regarding "all the calculator scenes in the Algodoo archives", I only see (2) other desktop calculator scenes when I search Algobox for "calculators" in the scene title. Now, with my latest revision that corrects the integer math errors, I believe I have the second best calculator on Algobox.

Sorry about screwing you up. I said "system.my." but meant "scene.my.". I read your previous responses and still didn't pick up on "system.my.".

For example:

scene.my.raData = [4,["Does it Swim",2,3],"Fish","Bird"]

scene.my.raData(0)
4

scene.my.raData(1)(0)
Does it Swim

scene.my.raData(1)(2)
3

scene.my.raData(3­)
Fish

I will look into this and respond this weekend.

I can post a "Guess the Animal" scene that utilizes my recent AlgoGUI controls. It will function OK but will not have any input validation. You can then take that scene, add an explanation, dress it up, add input validation, or modify it any way you want. I will translate the Animal game shown here and here. I believe that this version will meet the conditions you mentioned above.

P.S. Although the original BASIC program does not have a SAVE feature, the scene I make will save the data in a scene.my.raData variable.

Thanks for the evaluation and suggestions. I plan on dissecting the scene and see what is causing the lag. My first guess was that it was the multitude of scene.my object variables since an object variable is created for each form and control upon spawning. I'm not sure if I agree with the statement "This scene takes up about 45% of the step calculation time ... mainly because there's a lot of code on many objects' postStep." When I check the basic (12) controls on the left of the scene, (7) have no post step code, (3) check to see if the control has focus before running postStep, (1) ("Display1") only has (5) lines of code in postStep, and (1) checks the mouse pos before running postStep (Toggle1"). I like your idea of creating postStep on demand.

After checking out the percentage draw from each example and each control, I can see that the option box and the toggle button are the heavy hitters. I will need to focus on those first. I also just realized I can reduce the percentage draw 60% by running the scene at 60 Hz instead of 300 Hz.

S = Statement, R = Response

S: Well, I just realized that you used scene.my's to store entityID's.
R: I use scene.my.focusID to store the entityID of the active control. I use scene.my.[control _name] as object variables to store each control so that I can call each control by name at any time. I use _parentID in parts of each control that are not the main control box.

S: Honestly ... they use up a rather big amount of step time.
R: I concur.

S: I think the simplest way would be by using a texture, and you could probably just rotate it.
R: My first thought was to use a texture, but I never thought about rotating it. 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. If using a texture improved the control perfomance by more than 25%, then I may ingnore that issue in favor of performance.

S: Otherwise you can store each box's entityID in a scene.my.var via onSpawn and have no other code running ...
R: Good idea exept that I would try to use local _variables to to store EntityIDs.

S: ... then change each box's color from the button itself, using scene.entityByID.
R: That makes sense; use (1) postStep instead of (4).

S: Do you avoid onClick code for some reason?
R: I would use onClick but onClick code appears to execute on mouseUp, not mouseDown.

S: Just use something on the lines of this: ...
R: Another good idea that I didn't think of. I will try that.

S: ... sliders. you might have noticed that they will not stay attached to the cursor.
R: I did notice that.

S: I think a good way of solving this ...
R: I agree. I will try that.

P.S. I tried the suggested code and some variations, but could not get it to work. The scrollBar suggestion worked out well. I chose to leave the command button border control code in the borders because I didn't want to add more member variables to the button's main box. I did add a scene.my.GUIstrobe codition to the border postStep, so they should be runnining a 10% sim frequency.

P.P.S. I changed the Button1 code so it clicks even without having focus. This will cause a performance hit, but I'm not sure how to improve it.

Nice work. The terrain is believable and works well.

Thanks. The red "Exit" box worked perfect for me (until I reset Algodoo). Looks like I have more work to do.

Nice work. I like your presentation and improvements and I will put some in my scene. Likewise, feel free to use any of my recent modifications. I like how you handled the space bar. I tried unsuccessfully to improve on it.