Algodoo

Nice looking game, but the train gets blown up much too quickly by those pesky American drones! There is hardly a chance to shoot the drones from the train before the train gets destroyed. (Maybe I'm just not very good at playing video games?)

Sorry kilebantick. I didn't mean to insult your intelligence, but based on how you asked your question ("Not too sure what you're talking about regarding lag Xray?") I thought that you did not understand what lag is.

The lag that I'm experiencing with this scene might be due to something related to my own computer, but I won't know for certain unless other people chime in and mention whether they also experience lag or not.

s_noonan always does a great job on scenes, regardless of the lag.

The text numbers in all the boxes are too small to read easily, so I changed the front size to 0.50 and the color to black. Now they show better. Besides that minor detail, the scene is AWESOME. I especially like how you did the bimetallic strip. Good job on the coding, and on the overall aesthetics.

Um.... I don't get it. HOW can you use this scene, which is nothing but a fancy looking circle, to transfer stuff between computers? Please explain.

Nice improvement. Looks great now!

Not too bad! Arrows are a little tricky to load and shoot, but I found it works fairly well by using the Move tool to load an arrow, and switch to the Grab tool to pull the arrow back and let it go (Sorry, I don't know the proper terminology to use for bow and arrow work).

I think that the spring system would work Okay if it can somehow be tuned to act more like a real bow string. It's just too wobbly and sluggish in its current configuration. Overall, the scene is better than some similar bow and arrow scenes, but it could stand some improvement, especially concerning the handling and loading of the arrows.

Keep the scenes coming!

Just curious, why do you double-up your variables in all of your scripts? For example, you write:

scene.my.x1 = scene.my.x1 = 4.7

You only need to write: scene.my.x1 = 4.7

Anyhow, I ran the printer, and it doesn't seem to print anything other than a few squiggly lines. What is it supposed to print?

EDIT: I tightened the rollers so that they don't slip on the rails (as s_noonan suggested) and now the printer prints a 3D image of a cube (which is probably what it's supposed to print).

Thanks guys! The coding is actually straightforward, but there is a lot of it because of the 12 different rotations (six sides, and 2 directions per side) that are needed. I keep track of all the colors with six arrays (one for each side), and 9 elements per array, which contain the color definitions. The tricky part was figuring out the array rotations.

Thanks again for your comments and ratings.

Nice job. Works well, and is accurate.

I never heard of a thermistor anemometer before today, and so I researched it on the web. Interesting device! Seems to be useful at very low air flow rates, and where ambient temperature is fairly stable over a narrow range.

Good job on the scene.

My comment about the thermistor anemometer being stable over a narrow temperature range is from an abstract to an article about the theory of how the device works. The comment was not directed at your expensive, high-end, superior quality Algodoo anemometer. Here is a direct copy/paste of the statement:

The anemometer output was affected by changes in ambient temperature, and the use of calibration curves for various ambient temperatures is suggested.

Clearly, the article was discussing a cheap imitation, probably made in China.

Hello Faytree!

The circle's angvel parameter is constant, even when the scene is not running. Therefore, it has no effect on changing the frequency or intensity of the lamp colors. Did you realize that?

By the way, nice job on the lamp. It looks good.

It also removes dead flies.

A device like this would be great for dairy farmers.

Nice scene, but the shoe cold move a little faster to represent real life shoe scrubbing. (About 140 RPM on the motor looks about right)

It would be much better if you included text in each element box. Include the element name, atomic number, and atomic weight at the very least.

BTW - That's a clever mechanical mechanism that you designed to move the lanthanide and actinide blocks around!

I don't know how you found that one! It's quite interesting because his scene was done partially with mechanical devices. It appears to use X/Y platforms (not sure what else to call them) with springs that change their lengths, and there's a box at the X/Y intersection that's glued to a specific circle at the corners of the rotating cube. When each X/Y platform changes position, the corresponding corner of the cube gets translated. When all corners of the cube are translated together, it makes the entire cube rotate. It's very clever, but different from the way I did it, which uses only math, and moves each corner of the cube by adjusting its pos{0} and pos(1) position variables . I do not employ any mechanical devices at all.

Good find!

You should see the mat on the front porch of my house. It self destructed after 2 weeks of use!

Why do you call it "stupid"? I don't understand a lot about lenses, but it looks like you did a good job on the scene, especially for being your first one!

Wow, this is awesome!

Would you mind if I made a copy of it, and used it in my fish tank scene? I would of course give you credit for the original design.

I reverse engineered RBS16's scene also. It uses traditional trig (sin & cos) functions for calculating angles, but the algorithm he uses seems to be different from mine. I think that's because he calculates the X & Y positions of those 8 mechanical stages rather than direct manipulation of the pos properties of the cube's corner points, which, as you stated, was not possible in the early days of Algodoo and Phun. If RBS16 were still active on Algodoo today (his last scene was in 2010), he would probably do a really good 3D rotation scene because he would be able to use the latest Thyme features and functions. He seems to have a good understanding of Trig and how to utilize it in a practical application. I know just enough about Trig to be dangerous!

lololoer - There are many math functions in the Thyme script language, and they begin with "math.", such as math.pi (which returns the value of pi) and math.sin and math.cos (which return the sine and cosine of an angle.)

Read through the "Thyme Scripting" section of the Algodoo forum to learn about those and many other Thyme functions.

Thanks for your compliments!

I don't understand what your complaint is. When I drag the blue ball toward the red ball, it moves as it should. So, what's the problem???

BTW - No need for profanity. Many people (like me) do not appreciate it, and people will not take you seriously when you use profanity. Thanks.

Check out my scene response!

This is nothing unusual. You are simply forcing the circles to rotate by constantly adding a value to the angle variable. Some variables in Algodoo geometries execute Thyme script even when the scene is not running. Angle happens to be one of those variables. Because the angle gets updated with each simulation scan, it makes the geometry rotate. I have used a similar script in one of my early scenes.

Thanks openfablab!!!

No tutorial for this. Just a scene. Sorry....

s_noonan - Thanks for the tip! I'll try using that on future scenes.

lololoer - That formula that your teacher gave you is the same formula that I used in my example scene for you. Your teacher just laid it out a little differently, but it works the same way.

No, not a bug. It works as expected, based on my own experience with Algodoo. First off, I had to set the "strength" and "max force" of my Drag Tool to +infinite in order to move the blue and grey circles. The reason why the "Normal" circles do not come together is because they both move in the same direction that your Drag Tool pushes them. And that's because the pos variable for the smaller circle is not fixed. It is a value that will change as the circle's position changes. In the small red circle, you use executable script to set the pos position, which means that the position of the circle will stay glued to its position unless (and ONLY unless) the position (x and y) values change. So, with the small red ball stuck in its current position, the Drag Tool can push the blue ball toward it, and the distance will grow smaller and smaller until they collide.

If you do not like how it works, or you feel that it defies the laws of physics (or whatever) then you can request a change or a "fix" by submitting your request through the Algodoo forum.

Doesn't really work as a radar. I moved the target objects around and the RADAR image on the display doesn't change.

Titnic?

Nice job on the scene! It works quite well. I would suggest an improvement would be to implement a scoring system that keeps track of the number of bricks destroyed and also the total time per game (I don't know if the official Breakout game works this way, but it just seems logical to me).