Comrades in Arms Discussion Board

I was just reading a tutorial about triggers in MP which I found interesting. This may be useful.

Quote:TRIGGERS

Triggers work in a multiplayer environment a bit differently from how people usually think.  Triggers, like everything else in OFP, are executed locally on every client. This can lead to “desync”, which means that players experience different things because the mission is not synchronized anymore between the clients and the server.

Example scenario:

Trigger with Condition: East Present

Let player X be a west soldier and player Y be an east soldier.  When player Y walks into the zone of the trigger, his computer doesn’t send any particular information about the trigger event to player X’s computer. But in a normal situation the trigger also executes on player X’s computer because player Y’s character is also standing in the trigger zone on X’s computer.

But what if there is a lag peak, or player X’s / player Y’s connection lags slightly behind the other players’ connections just at the moment when the trigger should execute on all computers? That might cause player Y warping over the trigger on player X’s computer and thus the trigger will never fire for player X, even though it does so for player Y. These kinds of problems lead to entriely different situations in missions between players. Some players may have objectives marked done but others won’t etc…

To ensure this will not become a problem in your missions, you can implement a “safety net” for all mission critical triggers. This solution makes use of 2 triggers, set up as in the following example:

1st Trigger:
- Condition: East Present
- OnActivation: trig1Fired = True; publicVariable "trig1Fired"

2nd Trigger:
- Condition: trig1Fired
- OnActivation: hint "This is a more secure way to get things done in OFP."; [] exec "bringintheWOMD.sqs"

How this works:

1. Player Y walks into the 1st trigger’s zone and the trigger executes at least (but not necessarily only) on player Y’s computer, setting the trig1Fired variable to True and sending a publicVariable message about the trig1Fired variable to all computers in the session.  Now all computers should have variable trig1Fired variable set to True.

2. On all computers in the session the 2nd trigger notices that the trig1Fired variable has become True and executes whatever was in 2nd trigger’s OnActivation line.

This method ensures that even if the 1st trigger only fires on player Y’s computer, the information is sent to all computers in the session thus leading to a synchronized game flow with the help of the 2nd trigger.  It might be that some or even all computers in the session already saw the 1st trigger event and thus don’t need the additional publicVariable message, but this method takes into account the possibility of desync/lag etc. problems.

Is it just possible that lots of bullets flying could be a significant lag factor? I ask because I've observed that, first of all, desync almost never seems to occur when there's no shooting.

Also, my mission seems to have sporadic desync issues, and the only thing really unique about it seems to be an awful lot of chaotic shooting in the first 5 minutes or so. We've played missions with more groups, more triggers, etc, without such a hassle, but there don't seem to be too many missions with so many bullets flying everywhere.

But it's weird, just this week we've played the mission three times, and once it's gone flawlessly (in terms of performance, that is), once some people have experienced occasional desync (I didn't), and once it's desynced everyone to hell and crashed the server. Different players with different pings, maybe?

I'm curious: do ArmA1 and ArmA2 have such serious desync problems?

@Zulu

I've read that tutorial, not sure if it would help with the sort of desync we experience. :-\

There seems to be all sorts of contradictory advice regarding OFP performance. For example Zwobot was just remarking that triggers with conditions other than "this" could poll hundreds of times a second, leading to lag. But that tutorial is suggesting placing just that sort of trigger. ???

Triggers always evaluate condition every 0.5s. The test is simple:

Make trigger, condition:
call{hint format["%1", time];false}

Just realized two things from this:
A trigger that is set to activate once, unnecessarily evaluates the condition ad infinitum even after being triggered once. To save performance, you can deleteVehicle triggerName. Secondly, it doesn't trigger the deactivated event when its condition becomes false again.

