Comrades in Arms Discussion Board

i am totally dumb on many things, but especially on things that are related to computers and theyr behaviour...........so please i ask u all to set up a plan that will help us sorting out what is causing these bad desync issues that we encounter almost every wgl coop night, wich make unplayable the game, and make many people get stressed and force them to leave the game...........

i wish i could help..............i can cook u a nice pasta dish after u suessfully fix the problem.....
for the beer...... we know who to call..................S N O I F A R U I F F L E

I hope the desynch is more mission related than the server's fault. The last 2 or 3 sunday-wgl-sessions support this theory. I won't elaborate on that now but I observed that desynch and lag was more dependant on the mission played than the number of players on the server. E.g. yesterday we played Marto's new mission (the FARP) raid twice or three times with different number of players - 14 was the maximum I think - without any lag at all. The platoon mission with 17 players I think lagged like hell. That's only 3 players more than in the lag free mission.

Many complex triggers, UA fires etc. could be an explanation for those lags. I also observed this in missions I made on the server lately. However this does not prove the thesis...

I don't quite understand the desync issues myself.

As well as I can understand it, desync is caused when there's just too much data that has to be synchronized by the server. Different computers are running their own "version" of a multiplayer game. It's up to the server to sort out any contradictions that result. That's why you sometimes see soldiers "skipping" a few meters. The server must "synchronize" the different games being played, and sometimes men or vehicles have to be moved around.

When the server is forced to synchronize too much data...well, it can't, hence de-synchronization or desync.

It seems to me that we encounter more desync problems with WGL missions. I surmise that this is due to WGL's improved AI and other features. Or maybe WGL missions tend to be more complicated than FDF/BAS missions, or both.

Mission design is clearly a factor in causing lag. Too many units placed and too many triggers will lag up the mission.

I believe Marto commented that there must have been too many triggers in his mission. That would make sense. I opened up his CiA Attack in the editor, and observed that there were 42 triggers placed. Compare with Operation Gorod, which went flawlessly: that one had only 9 triggers. I also observed that it had only half as many unit groups.

Now, it can't be that 42 triggers always causes desync, though. I happened to take a look at the Shack Tactical Nogova Virus mission. That one has 41 triggers. But Nogova Virus is only for 5 players, and there are very few units placed at start. If someone made a 20-player version, all slots were filled, and lots of units were placed in the editor, I bet it would desync.

Also, I noticed that there were no desync problems in CiA Attack till the shooting started, yet presumably there was always the same number of triggers updating. I bet the fancy WGL combat AI kicked in and pushed the server over the limit in having to synchronize too much stuff.

But mission design doesn't seem to be the only cause of desync. Sometimes the server just seems to be having a bad day. When I was testing my ornery little brat of a mission, sometimes it would get completely sucked into desync hell and crash the server within two minutes. Other times, everything would go fine. ???

EDIT: This post was written without seeing Zwobot's post above. It seems that Zwobot has noticed the same thing regarding mission design and lag.

Part of it is the time at which triggers and scripts update. I imagine most of your scripts update relatively infrequently, whereas triggers update every second or so if i recall correctly.

The WGL AI is just standard AI with some of the values tweaked, but most of Martos missions seem to use far more waypoints than an ordinary FDF/BAS mission, which won't help.

Other features such as rucksacks add additional strain.

However the best solution to these problems will be spawning in units/AI on demand when needed. CIA Attack could have a script to spawn in the counter attack at the end rather than have them placed on the map.

I imagine that a newer/better server would help.

It's not just the number of triggers/units/waypoints but must be a combination of that and the number of players.

The CiA attack mission was tested with two players connected (both with "this setcaptive true"). No desync or lag happened. So this to me means that the number of players connected must also have some effect.

Viewdistance might too.

But the thing that I notice most consistantly is that when vehicles explode, especially multiple vehicles, this is when the desync occurs.

On another note, my team (Tony, Viking and myself, after Grips death by 12.7mm I think) didn't experience as much desync as the other groups were reporting. This was probably because we were in the dead ground, with our view limited to short distances, and couldn't see the large groups of enemy and vehicles exploding all at once.

I guess the lesson to all mission makers is keep it simple and don't use too many triggers.

But we all strive to make exciting and interesting missions.

Is desynch related to ping times? Is there a way to design missions/use scripts and triggers that take into account the varied ping times of folks who might play any given mission?

Yes, it's like a catch-22. OFP AI is too stupid to think for itself, so to get that immersive feel the map-maker has to think for it using triggers, looping scripts etc. But too many of those cause massive desync and completely un-immerses the mission. :'(

Well, hopefully we missionmakers can find that perfect middle ground. That mission would have been so fun with 17 players if it weren't for 46&*()#^%907! desync.

@Marto: Why would the number of vehicles and explosions that can be viewed cause desync? Do the graphic effects have to be transmitted over the server? That seems incredibly wasteful to me. ??? Or maybe the problem is that seeing more stuff slows down people's computers, making them take more time to send critical data?

@MJ

Quote:I imagine that a newer/better server would help.

Grip was suggesting a collection for a new server. Dunno if he was joking. 8)

@Anguis

Quote:Is desynch related to ping times? Is there a way to design missions/use scripts and triggers that take into account the varied ping times of folks who might play any given mission?

I can only suppose that more higher pings will be more likely to cause desync. There's no way to change to update rate for a triggers, but scripts can be made to loop more slowly. That could help. Also, maybe make sure that looping scripts only run on server (that way, no one gets contradictory results that have to get synced).

I was not joking about collecting fore a new server. But i dont know hove the current server is financed(if all). Since i havent sene any thing about donating money i guess this one is ether free from charge or Lob have it in his basement.
The problem collecting fore a new one is
1. Any one intrest in doing so.
2. The total cost fore a new server that could deal wite the game.
3. Whould players be redy to pay if its ends up being a montly fee.
4. Will every one continue to pay after the first 3-4months.
And probebly a few more

