Ah, yeah, seems like those are ACE markers :)
I've gotten so used to it that I forgot it wasn't standard :) No more questions, sorry for bothering.

How do you create marker with an angle?

With standard marker tools available on the map (sorry, I didn't notice it before)

No, of course no :)
I specifically tested with the marker rotated.

P.S. Ah, ok, this is how SQF realy works :)
I need to live with it now.

Hmm... Thanks. I think this info should be added to wiki.

As I described in the ticked, it happens ONLY in CBA functions.
If it is not a CBA function bug for any reason, then it is the bug of CBA + something, so it may be important only for CBA developers, not for debugging from my side.

If you mean the -1 issue - as you can see, all variables "privated" correctly, and there are no such variable names in upper scopes.
Also I mentioned that variables changes after the function call.
Current CBA realease has some problems with variables scopes - see the link above.

As it happened the mission maker called function from EH which through some script error was also called from another EH

In my case, the EH added in CBA FrameHandler cycle. I have already encountered a couple of serious bugs in CBA functions, and more than once I regretted using them in complex scripts.
The first one: https://github.com/CBATeam/CBA_A3/issues/1570#issuecomment-1465218758
The second one happened in the same PFH loop, just a bit above:

Not unless you do something wrong. (which is why posting your scripts will help)

Depends on what do you mean under "doing wrong". If it means just creating GetIn EH according to official wiki, and getting weird results, then I don't think I'm doing it wrong :)

Cannot happen by design, you can prove the engine wrong by adding a repro to this ticket.

Unfortunately, I have no enough skills to reproduce it in editor, it can only be reproduced in my mission, and I understand that it would be very hard for devs to reproduce it without knowing such info.

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 :)

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?

In T170544#2411210, @BIS_fnc_KK wrote:

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

Usually I don't use laser-guided projectiles for AI, as bots are not good with it.
It can't attack even with fire-and-forget missiles, like Mavericks, which has a heat guidance system.

Hm... What LG armaments the AI use in this case? I tested all of the available options, with reveal command - and AI even can't open the bomb bay.

In T150733#2068492, @Wulf wrote:

Hello.

I need to know on which map you created the mission on.

Yes, SP test in editor