n72.75
Seize the means of computation
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
- Joined
- Mar 21, 2008
- Messages
- 2,872
- Reaction score
- 1,714
- Points
- 128
- Location
- Saco, ME
- Website
- mwhume.space
- Preferred Pronouns
- he/him
This is a known problem. I am making this post here (hopefully we can sticky it), as both a notice, and someplace we can link people to when they run across this issue. For developers: the issue and the fix are known, so hopefully this saves someone a few hours of troubleshooting.
64 bit Builds of Orbiter are not currently usable (out of the box at least). In general if you want to try out the latest release of OpenOrbiter, stick with the 32bit x86version. If you're a bit more experienced and or working on development/experimentation: as you were.
The reason for the issue:
The moons of Mars, Uranus, and Neptune, do not have source code, and so when orbiter "builds", them the build process is just copying them to a release folder. these were written circa 2005 by (I believe, not 100% sure) someone other than Martin, and contributed to him, sans source.
Because thse 3 dlls are 32 bit, when a 64 bit application tries to find something like the mass of a moon for a gravity calculation, it reaches into the DLL's export table, and because of the word length mismatch, ends up in the wrong place,and getting absolute garbage back for data. What seems to be happening is that this garbage contains things like IEEE-754 NaNs, and those poison the math in the body force calculation. What I've seen from the debugger is when gpos is called, it returns a NaN, or 0, or random, sometimes. This is not surprising.

This will be experienced as seemingly random or odd movements of planets and the spacecraft.
64bit Orbiter will be unusable until this is resolved. A temporary fix is to remove those moons from sol.cfg.
We have some other threads for potentially fixing this. I will edit this post later to add them:
64 bit Builds of Orbiter are not currently usable (out of the box at least). In general if you want to try out the latest release of OpenOrbiter, stick with the 32bit x86version. If you're a bit more experienced and or working on development/experimentation: as you were.
The reason for the issue:
The moons of Mars, Uranus, and Neptune, do not have source code, and so when orbiter "builds", them the build process is just copying them to a release folder. these were written circa 2005 by (I believe, not 100% sure) someone other than Martin, and contributed to him, sans source.
Because thse 3 dlls are 32 bit, when a 64 bit application tries to find something like the mass of a moon for a gravity calculation, it reaches into the DLL's export table, and because of the word length mismatch, ends up in the wrong place,and getting absolute garbage back for data. What seems to be happening is that this garbage contains things like IEEE-754 NaNs, and those poison the math in the body force calculation. What I've seen from the debugger is when gpos is called, it returns a NaN, or 0, or random, sometimes. This is not surprising.

This will be experienced as seemingly random or odd movements of planets and the spacecraft.
64bit Orbiter will be unusable until this is resolved. A temporary fix is to remove those moons from sol.cfg.
We have some other threads for potentially fixing this. I will edit this post later to add them:
