Algodoo

I just realized that gun was made in White Bear Lake, MN. I live only about a 30 minute drive from there!

That's quite weird! I have tested other scenes for randomness, and they all seem to take a slightly different path each time I ran them.

In a perfect digital world, yes, every ball will move and react exactly the same time after time. But in a properly made simulation program, there is supposed to be some built-in uncertainty in how the physical objects react. So, I cannot explain why this is happening in your scene. I wouldn't call it "cool". I would call it problematic.

I see the objects on your radar display but there are no actual object targets in the scene. So, is this just a simulation of a radar display, and not really tracking objects in the scene like others have done?

I'm looking forward to your marble race parody. This is long overdue!

Sure, as I mentioned in my PM to you, it would be best if you upload your scene and describe the parts that don't work, and describe how you would like them to work. Then after I (hopefully) make it work, I'll upload it for you to add to it or make any changes you would like. After you don't need my scene any longer, I will delete it.

How does that sound?

By the way, if it turns out that I am not able to help you, I will give you DOUBLE your money back!

Actually, there are simpler ways to prevent an object from rotating (with the magic of scripting). It's actually very simple, and the user needs to know nothing about writing script. Here's the secret trick:

In the script menu, you will see a property called "angle". The numeric value next to it may have an odd looking number, but in most cases it is very close to zero. If that happens to be the case, you can change the value to 0.0 (zero), and at that point you should see little or no rotation of the object (in this case it's a rectangle for a piston). If the value happens to be a long way from zero (say, 1.35 or -2.87, etc) then just leave it alone.

Now the trick is, in order to prevent that value from changing, you simply place curly brackets around it ( for example: {0.0} or {1.78}, etc. Make sure that you use curly brackets and NOT parenthesis.

There is one more thing that you can do to make sure that the object doesn't rotate even under high torque from other objects, and that is to set property called "velocityDamping". You will see three numbers separated by commas and surrounded by square brackets. It should look like this: [0.0,0.0,0.0]. The first value on the left is for X motion damping, the middle is for Y motion damping, and the right is for rotation damping. The range of each value is 0 to 1.0. If you set the rotation damping to 1.0, the object will greatly resist any torque placed on it.

Try it and see if you like it any better than adding a hinge.

epicface129 - WHAT is it that you don't get?

Suggestion: You should give your scenes titles that either say what the object in the scene is or what the scene is about. When people search for scenes, they typically search on the type of scene that they are looking for. When you use only your user name as the title, then your scenes will not be found when people search for specific types of scenes.

Thanks!

It looks like two chairs doing circus acrobatics.

Why don't you use a title that people can read and recognize and search for? No one has any idea what this scene is about just from the gibberish title you gave it.

I don't believe that they are correctly timed. All cylinders fire at the same time rather than firing a few degrees out of phase with each other. They may look like they are running Okay, but in the real world, these engines would be extremely inefficient. (Well, spring engines don't exist in the real world, but the same timing issue applies to nearly all multi-cylinder engines.)

It doesn't seem to work. The pistons just sit there and shake.

In "onHitByLaser" you have scene.my.zDepth = 13. That is fine if your intention is to have some external object be changed. But if you want the zDepth of the red box to be 13, then you simply need to change that to zDepth = 13. (get rid of the "scene.my")

I tried it too, and it did set the zdepth to 13 as you requested.

Yes, I'll mod the scene and show you.....

Okay, I uploaded my zDepth scene.

I have never been able to do that. I tried asking for help in the forum a long time ago, and I was told it was not possible to script it. You can only move existing object forward or backward manually. Sorry

BUT...,. There may be an alternative method to achieve the essentially the same goal. Depending on your specific requirement, you may be able to do a similar thing with the collide layers or possibly some other way.

Could you upload your actual scene that you are having trouble with? If so, then point out what you are trying to achieve, and I will try to figure out a way to do it.

It's getting late here so I will have to look into this again tomorrow.

Have a great evening!

Thanks! Your comment means a lot to me!

I don't know why it's not working for me. I downloaded the latest version and ran my scene zDepth Change 2, and the red box still does not move to the front layer like it does in your version of the scene. What do you think is going on?

Nice "tight" control. Did you use PID algorithm for the position control?

Okay, I dragged the phone. What is it that's supposed to happen? Please explain.

Are you kidding??? Those ghost images are supposed to be there! Don't you see that they are programmable?

Yeah, there were blown up by Osama Bin Ugly's military. But, in case you haven't heard, that moron is DEAD!

When I start Algodoo, nothing happens. What is this scene supposed to do?

I had a 7th grade math teacher say that to me..... Could it be???

No..... That would make you about 100 years old!


Anyhow, YOU CHEATED! That's not fair play, my friend!

Well, lethalsquirrel was hoping that one of us would solve his issue of making an object move from behind another object to in front of the object via a script command. Your scene, which spawns another box, may make it LOOK like it did what he was hoping it would do, but it did not solve his problem. That's what I meant by cheating. As far as I know, there is no way to do what he was hoping could be done. And I still don't fully understand zdapth, even after reading through some of the forum threads on the subject (which there are very few).

I'm sure that you already know that "I' would reduce the error between the position setpoint and the measured position during steady-state conditions. It integrates the error over a preset time period, and continuously nudges the load being moved until the error is zero. "I" is only needed in applications where extreme position accuracy is required during steady-state conditions (no accel or decel). The bottom line is, if you don't need "I" then you are better off without it.

Yeah, they do look pretty cool!