Realistic stars, the return...

[Cody]

Then there's the other side of biology: who's to say that a particular species, regardless of tech level, isn't nocturnal? Or that they don't possess natural IR vision? Or that their eyes use a different part of the EM spectrum?

I was thinking exactly this just last night - felines are well known for having good night vision.

[mossfoot]

I love the ideas were hearing but to start I'd be happy with just a lightmap to see it work, then add complexity. Wouldn't specializing it to plant descriptions be difficult? For example, could you have it look for a keyword like civil war and add in the smoke? Or recognize a reference to bright lights to adjust?

[Zireael]

but to start I'd be happy with just a lightmap to see it work, then add complexity.

Seconded.

For example, could you have it look for a keyword like civil war and add in the smoke? Or recognize a reference to bright lights to adjust?

I think keywords is what they're thinking of.

[mossfoot]

but to start I'd be happy with just a lightmap to see it work, then add complexity.

Seconded.

For example, could you have it look for a keyword like civil war and add in the smoke? Or recognize a reference to bright lights to adjust?

I think keywords is what they're thinking of.

Would love to see it all happen. After all, the planets are pretty much a main character in the game. It's what you spend much of your time looking at, it's what triggers your imagination when you arrive and when you leave a main station, and if it can reflect the basic information you have about it in some way, all the better.

[Knotty]

hmmm
test script is getting errors, and only just started:

Code: Select all

this.startUp = function()
{
  log(this.name, "Initialising OXP " + this.name);
  system.info.sky_n_stars=1;
  system.info.sun_distance_modifier=100;

}

20:35:07.009 [Realistic-Stars]: Initialising OXP Realistic-Stars
20:35:07.009 [script.warning]: ----- WARNING: Change to property 'sky_n_stars' not applied, will apply only on leaving and re-entering this system.
20:35:07.009 [script.warning]: ----- WARNING: Change to property 'sun_distance_modifier' not applied, will apply only after leaving this system.

tried using systemWillPopulate, same issue:

Code: Select all

this.systemWillPopulate =  function()
{
    log(this.name, "changeing settings for " + this.name);
  system.info.sky_n_stars=1;
  system.info.sun_distance_modifier=100;

}

[Cody]

Knotty - could you put that code snippet in Code tags please?

[cim]

20:35:07.009 [script.warning]: ----- WARNING: Change to property 'sky_n_stars' not applied, will apply only on leaving and re-entering this system.
20:35:07.009 [script.warning]: ----- WARNING: Change to property 'sun_distance_modifier' not applied, will apply only after leaving this system.

Some properties can't (usefully) be changed once the system has been generated, and by the time startUp runs, a very basic system is already in place so that the player ship can exist in it. Leave and come back and the changes will have taken effect.

For example changing sun_distance_modifier should reposition the sun, but doing that when you're already in the system would have lots of side effects. Similarly the sky has already been generated, so changing the number of stars won't do anything.

[Knotty]

Hmmm,
So I'm stuck, the events all fire too late in the system generation process for me to take into account Oolite configuration and sensible sun.
Oh well, thanks anyway

[Knotty]

Update:
Sensible Sun Compatible version Posted to Expansion packs. http://wiki.alioth.net/img_auth.php/0/0 ... rs_ssc.oxz

[Zireael]

@ cim: would it be possible for the OXP to trigger leaving and returning somehow?

[cim]

No. There are two problems, both mostly solvable but not entirely.

Problem 1: There's no way to update the system the player is in when they load the game with this OXP installed, at least not at that point.

It is however possible to update any system the player is going to jump to - use System.infoForSystem(galaxyID,systemID) to get the SystemInfo object for that system, in the shipWillEnterWitchspace event, and update the system slightly before the player enters it.

It'll all work out okay - as soon as the player enters witchspace, every system they visit from then on with the OXP installed will have the correct settings.

Problem 2: JS-initiated SystemInfo changes are stored in the player's save game, and persist even after the OXP which made them is removed. So if you install an OXP that works that way, fly around for a bit, then remove the OXP, the systems you previously visited will retain the settings given to them by the OXP.

Solving that is possible in theory but it involves a fairly major change to how system information is handled by Oolite and how OXPs make changes to it. You could unset the changes made to a system back to their previous values (which you'd need to store temporarily) in the shipWillExitWitchspace event now the player has left the system, which would mean that only the system the player was in when they uninstalled the OXP would be affected.

[Wildeblood]

Problem 2: JS-initiated SystemInfo changes are stored in the player's save game, and persist even after the OXP which made them is removed. So if you install an OXP that works that way, fly around for a bit, then remove the OXP, the systems you previously visited will retain the settings given to them by the OXP.

This is the big problem. A player tries an OXP that messes around with SystemInfo from JS, decides they don't like it, removes it, but the damage is permanent. Their only option is to come to these forums and ask how to hack their save-games to repair them. Players not interested in the inner workings of Oolite shouldn't have to do that. These sort of OXPs should come in plain packaging with a health warning.

Knotty, what exactly was wrong with the old Realistic Stars that used planetinfo.plist? I still can't understand from your posts here exactly what is the problem you're trying to solve?

[Knotty]

I was trying to avoid maintaing 2 OXZ, one that clashed with sensible suns and one that was compatible. JS detection of Sensible suns on startup, and setting my value if not detected was the plan.
The secondary objective was to set the sky_n_stars dynamically based on graphic settings and attributes of the system, however this was more of a "nice to have"
From the sounds of it I'll have to avoid JS for these things, I get enough issues with things not putting things bad to how they were on uninstall in the day job