JS system.planets, reconstructs on every launch event.

[Frame]

I have been moving planets around a lot lately...

however, I found that every time you launch then system.planets is rearranged.

example... i load a commander... no planets have been added

I write system.planets in the debug console and I get this

Code: Select all

[Planet ID: 143 position: (0, 0, 340600) type: PLANET_TYPE_GREEN radius: 34.060km]

I now launch with system redux installed, that in this particular system adds 3 moons, and i add one Planet in my own script..

Code: Select all

[Planet ID: 143 position: (0, 0, 340600) type: PLANET_TYPE_GREEN radius: 34.060km],[Planet ID: 193 position: (23511.5, -97614.9, 406344) type: PLANET_TYPE_GREEN radius: 9.000km],[Planet ID: 192 position: (-64386.9, 52011, 270741) type: PLANET_TYPE_GREEN radius: 7.000km],[Planet ID: 194 position: (65069.1, 9371.3, 244347) type: PLANET_TYPE_GREEN radius: 8.000km],[Planet ID: 195 position: (0, 0, -4.91e+007) type: PLANET_TYPE_GREEN radius: 90.000km]

So far so good, everything is added in the correct order of things..

I then enter my jumpgate, and my script moves planets and moons around, so that everything stays inside the stable precision coordinate system..

then on the other side of the jumpgate, i again type system.planets
and i get this...

Code: Select all

[Planet ID: 195 position: (0, 0, 900000) type: PLANET_TYPE_GREEN radius: 90.000km],[Planet ID: 194 position: (65069.1, 9371.3, 5.02443e+007) type: PLANET_TYPE_GREEN radius: 8.000km],[Planet ID: 192 position: (-64386.9, 52011, 5.02707e+007) type: PLANET_TYPE_GREEN radius: 7.000km],[Planet ID: 143 position: (0, 0, 5.03406e+007) type: PLANET_TYPE_GREEN radius: 34.060km],[Planet ID: 193 position: (23511.5, -97614.9, 5.04063e+007) type: PLANET_TYPE_GREEN radius: 9.000km]

As you can see, everything has been rearrenged when i launched from the jumpgate, which is like a station... that however launches you 1 second after docking...

The only possible reason for this is that, the code recontructs system.planets on every launch event... and when planets have been moved around, these are not any longer in the original order. this is cosmetics, but not logical. That elements of an array will get a new place in the array, according to some set distance measurement to either the sun, or the witch point...

I find it a bit wasted CPU time,that the code reconstruct system.planets every time the player is launched, so a few cycles could maybe be saved here...

Of course with my limited insight to the scripting engine, something like this may be needed for some to me unimaginable reason...

There might be other arrays that are reconstructed on every launch event, like system.allShips, all though I have not tested that yet, but from a scripters point of view, I think at least system.planets order, should stay static, and of course expand by 1 every time a new planet/moon is added, and not rearrange its order at any time.

Luckly i had build my own array, and set that to the system.planets array, on the very first launch, and its order stays static. imagine the trouble I would have had with an array, that had a dynamic order...

Cheers Frame....

[Thargoid]

I think it essentially does a scan for planets centred around the ships current location, at least that's what it looked like from my testing of PlanetFall.

The order changes because your position does, hence the scan's focus and the distance to the planets does. It's presumably so triggers like enteredPlanetaryVicinity and such work on the correct entity (the closest one I would guess?).

[Frame]

I think it essentially does a scan for planets centred around the ships current location, at least that's what it looked like from my testing of PlanetFall.

The order changes because your position does, hence the scan's focus and the distance to the planets does. It's presumably so triggers like enteredPlanetaryVicinity and such work on the correct entity (the closest one I would guess?).

you are right, I entered from witch space, wrote out system.planets

I flew as close to a moon as possible... and wrote out system.planets again.. system.planets[3] was now system.planets[0]

So this happens in flight... I wonder what would be the reason to rearrange the array... as from a coders point of view.. well mine, that is not logical...

