TL and Station Types (Cori, Dodo, Ico)

[JeffBTX]

I did a search, and this subject HAS been brought up before in other threads; but NOT definitively answered.

The basic question is: What is the *native* distribution of the station types (Coriolis, Dodo, Ico) among systems per tech level (specifically)? (which, as I understand it, gets linked to > a "role", and that is how an OXP can change / set-up the distribution of stations).

I've examined planetinfo.plist, shipdata.plist, and stationAI.plist (native, non-OXP); no answers there, so it must be hard-coded into the engine.

I searched the wiki. No answer that I could find.

REASON: I'm *considering* trying my hand at integrating several OXPs into one OXP (in some cases, JUST extracting certain stations and leaving out the rest of what is in the OXPs); for my OWN USE of course. JUST for eye-candy and variety. I'll also be re-working System_Redux (a little) for my own use.

I think there is already enough info here in the forum to teach me HOW to setup new station distribution (probability)... all I need to do is consolidate the forum posts and paste them into a "mini-manual" of sorts. No need to repeat it here.

But in the meantime, I MIGHT want to kind of follow the canon as far as Cori-role, Dodo-role, and Ico-role (or I might want to change it). And I think the answer is in the engine, rather than in any documentation.

What I envision an answer to be (sort of - this is just an example of what I might be looking for):
"Mr Knowledgeable Developer" says:
Ico: High TL 12-14, probabilities are (whatever they are)... given (any givens)...
Dodo: Mid TL 6-13 (overlap with ICO) (bla-bla and et cetera)...
Cori: Can be anywhere, but given the above two types, the distribution will be statistically more apparant at lower TL, < = 6.

Thanks.

----- -----

Also (this is just a minor question): In shipdata.plist, what is "asteroid-alternative", "boulder-alternative", and "splinter-alternative?
Maybe I've been seeing two slightly different models of these objects in the Ooniverse but just haven't noticed it.

[JeffBTX]

I'll also be re-working System_Redux (a little) for my own use.

Ummm... never mind that, I think. What I WANTED to do was to insure that the new planet textures showed in the 7 / F7 screen (system info). I just had a look at the script and the planetinfo.plist for the OXP.

Unless someone wants to explain how to do it... I imagine that the answer is in a new kind of .plist, if such a thing exists - kind of along the lines of demoships.plist in function?

[Svengali]

Icos and Dodecs TechLevel > 11 (12+ in game, zero based) with 2/3 Dodecs and 1/3 Icos.

[Kaks]

I'll also be re-working System_Redux (a little) for my own use.

Ummm... never mind that, I think. What I WANTED to do was to insure that the new planet textures showed in the 7 / F7 screen (system info). I just had a look at the script and the planetinfo.plist for the OXP.

Unless someone wants to explain how to do it... I imagine that the answer is in a new kind of .plist, if such a thing exists - kind of along the lines of demoships.plist in function?

I'm going to do some guessing here, and I'll assume that if you look at the local system, the planet is retextured, when you look at all other systems, you see Oolite's generated texture. If you don't see the local F7 planet as textured, then you have a different problem altogether: retexturing on the F7 screen needs to have 'detailed planets' on, which was disabled on macs due to crashy bugginess. So if you're using a mac, no joy there, until - hopefully - 1.74.

The way system redux works, it waits for you to jump to a system before picking the planet texture out of a choice of 16. It then temporarily replaces the local system's texure. To permanently assign a texture to a specific planet (let's say lave: planet 7 in galaxy 0), the simplest way to do it is to add the following to planetinfo.plist.
Either:

<key>0 7</key>
<dict>
<key>texture</key>
<string>newPlanetTexture.png</string>
</dict>

or the 'slightly' tidier

"0 7" = {
texture = "newPlanetTexture.png";
}

Both formats are valid, though for most people it's a lot easier to play around with an openStep format file. The important thing is to either use one format, or the other. Mixing formats inside the same plist will just confuse Oolite.

You can override quite a lot of things inside planetinfo.plist:
look at http://wiki.alioth.net/index.php/Planetinfo.plist to find out more! A lot of the documentation hasn't been updated with openstep examples, so it's probably only going to show XML...

[JeffBTX]

Svengali; Thanks, that answers my question.

Kaks; Thanks, I think that answers my question... I'm on a PC, but I had a quick look to see where "detailed planets" might be stored... it isn't (stored anywhere in the most likely places)... and going from game documentation, it looks like "detailed planets" provision(s) removed altogether. (some time ago I did try that key sequence... I forget what it was, I think PAUSE then 't' or something... no effect).

I don't know if using planetinfo.plist the way you describe would impose the texture to BOTH the planets in-space appearance AND the F7 screen. I can do an experiment to find out, I pasted your post into a text file to at least see if this would work.

But even if it does work, and the goal is to have (with System_Redux) all planets match their appearence both externally and in the F7 screen, the file would be huge.

No big deal.

[another_commander]

I'm on a PC, but I had a quick look to see where "detailed planets" might be stored... it isn't (stored anywhere in the most likely places)... and going from game documentation, it looks like "detailed planets" provision(s) removed altogether. (some time ago I did try that key sequence... I forget what it was, I think PAUSE then 't' or something... no effect).

Hint: Game Options.

[Kaks]

