Page MenuHomeFeedback Tracker

getLighting working incorrectly
New, NormalPublic

Description

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.

Details

Severity
None
Resolution
Open
Reproducibility
Always
Operating System
Windows 7 x64
Category
General
Steps To Reproduce
  1. To catch a drop to zero the output can be monitored at daytime
  2. 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

MaxP created this task.Feb 20 2023, 2:48 AM
MaxP edited Steps To Reproduce. (Show Details)Feb 20 2023, 2:52 AM
This comment was removed by BIS_fnc_KK.
This comment was removed by BIS_fnc_KK.
BIS_fnc_KK added a comment.EditedFeb 20 2023, 1:30 PM

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

MaxP added a comment.EditedFeb 20 2023, 3:10 PM

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

"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.

BIS_fnc_KK added a comment.EditedFeb 20 2023, 3:57 PM

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];

MaxP added a comment.EditedFeb 20 2023, 4:22 PM

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?

BIS_fnc_KK added a comment.EditedFeb 20 2023, 6:15 PM

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.

MaxP added a comment.EditedFeb 20 2023, 6:29 PM
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.