Musings about stuff that I could do to the source code...

[Wildeblood]

I like what you've done with the space colors. Is that feature easy to implement for oxp-makers? Could you even make it yellow/red/green?
Then you could simulate that the planet in question lies within a nebula.

I like to see nebula's included one day in Oolite.

I think that Tianve OXP does an excellent job of simulating a nebula.

[Pleb]

I like what you've done with the space colors. Is that feature easy to implement for oxp-makers? Could you even make it yellow/red/green?
Then you could simulate that the planet in question lies within a nebula.

The colour values at the moment are part of the source code, but it probably wouldn't be hard to have it referenced in planetinfo.plist instead. Problem is at the moment the code in the source controls all space so it would have to be changed to reflect on what galaxy number and what system number the player is currently in. But I don't see why not I will look into this.

[Pleb]

Okay you can easilly modify the code to have an entry in planetinfo.plist to change the colour for the space background globally (in all systems). I will tonight try and make it so that it can be under system/interstellar/universal instead so you could have one system with normal black space and another with a dark green background and another with a dark red background, etc... I would have posted up the code for what I've done so far but my wireless internet dongle has run out of credit and I don't get paid till Friday! Also same day findind out sex of the baby! All happening Friday...

[Smivs]

Also same day finding out sex of the baby!

Exciting times, eh? My guess is it will be a boy or a girl!

[SandJ]

If system -1 is interstellar space, then the system number is not an 8 bit unsigned integer.

That means the 256-system limit is not a fixed limit; there could be up to 32767 systems per galaxy!

[Wildeblood]

If system -1 is interstellar space, then the system number is not an 8 bit unsigned integer.

That means the 256-system limit is not a fixed limit; there could be up to 32767 systems per galaxy!

I don' know about any of that technical stuff, but I know I accidentally created a galaxy with 257 systems last week (using unhacked 1.76.1).

[SandJ]

If system -1 is interstellar space, then the system number is not an 8 bit unsigned integer.

That means the 256-system limit is not a fixed limit; there could be up to 32767 systems per galaxy!

I don't know about any of that technical stuff, but I know I accidentally created a galaxy with 257 systems last week (using unhacked 1.76.1).

The numbers 255 and 256 keep coming up in 8-bit games because you can either store 256 numbers in 8 bits: either the values 0..255 in 8 bits ("unsigned") or the values -128..+127 in those 8 bits ("signed").

An Oolite galaxy has 256 systems because that was an easy thing to handle on those old 8-bit BBC, Spectrum, etc. computers.

But Oolite has a system number of -1 to represent interstellar witchspace, so the system number cannot be being stored in an 8 bit variable. The next size limit is 16 bits and since it must be signed (to hold -1), that would allow -32768..+32767.

Hence, 32,767 systems in one galaxy.

(Since we are all running on 32-bit machines or better, it may well be that 2,147,483,647 systems per galaxy is possible... which would mean about 655 systems on every point of the 2560x1280 point galaxy!)

[Wildeblood]

The numbers 255 and 256 keep coming up in 8-bit games because you can either store 256 numbers in 8 bits: either the values 0..255 in 8 bits ("unsigned") or the values -128..+127 in those 8 bits ("signed").

An Oolite galaxy has 256 systems because that was an easy thing to handle on those old 8-bit BBC, Spectrum, etc. computers.

But Oolite has a system number of -1 to represent interstellar witchspace, so the system number cannot be being stored in an 8 bit variable. The next size limit is 16 bits and since it must be signed (to hold -1), that would allow -32768..+32767.

From OOTypes.h...

Code: Select all

typedef uint8_t		OOGalaxyID;			// 0..7
typedef int16_t		OOSystemID;			// 0..255, -1 for interstellar space (?)


enum
{
	kOOMaximumGalaxyID		= 7,
	kOOMaximumSystemID		= 255,
	kOOMinimumSystemID		= -1
};

It would be nice if the exact number of systems per chart varied somewhat, perhaps between 200ish and 256. That would make the underlying nature of the chart less obvious.
The other number that keeps coming up, because of Elite's 8-bit origin, is eight. There are eight government types and eight economy types. It might be nice to see one or other list extended: perhaps planets with government type "Utopian", or economy type "post-scarcity" or "subsistence".

(Since we are all running on 32-bit machines or better, it may well be that 2,147,483,647 systems per galaxy is possible... which would mean about 655 systems on every point of the 2560x1280 point galaxy!)