I don't think that a new server is necessary - I think it runs the Arma2 games, too. I do know that there are ways to contribute. Just PM Lob. . .

I just can't wait for Pulv's explanation on this issue, guess he'll straighten things for us

But as many of you have mentioned, too many or complex scripts and/or triggers can cause lag along with too many units in the mission. Of course VD can play a trick or two.

It is also an issue if any player is driving a vehicle or not. As I have got it explained, the driver's box got highest priority on server for update. Ping can also be a big issue, especially if players with high ping are in charge of vehicles. The server need more time to update "high-pingers" than "low-pingers". This is why the players with high ping from time to time can play the game flawlessly when players with low ping lag as hell.

And there are some units that ain't very "MP-friendly", e.g. F-18 or FDF Shilka. I have switched that one with normal Shilka in several laggy FDF missions and they did run flawlessly afterwards. I don't know of any WGL units with the same problem but it would be easy to locate if it is. To add even more salt in the wound, even Islands can be laggy, especially with lots of AI's, remember it's the server who calculate the path for each AI, even worse with different vehicles.

I'm not sure (but I suspect) that low-end computers on server can play a role, especially if it's a "computing-demanding" (if anyone understand that one) mission. As always, nothing runs faster than the slowest wheel on the wagon, we just have to wait.

If a mission lag it would be a good way to try removing some effect scripts (if any), they can be quite demanding on slower clients.

For the server performance I think it should run WGL pretty well since we have no problems with AA2.
If a mission crash server every time, it's probably something wrong with the mission.

The only way to determine if it really is a server issue, is to try the mission on another server at equal conditions. Same mission, same players, exactly the same server setup, only significant faster hardware. A peek in the log can help pointing at problems too.

Or we can wait for Pulverizer's comments, bet they'll lighten up our journey in the darkest corners of on-line gaming 

(02-22-2010, 08:46 PM)Overlord link Wrote: [ -> ]But as many of you have mentioned, too many or complex scripts and/or triggers can cause lag along with too many units in the mission. Of course VD can play a trick or two.

Scripts may actually be less demanding than triggers. I recently have read in the ofpec.com forum that trigger conditions are checked virtually constantly (probably many hundred times per second, I can provide links to the source of information with the exact numbers later). Therefor a dozen of medium complex trigger conditions could already cause a significant drop of performance.

Edit: source for the above paragraph: http://www.ofpec.com/forum/index.php?top...#msg107989

Quote:A trigger with condition "this" polls every 0.5 seconds or so.  In other words its equivalent to a loop with a delay of 0.5s.    Otherwise a trigger polls as often as an @ condition in a script, which is like a loop with no delay

A script running a loop to check equally complex conditions with reasonable pauses between each iteration certainly would be less demanding than the trigger-only alternative.

The 'problem' is that triggers in conjunction with game logics are more comfortable for the mission designer than external scripts (well at least for me)   And with scripts you have to worry more about locality of execution etc. than with triggers.

(02-23-2010, 04:58 PM)Zwobot link Wrote: [ -> ]I recently have read in the ofpec.com forum that trigger conditions are checked virtually constantly (probably many hundred times per second, I can provide links to the source of information with the exact numbers later).

Please do, I'm always interested in issues of OFP performance. I already knew that triggers updated more quickly than most looping scripts, but I thought it was only once every 0.5 sec or so.

What I have noticed in the lobby during a desync situation it seems to be more of a client side issue than a server issue. Not everyone is hit by desync all at once, just selected players and their bandwidth is very, very low. This low bandwidth may account for why the server & client can't sync properly. I'm sure that other things have an impact as well, such as laggy addons, mission lag from heavy scripting etc. The players connection must players a role also (ie. connection speed, latency (ping), bandwidth, packet processing etc..)

The problem I have had on the CiA server is when I log on by my self I can vote my self admin, but when I call up the missions it hangs forever saying "wait for server". I don't get it other servers work fine, it's just on CiA that I experience this.

(02-23-2010, 04:58 PM)Zwobot link Wrote: [ -> ][quote author=Overlord link=topic=2094.msg11835#msg11835 date=1266864395]
But as many of you have mentioned, too many or complex scripts and/or triggers can cause lag along with too many units in the mission. Of course VD can play a trick or two.

Scripts may actually be less demanding than triggers.
[/quote]
Sorry for my inaccuracy, I know looping scripts often can be a better solution than triggers. My point was complex scripts (e.g. fire/smoke effects) or mod-related scripts (e.g. ECP) can be demanding.

(02-23-2010, 11:19 PM)Zulu1 link Wrote: [ -> ]What I have noticed in the lobby during a desync situation it seems to be more of a client side issue than a server issue. Not everyone is hit by desync all at once, just selected players and their bandwidth is very, very low. This low bandwidth may account for why the server & client can't sync properly.

That's true, that strange "bandwidth" in OFP seems to be related to clients upload bandwidth along with ping. Often affects players running P2P in background but also OS/AV updates. I strongly recommend everyone to shut down all kinds of "non-OFP" related programs when playing. AV update can be a bit risky to turn off (if you forgot to turn it on again) and not all can turn off win-update but everyone can turn off (or don't need to start) other types of programs. Ping can still be low but low outbound bandwidth will delay server I think.

Use the #monitor 15 command as admin to see if the cause is low server FPS or maxed bandwidth. Bandwidth settings can be modified in flashpoint.cfg

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. Ie, iterating loops is not done in parallel of other code, but by blocking all other execution. If you did a scripted version of this, it would not cause any noticeable stutter but still achieve the exactly same thing: