Generation of System Data - Game source question

[treczoks]

Hi!

I've got a question regarding the games' interna. In the original Elite and in Oolite, the systems positions, names, governments and techlevels are the same, and I've re-implemented all those classical Elite System variables in my perl program which I need for the generation of the Wiki Galaxy Guide.

Now Oolite has additional parameters (land colour, land percentage, sun colour, sun distance, etc.), some of which would be helpful for my project. As I am not familiar with objective C (I do regular C and a bit of perl for a living), I need some help where to find and how to read the algorithms.

I suppose the key is somewhere in Universe.m, but sadly, this stuff is all french to me

Could anybody help me?

Yours, Christian Treczoks

[JensAyton]

The base colours are determined in PlanetEntity.m (line 406-407 in trunk), as:

Code: Select all

land_hsb.x = gen_rnd_number() / 256.0;  land_hsb.y = gen_rnd_number() / 256.0;  land_hsb.z = 0.5 + gen_rnd_number() / 512.0;
sea_hsb.x = gen_rnd_number() / 256.0;  sea_hsb.y = gen_rnd_number() / 256.0;  sea_hsb.z = 0.5 + gen_rnd_number() / 512.0;
while (dot_product(land_hsb,sea_hsb) > .80) // make sure land and sea colors differ significantly
{
	sea_hsb.x = gen_rnd_number() / 256.0;  sea_hsb.y = gen_rnd_number() / 256.0;  sea_hsb.z = 0.5 + gen_rnd_number() / 512.0;
}

Prior to this, it will have called seed_for_planet_description(p_seed); (where p_seed is the system seed) and then (it appears) called gen_rnd_number() 14 times for a procedurally textured planet, but 12 times for a non-textured planet. Which is annoying, because I thought I’d verified that it ends up with the same colours in either case, but it turns out it doesn’t.

There’s some more code after that to generate pale variants of the colours. The _hsb suffixes refer to the HSV colour space.

Also, note that some systems’ colours are overridden in planetinfo.plist (because their description claims they have pink oceans).

[treczoks]

Thanks for helping that quick!

The base colours are determined in PlanetEntity.m (line 406-407 in trunk), as:

Code: Select all

land_hsb.x = gen_rnd_number() / 256.0;  land_hsb.y = gen_rnd_number() / 256.0;  land_hsb.z = 0.5 + gen_rnd_number() / 512.0;
sea_hsb.x = gen_rnd_number() / 256.0;  sea_hsb.y = gen_rnd_number() / 256.0;  sea_hsb.z = 0.5 + gen_rnd_number() / 512.0;
while (dot_product(land_hsb,sea_hsb) > .80) // make sure land and sea colors differ significantly
{
	sea_hsb.x = gen_rnd_number() / 256.0;  sea_hsb.y = gen_rnd_number() / 256.0;  sea_hsb.z = 0.5 + gen_rnd_number() / 512.0;
}

OK. Hopefully, I won't run into floating point differences with the implementation of dot_product and the comparison. Are the .x, .y and .z's floats or double? Are they x=hue, y=vvalue and z=saturation?

Prior to this, it will have called seed_for_planet_description(p_seed); (where p_seed is the system seed) and then (it appears) called gen_rnd_number() 14 times for a procedurally textured planet, but 12 times for a non-textured planet. Which is annoying, because I thought I’d verified that it ends up with the same colours in either case, but it turns out it doesn’t.

What are the other calls being used for? And how could I determine when to use 12 or 14 calls?

There’s some more code after that to generate pale variants of the colours. The _hsb suffixes refer to the HSV colour space.

Thanks for the hint about the colour space!

Also, note that some systems’ colours are overridden in planetinfo.plist (because their description claims they have pink oceans).

OK, another important point to keep in mind!

Could you do me a favour and help me verifying my implementation? I'd need the p_seed and a list of the first N (N about ten-ish sound sufficient to verify) results of gen_rnd_number() for, e.g. Tibedied (being the first of the firsts) to compare them with my results.

Yours, Christian Treczoks

[Commander McLane]

Prior to this, it will have called seed_for_planet_description(p_seed); (where p_seed is the system seed) and then (it appears) called gen_rnd_number() 14 times for a procedurally textured planet, but 12 times for a non-textured planet. Which is annoying, because I thought I’d verified that it ends up with the same colours in either case, but it turns out it doesn’t.

What are the other calls being used for? And how could I determine when to use 12 or 14 calls?

You can't. 14 calls are used if the player has chosen the option for procedurally textured planets, 12 are used if he hasn't. Neither are relevant if he uses any planet-texturing OXP, which overrides the base colours anyway.

In other words: depending on players' options and installed OXPs the Ooniverse looks differently for each player. You can't give information which is correct for every player.

I hope, though, that by 'annoying' Ahruman means 'buggy', and will fix this, so that the base colour will be the same regardless of the procedural option. Then you'd have a valid information for all vanilla Oolites.

[treczoks]

You can't. 14 calls are used if the player has chosen the option for procedurally textured planets, 12 are used if he hasn't. Neither are relevant if he uses any planet-texturing OXP, which overrides the base colours anyway.

