PlayerShip galaxyCoordinates and SystemInfo coordinates

[Commander McLane]

I thought they would be the same, the coordinates of the player on the galactic map.

Apparently they aren't. According to the Wiki the coordinates in SystemInfo are in light years, while the ones in PlayerShip in an unknown measure. They are, however, convertible, if the x-part is multiplied with 2.5 and the y-part with 5.

Code: Select all

> PS.galaxyCoordinates
(158, 13, 0)
> System.infoForSystem(galaxyNumber,system.ID).coordinates
(63.2, 2.6, 0)

This strikes me as odd. Why have two different ways of expressing coordinates on the map? For the rare case when you actually need to compare them it would be helpful if both values meant the same.

I want to test whether the player is currently located in interstellar space between two specific systems, and I can't think of another test than (systemA.coordinates + systemB.coordinates) / 2 = playerShip.galaxyCoordinates. However, that is made rather complicated by having to process playerShip.galaxyCoordinates.x differently from playerShip.galaxyCoordinates.y, and the same for the other two.

Is this intentional and—if yes—what is the intention behind it?

[Switeck]

The raw coordinates probably use 0-255 distances. Do you see any over 255 for PS.galaxyCoordinates?

[JensAyton]

Yep, PS.galaxyCoordinates and PS.cursorCoordinates are Doing It Wrong.

How annoying of you to discover it now rather than a few months ago. :-) Is anyone using PS.galaxyCoordinates or PS.cursorCoordinates? Unfortunately, they aren’t newly-added.

[Eric Walch]

The raw coordinates probably use 0-255 distances. Do you see any over 255 for PS.galaxyCoordinates?

PS.galaxyCoordinates were there first. Here were the internal raw values used. Only one or two Oolite version later, the systemInfo was added. At that time it was assumed to be much more user friendly to use LY as measure and not the pixels on the map.
(At least that is what I can come up as reason)
Advantage of the raw coordinates is of course that it are the values as mentioned in the galactic charts and in your saved games.

Is anyone using PS.galaxyCoordinates or PS.cursorCoordinates? Unfortunately, they aren’t newly-added.

I am using it in the "MisjumpAnalyser.oxp" When I wrote that we didn't have the systemInfo.

[Micha]

Jus FYI:
http://developer.berlios.de/pm/task.php ... ct_id=1753

While it wont make it into Stable, if you could add any scripting requirements that'd be fab.

[Commander McLane]

As Eric already said, the raw coordinates is what appears in the planet lists and in the save file.

From the planet list dump made from the F6-F6 screen many versions ago:

Code: Select all

System 7,	Lave	(20,173)	TL: 4	Human Colonials	Dictatorship
	"Lave is most famous for its vast rain forests and the Laveian tree grub."

Save-file:

Code: Select all

	<key>galaxy_coordinates</key>
	<string>161 11</string>

I would therefore argue that this is the established way of referencing the map-coordinates and should be the standard.

The 0..255 coordinates have the additional benefit of being integers, whereas the LY-based coordinates are prone to rounding errors which could be unexpected for scripters:

Code: Select all

> PS.galaxyCoordinates
(161, 11, 0)
> PS.galaxyCoordinates.x
161

but

Code: Select all

> System.infoForSystem(galaxyNumber,system.ID).coordinates
(64.4, 2.2, 0)
> System.infoForSystem(galaxyNumber,system.ID).coordinates.x
64.4000015258789

Having to add an additional Math.round() makes my current coordinate-comparison code even more awkward than it is anyway:

Code: Select all

Math.round((System.infoForSystem(galaxyNumber, this.system1).coordinates.x + System.infoForSystem(galaxyNumber, this.system2).coordinates.x) / 2 * 2.5) == player.ship.galaxyCoordinates.x && Math.round((System.infoForSystem(galaxyNumber, this.system1).coordinates.y + System.infoForSystem(galaxyNumber, this.system2).coordinates.y) / 2 * 5) == player.ship.galaxyCoordinates.y)

[JensAyton]

