"west knowsabout unit" locality trouble

[twistking 204]

Hello,
i've got a trigger with the condition:

west knowsabout off01 > 0.1 and alive off01

and act:

["kill01",off01] call BIS_fnc_taskSetDestination; ["kill01","kill"] call BIS_fnc_taskSetType;

My problem is that it does not work in MP when i set the trigger to "server only". SP works fine. It also works fine when i don't do "server only".
I assume that the expression "west" is the problem for the dedicated server. What other argument could i use to check if any blufor unit has spotted the officer?

[pierremgi 4886]

I guess off1 is edited, so known by all clients + server as off1 variable

Kill01 must be a shared task. How are you creating it? Who are the owners?
Anyway, the BIS_fnc_taskSetDestination calls the BIS_fnc_setTask  and the whole code seems to work locally. So, make your trigger not server only.

 

There is no problem with knowsAbout or WEST... Keep in mind public trigger (not server only) are useful for triggering local codes without broadcast which can be avoided, like in this case.

 

[Larrow 2822]

8 hours ago, pierremgi said:

Anyway, the BIS_fnc_taskSetDestination calls the BIS_fnc_setTask  and the whole code seems to work locally.

BIS_fnc_setTask will update the task globally as in its call from BIS_fnc_taskSetDestination param 7 is nil which will automatically become true due to params.

 

12 hours ago, twistking said:

My problem is that it does not work in MP when i set the trigger to "server only".

Works fine for me tested SP, MP and dedicated with a server-only trigger.

TEST_MISSION

[twistking 204]

@pierremgi@Larrow thanks for the replies! 🙏

