Lave Academy OXP

Post by **Micha** » Mon Mar 09, 2009 12:41 pm

Ok, I've found the problem too - even though the random seed was being saved/restored, there are actually more than 1 random seed which the system works with. Saving/restoring the other one fixes the problem (2 lines of code).

Kaks, no need to implement a new random number generator. If you're not too far into it, I can submit my patch, but don't want to steal your thunder

Post by **Kaks** » Mon Mar 09, 2009 1:34 pm

Micha, go right ahead! I haven't even started looking at the code yet, so there's no thunder from this neck of the woods!

Post by **Micha** » Mon Mar 09, 2009 4:59 pm

This explains why some people had the problem and others didn't, across various versions/OSs: it only depended on whether or not the binary was compiled with the Procedural Planets flag. It's also been a problem ever since the Procedural Planets compiler-flag was introduced.

Anyhoo, should be fixed in the latest 1.72.3 (WiP) and in 1.73 (WiP).

[OT]
This leads onto another question though: Should we add a '--version' / '--help' command line argument which shows what compile-time options were used to build Oolite? This might help track down inconsistencies in future. Alternatively I guess we can dump that into the logfile - and on second thoughts that's the better solution. I'll see about adding that in.
[/OT]

Wiki pages · Post by **Thargoid** » Mon Mar 09, 2009 8:09 pm

I think that sounds like a good idea, save all this faffing about again.

I'll leave LA at v1.01, the Academy where it was and we can all go back to playing the gunnery turkey-shoot

Therefore I now declare this OXP done, at least until another annoying bug shows up or I think of something more interesting to add in terms of new tests.

Post by **Eric Walch** » Mon Mar 09, 2009 9:05 pm

Micha wrote:
Ok, I've found the problem too - even though the random seed was being saved/restored, there are actually more than 1 random seed which the system works with. Saving/restoring the other one fixes the problem (2 lines of code).

Probably it is a good thing to write a warning in the source code to not use the Rotrand() function for new additions. The number of times this function is called must stay exactly the same as in the old elite versions or this number generator will get different results as its original. It looks saver to have a new planet-seed based number generator for new additions. There is also no need to use this 16 bit computer emulating generator for generating stuff that was not in original Elite.

At least I am glad this course is solved now. Without the Academy it could have taken some years until someone noticed differences changed since original elite. The only other oxp I know of that would have really suffered from this bug is assasains.oxp

I almost started to like the new difficulty. Once I knew where to look for I always managed to find it. To help others I made a screen shot of how the Academy looked as seen from the main station. Findable but you have to wipe off the dust from your screen first.

Post by **Micha** » Mon Mar 09, 2009 9:48 pm

This is getting really OT for this thread, but the best option to future-proof it against unwitting changes might be to profile RANROT and then put asserts() and counters into the code to ensure that RANROT never diverges from its legacy origins (as in, number of times called between critical tasks).

Post by **Kaks** » Mon Mar 09, 2009 11:49 pm

< OT!>

Eric Walch wrote:
Probably it is a good thing to write a warning in the source code to not use the Rotrand() function for new additions.

Couldn't agree more! At the moment there's about 5 different (but very, very similar) ways of getting planetary textures from PlanetEntity.m and the more I look at the code, the more I go crosseyed!

I'm still looking into it, but it might well be the case that adding a predefined texture to a planet using planetinfo.plist might also affect its exact position. Looks like the Oolite universe, even without orbits.oxp, is more dynamic than we suspected...

For the next few days I'll be having fun refactoring all of those methods into a more maintainable generic one.
</OT>

<back on topic(almost!)>
Hopefully by the end of it we'll have something more stable for the Lave Academy to build upon...

_ds_ · Post by **_ds_** » Tue Mar 10, 2009 1:59 am

Eric Walch wrote:
It looks saver to have a new planet-seed based number generator for new additions.

s/saver/safer/ (the DSP OXP could do with that too…)

