In T162211#2261852, @Tenshi wrote:

Hello thanks for reporting the issue. Could you upload a Mission or Scenario for the Repro?
This would help a lot, with checking it on our internal version and possible troubleshooting.

Will be fixed. Thanks!

Will be fixed, thanks.

Will be fixed, thank you.

Sorry, seems I have missed one object with the same problem
Please accept these changes:

dev build rev148862 has just been released with the fixes from this ticket, seems ↓this↓ change hasn't been committed, please investigate this

So something to add...
...I "resumed" the mission, (Pilgrimage on Altis) and I didn't have smoke. I tossed my smoke grenade as usual, restarted/resumed and of course I had smoke. However!, I had a busted tank at a gas station getting fix by TPW and I noticed that I didn't have any TPW repair sound. The mechanic was there but no repairing sounds. The sounds did come back after I restarted/resumed, just like the smoke fix.
...Now stranger things have happened but I can't imagine TPW would have anything to do with the topic at hand. Who knows.

Hello Georg,

rev. 148862, available on upcoming dev branch.

Hello Nivek,

Hello Nivek,

due to our team not being able to reproduce this issue, we will close this ticket.
It seems to be the "typical Arma case" in which a killed AI ragdolls into an object and then knocking it over.
If you have additional information and/or in the unfortunate event that (part of) the issue persists, please open a new ticket and include a link to this one.

Thank you for your feedback! It will now be reviewed by a specialist in our internal QA system.

Thank you for your feedback! It will now be reviewed by a specialist in our internal QA system.

Thank you for your feedback! It will now be reviewed by a specialist in our internal QA system.

due to not being able to reproduce this issue, we will close this ticket.
If you have additional information and/or in the unfortunate event that (part of) the issue persists, please open a new ticket and include a link to this one.

due to not being able to reproduce this issue, we will close this ticket.
If you have additional information and/or in the unfortunate event that (part of) the issue persists, please open a new ticket and include a link to this one.

due to the fact that we can not apply a separate animation for the case that a person is sitting in a helicopter or have dynamic animations where for example the angle of the gripping would adjust, here we are limited by the fact that the normal hand animation can't be changed.
Thank you for reporting but unfortunately we can't do much about it.

Thank you for your feedback! It will now be reviewed by a specialist in our internal QA system.

And direction going precisely up/down together with normal up vector just doesn't work.

What if you simply do something like:

if (dir.x == 0 && dir.y == 0) {
   up = {1,0,0};
}

? Does changing the up manually not fix it?

still happening, mostly when switching seats in vehicle via mousewheel

Laser always has a standard up vector of.. up.
And direction going precisely up/down together with normal up vector just doesn't work.

2 months and not even a look?

would be a great help indeed. VBS has done something similar I think

Not helpful. sorry, I need vanilla repro to be able to track it if there is a problem.

Perhaps this is related and will help

Duplicate of T154293

There has to be some script side filtering anyways, as the event reports changes in knowledge about friendly and enemy units/vehicles. Its not only about enemy targets. Even civilian groups are receiving events about "targets".

So? Friendly units are targets too. I never said "enemies". Plus a simple side check is nothing compared to a config check to detect what the object actually is.

In T161515#2281752, @Leopard20 wrote:

You still have to filter them out yourself in SQF, which is relatively slow. You're only thinking of those non vehicle objects, but your filter will still be in effect for actual targets too.
If the EH trigger is pre-filtered you don't have to do anything. The EH will only trigger for actual targets.

As all the non vehicle objects are already detected fully on first sight, they will be only reported once, so even in the current state the performance problem is not as much of an issue as it first seemed.

You still have to filter them out yourself in SQF, which is relatively slow. You're only thinking of those non vehicle objects, but your filter will still be in effect for actual targets too.
If the EH trigger is pre-filtered you don't have to do anything. The EH will only trigger for actual targets.

In T161515#2281724, @dedmen wrote:

I'll add a filter that only units/vehicles get detected... though vehicles is hard 😓 as houses are also vehicles.

If so, and if you add this EH to multiple groups, and each EH fires multiple times for irrelevant objects, a lot of performance will be wasted for these objects.

In T161515#2281353, @dedmen wrote:

[_group,"knowsAboutChanged",{hint "enemy Detected"}] call BIS_fnc_addScriptedEventHandler;

Scripted? These are not scripted handlers. addEventHandler is what you want.

Yeah but my point was more from a performance POV than mere inconvenience.

I have a plan for actionKeysEx which just returns the flags as an array, for which modifiers are pressed and stuff.
That way you don't need to handle big numbers at all

:poutcat:
could filter for only units

I like the new syntax of actionKeys. It makes some things previous impossible possible. However I have a request:

seen with T163387: Lightpoint flares not visible during daytime: apparently not fixed or not merged?

In T161515#2281542, @dedmen wrote:

They don't check. 4.0 is max value, thats special, they are not checking.

<no shape> also has an "interesting" value

What about these?

They don't check. 4.0 is max value, thats special, they are not checking.

also logic groups can see or been seen

Couple more strange ones:

@dedmen
I think the real question here is:

Group B Alpha 1-2 sees 11e1a0100# 482246: fridge_01_f.p3d delta 4.000000 now at 4.000000
Group B Alpha 1-2 sees 11e140b80# 482251: bandage_f.p3d delta 4.000000 now at 4.000000
Group B Alpha 1-2 sees 11e140100# 482252: radio.p3d delta 4.000000 now at 4.000000
Group R Charlie 4-6 sees 14bf36b00# 476558: dummyitem.p3d delta 0.018084 now at 0.091254

The sees messages were debug messages that I forgot to remove
But each f these triggers the "KnowsAboutChanged" handler.

Should be fixed in 148846

As yesterdays development branch changelog says "Added: Group Event Handlers" i assume its suppossed to work already with this version.

Should be fixed in rev 148845

what a bug!

Sorry to bring up a very old thread, but if anybody has a solution/fix to this problem it would be greatly appreciated. I've also always had this issue over multiple OS's, hardware, etc.