Multiplayer sector module problem

[target_practice 162]

I have been making a mission that involves sectors that are captured in a linear order.
This is achieved by having a trigger that monitors the owning side of the sector.

When the owner changes to a certain side (in this case BLUFOR) the trigger executes enableSimulation false on the sector, and then activates a second sector module to which the trigger is synced.
In multiplayer however, the second sector fails to initialise resulting in an endless loading screen.
On single player though it works fine.

All other modules spawn without issue on multiplayer.

Although I believe I have narrowed down the issue to the sector module being activated by the trigger, not only does the fact this happens baffle me, but also the fact it doesn't occur in SP.

I would really appreciate any help with this as its driving me mad.
I can also post screenshots of the mission configuration if it helps.

[Guest]

AFAIK when you have this kind of problems it can be solved by broadcasting the exec with remoteExec.

I think the trigger is local to the server (trigger is ran serverside).

This could be easily verified with diag_log (you can then check in what log it shows) but imo you should manage the sectors with scripting and not only triggers (you can trigger a remoteExec for exemple).

I'm trying to guess how you did your system so I may have told bullshit (also It's been a long time for me not working with triggers).

Well rip englisherino. Just remember you can figure out what the heck is happening debugging with diag_log.

[target_practice 162]

How would I use diag_log to record info for the triggers/sectors specifically?

Also in case it means anything, all the triggers have server only unticked, and I have defined the areas for the sectors using the modules themselves, as opposed to using an area game logic and trigger (as described on the biki).

[Guest]

You could use something like

diag_log "TRIGGER NUMBER 1";

Then check in your logs if this code is executed (if it show the text in your logs). Then you can know if the triggers run or not on the client / server.

 

EDIT : I think you can pass code onActivation.

[target_practice 162]

You could use something like

diag_log "TRIGGER NUMBER 1";

Then check in your logs if this code is executed (if it show the text in your logs). Then you can know if the triggers run or not on the client / server.

 

EDIT : I think you can pass code onActivation.

 

I'll try doing that and post the logs when I get the chance.

If anyone has any suggestions in the meantime though I'll appreciate that too.

[target_practice 162]

Can I just check, when you say logs, do you mean the .rpt files?

[target_practice 162]

Before I say anything, I should stress that all testing was done on a listen server, not a dedicated; therefor results clearly won't be entirely representative of those on a dedicated server.

After doing quite bit more debugging, I have noted the following behavior.

 

Firstly, when I added the diag_log call to the activation trigger, it appeared in the rpt log. (But as mentioned, this was on a listen server, so it probably doesn't mean anything.)

Secondly, I loaded a test mission in the VR terrain which had a similar set up (1 sector, a second one linked to a trigger that fires on the first's capture); and ran it in MP, and it worked.

Thirdly, although I have no been able to reproduce this reliably, but it seems that after running such triggers several times successfully (in MP or SP) and then loading the mission that has the issue, it then works in MP (but only during the same session).

 

Image of configuration of the test mission: https://www.dropbox.com/s/4uv91zbsu3lwkln/20161115190319_1.jpg?raw=1

 

Condition and activation fields of the test mission's trigger:

sector_a getVariable "owner" == WEST;

sector_a enablesimulation false;

Image of the main mission's configuration: https://www.dropbox.com/s/cv1qd5jdavzsx3j/20161115191202_1.jpg?raw=1

 

Condition and activation of the first trigger in the mission (remains similar for all other triggers)

sector_a getVariable "owner" == WEST;

sector_a enableSimulation false; deleteVehicle ind_resp_sec_a; "respawn_guerrila_ai" setMarkerPos getMarkerPos "airesp_b";diag_log "s_trigger_1";

Does anyone have any suggestions based on this?

[target_practice 162]

Ok I think I've got this more or less figured out, but I'll need someone more knowledgeable in the area to evaluate my assessment.

 

After a bit more debugging and testing, a number of factors, such as the third point mentioned above and a few other things (including the fact that my mission has couple of fairly heavy scripts running on it), have lead me to hypothesize that the problem comes from delay in script execution.

 

I'm assuming a lot of things here, but from what I can tell, modules placed as part of the mission are run as part of the scheduled environment; but modules activated by triggers are technically spawned 'in mission', and are therefore run unscheduled.

When it comes to the fact that other synced modules spawn, I assume it is due to the fact that they are fairly light in code whereas the sectors module is many hundreds of lines long.

 

As for the infinite 'loading screen' (as the game still runs in the background) I'm guessing that Arma is programmed to show a loading screen overlay when the engine is busy trying to load scripts.

 

Everything I just said might just be a load of nonsense as my knowledge about all this is minimal, but if its correct does this in any way open up ways to deal with the problem? (aside just deleting the scripts)

The scripts in questions are randomweather2, and CHVD.