25 replies to this topic

[HeadShot]

Post all broken content and missions here to be addressed for the next event.

[BlackHawk]

I had tank + ACRE2 problems. Upon entering a tank or turning in I would receive a PRC343. Not sure if IFA3 or ACRE2 issue. Happened in 2 different missions.

[Slider]

Same here, all of my crew somehow got 343s upen entering the Tiger.

[KmO]

For future mission making reference, what are some do's and don'ts for large playercount IF missions that have been found out in this event?

[Kingslayer]

For future mission making reference, what are some do's and don'ts for large playercount IF missions that have been found out in this event?

 

ACE cookoff needs to be turned off in the attributes for vehicles, that killed my Norwegian coop mission after about 50 mins of play when a half track blew up. ACE weather also needs to be disabled.

 

I'd also recommend spreading out the spawn location for the start of the mission, ACRE seems to dislike 80 people in close proximity. I've moved he platoons about 300m away in my COOPs for V2 to try and mitigate this, they are still in visual range, but will hopefully cause less issues.

 

I think headless client is important for any large scale coop, lessens the burden on the server. High player count tvts seem to function quite well though.

Edited by Kingslayer, 2017-11-19 @ 04:56.

[Xcenocide]

This is much less of an important bug note, but just an amusing little thing. The Bren light machinegun apparently employed some kind of bizarre anti-gravity and hyperspace technology in it's reloading system. Namely, the reload animation involved the magazine at the top literally floating out of the gun and into space, folloed shortly by a full magazine coming down from the heavens and inserting itself into the magazine well.

 

Something funny out of all of this at  least.

[KmO]

Is disabling babel for TVTs and disabling ACRE terrain interference in general improve acre performance? Does anyone know of any methods to stop ACRE shitting itself in large playercount missions?

[CathFawr]

I had tank + ACRE2 problems. Upon entering a tank or turning in I would receive a PRC343. Not sure if IFA3 or ACRE2 issue. Happened in 2 different missions.

 

 

I wasn't aware of that. I knew that my missions had 343s in the tanks because they were completed and submitted for review circa racks being broken earlier in the year, but I was unaware of duplication. Cheers!

[W-Cephei]

Duplicate weapons/gear from multiple mods.

 

Before making the missions there must be a list of "approved" class names so that all missions uses the same M1 Bazooka or same k98 ammo.

[Bluef16]

• Removal Of ACE Cook Off
• Do NOT place ACE Weather Module ( As of our current version)
• Minimize or eliminate global Inventories of Vehicles, Crates etc.
• If any object is placed it must be set to a Simple Object ( No Sim.)
• Removal of any loop scripts (End Conditions , Setup Timers , etc. 

 

Above are the major things that we've learnt from the past several events.

[kail]

I agree with Cephei. I found the same weapons (from different mods) in different missions to be performing wildly different. I would also suggest that when multiple mods are being used with duplicate weapons, that these are made consistent for the event.

[VPope]

Is disabling babel for TVTs and disabling ACRE terrain interference in general improve acre performance? Does anyone know of any methods to stop ACRE shitting itself in large playercount missions?

 

Issues with broken audio is related to load on the TS server rather than a problem with ACRE, we are looking into it at the moment.

[Kingslayer]

Issues with broken audio is related to load on the TS server rather than a problem with ACRE, we are looking into it at the moment.

Are we sure? The issue only seemed to pop up on high player count coops when 80 were spawned close together. As the missions progressed and people spread out the packet loss decreased.

 

On the tvts which we played with 80 players, and the players spawns were much more spread out, there seemed to be no issue with packet loss at all.

 

Seeing as how the issue is proximity rather than number of active people in a ts chanel, that seems to suggest it is ACRE, although please correct me if I'm wrong.

[Lunchyyy]

Are we sure? The issue only seemed to pop up on high player count coops when 80 were spawned close together. As the missions progressed and people spread out the packet loss decreased.

 

On the tvts which we played with 80 players, and the players spawns were much more spread out, there seemed to be no issue with packet loss at all.

 

Seeing as how the issue is proximity rather than number of active people in a ts chanel, that seems to suggest it is ACRE, although please correct me if I'm wrong.

 

During the first Vanguard event (I think) there was the same problem and people were spread out. I dont think it has anything to do with proximity. 

[kail]

Leading question: Did lowering the ACRE codec help?

 

If it did, then increasing the codec to a high level for, say, 20 players may well simulate the load ACRE/TS encounters at higher player counts. In short, a possible load-testing option here.

[j0zh94]

Leading question: Did lowering the ACRE codec help?

 

No, in fact, Nou pointed out that it makes things worse by lowering the TS3 codec. Simply put, you're trading audio quality for bandwidth when the original problem was not necessarily bandwidth related.

Edited by j0zh94, 2017-11-20 @ 08:59.

[kail]

Wow.. OK. Then, I guess, we'll avoid doing that in the future.

[BlackHawk]

ace_cookoff_enable = false;
ace_cookoff_ammoCookoffDuration = 0;
ACE_weather_syncWind = false;
ACE_wind = [0,0,0];
setWind [0,0, true];

Above code ran globally will completely disable cookoff and ACE wind.

[SgtDeadly12]

 

• Removal Of ACE Cook Off
• Do NOT place ACE Weather Module ( As of our current version)
• Minimize or eliminate global Inventories of Vehicles, Crates etc.
• If any object is placed it must be set to a Simple Object ( No Sim.)
• Removal of any loop scripts (End Conditions , Setup Timers , etc. )

 

Above are the major things that we've learnt from the past several events.

 

 

In my experience the list of things that crash high player count missions is slightly different.

 

• Remove ACE cookoff.
• Don't place ACE weather module.
• Vehicle inventories are fine, I placed around 20 vehicles full of gear and numerous crates in mission 3 of OP Vanguard and that mission had no issues.
• Avoid placing players in tightly packed clusters. Even if it is a coop, spread them out a bit.
• Disabling simulation is essential, however there are a few necessary points that I will elaborate on below.
• Having the end conditions loop is fine, but I will discuss some things you should change.
• Minimize all automated features in the mission. Unlike most Arma sessions, events are heavily moderated and do not need a lot of the automation that Olsen's offers. Do not put in setup timers, automatic end conditions, automatic capture zones, etc.

 

Mission makers, please note that any objects you disable simulation on are considered to be part of the map and players will not be able to interact with them. Do not disable simulation on crates, ladders, buildings with doors than can be opened, mines, razorwire, etc. This was a significant issue in a lot of missions after the first Vanguard event because people started to hear that they should disable simulation on all objects in order to help mission performance and weren't aware of its other effects.

 

Also, it is fine to have end conditions in an event mission. If you really want to get a minuscule improvement on performance than you can increase the sleep time, but the default one minute is more than long enough. I do recommend that any event missions are set up so that the end conditions are not automatic, but instead are triggered by a GM entering a command into the debug console. This is simple to set up and prevents a mission ending prematurely.

 

Capture zones are also alright as long as you don't link them to an automatic end condition. Just put the amount of time the attacking side needs to control the cap zone before they win, and the GM will count down once he sees the notification that the attacking side controls the zone.

[Starfox64]

Can we stop this meme about removing end conditions and setup timers to save performance. This will literally not fix any of the issues we had.

End conditions are just very basic maths ran every 60 seconds and setup timers are ran locally and only while they are active.

 

Look at AFI, they have a bunch of scripts and their TvT ran fine (the first one wasn't keeping up because of an abundance of arty).