Been investigating Andrei's question by trial and error.
_class_to_group (001FBDF5..001FBE12)
...
Probably something with star colours. Couldn't see any effects in-game; no idea what a "group" is supposed to be.
Group is used to determine planet climate. Your assumption that the rows are star color is correct. I believe that the columns are planet orbit. This process takes place before home systems, orion, and monster systems are assigned and modified, so those systems may override what is set here.
_climate_roll_table (001FBE13..001FBE3A)
_normal_gal_climate_roll_table (001FBE3B..001FBE62)
_old_gal_climate_roll_table (001FBE63..001FBE8A)
...
Judging by the names, these should determine the climates for the different galaxy ages. Can't figure out how, though. Mineral rich and average are identical?
You had the dimensions of these tables incorrect. They're actually suppose to be 4 columns (group number from the previous table) by 10 rows (each type of planet climate).
It appears the '_climate_roll_table' table is just completely ignored. Organic Rich uses the _old_gal_climate_roll_table while Average and Mineral Rich use _normal_gal_climate_roll_table. The reason these last two don't generate identical galaxies is that group depends on spectral class, and spectral class depends on galaxy age (as i'll get to).
Home worlds will get changed to terran/aquatic, obviously.
Orion, and some stars with monsters, will override these results and can either upgrade or downgrade planets in their systems.
This is what i believe the code looks something like:
Code: Select all
char galaxy_age; // this is either 0,1, or 2 for mineral rich,average, and organic rich respectively
struct planet p; //set to the current planet
struct star s; //set to the current star
char* climate_table = game_type == 2 ? _climate_roll_table : normal_gal_climate_roll_table;
char group = _class_to_group[s.spectral_class*5+p.orbit_number];
short total = 0;
for(int i = 0;i<10;i++) short += climate_table[i*4+group];
short rand = rand(total);
short sum = climate_table[group];
p.climate_type = 0;
while(sum < rand) {
p.climate_type++;
sum += climate_table[p.climate_type*4+group];
}
_star_class_table (001FBED2..00IFBEE6)
...
I have no idea, but the 1..6 at the bottom might serve a special role or not be part of the table at all.
This table is what you need to change the generation of different colors of stars/black hole. The column is the galaxy age . The row is the spectral_class, 0-6. The value at each set of coordinates represents the weighting.
There appears to be some sort of routine running after this that changes some stars to spectral class 4 (red). Stars that get changed to red always seem to be within 6 parsecs of a home star, so i believe this may be the game trying to ensure that every race has nearby star that can be colonized.
The game does not seem to like blue stars as home stars either. For example, if you set the first byte in this table to 0xFF, the 7th byte to 0x01, the 4th, 10th, 13th, 16th, and 19th bytes to 0x00, and finally start a new mineral rich game, then the home stars should all be yellow, with the rest being blue. If you then set the 7th byte to 0x00, restart the game, and start another game as mineral rich, it should hang infinitely on the 'Placing Home Worlds' step.
Here's a short bit of code to describe what, as far as i can tell, the game is doing:
Code: Select all
char galaxy_age; // this is either 0,1, or 2 for mineral rich,average, and organic rich respectively
struct star s; // set to the current star
short total = 0;
for(int i=0;i<7;i++) total += _star_class_table[i*3+galaxy_age];
short rand = rand(total);
short sum = _star_class_table[galaxy_age];
s.spectral_class = 0;
while(sum < rand) {
s.spectral_class++;
sum += _star_class_table[s.spectral_class*3+galaxy_age];
}
The code for both these may actually be using char instead of short. Also not sure if they're signed or unsigned. I don't really feel like testing since there is still plenty of granularity keeping the sum of each column under 128.