Iffy question / discussion; Permanently retextured planets

[JeffBTX]

I brought this up in another thread several months ago... at the time it was kind of off-topic. The discussion was kind of "thin" and didn't really go anywhere.

What if, using techniques from Famous Planets (or some other technique that does the same thing), ALL the planets in ALL 8 galaxies were specifically textured such that the F7 / Planet Data screen always shows the same planet texture as the actual planet texture... even when you are NOT in that system, and even if you have NOT visited it yet? Like Famous Planets does?

Even if using fairly low rez textures. But for all 8 galaxies x 256 planets (I think that's right) = 2048 planets?

I REALLY DOUBT that it should be considered at all with high or ultrahi rez textures. but (shrug)

Would even powerful computers cough, fall down, and go comatose? I am not knowledgeable or experienced enough at coding for Oolite to even guess.

PERHAPS it is do-able, PERHAPS worthy enough to at least consider for an OXP. I might even try it myself, if it isn't considered to be impossible.

The goal would be:

(a) To force the F7 / Planet Data screen to always depict the planets in their proper textures, even when out-system.

(b) So that textures match the basic descriptions of the planets (desert, icy, forested, Leesti could have impact craters, etc).

OR perhaps someone who knows more than I do can share their knowledge on this. The answer might be "What - do you want your computer to explode or something?"

[Eric Walch]

The goal would be:

(a) To force the F7 / Planet Data screen to always depict the planets in their proper textures, even when out-system.

(b) So that textures match the basic descriptions of the planets (desert, icy, forested, Leesti could have impact craters, etc).

(a) does already work as long as the texture is defined in a planetInfo plist. It just means 256 entries per planet. 2048 in total. This has no impact on performance but is just a lot of manual work.

(b) already happens in core Oolite. The current texture generator takes the descriptions into account. Or more precise: For most planets that have a description about the appearance of the planet, there is a setting in planetInfo.plist inside Oolite. When the description says that the planet is pink, the planet will be pink.

From the oxps that add textures, it is only Famous Planets that takes the description into account as far as I know.

[another_commander]

The goal would be:

(a) To force the F7 / Planet Data screen to always depict the planets in their proper textures, even when out-system.

(b) So that textures match the basic descriptions of the planets (desert, icy, forested, Leesti could have impact craters, etc).

Both of these goals are achieved if you just use the default procedurally generated planet textures. I understand that you may prefer the high detail quality of FP2.5 or System Redux or Deep Horizons, but if you try to implement what you are envisioning here, you may find that the performance price to pay is too high. The choice is yours.

[Cody]

A comment from a user of System Redux/DHI-Systems: I took vanilla trunk out recently… I’d forgotten just how good Oolite’s own planet textures look. I could happily revert to them, if the oxp textures were not available, or if my poor old machine couldn’t handle them anymore, for some reason. Even straight out of the box, this is a great-looking game.

[pagroove]

I played with the idea to do a 2056 textures set with very low Res. But That's just to much work. and it would be probably still a big download.

EDIT 2048.

[Cmd. Cheyd]

The current Deep Horizon - Systems OXP actually achieves B, but due to the limited number of textures I had completed when I released it- it wasn't apparent. It's one of the reasons folks get so many gas giants.

I'm currently overhauling the script for Deep Horizon - Systems and both A and B will be achievable. Along with a few other wish-list ideas.

[Lestradae]

I'm currently overhauling the script for Deep Horizon - Systems and both A and B will be achievable. Along with a few other wish-list ideas.

Good to hear that!

Might that include compatibility with system demux, system redux and famous planets?

[Cmd. Cheyd]

Time will tell...

[Kaks]

There's a 'permanent js' option: it will increase a player's savegame size, but doing:

System.infoForSystem(0, 55).texture='splash.png';

will permanently change Leesti's texture.

Change 'splash.png' for whatever texture you want to use, and tah-dah, you've got a js changed texture that's going to stay changed through savegames.

Do that sort of thing 256 times, and you get a permanently altered galaxy.


Do it 8*256 times, and you get a permanently altered Ooniverse, all without a single .plist setting!

[JeffBTX]

The current Deep Horizon - Systems OXP actually achieves B, but due to the limited number of textures I had completed when I released it- it wasn't apparent. It's one of the reasons folks get so many gas giants.

I'm currently overhauling the script for Deep Horizon - Systems and both A and B will be achievable. Along with a few other wish-list ideas.

Good luck on it.

Hopefully it will not impact on performance or game system requirements too much. It's just one of those things I guess; you never know till you try.

I have the latest Deep Horizon Systems (and other DH OXPs) downloaded. I will definitely keep an eye out for developments.

[JeffBTX]

There's a 'permanent js' option: it will increase a player's savegame size, but doing:

System.infoForSystem(0, 55).texture='splash.png';

will permanently change Leesti's texture.

Change 'splash.png' for whatever texture you want to use, and tah-dah, you've got a js changed texture that's going to stay changed through savegames.

Do that sort of thing 256 times, and you get a permanently altered galaxy.


Do it 8*256 times, and you get a permanently altered Ooniverse, all without a single .plist setting!

With that technique...

Will the F7 / Planet Data screen show the specified textures even when not in-system and even when you haven't visited the system yet?

(filing that info away for future reference...)

[Cmd. Cheyd]

Yes, it will, Jeff. BUT - It also writes every one of those assignments into the save-game file in a fashion similar to a mission variable. So if you do it for all 2048 system, you have added 2048 lines to the save game. Also, if you later remove the texture file, the save game is not updated. I have not tested it to know whether it would default to the procedural texture or to a blank grey/white. My solution does not rely on this method but does suffer it's own tradeoffs.

As for performance hits - That has more to do with the size of the textures you're using than it does the scripting mechanism utilized.

[JeffBTX]

Hopefully, then, by the time that 2048 planets are developed, the system / performance impact doesn't reduce you to THIS resolution:


Leesti:

*

[CaptKev]

The code below works with System Redux 1.3 and only saves the systems you've viewed with F7 key, it defaults to the standard procedural texture if the OXP is removed.

This technique should work for any of the planet re-texturing OXP's.

Code: Select all

this.guiScreenWillChange = function(toGUI) {

	if (toGUI == 'GUI_SCREEN_SYSTEM_DATA') {

		if (!system.infoForSystem(galaxyNumber, player.ship.targetSystem).texture) {

			system.infoForSystem(galaxyNumber, player.ship.targetSystem).texture = 'home_planet' + (((this.system_info[galaxyNumber * 256 + player.ship.targetSystem] & 0x3F000) >> 12) + 1) + '.png';
		}
	}
}

[JeffBTX]

Umm... I've probably brought this up before and just forgot...
... or maybe someone else has...

I am not a developer / Oolite Developer; so bear in mind what I am about to say is simplistic and possibly naive.

But this almost seems too simple...

Can't this be more easy to fix in Oolite itself? (Easier on OXP makers). And all of these solutions posted, for example, here in this thread become unnecessary.

Okay... lets say you install any given Planet OXP. For example, System Demux 2.

Lets say that you have Procedural Planet Textures set in your Options.

You start Oolite, flushing your cache as you should. With me, whenever I flush the cache, I just quit and reload the game afterwords. That way I know that after I have installed a new OXP, I can be sure I am starting with a "clean cache"; but this probably doesn't matter.

Okay then, lets say you start a new game and you are on Lave.

You call up the F7 Planet Data Screen. Lave is using the default Oolite Procedural Planet texture for Lave. You launch from the station... now the planet looks different. The game has loaded a planet texture from the System Demux OXP. You call up the F7 screen, and now THAT looks different, too.

(okay... also, there might be other planets and moons, depending on the OXP, which will PROBABLY have a bearing on my final statement/point)

Set your course for Zaonce. Look at Zaonce in the F7 screen. Default Oolite procedural texture. Witchspace to Zaonce. NEW texture, both directly/visually, and in the F7 screen.
(and probably extra planets and moons)

When were the new textures loaded? Upon "entering" the system... either from leaving the station, or witchspacing to the system.

... see where I am going with this?

Why can't the F7 key do the same thing, with some code changes to Oolite (for the main planet)? When "deciding" what planet texture to display for a (main) planet, can't the F7 key do *the same thing* that witchspacing / leaving the station does, to load the new OXP textures?

(extra planets and moons = possible problem here... am I asking for the F7 key to do a kind of "look ahead" feature, and "pre-generate" the system?)

Something to think about; unless I am TOO naive and there is some reason why this can't be done. The only thing I can think of is that it might delay the F7 key a little.