You have a 2560-pixel wide monitor? Sigh.

[JensAyton]

If system -1 is interstellar space, then the system number is not an 8 bit unsigned integer. :twisted:

This doesn’t actually follow. It would be entirely possible for the game to store an eight-bit galaxy ID but return -1 to the scripting interface if there’s no sun in the current system.

The other number that keeps coming up, because of Elite's 8-bit origin, is eight. There are eight government types and eight economy types.

Not strictly true; it could just as easily be four or sixteen regardless of the bitness of the system. Eight is a design decision. Other numbers would be much more expensive on eighties systems because they didn’t have hardware division. (Well, technically, to divide by a constant quickly it’s sufficient to have hardware multiplication, which is much cheaper than division.)

[Pleb]

If system -1 is interstellar space, then the system number is not an 8 bit unsigned integer.

No it is not an 8bit unsigned integer it is in fact a 16bit integer, as you can see from the code below:

From OOTypes.h...

Code: Select all

typedef uint8_t OOGalaxyID; // 0..7
typedef int16_t OOSystemID; // 0..255, -1 for interstellar space (?)


enum
{
kOOMaximumGalaxyID = 7,
kOOMaximumSystemID = 255,
kOOMinimumSystemID = -1
};

You could have more than 256 systems but it may cause issues. I've never really experimented with changing this as I assumed it would cause the game to crash. I will investigate this and post up my results if something good comes from it...

The other number that keeps coming up, because of Elite's 8-bit origin, is eight. There are eight government types and eight economy types.

Not strictly true; it could just as easily be four or sixteen regardless of the bitness of the system. Eight is a design decision. Other numbers would be much more expensive on eighties systems because they didn’t have hardware division. (Well, technically, to divide by a constant quickly it’s sufficient to have hardware multiplication, which is much cheaper than division.)

This is something else I wondered about, adding more governments, economies, etc... The first problem with this is that it would change the government types for Galaxies 1-8, which is a big no-no in my book. The second problem is how to go about having Galaxies 1-8 populated using the original/current algorythum and the newer Galaxies 9-16 using a different one. If this was possible, then other features could be added such as changing the way system names are generated to include the missing letters.

[cim]

The second problem is how to go about having Galaxies 1-8 populated using the original/current algorythum and the newer Galaxies 9-16 using a different one. If this was possible, then other features could be added such as changing the way system names are generated to include the missing letters.

The obvious solution is to define the information through planetinfo.plist rather than using seeded random generation at runtime. (Generate the planetinfo.plist using a RNG to get the first 8 galaxies the same as before, sure...)

There are at present a number of parameters defined by the random generation which cannot be changed via planetinfo.plist; for your private use that's just a bit of programming away. I haven't looked to see exactly what this applies to, but I expect at least some of them should be editable (while allowing editing of others - at least for Galaxies 1 to 8 - could easily break things)

[SandJ]

(Since we are all running on 32-bit machines or better, it may well be that 2,147,483,647 systems per galaxy is possible... which would mean about 655 systems on every point of the 2560x1280 point galaxy!)

You have a 2560-pixel wide monitor? Sigh.

My mistake. What I mean is, the systems are located on a 256 x 128 grid, where the points are in steps of 0.1 - but they are in steps of 1 so there are 256 x 128 possible locations, not 2560 x 1280.

Tibedied (2,90)
Uszaa (3,153)
Gelegeus (253,159)
Aate (253,35)
Cemave (6,0)
Zaatxe (236,0)
Laeden (4,254)
Legees (4,253)

These co-ordinates allow for 256 x 128 locations which allows for 32,768 different places for systems to be. We already have cases of 2 systems being in the same place in space with just 256 systems per galaxy.

[cim]

My mistake. What I mean is, the systems are located on a 256 x 128 grid
[...]
Gelegeus (253,159)

Actually it's a 256x256 grid, but the spacing between grid points is larger in one direction than the other, so 65536 possible positions.

[SandJ]

My mistake. What I mean is, the systems are located on a 256 x 128 grid
[...]
Gelegeus (253,159)

Actually it's a 256x256 grid, but the spacing between grid points is larger in one direction than the other, so 65536 possible positions.

And I even provided the evidence to prove myself wrong.

I shall sit in the Dunce's corner for the rest of the evening.

[Pleb]