Ah, ok. I assumed that this "use or not use texture" depends on one of the former values (which would make it deterministic). With this being a player option, it sure is a bug.

In other words: depending on players' options and installed OXPs the Ooniverse looks differently for each player. You can't give information which is correct for every player.

Which is indeed an undesirable state of the ooniverse.

I hope, though, that by 'annoying' Ahruman means 'buggy', and will fix this, so that the base colour will be the same regardless of the procedural option. Then you'd have a valid information for all vanilla Oolites.

I hope he will. And as it would be difficult to not-use two calls, we'll end up with 14, so I'm aiming there.

I'll start digging in the source Aruman mentioned and see whether I can read something out of this objective C stuff. Nonetheless I need some real-world values to compare my results. As I cannot play the game at the moment (GFX card down, and buildin GFX yields 5fps), and I have no debugging environment running on the PC, I have to rely on the data I can get from somebody in the coder group.

Yours, Christian Treczoks

[Commander McLane]

In other words: depending on players' options and installed OXPs the Ooniverse looks differently for each player. You can't give information which is correct for every player.

Which is indeed an undesirable state of the ooniverse.

Is it? I think the usual consensus is that it's a strength of Oolite to be fully customizable.

But yes, if your aim is to give system and planet descriptions that are valid once and forever, you're bound to fail. That's impossible, exactly because each player can customize their Oolite experience to their personal liking.

Example: in your thread somebody pointed you to Ionics.oxp, which alters a couple of planets in the upper right corner of Gal 2. Which means that for every player who has installed Ionics, the planet look different, have different techlevels from vanilla Oolite, and so forth. But for everybody who hasn't installed Ionics, none of these changes exist. So effectively there are two completely distinct planets 'Ramaza', depending on your choice of OXPs. And the same applies to many other OXPs, of course. Myself for instance, I haven't installed FamousPlanets.oxp. So all the fancy special planets with their nice descriptions simply don't exist; and the whole concept of trade routes doesn't exist as well.

