Matching Planets?

[Cody]

I use the System Redux OXP because it’s just so…decorative. You cruise in to a planet, admiring the view. Lovely.

Then you dock and look at the F7 screen. Oolite’s own planets are pretty good as well, and I use them if I take Trunk out for a spin.
But sometimes I wish that the F7 image would match the System Redux image.

Last night I was in the Divees system (G5) using System Redux:

First pic is approaching Divees.



Second pic is docked at Divees.



I was struck by the similarity. Anyone else seen anything as close to a match as this?

[another_commander]

If you are looking at the F7 planet in the system you are currently in, you will always see the same texture as when viewing it from your ship. You will not see the same texture if you are on planet A and you are viewing info for planet B.

[Cody]

Well I'll just go and slap myself round the face.
Got round 5 galaxies and never noticed that!

Thanks, A_C.

[Cmd. Cheyd]

Believe that is new as of the 1.73.x releases.

[Kaks]

Yep. One other thing: if you define a distant planet's texture using:

Code: Select all

system.infoForSystem(0,211).texture = 'newtexture.png'

- or its plist equivalent, you will be able to see 'newtexture.png' around that distant planet too.

It's no longer only for the local planet anymore!

[Cody]

It's no longer only for the local planet anymore!

Cool!

[Cmd. Cheyd]

Hmm... Going to have to work out how I can manage to access / leverage that inside SR2 without pre-loading 2048 (or even 256) system.infoForSystem(x,x)'s.

[Lestradae]

planetinfo-overrides.plist



Seriously, otherwise FP would have to go incompatible with Assassins, Aquatics, Ionics, OSE ...



L

[Kaks]

Yep. planetinfo.plist is where you can put the data. Unfortunately the whole pretty planets on F7 thing is disabled on the mac until we find a solution for some nasty mac only crashes that kept happening with the procedural textures on...

[Cmd. Cheyd]

Need a JS method for catching the request for the sysinfo so we can feed it back stats or a texture via JS. Or if there's a way to do this now, I'm not really sure what it'd be.

@L - Look at the API I published for SR2. You might like the concept. It's lays out a bit of a model for which OXP's can inter-operate when it comes to textures, sysInfo, etc...

[Kaks]

CC: you can check if system.info.texture is set already with 1.73.4, but it might or might not have been applied, depending on users settings / OS used. The automagical texture thing, (and the pretty F7 planet) depends on the procedural planets being turned on, which you can't currently do on a mac.

I'm thinking of a way of enabling system.info.texture regardless of user settings, but there were/are ...err... complications... with the underlying planet rendering code, so I definitely wouldn't hold my breath there.

In trunk you can test using system.mainPlanet.texture directly. if it's not null, you've got an already retextured planet.

Does this help?

[Cmd. Cheyd]

Kaks: Unfortunately, no. I can currently detect the player is on the system info screen via:

Code: Select all

this.guiScreenChanged = function(to, from) {
	if (to == "GUI_SCREEN_SYSTEM_DATA") {
					<Foo>
	}
}

The problem is I can't determine WHICH system they are viewing. System.info.texture will only return for the CURRENT system I'm in. If I could somehow find out WHAT the systemID is for the GUI_SCREEN_SYSTEM_DATA, it'd make this EASY. Also, system.info.texture = 'foo.png' doesn't seem to take immediate effect on the SYSTEM_DATA window. It does take effect immediately on the forward view though. So even once I can capture the systemID, if I try to directly test for a texture, it returns false, and I apply one - It still won't be visible.

However, thank you for helping me to realize I need to texture the main planet on startup, in addition to shipWillLaunchFromStation and shipWillExitWitchspace.