Oolite Bulletins

Kaks wrote:

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!

Oh yes. The two PRNGs being used both for procedural stuff and for random stuff, and not being reset before each procedural thing, is the stuff of nightmares. Can we start again, please?

_ds_ wrote:

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.

This probably boils down to x87 FP vs. SSE FP. (Oolite for OS X x86 uses SSE despite being 32-bit; this is the norm on OS X, because its behaviour is closer to PowerPC behaviour and all Intel Macs have SSE3.)

Ok, OS X on i386 gives exactly the same results as Linux 64-bit (confirming Ahruman's comment above), however it does give different results between PROCEDURAL and non-PROCEDURAL planet generation, confirming my earlier results. So I'm not sure how you got your results, Kaks.

In either case, I agree with Ahruman to start again, or rather, that we refactor the code to segregate the procedural 'random' functionality from the functionality which is truly supposed to be random. Whether we achieve this by resetting the seeds for the procedurally-random stuff or by running a new RNG for the truly random stuff and keeping RANROT for the legacy stuff I don't know. This would future-proof the code from further surprises such as this.

Micha wrote:

In either case, I agree with Ahruman to start again

I’m not sure I do – it was meant as a joke. Redoing it with a clear separation of “random” and “procedural” is conceptually the right thing, but making the right decisions will be difficult and painful. For instance, the way %R random-name tokens reset under various badly defined circumstances would probably change, and I’m pretty sure there are things that depend on that behaviour.

Micha wrote:

Ok, OS X on i386 gives exactly the same results as Linux 64-bit (confirming Ahruman's comment above), however it does give different results between PROCEDURAL and non-PROCEDURAL planet generation, confirming my earlier results. So I'm not sure how you got your results, Kaks.

Trunk does does indeed give different results between procedural and non-procedural on my system too, and I'm sure I've already said so. What I was saying is that my bracketed code & mac non-procedural was giving me the same positions. I had a bit of RL tonight, and on coming back I've done a bit more testing. As luck would have it, the planets I looked at last night were Lave(0, 0, 452760), Diso(0, 0, 677050) & Reorte(0, 0, 834470) . They show the same coordinates in 1.72.2. on a mac as they do on my homebrew 1.73 build on mac, linux & windows. On further testing, it turns out that it was an amazing string of bad luck on my part. Other systems in the neighbourhood, like riedquat(0, 0, 960450 in my homebrew 1.73 - 0, 0, 576270 in mac 1.72.2) and zaonce (0, 0, 387300 in my homebrew 1.73 - 0, 0, 464760 in mac 1.72.2) show a marked difference between the two versions!

I might be repeating myself here, but using my homebrew 1.73 code there's no positional difference across formats, and procedural/non-procedural ( and confusingly, the first 3 planets I looked at were positioned identically between my code & 1.72.2 mac) .

Of course, and still more confusingly, using trunk there are differences both between platforms & procedural/non-procedural within the same platform.

Here's the patch between my homebrew 1.73 & trunk v2089, there's a couple of non-planet related things in there, but I'm sure you can safely ignore those!

@Ahruman: Whoops, sorry, that one went straight over my head and into the stratosphere!

So I guess our biggest question moving forwards is whether or not we need to maintain backward compatibility with planet/station positions or not. And if so, to which platform do we maintain compatibility? If we fix planet positions to be consistent we'll always break compatibility with at least some pre-fix builds.

Wait! Let's recap the situation: so far we have 4 (or 6?) different planet/sun/witchpoint positions depending on platforms & procedural/non procedural textures.

No matter what we do, if we get to a single fixed position across platforms we will 'break' things one way or another. But are we sure there's going to be some real breakage if we do that?

We've already got 'some' drift from 1.65, so maybe keeping the planets' absolute position exactly as they were in 1.72 isn't going to be that vital, expecially if no more OXP is going to be affected one way or another.

Apart from Lave Academy, are there any other OXPs that rely on absolute positioning?

Kaks wrote:

Apart from Lave Academy, are there any other OXPs that rely on absolute positioning?

The v1.02 doesn't rely on it, I recoded it to position everything in relation to the main station. It still spawns things using absolute, but the actual co-ordinates are calculated from the main station so moving things about in the z-axis won't hurt it.

Only people with v1.01 will be affected, and if it becomes a problem they can just update.

Ok, quick emergency editing:
Are there any OXPs that rely on absolute positioning?

Kaks wrote:

Ok, quick emergency editing:
Are there any OXPs that rely on absolute positioning?

I think none of the ship or equipment oxps do, that should narrow it down.

Kaks wrote:

Ok, quick emergency editing:
Are there any OXPs that rely on absolute positioning?

I don't think there could be many as this possibility is quite new and only a few oxp programmers worked with it. The only i can come up with is "save everywhere" from Frame. He stores the absolute position in a saved file. So when coordinate system changes and on old game is loaded there could be troubles.
But this won't be a to big problem as I assume most will only use it for a temporary saving a commander. It is still development work so I assume all players will also save a commander on the main station as backup.

None of my work uses it. All my uses of "abs" are with calculated relative coordinates.

-----
Looking through al that randomness I notice it wastes also a lot of time to repeat calculating known random numbers over and over again. It would make more sense to calculate them once on entering a system and store in an array.

I just noticed that every police asks every 10 seconds for the witchpoint location. And because that location is also a bit randomised, it does reset the seed for this calculation every time and recalculates that random location over and over again and for every ship again. It would make more sense to me to just redefine that entry point on system creation, making it a system property and only transmit that calculated coordinate on each request.

If Cataclysm current depends on system-bodies being at specific coordinates then Cataclysm currently will break depending on which platform it's run on anyway. So it'll need to be fixed anyway.

Micha wrote:

If Cataclysm current depends on ....

Not if, it does!

Cataclysm uses it on two places to add stations in space. The second is in deep space so a difference would not be noticed. However, the other is a station in Galaxy 3. This station is located at the back of enrece in "abs" coordinates. Strange he used this coordinates. As it is in planetary orbit the planetary radius based "pwp" system would have been more logic to me.

Also, not sure about keeping a big array of random numbers in memory, but definitely cache the ones which keep being referenced such as the Witchspace-Beacon location.