this is crazy. i've set up my mission similar to larrow's test, with the only difference that the trigger in question is linked to a "task description" module, which is linked to the original task module (i think it's a leftover from when i did the whole task tree with modules only. i like modules). the officer is placed and named in eden, same as with larrow's test.

 

(to be absolutely clear: i have the task module placed, that creates the task. i have the trigger that fires the two functions. but i have also linked a task description module to the trigger and task module. so on activation the trigger fires the two functions from the activation field and the third by activating the modul. now that i think of it, it is maybe weird to mix function and module workflow... but hey... it worked in SP)

when i have time i will test, if it helps to delete the "task description" module and fire the task derscription by function in the same trigger with "task destination" and "task type". this would kinda make it a bug in the task framework, however to be fair, i'm probably the only one mixing syncing modules and calling functions in the same mission...

[Larrow 2822]

20 hours ago, twistking said:

now that i think of it, it is maybe weird to mix function and module workflow

In this case instead of having the BIS_fnc_taskSetDestination/Type as code in the trigger use the options available in the modules. Type can be set in the Create Task module and there is a Set Task Destination module.

I noticed the same thing while testing, as I originally had the trigger tied to the create task. In fact if you make this change( sync create task to trigger ) you will see the destination and type do not update.

Your asking for trouble, what comes first? trigger creating the task or the code changing the task settings? and if its the create task how quickly does the task get initialised so its ready to receive changes from triggers code etc.

[twistking 204]

@Larrow the mystery continues: I now did some test on dedicated and found that any knowsabout would return 0 when called from server and return the actual value when called locally (debug console):
i tested with "west" and the actual unit name (p1 in my case).

p1 reveal off01 executed on server will fire the trigger and execute the task functions without error. when run on server only the knowsabout values will differ between server and client. so after "reveal" on server, the server will report "4" on p1 knowsabout off01, while called locally it will give the value that was determined by how often you click "t".

i conclude that on my setup knowsabout values are not properly synced between client and server. are you sure it worked for you when running on dedi? i'm running cba mod and the rhs modpack, but i doubt that those would have such a big effect.

 

i also tested your test missions on dedicated  and i experienced the same.

 

as a workaround until the problem is fully solved, i thought i could just run a trigger locally that checks the conditions and on activation sets a variable globally. can i use remoteExec to do "spotted01 = true", or is there another way to broadcast a variable?

[twistking 204]

if i check for knowsabout locally, how can i tell the server that the trigger has fired locally?

i was thinking of: condition:

west knowsabout off01 > 0.1 or spotted01 == 1

act:

spotted01 = 1;
publicVariable "spotted01";

then the "server-only" trigger would check for

spotted01 and alive off01

and call all the task-related functions.

 

**********

is this "ok" to do so?

[pierremgi 4886]

knowsAbout

who must be local, while target can be remote

Why using a "server only" trigger? why using a variable (spotted01) when you trigger some code? why using such condition when you could use a detectedBy trigger?

trigger owned by off001 (linked to this unit), so activation is "owner only"

activation type "detected by" (here BLUFOR)

run the activation code where you want.

 

 

[twistking 204]

1 hour ago, pierremgi said:

knowsAbout

who must be local, while target can be remote

Why using a "server only" trigger? why using a variable (spotted01) when you trigger some code? why using such condition when you could use a detectedBy trigger?

trigger owned by off001 (linked to this unit), so activation is "owner only"

activation type "detected by" (here BLUFOR)

run the activation code where you want.

 

 

 

Ah, i see. So "west" knowsabout x would only work when the actual entity doing the spotting "in the name of west" would be local to the server, which a player is not. So "west" is not truly local to the dedicated server... while "east" would be local in my case, because the whole faction consists of server owned AI.

Regarding the "server only" trigger i thought it was "cleaner" to run all the task-functions on the server only, so there is no network spam when all clients trigger the task-updates. Maybe i'm overthinking this? Also i try to run everything "server only" where it is feasible to save the calculations from the clients again maybe overoptimizing?

 

Your suggestion with the detected-by trigger is indeed more practical. I think i did not do it that way initially because the premade trigger conditions don't allow to specify detected by whom exactly. But for this missions, it's enough to specify by which side he was detected, so it's fine. I was also assuming that the detected trigger also uses "knowsabout" internally and would therefor have the same locality limitations...

[Larrow 2822]

On 11/19/2022 at 7:36 PM, twistking said:

are you sure it worked for you when running on dedi?

Yes, even the debug remoteExec hint and systemChat showed detection was working when I ran my test mission on a dedicated server.

 

[twistking 204]

53 minutes ago, Larrow said:

Yes, even the debug remoteExec hint and systemChat showed detection was working when I ran my test mission on a dedicated server.

 

thanks for checking again. i also ran your mission again and it did not work. the task did not complete and the system chat message did not change.

i then restartet the mission with "regular" difficulty preset (before i had custom, which on our server is basically just veteran with "tactical ping" activated) and it worked. so somehow the knowsabout locality issue is dependant on game difficulty?! this game is driving me mad!

[NightIntruder 710]

2 hours ago, twistking said:

this game is driving me mad!

Welcome to the arma jungle, comrade 🙂 I just realized what the reason behind my unstable blood pressure is!
But jokes aside, yeah, this is the famous Yeti. The cause of every joke about "this is arma" here and there - a player or mission/addon maker deeply unaware of the logic of this game or its limitations. And this includes myself as well, sure. We should form a support group and sue BI for turning our lives into psychotic horror, lol.

[pierremgi 4886]

12 hours ago, twistking said:

 

Ah, i see. So "west" knowsabout x would only work when the actual entity doing the spotting "in the name of west" would be local to the server, which a player is not. So "west" is not truly local to the dedicated server... while "east" would be local in my case, because the whole faction consists of server owned AI.

 

Did you test my solution?
EAST, WEST are same for everyone (all clients + server) Your off001 is probably on server (but that doesn't matter if on headless client). That doesn't mean the detectedBy trigger will run only here.

When a trigger "detectedBy" is activated, not server only, you can decide where the activated code run for example:

if (playerSide == WEST) then {..your task code..};

 

12 hours ago, twistking said:

Regarding the "server only" trigger i thought it was "cleaner" to run all the task-functions on the server only, so there is no network spam when all clients trigger the task-updates. Maybe i'm overthinking this? Also i try to run everything "server only" where it is feasible to save the calculations from the clients again maybe overoptimizing?

 

Not really, if you trigger on server only, your code must be shared (broadcast) for a public effect.  Tasks system has its own broadcast in fact, so you can decide what you want: local executions with same result or server exec with task management. (see BIKI).

12 hours ago, twistking said:

Your suggestion with the detected-by trigger is indeed more practical. I think i did not do it that way initially because the premade trigger conditions don't allow to specify detected by whom exactly. But for this missions, it's enough to specify by which side he was detected, so it's fine. I was also assuming that the detected trigger also uses "knowsabout" internally and would therefor have the same locality limitations...

 

I gave you the solution for a preset on off01 only: link this unit to the trigger, so the trigger becomes "owned by" off01. And only off01 is taken into account for the detection of West units. Easy to check in a small preview!

[Larrow 2822]

19 hours ago, twistking said:

i then restartet the mission with "regular" difficulty preset (before i had custom, which on our server is basically just veteran with "tactical ping" activated) and it worked.

From testing it seems to be related to autoReport setting.

Quote

autoReport Automatic Reporting recruit 1, regular 1 veterian 0, 0 = disabled, 1 = enabled Enables/disables automatic reporting of spotted enemies by players only. To stop AI from talking with script, use unit setSpeaker "NoVoice";

 

I don't know whether to flag this as a bug or not. Surely autoReport is just meant to stop the "Enemy 100m" when you cursor over an enemy, much like the suggested NoVoice for AI.

Actually breaking the knowsAbout command seems a little stupid.

Even using the Reveal keybind, which you would think overrides autoReporting, does not change the status of knowsAbout.

 

[twistking 204]

9 hours ago, pierremgi said:

 

Did you test my solution?
EAST, WEST are same for everyone (all clients + server) Your off001 is probably on server (but that doesn't matter if on headless client). That doesn't mean the detectedBy trigger will run only here.

When a trigger "detectedBy" is activated, not server only, you can decide where the activated code run for example:

if (playerSide == WEST) then {..your task code..};

 

 

Not really, if you trigger on server only, your code must be shared (broadcast) for a public effect.  Tasks system has its own broadcast in fact, so you can decide what you want: local executions with same result or server exec with task management. (see BIKI).

 

I gave you the solution for a preset on off01 only: link this unit to the trigger, so the trigger becomes "owned by" off01. And only off01 is taken into account for the detection of West units. Easy to check in a small preview!

 

So, i finally found time to do more testing. I tested your solution and it worked in Singleplayer, but did not work on dedicated server with veteran difficulty (can't remember if i also tested dedicated with low difficuly, but i think now it's safe to assume that the detected trigger uses "knowsabout" internally and also suffers from the locality issue with autoReporting turned off. see @Larrow's post above).

I did not know that you can put conditions in the activation field even. Thanks.
 

Ok. i see about the tasks. I guess i'll just be more relaxed about firing the task-functions from clients. I somehow feared the system may break if it gets spammed from many clients at the same time. I did never experience that though to eb fair, so it was just me being overly cautious...

 

One somehow related question arises: If i'm more relaxed about running triggers with global effects locally, would it be good practice to delete or somehow deactivate the trigger for all other clients after it fired? Let's take for example the detected trigger that will only activate locally because of the "knowsabout" issue. This will trigger some task functions with global effects. Now all other clients and server will have the tasks updated nicely, but on their machine the trigger is still checking for the conditions to be met. Would it make sense to "remotexec deletevehicle" the trigger somehow (if that is even possible)?

[twistking 204]

55 minutes ago, Larrow said:

From testing it seems to be related to autoReport setting.

 

I don't know whether to flag this as a bug or not. Surely autoReport is just meant to stop the "Enemy 100m" when you cursor over an enemy, much like the suggested NoVoice for AI.

Actually breaking the knowsAbout command seems a little stupid.

Even using the Reveal keybind, which you would think overrides autoReporting, does not change the status of knowsAbout.

 

 

I'd call it a bug honestly. It's not super severe, but neither can i imagine that it's deliberate, nor can i see how this is an unsolvable issue. My guess would be that it's just an oversight...

[pierremgi 4886]

3 minutes ago, twistking said:

Ok. i see about the tasks. I guess i'll just be more relaxed about firing the task-functions from clients. I somehow feared the system may break if it gets spammed from many clients at the same time. I did never experience that though to eb fair, so it was just me being overly cautious...

 

One somehow related question arises: If i'm more relaxed about running triggers with global effects locally, would it be good practice to delete or somehow deactivate the trigger for all other clients after it fired? Let's take for example the detected trigger that will only activate locally because of the "knowsabout" issue. This will trigger some task functions with global effects. Now all other clients and server will have the tasks updated nicely, but on their machine the trigger is still checking for the conditions to be met. Would it make sense to "remotexec deletevehicle" the trigger somehow (if that is even possible)?

 

On dedicated server, you can set the difficulty for all clients. So, all clients can have the same one, regardless of their own settings.

There is no knowsAbout issue (command or detectedBy trigger), only scripts or setting ruining this behavior. Perhaps need more tests, some modded units can have different visibility.
You don't need to remoteExec for deleting a trigger as far as deleteVehicle is an GA GE command : Global Argument (no matter where the command runs), Global Effect (concerns all clients +server)
 

[twistking 204]

8 hours ago, pierremgi said:

 

On dedicated server, you can set the difficulty for all clients. So, all clients can have the same one, regardless of their own settings.

There is no knowsAbout issue (command or detectedBy trigger), only scripts or setting ruining this behavior. Perhaps need more tests, some modded units can have different visibility.
You don't need to remoteExec for deleting a trigger as far as deleteVehicle is an GA GE command : Global Argument (no matter where the command runs), Global Effect (concerns all clients +server)
 

well, the knowsabout command and the "detected by" trigger work differently depending on the autoReporting difficulty setting. See Larrow's test mission. Not an issue in your mind?

[pierremgi 4886]

3 hours ago, twistking said:

well, the knowsabout command and the "detected by" trigger work differently depending on the autoReporting difficulty setting. See Larrow's test mission. Not an issue in your mind?

 

It's up to you using one or the other, and setting autoreport as you need, depending on your scenario. Veteran difficulty is not mandatory. You can customize it.
If you think it's an issue, take time for writing a ticket.