Page 1 of 1

Redux (sky)

Posted: Sat Jan 30, 2010 9:46 am
by Zbond-Zbond
When I add an object somewhere in Oospace, there is an opportunity to alter the appearance of the background sky, by including something like

Code: Select all

		"sky_blur_alpha" = "0.15";
		"sky_blur_cluster_chance" = "0.15";
		"sky_blur_scale" = "725";
in planetinfo.plist

That opportunity arises when I define the object to add, and where in the sky to add it; including the above 3 lines of code alters the appearance of the sky.

If I just describe the object I am adding, then the sky is quite dark - with or without System Redux.

Other OXP's alter the appearance of the background skies. If I leave the skies in my planetinfo.plist undefined (i.e. if I do not include the 3 lines of code) will that ensure that other OXP's (which do alter the sky) are unaffected?

? Is there a default setting in System Redux for sky_blur_

Posted: Sun Jan 31, 2010 10:11 am
by Commander McLane
For the answer to your last question you would best look into System Redux, don't you think?

As far as the general use of planetinfo.plist is concerned: Adding planetary objects and altering the background sky are two completely different and independent actions. You can do the first without doing the second and the other way round.

Here's an example from Ionics1.2.1.oxp:

Code: Select all

    "1 32" = {
        description = "Bebege is a terraformed world rumoured to be the home of The Link."; 
        economy = 3; 
        government = 0; 
        inhabitants = "Black Furry Humanoids"; 
        "land_hsb_color" = "0.37 0.6 0.53"; 
        name = Bebege; 
        "percent_land" = 57; 
        population = 43; 
        productivity = 245873; 
        radius = 3111; 
        "sea_hsb_color" = "0.6 0.91 0.73"; 
        "sky_blur_alpha" = "0.300000"; 
        "sky_blur_cluster_chance" = "0.800000"; 
        "sky_blur_scale" = "75.000000"; 
        "sky_rgb_colors" = "0.65 0.85 0.97 0.45 0.76 1.0"; 
        station = dodec; 
        techlevel = 11; 
    };

It produces huge and colourful nebulae, also changes some of the statistics of the system, but doesn't add any object whatsoever. All values are only in effect in galaxy 2, system no. 32 (Bebege).

The second example is from Cataclysm.oxp:

Code: Select all

    "2 86" = {"script_actions" = ("addMoon: cataclysm_enrece_moon"); }; 
    "cataclysm_enrece_moon" = {
        orientation = "1 0 1 0"; 
        "polar_color_factor" = "2.5"; 
        position = "-78435.8 -16254.8 436356"; 
        radius = 1000; 
        "rotational_velocity" = "0.01"; 
        seed = "12 7 199 244 185 54"; 
        texture = "cataclysm_enrece_moon.png"; 
    };

It only adds a new object, a moon, in galaxy 3, system no. 86 (Enrece). Nothing else at all is changed, neither the stars nor the nebulae.

As you see, adding new objects has nothing to do with changing the general appearance of the sky in a system. These are two completely unrelated operations. Of course you can do both in one and the same system. Nothing hinders you.

Note that in both examples only one specific system in one specific galaxy is affected. Different from that is System Redux.oxp, which affects all systems in all galaxies:

Code: Select all

    universal = {
        "ambient_level" = "1.25"; 
        "percent_cloud" = "0.0"; 
        "rotational_velocity" = "0.010"; 
        "sky_blur_alpha" = "0.25"; 
        "sky_blur_cluster_chance" = "0.10"; 
        "sky_blur_scale" = 25; 
    };
