Triggers with a publicvariable variable in conditions

[RKurtzDmitriyev]

I read in Baddo's tutorial Triggers, Scripts & addAction in MultiPlayer that you should make sure that triggers activate for everyone by using the publicVariable command. First, one should place a trigger with such-and-such conditions, and in its "on activation" field, define a global boolean variable such as "blahthingie = true." Then, transmit this variable to all players by putting "publicvariable "blahthingie"" in the same "on activation" field. Then, place another trigger with conditions "blahthingie". Finally, in the activation field of this second trigger, put whatever you want. This protects against massive desync caused by triggers flipping on only some computers.

My question: is it possible to simplify this process by simply writing a single trigger, as follows?

Condition:

Code: [Select]

this OR blahthingie
On Activation:

Code: [Select]

blahthingie = true; publicVariable "blahthingie"; [blahparameters] exec "blahscript.sqs"
I believe that this will broadcast "blahthingie" as soon as one player's computer fulfills the trigger conditions. Then, everyone else's computer will necessarily flip the trigger, too, because "blahthingie" was also a condition. So now everyone has blahscript.sqs running (that part was just for example). This should provide the extra layer of protection without having to lag things up by making a second trigger.

But what do I know, I've only made one MP mission so far!   Is there a reason that Baddo (or rather, Kegetys) suggests that two triggers should be used, rather than one, as described above? Thanks.

[dr. seltsam]

.. should work

But make sure that you have an Init.sqs and predefine

blahthingie=false

If not, your trigger is buggy, maybe without any function. OFP doesn't like to calculate with undefined variables much.

I know many mapmakers have a problem when it comes to the testing of their multiplayer maps. Not everyone has a server ready for that. Here is a trick:

Save your mission to MP. Go into MP and select the mission, wait in lobby. Then Alt-Tab down OFP. Open a second instance of OFP, choose a different player name and join the previously selected mission in MP again. Start the mission. With Alt-Tab you can now switch between the 2 instances of OFP. Your first one will behave like a hosted game, your second instance behaves like a pure client. You can workout many publicvarible and locality issues with that, but no lag effects occur. Now you have a pseudo MP test environment on one computer.

[RKurtzDmitriyev]

Thanks for your responses to this thread and the other one I made, dr. seltsam . I'll see what I can do. Sadly, the co-op mission I made seems to be a supermassive black hole of desync, and I'm not sure what's causing it. Your suggestion about MP testing might help, though.

[dr. seltsam]

There are ways out of the mess...

Known lag reason in MP are:

1. Server problems, i have no knowledge here, but you need a strong and good configurated internet connection

2. Addons, limit them to a minimum, search for addons that increase the desync, don't use them anymore

3. Trigger and waypoints, certain types of them (trigger detected by east, west, etc. for example) are known to lag a mission, a trigger can be deleted after usage to increase the performance

4. Abusive scripting, to much, to fast creation of objects for example always produces desync

5. Islands, a few addon islands are known to be buggy and laggy

6. The unit count at all, that is a big factor, limit yourself, if you really need an enemy army in your mission, then use spawning and deleting scripts instead of placing all at mission start



 

[mikey]

I believe that this will broadcast "blahthingie" as soon as one player's computer fulfills the trigger conditions. Then, everyone else's computer will necessarily flip the trigger, too, because "blahthingie" was also a condition.

You're reasoning is wrong here. All the other clients will also execute the on act field. If you have 30 clients on the network, every client is gonna rebroadcast that variable again, thus creating a big amount of traffic in a short timespan.

Never ever put publicVariable in an On Act. field.

[RKurtzDmitriyev]

Thanks for your input. At the risk of sounding argumentative, though, I got the idea of sticking publicvariable in an On Activation field from the tutorial "Triggers, Scripts, and addAction in Multiplayer," hosted by OFPEC, originally written in Finnish by Kegetys and translated into English by Baddo. According to that resource, it is indeed possible for a trigger activation not to get sent to all computers. If the information contained in this tutorial is inaccurate, perhaps OFPEC should reconsider hosting it.

[dr. seltsam]

maybe this is the compromise:

onActivation

Code: [Select]

if (not blahthingie) then {blahthingie = true; publicVariable "blahthingie"}; [blahparameters] exec "blahscript.sqs"


[RKurtzDmitriyev]

I didn't think of that. That might capture the best of both worlds.

[mikey]

edit: nevermind..