And in yet another episode of the Desync Saga, today we had a lot of fun with five of us playing Pull the Plug (Killerbob's mission, apparently converted to WGL). And it had essentially zero lag from my perspective, despite the presence of 63 (!) groups and 12 triggers . Could be that we were only playing with 5 players, but I think we've played that one before with even more and it didn't lag then either.

Honestly I'm starting to think that the #1 desync factor is moving vehicles. Even in singleplayer you'll notice that performance takes a nose dive once tanks, or even worse, choppers start moving. Killerbob's mission had tons of infantry but basically only one continuously moving vehicle (a UAZ which took no part in the fighting). Besides that there was one friendly chopper at the beginning, and one enemy chopper (kudos to Osku for crashing that party with an RPG) and a BMP at the end. And by that time the tons of enemy infantry were mostly dead.

Then again my theory doesn't seem to account for why a few vehicle intensive missions, such as Marto's Operation Gorod and the Pilot Down mission seem to run okay. ??? Maybe I'll have to take a closer look at those.

EDIT: Taking a closer look at those, it could be that usually not enough vehicles move at once to lag things up. Perhaps in Marto's Gorod mission we get vaporized by the AH-64 before we can set off too many triggers. As for Pilot Down, now that I think of it, the one time I played it and we got along far enough to provoke T80s to move in, there also just happened to be massive lag problems--several people getting bumped off the server entirely, "no message received" boxes for me. Suspicious.

And I don't want to make it sound as though I'm always dragging my own mission into the conversation, but I can't help but notice that there are a total of 11 enemy vehicles and many of them could be moving at once. Again, suspicious.

Obviously there are other factors, but I really think vehicles are a biggie.

Nice idea about the moving vehicles Kurtz.
However I remember a mission of mine which hasn't got any vehicles at all, only infantry and it turned out to be one of the most laggy missions I've ever played on the server. Although it looked more like screen lag rather than network lag for most of the players it definitely was not caused by vehicles moving around. It was the PvP mission with DAC where two teams have to go to various checkpoints and then extract for anyone who remembers.
In this case the lag seemed not to be triggered by the number of players connected to the server because there was no lag at all when I tested the mission on the server alone (or with 2 Ofp instances of my user connected at most). Still not sure what caused the lag though; it could be DAC but I have another DAC featuring mission on the server which did not lag at all when we played it...

It could possibly be to do with certain people lagging, yet others not. Especially if the server is the one not lagging, I find its usually when a vehicle explodes that it starts, or if there is a lot of stuff going on. When there are only a few enemies on screen at one time for all of us, there very rarely seems to be desync. But it starts to happen when there are a couple of dozen ai running around and shooting in direct line of sight. Maybe, we could try Sanctuary's WW4 mod when he does the WGL config he mentioned (which is just going to replace the models and the anims, so nothing will be broken) as I have a massive performance boost when using his ww4 mod.

Quote:Still not sure what caused the lag though; it could be DAC but I have another DAC featuring mission on the server which did not lag at all when we played it...

Honestly sometimes this business seems to be pure voodoo.

How did Hawke's Linoleum mission perform when we played it pre-planned? It has 106 groups, including a bunch of vehicles, and 40 triggers. :o I crashed about 10 minutes in, but from what I remember it didn't perform nearly as badly as one might expect from a mission with so much stuff. Enemies in the distance were skipping around a little, but nothing like the completely unplayable mess we got in CiA Attack or Vermay Wind Farm Insurgency, or sometimes my own mission.

Quote:In this case the lag seemed not to be triggered by the number of players connected to the server because there was no lag at all when I tested the mission on the server alone

I don't understand. If there is no lag when you play by yourself, wouldn't that suggest that the number of players is a factor?  ???

(03-30-2010, 02:51 PM)Mjolnir link Wrote: [ -> ]Maybe, we could try Sanctuary's WW4 mod when he does the WGL config he mentioned (which is just going to replace the models and the anims, so nothing will be broken) as I have a massive performance boost when using his ww4 mod.

I would approve of this idea. Course someone will need to make or convert some missions, I'd be happy to volunteer whatever skills I have in that department.  8)

(03-30-2010, 03:00 PM)RKDmitriyev link Wrote: [ -> ]I would approve of this idea. Course someone will need to make or convert some missions, I'd be happy to volunteer whatever skills I have in that department.  8)

No conversion needed, it would just be a change to the models and change of the animation section of the config.

(03-30-2010, 03:00 PM)RKDmitriyev link Wrote: [ -> ]

Quote:In this case the lag seemed not to be triggered by the number of players connected to the server because there was no lag at all when I tested the mission on the server alone

I don't understand. If there is no lag when you play by yourself, wouldn't that suggest that the number of players is a factor?  ???

Right. I messed up my own sentence there. I meant: the lag apperantly was triggered by the amount of players connected to the server.

I'm undecided about the WW4 mod. I know it features optimised models but so does WGL if you do not use custom model configs.

CiA server might migrate to a different host in the foreseeable future anyway. Nothing is decided yet but maybe it's not worth putting much more effort into the desync issue now until the hosting situation is resolved.

(03-30-2010, 05:13 PM)Zwobot link Wrote: [ -> ]I'm undecided about the WW4 mod. I know it features optimised models but so does WGL if you do not use custom model configs.

The WGL aren't anywhere near as optomised as the WW4 ones, plus I personally think that the WW4 ones look better tbh.

(03-30-2010, 07:31 PM)Mjolnir link Wrote: [ -> ]The WGL aren't anywhere near as optomised as the WW4 ones, plus I personally think that the WW4 ones look better tbh.

Really? First time I saw WW4 models, I wanted to barf. But tastes differ.

(03-30-2010, 08:37 PM)RKDmitriyev link Wrote: [ -> ][quote author=Mjolnir link=topic=2094.msg11963#msg11963 date=1269970290]
The WGL aren't anywhere near as optomised as the WW4 ones, plus I personally think that the WW4 ones look better tbh.

Really? First time I saw WW4 models, I wanted to barf. But tastes differ.
[/quote]

Barf? That's a bit much, I'd say, even for a first impression! They're pretty good!

Now, if Sanc's WGL model config runs the same way the others do, the ww4 models should give a good performance boost, especially over the Ryan ones I'm running. I don't think this'll be realized on all clients, however, unless we're all running them. Thus, I don't believe they'll be a good remedy for desync (I hope I'm wrong).

Well, the WW4 models have grown a little on me since the first impression.

Desync, however, has never grown on me, and so I'd approve of using the WW4 models if it'd solve some of our problems.

(03-31-2010, 03:33 AM)RKDmitriyev link Wrote: [ -> ]Well, the WW4 models have grown a little on me since the first impression.

Desync, however, has never grown on me, and so I'd approve of using the WW4 models if it'd solve some of our problems.

One thing you have to remember is that the WW4 models look quite a lot better with backpacks on. It makes them more balanced and generally more soldier like.  ;D

Quote:Trigger condition is evaluated every 0.5 seconds in OFP, but it's still a good practice to not have super long conditions (like forEach'ing large arrays of units) because they block all other execution. For example, try this condition for a trigger:

a=[];while"count a<9999"do{a=a+[random(1000)]}; hint format["%1",{_x>500}count a]; time%1<.5

It will make the game freeze for a split second every time the condition is evaluated.

Or, if you really want to see some CPU lag, check out this failed attempt at a number-factoring .sqf function that I tried to make (I'll get it eventually!). It has to be named "factorthis."


Clearly, my thinking went wrong somewhere. ;D