Eric Walch wrote:
There is also no need to use this 16 bit computer emulating generator for generating stuff that was not in original Elite.

16-bit 6502?

Post by **Eric Walch** » Tue Mar 10, 2009 8:30 am

_ds_ wrote:
Eric Walch wrote:
There is also no need to use this 16 bit computer emulating generator for generating stuff that was not in original Elite.
16-bit 6502?

Sorry, 6502 & 6510 are 8 bit machines but I mend it used a 16 bit representation for its integers (and addressing)

s/saver/safer/ (the DSP OXP could do with that too…)

I know my English always has been bad. In my exam year I even got a 1 for writing down English. (a pretty pretty low rating in the Netherlands) I was just lucky that I could compensate that with my understanding of English.

This error I noticed already and corrected in 1.03. It is just that the Wiki has been down for some time so my sign still leads to the older 1.0 version. (same for ups) Wiki is on since yesterday so one of these days I start to update things there.

Post by **Kaks** » Tue Mar 10, 2009 12:45 pm

Bad news, I'm afraid. It looks like Lave's position is not as fixed as previously thought, and Ranrot is producing different absolute position coordinates between 32 & 64 bits linux, and between windows and macs.

Thargoid, we should be able to sidestep the problem by using the pws coordinates system. Within that system, the planet is always at coordinates 0,0,0. The units in pws are planet radii - variable between systems - it's a bit of a pain compared to abs, but at least it should ensure consistency across all platforms...

Wiki pages · Post by **Thargoid** » Tue Mar 10, 2009 1:49 pm

How different? Noticably so (the 20km + from before, or less)?

I'll look at making everything relative to the main station, I think I can see a way to do it at spawn-time as long as things are done carefully.

Post by **Kaks** » Tue Mar 10, 2009 2:34 pm

Noticeably so, I'm afraid. On a mac I'm seeing Lave at ~~abs(-49515.3,60769.4,427622)~~ sorry, looking at the wrong figures! abs(0,0,452760) as opposed to abs (0,0,617400) on an XP pc.

To follow on from what I was saying earlier, something like pws (0,-3,3) as a spawn position should place the academy 3r (planetary radii) towards the sun, and 3r on the opposite side of the planet in relation to the witchpoint.

edit: facing_positon pws(0,0,0) should face the planet, pws(0,0,10) the sun - more or less - and (0,10,0) the witchpoint, if I've got my bearings right....

Wiki pages · Post by **Thargoid** » Tue Mar 10, 2009 2:57 pm

The problem will then be the three course buoys outside the Academy, plus the pilot course when triggered. Those are all also absolutely positioned, and somehow I don't think using planetary radii is a suitable measurement for spawning those

I'll rework it in absolute co-ords relative to the main station. It'll be simpler all round.

Those Mac figures look like the earlier reports. Is it something broken in 1.72.2.1 compared to 1.72.2 on the other OS's? I ask as my Ubuntu 32-bit information matched my WinXP position exactly...

Post by **Micha** » Tue Mar 10, 2009 3:28 pm

I've found the problem, at least between procedural & non-procedural planets on 32-bit linux. Can't test my theory on 64-bit till tonight/tomorrow night.

As far as I can see, there's no easy fix to this that would keep all absolute positions the same as before. However, I think it is possible to change the code in such a way as to ensure all -future- absolute positions will always be the same. However this potential fix would also mean that everything is going to move about on every platform between now and a mythical release including this fix - and that would break every OXP which relies on certain things being at certain absolute positions.

Post by **Kaks** » Tue Mar 10, 2009 3:32 pm

Hmmm, I suppose the best thing to do for the moment is to steer clear of the abs system from within planetinfo.plist until the dust settles on this one...

edit Thargoid, it looks like the underlying random number generator is different between macs and the other platforms. If that's the case, I suspect the breakage is in GNUstep, which didn't manage to come up with an exact replica of the original. I suppose that since it's meant to come up with random numbers, it wouldn't have mattered too much if the numbers in question were different from the original ones.