Edit: a notation if this behaviour might be valid on the wiki...

[Thargoid]

Presumably to streamline the code (it can use the same type of scan engine code as for scans relating to ships and other entities.

Also to allow for dynamically introduced planets and moons, such as yours and those of System Redux.

[JensAyton]

Edit: a notation if this behaviour might be valid on the wiki...

No. The order of items in system.planets is not guaranteed and is likely to change in future. (Implementationwise, searching for planets is known to take up an unacceptable amount of time and some sort of caching will be added, probably for 1.73. I’m certainly not going to make guarantees about order before implementing it and rewriting the various things that depend on it.)

[Frame]

Edit: a notation if this behaviour might be valid on the wiki...

No. The order of items in system.planets is not guaranteed

That notation... would be though

like this...

The order of items in system.planets is not guaranteed, in any of the test releases

[Commander McLane]

I was under the impression that every search method which returns an array will sort that array with growing distance to the player ship, unless something else is specified. ?!?

[JensAyton]

I was under the impression that every search method which returns an array will sort that array with growing distance to the player ship, unless something else is specified. ?!?

True, but I don’t think it’s documented that system.planets is a search method. :-)

[Thargoid]

Without wishing to ask a daft question (ok, more daft than normal) if it isn't then what else would it be?

Also is there any other planet type than type: PLANET_TYPE_GREEN ?

[JensAyton]

Without wishing to ask a daft question (ok, more daft than normal) if it isn't then what else would it be?

Personally, I’d expect it to be an accessor for a quasi-static list, which I believe is what Frame was expecting.

Also is there any other planet type than type: PLANET_TYPE_GREEN ?

Yes: PLANET_TYPE_SUN, PLANET_TYPE_ATMOSPHERE and PLANET_TYPE_MINIATURE. I don’t think you’re likely to find a situation where this matters, though. :-)

[Thargoid]

I don't think I've ever seen any of those other planet types, even in the PF scan which includes the sun.

Or is that perhaps a glitch in system redux that it always spawns type green's? (although that doesn't explain the sun, unless I'm wrong about that, will need to check).

[JensAyton]

ATMOSPHERE and MINIATURE-type planets are never part of the system. Atmospheres are owned by Greens, and Miniatures are only used for the F7 screen. Suns are a different type of object from the perspective of scripts.

In short, PLANET_TYPE_GREEN means planet, and the others are implementation details.

[Lestradae]

BTW ... would it be very difficult for you devs to let the system redux planets also appear on the F7 screen?

It would be a really nice feature.

[another_commander]

BTW ... would it be very difficult for you devs to let the system redux planets also appear on the F7 screen?

It would be a really nice feature.

It's been attempted. It's more hassle than it's worth. I'd rather go with the procedural textures instead, if we could find a way to optimize their performance.

[Frame]

BTW ... would it be very difficult for you devs to let the system redux planets also appear on the F7 screen?

It would be a really nice feature.

It's been attempted. It's more hassle than it's worth. I'd rather go with the procedural textures instead, if we could find a way to optimize their performance.

Yeah I can Imagine that, since you can never know when looking via the F7 screen at Lave, and being docked in Zaonce, what texture any script might set it Lave.

Should it be done, i´d say the scripter should be responsible for changing its texture, and as usual if more than one script tries to then the one last running wins...

something like

Code: Select all

this.guiScreenChanged = function()
{
if(GUI_SCREEN = "PLANET_INFO")
{
let CurrentPlanetInfo = player.currentPlanetInfo
// do something to figure what texture to use, and if we want to use any at all
system.minituretexture = "myminiplanettexture.png")
}

Alternatively we could have

Code: Select all

if(GUI_SCREEN = "PLANET_INFO")
{
//script that checks that we are at a planet where we want procedual textures...

player.setProcedualTexture = yes...
}

Procedual textures, yes, but the latest attempt