Back to first principles then: if you press f2, you should see a line that says 'game options': if you highlight it, double click it / press enter / whatever, you'll see it amongst the game options.

By the way, do have a look at the reference sheet that comes with Ooite, you might find tons of interesting info like that.

Edit: drats, Nikos was faster!

PS:

I don't know if using planetinfo.plist the way you describe would impose the texture to BOTH the planets in-space appearance AND the F7 screen. I can do an experiment to find out, I pasted your post into a text file to at least see if this would work.

But even if it does work, and the goal is to have (with System_Redux) all planets match their appearence both externally and in the F7 screen, the file would be huge.

I know it does, I'm the one that coded it.
So you need 3 lines per planet:

3*256*8 = about 6200 lines, mostly a matter of copy & paste. 3 / 4 hours' effort, and you've got the system exactly as you want it.

[JeffBTX]

Another_Commander;
Ok... I guess I / we ended up talking about a couple of different things... wires are crossed a bit.. yes, I just checked, toggling "Detailed Planets" in game options changes between *procedurally* textured planets and *"featureless"* planets.

With system_redux, the planets ARE retextured nicely when one is "outside flying around". But if you invoke F7 to get system info, you see the native procedurally textured planet... both for the current system and any other systems that are selected in F6.

EDIT: I've always operated w/ Detailed Planets: ON

[Kaks]

Let's try one more time: retexturing planets using texture = 'blah.png' inside planetinfo.plist, and displaying the texture in the F7 screen only works if detailed planets is on. There's only one detailed planets option, and it's the one available from 'game options'.

If you start a new game and look at the F7 screen while still inside the station & with System Redux on your AddOns folder, you'll see Oolite's 'standard' generated planet on the F7 screen.

Once you launch from Lave station and System Redux has a chance to retexure the planet, does the same texture show up when you look up Lave with the F7 screen again?

Using the planetinfo.plist method, all the custom textures are available on the F7 screen at all times.

[JeffBTX]

Ah... start a new game... that makes sense. I'll have to do a quick experiment...

[JeffBTX]

Ok... just a minor oddity... and I think I understand vaguely what is happening.

In my *current* game, I am docked at Ensoreus. If I look at F7-Ensoreus, it is procedurally textured. If I select a nearby system Ararus, it is also procedurally textured.

If I undock (and Ensoreus is now effected by system_redux) and look at F7, the new detailed texture appears. If I dock, F7 is using the detailed texture. Ararus is still procedurally textured.

I jump to Ararus, and Ararus is repainted by system_redux, and it also now shows in F7. If I select Ensoreus, the previous system, F7 is BACK to PROCEDURALLY texturing Ensoreus (until I fly back again). It isn't "retaining" the textures for the F7 screen. (unless using a planetinfo.plist would force retention - but the file would be too big I think to be practical - a lot of work!).

I'll try it with a new game...

EDIT:

Same thing with a new game. At Lave, with a new game, F7 shows the procedural texture. Exiting the station is required to "Load" the texture in, after which F7 shows the .PNG texture. Select another system, F7 is procedural, fly there and F7 becomes PNG for the *local system*. F7 for Lave though is back to procedural; the game didn't "retain" a reference to the PNG for the previous system.

No Biggie. Maybe a huge planetinfo.plist would fix this (it ISN'T really broken... just odd and inconsistant)... but I don't think I want to.

[Thargoid]

If I remember correctly SR (and Famous Planets) change the planet's texture "on the fly" when you just into the system (via this.shipWillExitWitchspace and this.shipWillLaunchFromStation), not by using planetinfo.plist. These do only last while the system "exists" (ie you're in it and not docked).

That's why you're seeing what you are, the textures are being applied differently. What you'd need to do is write a planetinfo.plist that contains an entry for each system (and each galaxy) as you've already described. That isn't how SR works at the moment.

[JeffBTX]

Thargoid... thanks (Do Thargoids have dieties? Would they be Thargods?)...

And the planetinfo.plist would be too huge to mess with, even if it worked. I'm not going to try.

EDIT: That's one thing that I didn't check, or notice... whether system textures were being generated "on the fly". They don't SEEM to... the systems are consistant from visit to visit. But I seem to remember a "SEED" keyword being used several times in the system_redux config files... if it is seeding a random number generator consistantly, that follows.

[Eric Walch]

Icos and Dodecs TechLevel > 11 (12+ in game, zero based) with 2/3 Dodecs and 1/3 Icos.

Almost there. According to the code it is:

Code: Select all

	defaultStationDesc = @"coriolis";
	if (techlevel > 10)
	{
		if (system_seed.f & 0x03)   // 3 out of 4 get this type
			defaultStationDesc = @"dodecahedron";
		else
			defaultStationDesc = @"icosahedron";
	}

techlevel > 10 is zero based, so in game it is 12+ as you write, only the chances are a bit different according to the comment.

In my private universe I disabled all internal stations with an override.plist (As in Griffs work) and than added conditions to the stations in shipdata so I always get consistent stations for a system. Conditions containing selections by additional techLevels, governments and preudoRandom chances. Just make sure it can always meat one of the conditions.

[Svengali]

You're right, Eric. I remembered it wrong .-)

And your idea with the shipdata-overrides.plist+conditions is probably even better than with my approach (planetinfo.plist).