This is achieved by using the universal property instead of a galaxy_number planet_number pair like in the examples above. And here you also see immediatly which values are changed globally by System Redux.oxp. (By the way: in my personal copy of System Redux.oxp I have reduced the ambient_level to 0.75, because I found the planets too bright and lacking shadow.

Now to the question of possible clashes: planetinfo.plist is like all plists read and cached by the game when you start it. In that process all planetinfo.plists from different OXPs are merged into one long list. Usually this happens in alphabetical order concerning the OXP names. So, taking the three examples here, the bit from Cataclysm will be on top of the merged plist, followed by the bit from Ionics and finally the bit from System Redux. The plist is run by the engine from top to bottom. Therefore, if Cataclysm would define a sky_blur_alpha for let's say system "4 201", and afterwards Ionics would define a different sky_blur_alpha for the same system "4 201", obviously the latter will overwrite the former. So Ionics would be unaffected by Cataclysm, but Cataclysm would not be unaffected by Ionics. Generally AFAIK specific definitions for a system override the general definition in a universal property, therefore both Cataclysm and Ionics would be unaffected by System Redux, but System Redux would not be unaffected by the two other OXPs, because they would prevent it from making all systems look alike. On the other hand, System Redux can affect both Cataclysm and Ionics by adding additional planets and moons into "their" systems, without either of the OXPs anticipating or even wanting that.

All clear now?

Posted: Sun Jan 31, 2010 11:14 am
by Eric Walch
Commander McLane wrote:
All clear now?
If yes, I want to confuse further. planetInfo.plist is one way to change system data. An other is through JS script:

Code: Select all

System.infoForSystem(0, 55)["ambient_level"] = 2.25
This will also set the ambient_level of system number 55. But unlike planetInfo.plist, this data is written with the save file and stays in effect after the oxp is removed. Changes written here, overwrite changes defined in planetInfo.plist, therefor the use of planetInfo.plist to change settings is preferred. And it won't change the appearance of the system you are already in.

Posted: Sun Jan 31, 2010 5:22 pm
by Cmd. Cheyd
Commander McLane wrote:
On the other hand, System Redux can affect both Cataclysm and Ionics by adding additional planets and moons into "their" systems, without either of the OXPs anticipating or even wanting that.
Just to muddy the waters a smidge more - This is true for System Redux 1. System Redux 2 (coding 98% complete, mainly waiting on me to make more textures) has an API interface so other OXP's and scripts can alter SR2's behavior or override it completely. It tries hard to "work and play well with others". :P

Posted: Sun Jan 31, 2010 10:25 pm
by Zbond-Zbond
Thanks for those replies which were so interesting that I forgot what my original question was: I have now re-read it, and - if I understand correctly - including NO DATA regarding sky_blur_whatever (in planetinfo.plist) (when I add objects) will have NO EFFECT on any other oxp's that DO want to change the sky.
------------------------------------------------------------------------------------
By writing a planetinfo property list which defines an object, places it somewhere and does not mention the sky in any way I will not compromise sky_blur_factors mentioned (in sys.redux or any other oxp) by anyone else.
------------------------------------------------------------------------------------
..which is what I'd expected ( = hoped), but it's always a good idea to ask questions

As it happens Ionics was an oxp I had in mind: I'll go up there and experiment.

the planetinfo.plist is already completed (I will not be adding any sky_blur_data)

think ?name it something starting with "A"
------------------------------------------------------------------------------------
cheers :)

Posted: Sun Apr 04, 2010 8:31 pm
by Eric Walch
Zbond-Zbond wrote:
As it happens Ionics was an oxp I had in mind: I'll go up there and experiment.

the planetinfo.plist is already completed (I will not be adding any sky_blur_data)
I just noticed yesterday that there is a conflict between Ionics and system_redux. Both are trying to bring more nebula colours to the sky, but on different ways.

Ionics.oxp sets: sky_blur_scale = 32; to create bigger nebula for three of its systems.
system_redux.oxp sets: sky_n_blurs = 1000; to create more nebula for every system.

And you get it probably: Defining one of both looks nice but when both are defined simultaneously, you get more and bigger nebula. Than its overdone and the sky look way to colourful.

For system redux the definition is okay, but Ionics should also set the nebula count for those systems. The default value is randomised around 80 so defining that default count brings back the colouring the author originally had in mind for those systems. (Updated Ionics.oxp accordingly and also updated the wiki with some additional defaults values)

Posted: Tue Apr 06, 2010 4:46 am
by Zbond-Zbond
I don't want anything I add to interfere with anything anyone else does. So when adding (a few) objects I've kept everything to a minimum.
The property list was finished, but has required mdoification to enable the objects to be located in Nova systems which, in combination with extraneous matters not related to Oolite, has consumed some time. I don't think it will clash with anything in G4