System Demux

[Dr Beeb]

Want to try out some other planet textures for a while?

http://wiki.alioth.net/index.php/System ... 8Oolite%29

Note - probably not compatible with some other similar OXPs, let me know.

[Commander McLane]

Very nice. Downloading right now.

[Cody]

This looks really good in-game, Dr Beeb... a nice alternative. Thanks!

[Eric Walch]

Note - probably not compatible with some other similar OXPs, let me know.

I assume it will have problems with famous planets also.

And I see that you have been working on this one for some time and mainly made it with Oolite 1.73. At the end you use a "setTexture()" that is deprecated with 1.74. Should be "texture=" now. Or alternatively, when you want to keep using it with 1.73 you can also replace it with:

Code: Select all

        if (0 < oolite.compareVersion("1.74"))
            system.mainPlanet.setTexture('home_planet' + hp_idx + '.png')
        else system.mainPlanet.texture = 'home_planet' + hp_idx + '.png';

But better raise the minimum oolite version and keep the code simple.

[DGill]

Thank you Dr Beeb - very nice and no texture loading delay as with Deep Horizons

[Commander McLane]

Noticed a few things:

1) You are defining this.system_info during startUp. That's okay, but you could do it as well outside any function, like in the original SR. I am not sure which is more efficient. Eric?

2) I don't understand the leading "0" in the array for Galaxy 1.

3) The way you exclude the famous planets has two problems. First, you make it depending on a mission variable, but this is an unreliable approach. Does Famous Planets.oxp even create a mission variable? I don't think so. And even if it does, the mission variable would continue to exist even after the player has removed Famous Planets.oxp from his AddOns-folder. Therefore a mission variable isn't a proper way to test for the existence of another OXP. You should test for the installment of the OXP script instead. Only that will give you the information you need. So, instead of

Code: Select all

	if (missionVariables.famous_planets) {

you need

Code: Select all

	if (worldScripts['Famous Planets Launch Script']) {

or whatever the current name of the famous planets script is, as I probably have an outdated version.

Second, famous planets currently only influences Galaxies 1 and 2 (I think), and it concerns different planets in these galaxies. Your exclusion script, however, will exclude the same planets in all galaxies. And that you don't want.

[Cmd. Cheyd]

Nicely Done, Dr. Beeb. I see a lot of Perlin noise. Did you use a generator or gradient overlays w/ thresholds? Just curious as to another artist's technique. Also, if you would like, I can probably provide some code to manage compatibility with FP, SR1, DH-SR2, etc...

DGill-
There's no delay because the textures are hard-coded via the planetinfo.plist. It's a faster approach, but it means (for example) MoonA1 will always appear in the exact same position and with the same texture in every system that it is spawned. DH-SR2 separates the moon's .plist entry (which stores location) and it's texture (chosen by the jscript). It's slower, but offers more dynamic results.

[Eric Walch]

Noticed a few things:

1) You are defining this.system_info during startUp. That's okay, but you could do it as well outside any function, like in the original SR. I am not sure which is more efficient. Eric?

It is almost the same script as the original SR script of SR1.2. Probably you compared with that of 1.0

2) I don't understand the leading "0" in the array for Galaxy 1.

Me neither. The zero is added because he always adds 1 to the system ID and than the first entry is skipped. Mometimes it makes code more readable bus as the galaxy ID stays zero based I see no benefits.

3) The way you exclude the famous planets has two problems. First, you make it depending on a mission variable, but this is an unreliable approach. Does Famous Planets.oxp even create a mission variable? I don't think so. And even if it does, the mission variable would continue to exist even after the player has removed Famous Planets.oxp from his AddOns-folder. Therefore a mission variable isn't a proper way to test for the existence of another OXP. You should test for the installment of the OXP script instead. Only that will give you the information you need. So, instead of

