Oolite Bulletins

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...

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 d...

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 ...

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 w...

I always took the Elite "Gal Tonne" to be a measure of volume rather than mass, similar to current-day containers or the olden-day barrels. They're a universal size, but depending on what's loaded into them they have different mass.

The definitive resource has the original ship sizes in feet:
http://www.iancgbell.clara.net/elite/manual.htm#A47

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 differe...

If we're going to talk facts of life, then real spacecraft have external docking ports with which they attach to each other directly. There's no requirement ever to land a spacecraft inside an internal docking bay of another spacecraft - what a HUGE waste of resources building an enclosed chamber in...

Incidentally, for docking with the Academy, I've so far succeeded only once out of about 5 attempts, all other attempts were Instant Death. Can you dock from both sides or only one? Is the docking slit rectangular or square? Ie, is it the whole visible opening, or is it invisibly smaller? Do you hav...

According to canon Elite (at least the C64 version), the cargo bay expansion was performed by installing advanced sub-space compressors inside the hull. Thus it was entirely internal. Also I believe that ship-shapes had to be streamlined due to an 'ether' which the ships fly through - this also expl...

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 ite...

Incidentally, on a completely different Topic (ie, the original thread), having finally seen the Lave Academy at it's designed position/distance, it's easily visible from the Station. No wonder Thargoid was initially confused about our complaints

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...

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).

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 ...