I think it's quite a challenge to give accurate information about systems and planets in the Wiki, simply because there are so many planets for which you need to give two distinct sets of information (actually it's even more, because multiple OXPs can affect the same system, and there will be players with any possible combination of these OXPs on their computers). You have set yourself a task which is nothing short of titanic. Or you have to put a disclaimer on top of your project, specifying the mix of OXPs (and game options) for which the information will be accurate. (To be honest, I haven't followed your project very closely, so I have to admit that I am actually unaware whether you already have included switches and alternative descriptions for different game setups.)

[Eric Walch]

But yes, if your aim is to give system and planet descriptions that are valid once and forever, you're bound to fail. That's impossible, exactly because each player can customize their Oolite experience to their personal liking.

I assume you agree that every planet should look the same when no oxp is installed.

You probably remember a few Oolites back were the number of random calls on system setup was different for mac and windows, resulting in different systems sizes on both platforms. It was Lave Academy oxp that brought the difference under our attention.

I remember that as a very memorial discussion. Thargoid (on windows) stating that the station was easy visible, and on the mac it was only 2 pixels in size, almost identical to other stars in the sky. Thargoid thinking the mac players were blind and the mac players not able to understand why Thargoid called that dot 'easy' visible

[treczoks]

Example: in your thread somebody pointed you to Ionics.oxp, which alters a couple of planets in the upper right corner of Gal 2. Which means that for every player who has installed Ionics, the planet look different, have different techlevels from vanilla Oolite, and so forth. But for everybody who hasn't installed Ionics, none of these changes exist. So effectively there are two completely distinct planets 'Ramaza', depending on your choice of OXPs. And the same applies to many other OXPs, of course. Myself for instance, I haven't installed FamousPlanets.oxp. So all the fancy special planets with their nice descriptions simply don't exist; and the whole concept of trade routes doesn't exist as well.

I'm well aware of this problem. Luckily, there are no OXPs I know of that do kind of "mass-alteration" of the Ooniverse. Most OXP don't even touch the systems, and those who do, change only a few. Take Ramaza, which is a good example how I took care of the situation.

Having a Ooniverse where a user-controlled option changes each and every system is not a good thing.

Yours, Christian Treczoks

[treczoks]

I assume you agree that every planet should look the same when no oxp is installed.

Yes, indeed. As I currently don't know what kind of other options/variables depend on this 12/14 problem, this might pose a major problem for an OXP.

You probably remember a few Oolites back were the number of random calls on system setup was different for mac and windows, resulting in different systems sizes on both platforms. It was Lave Academy oxp that brought the difference under our attention.

I remember that as a very memorial discussion. Thargoid (on windows) stating that the station was easy visible, and on the mac it was only 2 pixels in size, almost identical to other stars in the sky. Thargoid thinking the mac players were blind and the mac players not able to understand why Thargoid called that dot 'easy' visible

No, I'm not aware of this particular discussion, but I agree that things like that should never happen.

Yours, Christian Treczoks

[JensAyton]

OK. Hopefully, I won't run into floating point differences with the implementation of dot_product and the comparison. Are the .x, .y and .z's floats or double?

They’re single precision.

Are they x=hue, y=vvalue and z=saturation?

Yes. (All ranging from 0 to 1.)

What are the other calls being used for? And how could I determine when to use 12 or 14 calls?

As I said, it’s 14 for procedurally textured planets (“Detailed planets” in settings) and 12 for untextured ones. They’re used to determine which parts of the model are sea and which land; this information is only actually used for untextured planets.

(BTW, I tried forcing the same colours in textured and untextured mode the other night, but the plants ended up looking completely different anyway, so there’s not much point. Planets inevitably look completely different in textured and untextured modes.)

[JensAyton]

Here’s the data for the first eight planets in system 0:

Code: Select all

     74, 90, 72,  2, 83,183,   227,185,144,  2,   0.675781, 0.933594, 0.933594,   0.316406, 0.031250, 0.673828
    128,205,184,152, 29,122,   142, 18,112,152,   0.250000, 0.394531, 0.394531,   0.339844, 0.070313, 0.707031
     42,243,156, 77, 27, 33,    84,110, 56, 77,   0.589844, 0.957031, 0.957031,   0.156250, 0.015625, 0.585938
    152,208,148, 83, 13,134,    54,217, 40, 83,   0.132812, 0.882812, 0.882812,   0.871094, 0.179688, 0.525391
    218,131, 32,180, 51,226,   115,150, 64,180,   0.527344, 0.687500, 0.687500,   0.156250, 0.191406, 0.675781
    128,176,224,172,141,119,    78, 36,192,172,   0.519531, 0.230469, 0.230469,   0.187500, 0.839844, 0.515625
     90,249,212, 69, 27, 20,   196, 89,168, 69,   0.906250, 0.281250, 0.281250,   0.187500, 0.218750, 0.705078
     56,173,156, 20, 29, 21,    86, 41, 56, 20,   0.117188, 0.363281, 0.363281,   0.847656, 0.332031, 0.589844

The first group is p_seed/systemSeed (Random_Seed); the second is the RNG_Seed set by seed_for_planet_description(p_seed); the third is land_hsb x, y, z; the last is sea_hsb x, y, z.

[treczoks]

Thank you very much!

Here’s the data for the first eight planets in system 0:

Code: Select all

     74, 90, 72,  2, 83,183,   227,185,144,  2,   0.675781, 0.933594, 0.933594,   0.316406, 0.031250, 0.673828
    128,205,184,152, 29,122,   142, 18,112,152,   0.250000, 0.394531, 0.394531,   0.339844, 0.070313, 0.707031
     42,243,156, 77, 27, 33,    84,110, 56, 77,   0.589844, 0.957031, 0.957031,   0.156250, 0.015625, 0.585938
    152,208,148, 83, 13,134,    54,217, 40, 83,   0.132812, 0.882812, 0.882812,   0.871094, 0.179688, 0.525391
    218,131, 32,180, 51,226,   115,150, 64,180,   0.527344, 0.687500, 0.687500,   0.156250, 0.191406, 0.675781
    128,176,224,172,141,119,    78, 36,192,172,   0.519531, 0.230469, 0.230469,   0.187500, 0.839844, 0.515625
     90,249,212, 69, 27, 20,   196, 89,168, 69,   0.906250, 0.281250, 0.281250,   0.187500, 0.218750, 0.705078
     56,173,156, 20, 29, 21,    86, 41, 56, 20,   0.117188, 0.363281, 0.363281,   0.847656, 0.332031, 0.589844

The first group is p_seed/systemSeed (Random_Seed); the second is the RNG_Seed set by seed_for_planet_description(p_seed); the third is land_hsb x, y, z; the last is sea_hsb x, y, z.

OK, and these are the results of GetLongSeed($System) for the first systems from my perl library:

Code: Select all

74;90;72;2;83;183
128;205;184;152;29;122
42;243;156;77;27;33
152;208;148;83;13;134
218;131;32;180;51;226
128;176;224;172;141;119
90;249;212;69;27;20
56;173;156;20;29;21

Looks like a good start...
The second set looks manageable, as this seed_for_planet_description() is part of legacy_random.(c|h) which I can actually read
I've got to see which functions from legacy_random.c I've got and which are missing in my library. But not today - I'm about to fall asleep at the keyboard...

Yours, Christian Treczoks

[Switeck]

Galactic Navy OXP and probably Constrictor hints OXP also alter system description, if only slightly.

[treczoks]

Galactic Navy OXP and probably Constrictor hints OXP also alter system description, if only slightly.

I've already included the Galactic Navy, but so far I have not found changes to any system by this OXP, they just add their ships and stations to the Ooniverse, which is duly noted.
The Constrictor Hunt was not yet on my list. I'll investigate. Thanks for the tipp!
Did you mean the original Constrictor Hunt mission or the Cataclysm OXP?
Cataclysm 1.1 has been checked, no systems modifications found(*).
AFAIK, the classical missions do not change any system data(*), except for Nova, which takes place in Galaxy Sector 4 (which is yet to come).
(*) If you know something that I've missed please tell me!

[Switeck]

The 2 mentioned OXPs only changed system description F7 key as far as I know, I only mentioned them because technically it is a system "change".