Confusion in Galaxy One

[Pleb]

In that case maybe it should be left alone, as those of us who know this rule would like you said get confused if you changed it. It's not a complicated rule to remember just a bit strange at first, but once you understand why its that way it does make more sense...in a complicated way...

[Wildeblood]

I'm just theorising I know what I said before is trivial to implement I was thinking more about a way of the game determining if an OXP was made after a certain version release, that way you could implement a load of new coding features like updating system numbers and galaxy numbers to actual values (eg - Galaxy 1 = Galaxy 1 not Galaxy 0 = Galaxy 1) without screwing old OXPs?

But there is no "Galaxy 1". There is merely a screen, internally called GUI_SCREEN_LONG_RANGE_CHART (IIRC), which happens to have "Galactic Chart x" displayed at the top, where x is often equal to 1, in an unmodified, English language localized, Oolite installation. My Oolite usually says "Galactic Sector 1" on that screen, but has also at times said "Galactic Area 1", and sometimes occasionally "Galactic Chart 1" or just "Galactic Chart". There is no particular reason to include a number at the top of that screen. Like OXPs that expose bounties, this is an example of unnecessarily exposing internal workings to the player.

Hmm... feature request... let the key in descriptions.plist that often has the value "Galactic Chart" accept a list of values, and step one place through the list after each galactic jump. (<--- That's me avoiding saying "named galaxies" in so many words.)

[Smivs]

Am I the only person who thinks we are discussing a non-existant problem here? Numbering systems starting with zero are common enough - I have a system monitor on my quad-core computer which amongst other things has four graphs for the four cores. These are numbered as CPU0, CPU1, CPU2 and CPU3. I know what it means.
And we have been happily working with the current system for years now without any problems. We know Galaxy 0 as Galaxy 1 because that's what humans do - Galaxy 0 is the first galaxy so it's called Galaxy 1 on the charts etc. The fact that 'internally' the game knows it as Galaxy 0 is irrelevant.

[Cody]

"named galaxies"

Now there's a good idea!

[Fatleaf]

"named galaxies"

Now there's a good idea!

I like the sound of that.

In Britain the equivalent to a US first floor we number it zero and give it a name "Ground Floor". So it is nothing new to a lot of people.

[cim]

Hmm... feature request... let the key in descriptions.plist that often has the value "Galactic Chart" accept a list of values, and step one place through the list after each galactic jump. (<--- That's me avoiding saying "named galaxies" in so many words.)

Lists in descriptions.plist tend to represent random choices, rather than numbered lists. I'd rather keep that convention if possible.

However, adding "long-range-chart-title-0", "long-range-chart-title-1", etc. parameters should be straightforward, and allows the "long-range-chart-title-d" parameter to be kept for galaxies a particular OXP doesn't want to name.

[Wildeblood]

However, adding "long-range-chart-title-0", "long-range-chart-title-1", etc. parameters should be straightforward, and allows the "long-range-chart-title-d" parameter to be kept for galaxies a particular OXP doesn't want to name.

Yes. That system is already used for the screenbackgrounds.plist, where you can define a default for all charts and also individual over-rides for each chart.

(Don't bother includin' any arbitrary upper limit - especially not 7 - on the number. Apparently, some people hack Oolite to use 24 charts.)

Lists in descriptions.plist tend to represent random choices, rather than numbered lists. I'd rather keep that convention if possible.

I've been meaning to ask about those sort of lists. Are they intended/expected to contain a definite number of elements, or can they be extended? In a similar vein, Submersible Nebulae OXP contains four alternative nebula images that just over-ride the usual ones, I added a nebula.plist to it that listed all eight images, but I don't know whether it's having any effect.

[cim]

(Don't bother includin' any arbitrary upper limit - especially not 7 - on the number. Apparently, some people hack Oolite to use 24 charts.)

It would be harder to add an arbitrary limit than not.

Lists in descriptions.plist tend to represent random choices, rather than numbered lists. I'd rather keep that convention if possible.

I've been meaning to ask about those sort of lists. Are they intended/expected to contain a definite number of elements, or can they be extended? In a similar vein, Submersible Nebulae OXP contains four alternative nebula images that just over-ride the usual ones, I added a nebula.plist to it that listed all eight images, but I don't know whether it's having any effect.

All of them in descriptions are arbitrarily extensible, though the ones in the system-descriptions array of arrays have a special case (for Elite-compatible RNG) when the inner array has the usual 5 elements.

nebulatextures.plist should work with any number of rows, as far as I can tell.

EDIT: fix quote markup

[Commander McLane]

Am I the only person who thinks we are discussing a non-existant problem here? Numbering systems starting with zero are common enough - I have a system monitor on my quad-core computer which amongst other things has four graphs for the four cores. These are numbered as CPU0, CPU1, CPU2 and CPU3. I know what it means.

No, you're not the only one.

Agreed, I have already gotten used to the fact that when scripting you always take 1 number away for tech levels and system numbers and even galaxy numbers (have I missed one? )

Yes, you have missed everything else. Everything in Oolite that's in any way numbered (take for instance a look at all the properties of planetinfo.plist that you didn't mention: economy, population, GDP, political system; also the coordinates on the map; also the elements of any array in your script, the first one is number 0) starts with number 0. That's how computers work and have always worked, and there is nothing new, complicated, or confusing about it.

So yes, a total non-issue.

[Fatleaf]

Am I the only person who thinks we are discussing a non-existant problem here? Numbering systems starting with zero are common enough - I have a system monitor on my quad-core computer which amongst other things has four graphs for the four cores. These are numbered as CPU0, CPU1, CPU2 and CPU3. I know what it means.

No, you're not the only one.

Make that three!

So yes, a total non-issue.

There are a few times I disagree with you Commander McLane, but this is not one of them

[Svengali]

The question was though if it makes sense to state the output value only in the documentation, so if OXPers are looking up a specific entry they always have to remember that .techLevel is non-zerobased when it needs to be exposed to the player.

cims point (if I get this right) was that you can't use .techLevel directly for displaying it as it needs the offset to match the descriptions on GUI_SCREEN_SYSTEM_DATA.

But I guess we can let it slip away, remove the old lists and Bob's your uncle .-)

[JensAyton]

Well, the fact that Oolite uses one-based for TL output and zero-based for TL input is the mess. It should probably use one-based for input as well (even if it continues to use zero-based internally), but that would break all existing equipment.plists and some planetinfo.plists.

If changing this was found to be a good idea, the equipment.plist case could be handled by allowing dictionaries instead of arrays for equipment definitions (which would make more sense anyway), and using one-based tech levels in the dictionary form. However, I think this would just result in more confusion and risk of human error.

[JensAyton]

In a similar vein, Submersible Nebulae OXP contains four alternative nebula images that just over-ride the usual ones, I added a nebula.plist to it that listed all eight images, but I don't know whether it's having any effect.

Yes, that’s why nebulatextures.plist and startextures.plist exist in the first place.