Radius confusion

General discussion for players of Oolite.

Moderators: winston, another_commander

another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6682
Joined: Wed Feb 28, 2007 7:54 am

Post by another_commander »

Have you tried holding Shift while starting up the game, after applying your changes?
User avatar
dmipet
Above Average
Above Average
Posts: 19
Joined: Sat Jul 19, 2008 4:01 pm

Post by dmipet »

Oops, I had no idea that I should.
No, it did not work either.
User avatar
Commander McLane
---- E L I T E ----
---- E L I T E ----
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Post by Commander McLane »

Sorry, dmipet, I was a little too fast.

First I made an error by not c&p'ing the opening bracket of my code, so it can't work. It should be this (in ASCII):

Code: Select all

{
	universal = 
	{
		"ambient_level" = "0.5"; 
	}; 
}
or this (in XML):

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>universal</key>
	<dict>
		<key>ambient_level</key>
		<real>0.5</real>
	</dict>
</dict>
</plist>
Second, you have indeed to restart Oolite while holding down SHIFT, in order to make changes in plists to work (holding down SHIFT clears the cache; without doing it Oolite just falls back to its cache, containing the plists as they were loaded on the previous start-up; so naturally all changes are ignored).

But third, and most important, I didn't think about your other OXPs. You have System Redux installed, haven't you? This OXP contains a planetinfo.plist, in which ambient_level is set to 1.25. So whatever you do to its value in Oolite.app/Contents/Resources, or in Addons/Config, it will be reversed and overwritten by System Redux (which is read later than the built-in plist and the one put into Addons/Config).

So the right thing to do is to get rid of your newly created plist, and manipulate the value in System_Redux.oxp/Config instead.

Then don't forget to press SHIFT, and there you are.

By the way: The change is not so visible if you just launch from the station and look at the planet right in front of you. But if you jump to the next system and look to its planet from the distance, you will clearly see the difference between day- and night-side of the planet(s and moons). And if you reduce the ambient_level to 0.0, the dark sides will be really dark.
User avatar
dmipet
Above Average
Above Average
Posts: 19
Joined: Sat Jul 19, 2008 4:01 pm

Post by dmipet »

Ahh, now it is as it should be. Everything seems so clear - after your explanation :)
Yes, as the initial code did not work I tried to modify it by putting in an opening bracket - it seemed logical, so I was a bit disappointed when it did not work. However, I did not really think of OXPs that may configure ambient lighting level. Thank you for help! :D
And here I might add - if the sun is behind the planet at the moment one launches from the station, than these changes are indeed visible, especially drop in lighting from 1.25 to 0.1.
Why is it so that user configs are loaded before OXPs? It does make configuring a bit more difficult for the user who is not thoroughly familiar with all installed OXPs (as it was in my case). Maybe it would be more useful to load user configs last?
User avatar
Commander McLane
---- E L I T E ----
---- E L I T E ----
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Post by Commander McLane »

dmipet wrote:
Why is it so that user configs are loaded before OXPs?
Because there is no difference between OXPs and user configs. OXPs are basically user configs.

Therefore the problem exists not only between a user config and an OXP, but also (and more seriously) between different OXPs. In your case the relevant definition of ambient_level was in System Redux. But among your OXPs there could be four or five which set a different value to ambient_level (or to any other setting, for that matter). So, which one will be finally used for the game? Always the one which is read last, and thereby overwrites all earlier settings. And this is precisely why OXPs may (and in many cases do) conflict with each other. (And it is also the reason why some OXP-names start with ZZZ..., to make sure that this OXP is read last, and its settings cannot get changed anymore, but it will rule over all other OXPs.)

This is, of course, a limitation to the customization possibilities. But by and large we can live with it.
Post Reply