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.

Cannot be fixed, too risky, fixing leap year might move dates and missions could be dependent on it and full moon dates could change, so we have to live with the fact that you cannot have December 31 on a leap Year

Should be fixed in 148841

Rev 148840, skipTime is limited to +/- 1000 hours per skip

Will be fixed in the next update. Thank you!

Will be fixed in the next update. Thank you!

Will be fixed in the next update. Thank you!

Will be fixed in the next update. Thank you!

Will be fixed in the next update. Thank you!

Will be fixed in the next update. Thank you!

2.10 adds group eventhandlers with KnowsAboutChanged /*group:group, object:targetUnit, number:newKnowsAbout, number:oldKnowsAbout*/ \
dev branch this or next week

This is for bug reporting only

This doesn't make sense. SoundPlayed EH doesn't fire "if you want to make a scripted customized system." by which I assume you mean playing sounds yourself.
It only plays the hardcoded engine sounds played by units. And the source object is always the unit itself that is passed in first parameter already, doesn't makse sense to pass the unit twice.

In T161515#2255851, @Ron4Swat wrote:

From my point of view it would be enough, especially as the followup code usually has to be executed where unit and its group is local anyway.

If you're carrying the schematics in any other vehicle and you get blown up, the schematics drop out of the vehicle. If you get blown up in a Zamak Truck, the schematics are destroyed and the game ends in either a defeat or a draw. The issue is that it ends.

2.06 profiling v9
2.08 profiling in general
2.10

So you would like the schematics to drop out of the vehicle?
I don't see how the match could end differently if the Schematics are destroyed, which would be a realistic consequence to it getting blown up in a truck.
or is it more the issue that it doesnt end consistently in either draw or defeat?

Just a note - this parameter is only relevant for helicopters and will be removed from all other vehicles - including HEMTT