Quote from Tony on 02/25/09 at 15:27:37:

 
This is great Tony, thanks . But what does the part I quoted mean exactly?

It's brilliant watching my asteroid belt with the new beta... I've got it going at 65k with the trails off, and every now and then it looks like it lurches into "bullet time" when it's doing a close encounter at 1024 .

Quote from chemist on 03/18/09 at 00:13:18:

 
That's on my "to do" list.  Welcome to the forum!

This version allows you to use either "." or "," when editing numbers in the Edit Object interface, to make it compliant with non-English settings.
http://orbitsimulator.com/gravity/beta/GravitySimulatorBeta2009Nov22.exe

Tony - have there been any more updates to the program recently? The most recent beta I've got is the 2009Nov23 one. Is that the one you're still using at home, or are you using a super-seekrit advanced version with lots more cool stuff?  
 
And what version is available for download on the main gravity simulator site - is that still the original version?

If it were super-seekret I wouldn't tell you    I'm still using Nov2009.  I thought I'd get around to doing some coding this summer, but I cleaned out the garage and painted the house instead.
 
You can migrate things already.  In Autopilot, choose "Continuous Orientation", select your object, and choose "Orient Retrograde" to make an object migrate in.  Then choose "Thrust", select your object, and choose a super-slow acceleration.  Then watch as it spirals in towards the Sun.

Two things I'd like to see in a future version:
 
1. TEST MASSES. These would react to gravity but produce none of their own.
 
Why not just make a 1 kg object; isn't that the same thing? Well, for ONE object, yes, but say you want THOUSANDS of objects. The algorithm seems to compute gravity between every object in the system, no matter how small... generally a good thing, but as the number of objects rises, the number of calculations required rises according to
x-1
Σ n
n=1
where x is the number of objects in the simulation.
 
But if we could make test masses with no gravity of their own, the number of calclations becomes
x-1
Σ n
n=m
where x is the total number of objects and m is the number of test masses.
 
So let's say you want to simulate the rings of Saturn and its large moons, considering the ring particles to be of negligible mass. You put in Saturn and say its dozen largest moons and 2000 ring particles and let 'er rip. Currently this would require 2025078 gravitational calculations per frame (and would probably crash the program). But if the ring particles are test masses with no gravity of their own, the number of calculations drops by almost 99% to only 26078 per frame.
 
2) Rotating frames confined to rotation IN THE ORBITAL PLANE. For example, I'd like to look at the dynamics of Trojan asteroid inclination with respect to Jupiter, so I'd like to look at the rotating frame obliquely. Currently, the axis of rotation is always orthogonal to the screen.
 
Overall I love this program, but as with anything else, there are things I want to do that it can't... but I think both of the above are fairly easy to implement. (If you want to throw me some source code, I'll happily have a crack at it.)

It would be nice to be able to define a secondary color for objects when z is negative. This is already a common practice in orbit illustration to show the longitude of nodes, as in this picture from the Wikipedia article on Ceres: