Limit abs coordinates to scripting?

[Kaks]

I've been following the 'adventures' of Lave Academy, which looked as if it kept moving away from Lave when used on different computers. As it happens, it was the only thing to stay in the same place, while the rest of Lave kept drifting about depending on various versions of Oolite, and different operating systems.

The actual position of a planet, sun or witchpoint has been anything but constant in the past, and - while we might just be able to stop all this drifting for future versions - it looks like we'll have to live with different planets positions on different platforms for the time being.

While the abs coordinates make it possible to place items in the ooniverse with great accuracy - and it's the only way to place items in witchspace - the older coordinate systems - pws, pwm, psm, etc (all the ones mentioned here actually!) seem to provide a more than adequate way of avoiding major positioning problems.

Should we just disable abs from within shipdata.plist? We could have oolite check for witchspace, still use abs if we're in a witchspace pocket universe, but get Oolite to stop spawning ships with an error like

Code: Select all

ERROR - spawnShip cannot use 'abs' coordinates in normal space

inside normal systems.

This would only apply to the spawnShip/legacy_spawnShip command. The other commands used to add ships to the universe ( addShip/legacy_addShip and similar) could still be free to use abs, of course.

What do you think?

[another_commander]

Before doing something like that, I think it would be very helpful if we could figure out why exactly we have all these differences with different versions and operating systems. Any ideas?

[Micha]

One definite problem we isolated is a switch between Procedural and normal planets. Procedural planets use a different model (icostextured.dat vs icosahedron.dat) and these models seem to define a different number of vertices.

The number of vertices in turn affect how often a couple of loops are iterated inside of which are calls to the RNG's - which throws off the RNG seeds for later on when the planet position gets generated.

One issue with the current codebase is that the generation of 'fixed' data for a system (such as planet and sun positions and sizes, techlevel, government etc.) is interleaved with generation of data which may depend on variable input (such as the planet textures which depend on the number of vertices in the planet object). If all fixed data was generated first it would always be static (since the rng's are initialised with the system seed).

If nobody beats me to it I'll see if I can track down the difference between 32&64-bit Linux tomorrow night. Afraid I can't do much about Mac since I don't have one. But at least Linux32 & Win32 seem to be in agreement with each other.

[Kaks]

I'm going to try and figure out the difference between macs & GNUstep!

Whatever we find, I've got a strong suspicion we'll have to change the way absolute postions are generated. If we end up doing that, chances are the abs coordinates will be quite different from what they were in 1.72 but at least we'll get consistent numbers across all the systems.

Disabling abs when using spawnShip in normal space does sound a bit draconian, but I thought that in the long term it might reduce the number of oxp rewrites needed, if we end up having to move planets from time to time...

A 'nicer' option is to issue a warning instead, but still allow spawnShip to go ahead using abs coordinates. At least that would alert OXP makers not to expect system objects to appear in the exact place from platform to platform or across different versions of Oolite!

[JensAyton]

This is one of the problems I’ve been avoiding for years because it’s so painful. :-/ Another thing affected is the generation of sky objects. I’d been considering restoring to the base system seed for that.

[Thargoid]

Just to be a full hand-over to this thread, the Academy adventures should now be fixed with v1.02 (just uploaded). It spawns everything relative to the main station, so should no longer be affected by all the fun and games (although it will need to be reworked for v1.73 with setPosition/position).

Therefore now if you've mislaid the Academy, the main station or the planet then it's your own problem and carelessness

[Micha]

The difference between 32 & 64-bit (on Linux) during Planet generation is different branching in PlanetEntity::initialiseBaseTerrainArray(). Each time a branch differs affects the count of calls to RANROT.

3 ways around it: Fix the code to behave identically on 64-bit as on 32-bit, use a different RNG here, or save/restore the RNG seed in this function. The first option would maintain backwards compatibility with current 32-bit builds but is also the most difficult.

Haven't looked yet why the number of times the branches are taken can differ between 64&32-bit (not my area of expertise) but I'll have a go at muddling through it if nobody beats me to it.

[Kaks]

It looks like the mac code doesn't change the rnd seed at all when using icosahedron.dat

When fed the same seed, the rng does come up with the same numbers with both macs & pcs.
I bracketed the whole texture generating code with a couple of lines to save/restore the seed & the planet's coordinates are exactly the same across macs, windows & linux-32bit, using either old style planets or textured planets. I'll do some more testing in a few other systems to make double sure, though.

So far, it looks like we can fairly painlessly make 1.73 put the planets at the same abs coordinates as 1.72 on a mac.

[Micha]

There's 2 seeds and RNG's - sRANROT and rnd_seed.

rnd_seed is used by gen_rnd_number, sRANROT is used by randf(), Ranrot() and ranrot_rand().

The basic (non-PROCEDURAL) planet generator uses the gen_rnd_number, but that is bracketed around saving/restoring the rnd_seed. The PROCEDURAL generator as well as the terrain and atmosphere generator (which are affected by the number of vertices in the model) all use the RANROT-based RNG.

Finally, the planet (and thus station) positions are generated using the RANROT RNG. Hence it doesn't really matter what happens to rnd_seed at all (as far as positions are concerned).

I can't see how you can ensure 1.73 will always generate the same positions (with or without PROCEDURAL) as 1.72 without PROCEDURAL (which should be the benchmark).

It's trivial to ensure consistent positions across all platforms as long as we don't care about backwardly-compatible positions.

[Kaks]

Agreed! What I was trying to say was that procedural generation on the mac will alter the ranrot seed, however, non-procedural in the mac doesn't seem to touch ranrot at all.

Saving/restoring ranrot does seem to produce consitent positions across all platforms. As it happens, those positions seem to be backward compatible with 1.72 on macs.

Sadly they are definitely not backwards compatible with 1.72 on PCs.

[Micha]

Agreed! What I was trying to say was that procedural generation on the mac will alter the ranrot seed, however, non-procedural in the mac doesn't seem to touch ranrot at all.

?!?? How on earth can it not? PlanetEntity::paintVertex (amongst other things) gets called irrespective of PROCEDURAL, and that calls ranrot.

I can't see how sRANROT pre-PlanetEntity::initWithSeed() == sRANROT post-PlanetEntity::initWithSeed() with the trunk/1.72-maint code prior to me submitting the initial (non)fix.

[Kaks]

Don't ask me, I just work here!

It kind of puzzled me too... I might be doing something terribly wrong, but on a mac I seem to be getting the same results from both 1.72.2 & my modified 1.73. That's why I wrote

I'll do some more testing in a few other systems to make double sure, though.

[Micha]

Sorry if it came across like it, but I most definitely wasn't having a go at you

I'm just -totally- confused now!

If it'll help I can send you some instrumentation code I've chucked in which will churn out how often the various RNG functions have been called, useful when stepping through with a debugger.

[Kaks]

Please do PM me with the instrumentation. I can assure you I can do with all the help I can get: I'm not a mac developer & xcode is still a bit of a mysterious beast for me!

edit: yes, I am -totally- confused too... luckily we're in good company here. Ahruman seems to have had a few problems with ranrot too!

[_ds_]

If it'll help I can send you some instrumentation code I've chucked in which will churn out how often the various RNG functions have been called, useful when stepping through with a debugger.

I've done a little testing of my own, and I'm certain that the problem isn't in the random number code, but is instead in the FP handling.

http://tartarus.org/~ds/oolite/planet-trace.patch adds some debug printf()s for tracing this (note that it prints floats in their raw form). It looks like i386 is rounding down and amd64 is rounding to nearest; and amd64 is truncating the values from their internal representations to 32-bit before converting to int rather than just doing straight conversions.

The truncation issue is trivially fixable:

Code: Select all

int s1 = (int)(0xFFFF00 * base_vertex_array[v01].x) << 8;
int s2 = (int)(0xFFFF00 * base_vertex_array[v01].y);
int s3 = (int)(0xFFFF00 * base_vertex_array[v01].z) >> 8;

and similarly for the other two instances. This leaves the apparent rounding issues still to be resolved. (Initial vertex coordinates & normalisation are affected.)

(Test CPUs: Centrino T1350; Athlon 64 3500+.)