Code: Select all

	if (missionVariables.famous_planets) {

you need

Code: Select all

	if (worldScripts['Famous Planets Launch Script']) {

or whatever the current name of the famous planets script is, as I probably have an outdated version.

Second, famous planets currently only influences Galaxies 1 and 2 (I think), and it concerns different planets in these galaxies. Your exclusion script, however, will exclude the same planets in all galaxies. And that you don't want.

Yes that check is wrong as I mentioned elsewhere. It only checks if the player once had famous planets installed, not if it is still installed.

And as you say, your proposal only works for FP 1.0. FP 2.0 contains much more planets to exclude. But the script name has changed so you now can use both checks:

Code: Select all

	var excl = new Array();

	if (worldScripts['Famous Planets Launch Script']) {
		excl.push(8, 130, 40, 125, 247, 101, 56, 155, 149, 142);
	}	

	if (worldScripts['Famous Planets 2 Launch Script']) {
		excl.push(7, 129, 39, 124, 246, 99, 55, 154, 147, 141, 73, 50, 89, 35, 227, 250, 188, 111, 186, 101, 222, 29, 23, 177, 93, 131, 42, 21, 100, 28, 16, 221, 36, 198, 150, 62, 172, 241, 200, 18, 86, 126, 3, 153, 132, 90, 44, 228, 13,
        458,370,298,365,383,463,392,262,280,304,309,334,460,449,477,492,322,314,344,396,445,321,400,434,301,369,371,313,350,285,289,330,378,310,279,444,338,
        570,677,618,710,676,
        781,815,898,786,890,
        1040,1217,1255,1116,1033,
        1431,1286,1365,1426,1520,
        1725,1682,1666,1654,1573,
        1969,1823,2003,1949,1812);
	}	
	for (var i = 0; i < excl.length; i++) this.system_info[excl[i]] = 0;

You see, the amount of planets has grown. NB, not tested, but the numbers were calculated based on what the FP script had defined so it should not contain wrong systems.

But it would probably better to not hard code the array in the script but get the list from "worldScripts['Famous Planets 2 Launch Script'].planetList[galaxy][system.ID]" directly. That way you stay correct if FP would be updated.

[Commander McLane]

Noticed a few things:

1) You are defining this.system_info during startUp. That's okay, but you could do it as well outside any function, like in the original SR. I am not sure which is more efficient. Eric?

It is almost the same script as the original SR script of SR1.2. Probably you compared with that of 1.0

Yes, I only have v1.0.

And do you have an opinion on which way is better?

[Dr Beeb]

thanks all for the comments. Hmm, some homework assignments.

As for the '0' business, the original SR1.2 that I used had zeros at the beginning of each galaxy bank of random numbers, so I deleted them all after Galaxy 1 as things went out of sync in the later galaxies with the 257 entries present. I will check if Demux as it stands is correct.

[Dr Beeb]

Nicely Done, Dr. Beeb. I see a lot of Perlin noise. Did you use a generator or gradient overlays w/ thresholds? Just curious as to another artist's technique. Also, if you would like, I can probably provide some code to manage compatibility with FP, SR1, DH-SR2, etc...

Thanks, any compatibility code much appreciated if not covered by others. Its not clear to me how to make compatible with SR1 DH-SR2 as they all spawn planets&moons in all systems, so things would just overfill? I have no problems with some of my textures going into others.

You are correct that there is a lot of simplex Perlin noise going on, I wrote my own generator, which does things similar as you describe along with other basis functions, higher/lower powers to 'canyonize' or 'glaciate'. There is a major problem with most simplex Perlin noise at high frequency involving not being 'flat-fielded', maybe I should do a wiki page on what I did to give some ideas for what to do in the future.

I had never seen the inbuilt Oolite detailed planets until 1.74 came out for Macs - at which point I also discovered there was a DH-SR2 and realized that my little effort was approaching the point of never making it 'out of the door'. Getting my generator into Oolite looks like a major project/very slow and easier to keep generating pngs for a while. I noticed during this project that life (download time) would be much easier if indexed pngs were used that simply contained a height-map and a palette of colours, in my case 256 indexed simply to height. If the palette itself could be modified once the png was loaded that would generate a lot of different planets, with different sized-oceans etc, without huge texture folders. Of course this could free up space for other texture files, eg ones that gave the polar regions, or break up the mountains into different colour blocks etc.

[Eric Walch]

As for the '0' business, the original SR1.2 that I used had zeros at the beginning of each galaxy bank of random numbers, so I deleted them all after Galaxy 1 as things went out of sync in the later galaxies with the 257 entries present. I will check if Demux as it stands is correct.

That '0' at the start of each galaxy made that with SR there was one system in every galaxy that was not textured. The way it was coded, it made only the first system '1' based, the remainder stayed '0' based. It would involve a lot of more calculations to let it work. But because the main reason was to make it more readable this would be counter productive.
Your code fixed a bug in SR. But than you could as well remove the first '0' and replace all occurrences of "system.ID + 1" with just "system.ID".

[Eric Walch]

Your code fixed a bug in SR. But than you could as well remove the first '0' and replace all occurrences of "system.ID + 1" with just "system.ID".

On testing my previous fix against FP I notice it does not work. Looking better, I see that all the planet ID's must be added by 1 in my list. Because the same starting '0'. So better remove that first zero also, so it enables you to work with the real system ID's. On comparing my list with that of FP 1.0 I see that 2 systems differ 2 numbers instead of 1. This must mean that already SR1.2 excluded two wrong planets in combination with FamousPlanets in galaxy 1.

1) You are defining this.system_info during startUp. That's okay, but you could do it as well outside any function, like in the original SR. I am not sure which is more efficient.

I think both are equal. But when defining it at the main level, it is immediately accessible by other scripts when they run this.startUp. When defining in startUp itself, the other oxp can only access it is its startUp runs later.
I noticed when trying to access the exclusion list of famous planets by script. It would have been easier to access by other scripts at startUp if that was defined at main level.

Edit: And I found another interesting bug. SystemDemux adds planets on every launch, not only the first launch. System Redux 1.2 Had a special check for this that was deleted in SD1.0 For the player it does not show because the duplate planets are overlapping the older ones, but when asking for a planet list in the console, you see it grow on every launch

[Commander McLane]

IIRC the same problem existed in an early stage of SR. It does begin to show after a while, because the textures of the overlapping planets begin to interfere.

[Dr Beeb]

And I found another interesting bug. SystemDemux adds planets on every launch, not only the first launch. System Redux 1.2 Had a special check for this that was deleted in SD1.0 For the player it does not show because the duplate planets are overlapping the older ones, but when asking for a planet list in the console, you see it grow on every launch

Oh, that's not good.

All, let me know which textures you liked, which ones you did not and I can twiddle for the next release.