If you try to get the result of the command during the day in game, it periodically drops to zero (noticeable constant proportional reduction), and seems like the script behaves differently than in the console.
Description
Description
Details
Details
- Severity
- None
- Resolution
- Open
- Reproducibility
- Always
- Operating System
- Windows 7 x64
- Category
- General
Steps To Reproduce
- To catch a drop to zero the output can be monitored at daytime
- To catch strange behavior:
[] spawn {
while {true} do {
sleep 0.5;
_linear = linearConversion [3, 150, ((getLighting#1) min 150) max 3, 1, 0];
diag_log str _linear;
};
};At evenings sometimes it jumps from 0 to 0.9+ (the raw value, for example, jumps from 2.6 to 166 momentary), although I wasn't able to get such results with appropriate commands from console directly.
Event Timeline
This comment was removed by BIS_fnc_KK.
This comment was removed by BIS_fnc_KK.
Comment Actions
as wiki shows second element can go up to 28526.2, if you limit it to 166 it is expected it will seem as instant jump
Comment Actions
"second element can go up to 28526.2"
More than 120000, but it doesn't really matter., I just limit the upper and lower boundaries.
"if you limit it to 166 it is expected"
Hm... Why? :) At 150 and higher it will just always be the 0. It is the expected behavior, and it works in 90%.
I expected the raw value to decrease when it comes dark (it was really dark), and not to jump from 0 to, say, 266, without any other changes like external ambient lightsources or so. Or to drop to 0 at daytime.
Am I wrong? Such deviations logic is unclear for me.
I wanted to use this value for calculating total lighting level, to use in scripts. Or is it not supposed to work this way?
It would be great to have a real working tool to get an actual lighting level.
Comment Actions
max and min would create hard limit that would seem like a jump, this is why you have linearConversion that does interpolation smoothly. Get rid of max and min and you wont see instant jumps to 0
linearConversion [0, 120000, getLighting#1, 1, 0];
Comment Actions
max and min would create hard limit that would seem like a jump
No, it is not supposed there could be such jumps. I tested in a sequence of thousands iterations, and linearconversion works perfectly on both dedicated and local machines, the result is absolutely predictable for specified values.
But let's forget about the linearConversion. The main question - why the getLighting param jumps?
Comment Actions
Because you use hard limits. If you have something that changes from 0 to 120000 gradually and you set it to cut off at 266, everything from 267 to 120000 would return 266, which in your formula is 0 due to linearConversion.
Comment Actions
If you have something that changes from 0 to 120000 gradually and you set it to cut off at 266, everything from 267 to 120000 would return 266, which in your formula is 0 due to linearConversion.
Not at all. In my case it will return values from 1 to 0. 1 for raw values from 3 to 0, and 0 for values from 150 and higher. There will be no jumps in return values at all. Take a closer look at the example above.
But it doesn't matter at all, it is just a use case. I guess I gave that as an example for nothing :)
I'm asking about the getLighting param, not linearConversion. It jumps accidentally, and I catched that without regard to linearConversion function.
This comment was removed by BIS_fnc_KK.