These particular rounding issues are illusory. The difference between 64.4 and 64.4000015258789 is simply that the former is shown with fewer digits of precision (specifically, six); 64.4 can’t be represented exactly. If Oolite consistently provided coordinates in LY, it would always provide the same value for 161/2.5 and exact comparison would work – although performing different calculations to arrive at that result might produce small deviations.

If the issue had been exposed before 1.75, I would definitely and without question switch to LY coordinates. That the internal format is used internally is utterly and completely irrelevant; hiding internal details in favour of clean interfaces is a constant theme in the JavaScript interface. (Relying on current internals is a loser’s game anyway; sticking with the current internal coordinate scheme doesn’t guarantee that you’ll only get integer coordinates in future, and that’s not purely hypothetical.)

[Commander McLane]

My rounding was bad anyway, because I had erroneously assumed the right side of the equation to be an integer under all circumstances. Of course that was faulty logic in case of coordinates in the middle between systems. Halfway between [10, 10] and [13, 13] is [11.5, 11.5], for example.

Therefore the code now rounds to the next tenth (although the next half should actually suffice for single misjumps).

I don't think that the rounding issues are illusory, though. Being in the same system as in the example above, I just made the comparison in the JS console:

Code: Select all

> System.infoForSystem(galaxyNumber,system.ID).coordinates.x
64.4000015258789
> PS.galaxyCoordinates.x
161
> System.infoForSystem(galaxyNumber,system.ID).coordinates.x * 2.5 == PS.galaxyCoordinates.x
false
> System.infoForSystem(galaxyNumber,system.ID).coordinates.x == PS.galaxyCoordinates.x / 2.5
false
> Math.round(System.infoForSystem(galaxyNumber,system.ID).coordinates.x * 2.5 * 2) / 2 == PS.galaxyCoordinates.x
true

Without rounding the result turns out false, regardless how it's calculated, therefore the JS code would believe that I am not in the system I am in.

[JensAyton]

I don't think that the rounding issues are illusory, though. Being in the same system as in the example above, I just made the comparison in the JS console:

Code: Select all

> System.infoForSystem(galaxyNumber,system.ID).coordinates.x
64.4000015258789
> PS.galaxyCoordinates.x
161
> System.infoForSystem(galaxyNumber,system.ID).coordinates.x * 2.5 == PS.galaxyCoordinates.x
false
> System.infoForSystem(galaxyNumber,system.ID).coordinates.x == PS.galaxyCoordinates.x / 2.5
false
> Math.round(System.infoForSystem(galaxyNumber,system.ID).coordinates.x * 2.5 * 2) / 2 == PS.galaxyCoordinates.x
true

Without rounding the result turns out false, regardless how it's calculated, therefore the JS code would believe that I am not in the system I am in.

If System.infoForSystem(galaxyNumber,system.ID).coordinate and PS.galaxyCoordinates were provided in the same coordinate system by Oolite, the conversion would be done in exactly the same way and the results would be equal. However, since they aren’t, you can’t guarantee identical results in JavaScript (and it may be impossible to achieve in JS).

[JensAyton]

OK, here’s the deal. I’m adding:

• SystemInfo internalCoordinates
• player.ship.cursorCoordinatesInLY
• player.ship.galacticHyperspaceFixedCoordsInLY
• player.ship.galaxyCoordinatesInLY

The versions using internal coordinates will be marked discouraged (but not deprecated).

Incidentally, as discussed elsewhere the general way to test the equality of two vectors is to check that the distance between them is very short:

Code: Select all

if (v1.squaredDistanceTo(v2) < 1e-12) // if distance is less than 0.000001
{
    // vectors are effectively equal.
}

Rounding isn’t a general solution, because it divides vectors into discrete equivalence classes; if a and b differ only by the smallest possible value, but are on different sides of a round operation, they’ll be considered further apart than values on opposite sides of the same equivalence class.

[Kaks]

are on different sides of a round operation, they’ll be considered further apart than values on opposite sides of the same equivalence class.

And for English speakers amongst us: if you round numbers, the code will treat 1.49 & 1.50 as totally different values, but will treat 1.50 & 2.49 as the same value!