Your My INI Settings file lists "uMaxNumShadowCastingCelestialBodies=-1", but the mod's Description mentions setting "uMaxNumShadowCastingCelestialBodies=1". Which value is correct: 1 or -1? My game appears to be working with a value of 1.
I see in earlier posts: ""u" prefix means the value is supposed to be unsigned, zero and above....." and "Unsigned integers in code are like regular integers (whole numbers including zero) only they are assumed to always be positive. If you assign a negative number as an unsigned integer it will be converted to a positive value by adding adding UINT_MAX + 1 (UINT_MAX being the 4294967295 value posted above) which for small negative numbers will result in a huge positive number.
What is dangerous is that depending on what the engine is doing with this value, it could result in MASSIVE allocation of memory and crash the game...."
Followiing up with some of the comments, I noticed a huge stutterings in Akila after using the -1 setting. So I tried other numbers, like 1, 9, 99. 1 seemed to have the same effect. But if you want to be on the same side, any number between 1 and 50 should work just fine. -1 is no longer recommended.
It makes sense; -1 means no limit, so potentially a lot of otherwise unintended things casting shadows in a highly hand-modified map like Akila which might have a bunch of tricks being used to get desired results without considering how it would effect shadows that don't normally render. Maybe someone hand placed 30,000 "close" stars in the sky or something silly like that (probably not this, but I can't think of a better example of things that could be "celestial" placed by someone tweaking the look), and then with -1 you would be rendering all those shadows.
So, I might make it 5 on mine just to be safe if there is some weird planet where two moons can eclipse two suns at the same time (it is unlikely to be 5 moons, so it is effectively infinite without being actual infinite if any "celestial" hacks were put in a scene not meant to be treated as real celestial bodies).
"u" prefix means the value is supposed to be unsigned, zero and above. Is it actually safe to set it to -1? Is it identical to 4294967295 (max UInt32) in this case? Maybe we can set it to 999 instead to keep "u for unsigned" rule?
Unsigned integers in code are like regular integers (whole numbers including zero) only they are assumed to always be positive. If you assign a negative number as an unsigned integer it will be converted to a positive value by adding adding UINT_MAX + 1 (UINT_MAX being the 4294967295 value posted above) which for small negative numbers will result in a huge positive number.
What is dangerous is that depending on what the engine is doing with this value, it could result in MASSIVE allocation of memory and crash the game.
What is really needed is to understand how the game is using these values to represent shadow distance. Since so much of the celestial objects are using AU values to represent distance it would be convenient to assume they are using unsigned integers to represent these units in distance calculations, but there is no real way to know that save to get the actual distance from the star to the planet and feed it values until the shadow appears during an eclipse, and see if there is a correlation between the unsigned integer value and distance in AU to the star.
It’s my understanding that that settings is actually preventing the game from showing those shadows that are already there in the game. The vanilla value is 0, which in this cases means it’s “on” so any negative number serves to negate that settings. Once it’s negated, you will have those shadows..
From what i know, if this engine can't handle any settings for whatever reason - it reverts it to default conditions. So this settings should not harm you game anyway
rpsbrbrasil Wrong. Here's a bit of my own research.
uMaxNumShadowCastingCelestialBodies means exactly what is expected - max number of celestial bodies (in scene) that cast shadows. - Value 0 means no shadows from celestial bodies allowed. - Value -1 turns into 4294967295 in runtime (you can test it with GetINI "uMaxNumShadowCastingCelestialBodies:Weather") and I assume this can lead to unforeseen consequences. - Value 999 is 999, this is large but it's easy to understand. Still, there is no in-game solar system with 999 celestial bodies so setting uMaxNumShadowCastingCelestialBodies to 99 is quite enough. It works nice and makes sense.
Kpblcep Yes and no. Engine can handle wrong setting value, it turns incorrect -1 into correct 4294967295 as we can see here. But it may not be able to handle further calculations with such a big value involved.
If we are talking about clean code "-1" is really bad settings cause it made a large amount of objects floating in memory even if they not used. But if we are talking about game stability - these settings will not cause any catastrophic consequances like crashes fps falling etc.
Anyway i agree that something around "30" will be the best way cause we will not find systems with many celestial bodies.
Kpblcep Explanations, sure. For every setting it depends on how the engine uses it. If you set [General]uMainMenuDelayBeforeAllowSkip to -1 you will reach main menu in 136 years. If you set [Water]uRainBaseIntensity to -1 you will never see water ripples because the game will crash on trying to process them.
Yeah i know. I mean explanations about how exactly parameter of this mod works and i tried to explain it in the most accessible language. Consider this as result of descussion from both sides.
25 comments
but the mod's Description mentions setting "uMaxNumShadowCastingCelestialBodies=1".
Which value is correct: 1 or -1?
My game appears to be working with a value of 1.
I see in earlier posts:
""u" prefix means the value is supposed to be unsigned, zero and above....."
and
"Unsigned integers in code are like regular integers (whole numbers including zero) only they are assumed to always be positive. If you assign a negative number as an unsigned integer it will be converted to a positive value by adding adding UINT_MAX + 1 (UINT_MAX being the 4294967295 value posted above) which for small negative numbers will result in a huge positive number.
What is dangerous is that depending on what the engine is doing with this value, it could result in MASSIVE allocation of memory and crash the game...."
So, I might make it 5 on mine just to be safe if there is some weird planet where two moons can eclipse two suns at the same time (it is unlikely to be 5 moons, so it is effectively infinite without being actual infinite if any "celestial" hacks were put in a scene not meant to be treated as real celestial bodies).
[Weather]
uMaxNumShadowCastingCelestialBodies=99
There were a few planets/moons I was on that got eclipsed but were still full brightness, I really love this!
What is dangerous is that depending on what the engine is doing with this value, it could result in MASSIVE allocation of memory and crash the game.
What is really needed is to understand how the game is using these values to represent shadow distance. Since so much of the celestial objects are using AU values to represent distance it would be convenient to assume they are using unsigned integers to represent these units in distance calculations, but there is no real way to know that save to get the actual distance from the star to the planet and feed it values until the shadow appears during an eclipse, and see if there is a correlation between the unsigned integer value and distance in AU to the star.
Wrong. Here's a bit of my own research.
uMaxNumShadowCastingCelestialBodies means exactly what is expected - max number of celestial bodies (in scene) that cast shadows.
- Value 0 means no shadows from celestial bodies allowed.
- Value -1 turns into 4294967295 in runtime (you can test it with GetINI "uMaxNumShadowCastingCelestialBodies:Weather") and I assume this can lead to unforeseen consequences.
- Value 999 is 999, this is large but it's easy to understand. Still, there is no in-game solar system with 999 celestial bodies so setting uMaxNumShadowCastingCelestialBodies to 99 is quite enough. It works nice and makes sense.
Kpblcep
Yes and no. Engine can handle wrong setting value, it turns incorrect -1 into correct 4294967295 as we can see here. But it may not be able to handle further calculations with such a big value involved.
If we are talking about clean code "-1" is really bad settings cause it made a large amount of objects floating in memory even if they not used.
But if we are talking about game stability - these settings will not cause any catastrophic consequances like crashes fps falling etc.
Anyway i agree that something around "30" will be the best way cause we will not find systems with many celestial bodies.
Explanations, sure. For every setting it depends on how the engine uses it. If you set [General]uMainMenuDelayBeforeAllowSkip to -1 you will reach main menu in 136 years. If you set [Water]uRainBaseIntensity to -1 you will never see water ripples because the game will crash on trying to process them.
<3