Okay a bit of thread necromancing here (but its my thread so ), but after a small amount of tweaking I've figured out how to create a reversible Galactic Hyperdrive...well a piece of equipment that is single use like the Galactic Hyperdrive itself. Two source files need to be edited to achieve this, and a new entry needs to be added to the equipment.plist file. I used the source code from version 1.76.1.

First, open the legacy_random.h file in the 'src\Core' directory and go to line 108. It should look like this:

Code: Select all

OOINLINE int rotate_byte_left (int x) INLINE_CONST_FUNC;

Add below this line the following code:

Code: Select all

OOINLINE int rotate_byte_right (int x) INLINE_CONST_FUNC;

Now go down to about line129 to the following code, which should look like this:

Code: Select all

OOINLINE int rotate_byte_left(int x)
{
	return ((x << 1) | (x >> 7)) & 255;
}

Now add below this code the following code:

Code: Select all

OOINLINE int rotate_byte_right(int x)
{
	return ((x >> 1) | (x << 7)) & 255;
}

This has now created a new command in the source code, which will allow the program to rotate the galaxy seed right instead of left (how it normally does).

Now, open up the PlayerEntity.m file in the 'src\Core\Entities' directory and go to line 5044, which should look like this:

Code: Select all

	galaxy_number++;
	galaxy_number &= 7;

	galaxy_seed.a = rotate_byte_left(galaxy_seed.a);
	galaxy_seed.b = rotate_byte_left(galaxy_seed.b);
	galaxy_seed.c = rotate_byte_left(galaxy_seed.c);
	galaxy_seed.d = rotate_byte_left(galaxy_seed.d);
	galaxy_seed.e = rotate_byte_left(galaxy_seed.e);
	galaxy_seed.f = rotate_byte_left(galaxy_seed.f);

Now replace the entire code shown above with the following code:

Code: Select all

	// Check if the GH Reverse Unit equipment is present:
	if ([self hasEquipmentItem:@"EQ_GAL_DRIVE_REVERSE_UNIT"])
	{
		// Decrease galaxy number and do it in a safe way:
		if (galaxy_number > 0)
		{
    			galaxy_number--;
		}
		else  // we are at galaxy 0, now we need to cycle to 7
		{
			galaxy_number = 7;
		}
		
		// Rotate Galaxy Seed right instead of left to change to previous Galaxy Seed:
		galaxy_seed.a = rotate_byte_right(galaxy_seed.a);
		galaxy_seed.b = rotate_byte_right(galaxy_seed.b);
		galaxy_seed.c = rotate_byte_right(galaxy_seed.c);
		galaxy_seed.d = rotate_byte_right(galaxy_seed.d);
		galaxy_seed.e = rotate_byte_right(galaxy_seed.e);
		galaxy_seed.f = rotate_byte_right(galaxy_seed.f);
		
		// Remove the GH Reverse Unit equipment:
		[self removeEquipmentItem:@"EQ_GAL_DRIVE_REVERSE_UNIT"];
	}
	else
	{
		galaxy_number++;
		galaxy_number &= 7;

		galaxy_seed.a = rotate_byte_left(galaxy_seed.a);
		galaxy_seed.b = rotate_byte_left(galaxy_seed.b);
		galaxy_seed.c = rotate_byte_left(galaxy_seed.c);
		galaxy_seed.d = rotate_byte_left(galaxy_seed.d);
		galaxy_seed.e = rotate_byte_left(galaxy_seed.e);
		galaxy_seed.f = rotate_byte_left(galaxy_seed.f);
	}

Now this will make the program check if the player has a piece of equipment, in this case the 'GH Reverse Unit' and if this equipment is present will allow travel to the previous galaxy and will remove the equipment after use.

Finally open up the equipment.plist file in the 'oolite.app\Resources\Config' directory and add the following code:

Code: Select all

	(
		10, 50000, "GH Reverse Unit",
		"EQ_GAL_DRIVE_REVERSE_UNIT",
		"A single use device that forces the Galactic Hyperdrive to enable travel to a previous galaxy.",
		{
			available_to_all = true;
		}
	),

This will create a new piece of equipment, the 'GH Reverse Unit', which will be available in the same systems/stations that the Galactic Hyperdrive is, and will cost the same amount of money.

So now you have the ability to travel from Galaxy 2 back to Galaxy 1, and even travel from Galaxy 1 to Galaxy 8 without having to go all the way round. This will work with the standard source code for version 1.76.1 and in the trunk. But if you are using the modified source code for extra galaxies that I wrote then this will need to be modified to incorporate that...