[IPAndrews]

I have a very bright skybox, and a very dark landscape. Anyone have any ideas how I can make the landscape better match the skybox?



I'm using ambient factor 65 and I'd rather not have to change that, since it works very nicely for space scenes. The landscape is using exactly the same texture as the bottom of the skybox.

[Colonol Dekker]

Is it the colours or positioning you're unhappy with?

If its the colours, try adjusting the ambient light values in the background editor maybe?

[IPAndrews]

The colours. The positioning is okay. The ambient light values in the background editor don't seem to do anything. I tried whacking them up to 255,255,255 and saved the mission. Reloaded it later and the values had reset back to 128,128,128.

[Colonol Dekker]

?????  ^


<is lost now, Help someone !!!!!

[karajorma]

He's talking about the ambient settings in FRED.

I've got no idea if the ambient light sliders were ever implemented. From what you're describing it sounds like they weren't.

[Nuclear1]

That's what I was thinking too. In that case, the ambient light sliders were never fully implemented (i.e. the sliders are there, but they don't do anything).

[IPAndrews]

So is it that the sliders don't work in FRED, or the ambient light support doesn't work? In other words... can I hack some values into the mission file in notepad to increase the light on the models (the landscape) to make it match the bright skybox.

[karajorma]

Whenever you see a dialog remembering the values when you enter and exit the dialog but resetting back to the default when saved you're likely to be dealing with an error in the way FRED saves the mission. In this case you have this code

Code: [Select]

float Ambient_light_level = 1.0f; // JAS: Should this be set to something?
required_string_fred("$Ambient light level:");
parse_comments();
fout(" %d", Ambient_light_level);
Now that's really interesting. Looking at the rest of the code, it appears as though FRED goes to great lengths to set a value for the ambient factor and then at the last hurdle fails to actually write that value to the mission file for some stupid reason.

Looking at missionparse.cpp it is quite clear that both FRED and FS2 both read that value. Freespace 2 does appear to use it as well. Fixing the problem looks like a five minute job actually but I don't particularly fancy making a build of FRED and trying to upload it tonight using an install of MS VC that I installed today and haven't yet configured so most likely any changes I make will just go straight into CVS.

If you fancy having a play with it now though it's pretty simple if you know how to convert hex to decimal (basically use Windows calculator in scientific mode).

FRED will write 0 into any mission you save with it. Wehn loading however the game doesn't accept an ambient factor of 0 and converts it into 120, 120, 120. It will however accept any number between 1 and 16777215 as a valid RGB value.

Ambient factor changes the RGB into hex and then back into a decimal. So basically you have this FFFFFF converted to a decimal.

All you have to do is replace

Code: [Select]

$Ambient light level: 0
in the mission file with a number between 1 and 16777215 and you're sorted.

[IPAndrews]

Ooh hex. Okay that's fine. Even windows calculator can do that.

[karajorma]

Yep. It's pretty simple. Shouldn't take you more than a minute to work out the number you need. You can even load the mission into FRED to double check (Just don't save it)

EDIT : Fix is in CVS. It actually took me longer to open FRED and save a mission to test it was working than to actually fix the code