Ryko

IA4 change logs for 067 and 068; 068 will be tested today at 1800 UTC.
 
068
---
NEW
1. Engineers, Pilots and Armor crew have a new action to add emergency fuel to a vehicle that has no fuel.
2. Any role which has access to the Air channel may now use the button in the IA4 menu to add or remove themselves from the channel. Intended for Squad leaders who don't want to hear air chatter.
3. Added Livonia camo uniforms to default western arsenal.
4. Added Quality of Life features for Zeus users:
- canned admin messages
- ability to delete objects while not in zeus
- admin scripts submenus available (and can be toggled)
5. New rule for picking up non-class or non-faction weapons: instead of not being able to run, you will have an increased difficulty to aim. (setCustomAimCoef=4 instead of default 1)
6. If you are incapacitated, there is a small chance every 4 seconds that you will wake up.
FIXES
1. Zeus/staff players can now donate points and purchase rewards without having any points.
2. Refined success condition for enemy mortar subobjective.
3. Attempt to catch error when player attempt to join role before fully connected to the server (prevent 'Error: No Unit' in squad list)
4. Reward point donation to team/group.
5. Only Vortex group members can fly Transport aircraft (previously: VIPER pilots could crew/fly Vortex vehicles)
6. Contact DLC woodland uniforms were accidentally added to Sniper/Spotter kit; added for all roles to select.
7. Error in Destroy Radio Tower secondary mission
8. Added all base magazines to arsenal.
9. Pre-purchased gear configuration (taking gear from arsenal no longer disappears)
10. Being nearby a destroyed subobjective will no longer delete your vehicle; you still might take damage from an explosion, however.
11. Fixed secondary missions to improve performance. Enemy unit composition has been lowered in all missions.
12. Armed/Unarmed UGV reward fixed, should now work
TWEAKS
1. Reinforcement air vehicles spawn further away, and despawn further away.
2. Changed IA4 menu: toggle map markers button moved to map/diary link.
3. Changed method for detecting player interaction with primary / secondary objectives and moved to client to improve server performance. Message to player on these engagements also changed to be less intrusive.
4. Additional information on teamkill/incapacitation situations.
5. Rending an OPFOR mortar disabled in any way will destroy the spotting UAV.
6. Attempt to get enemy subojectives off the roads.
7. Hold Actions now have percentage hints to show progress, in the event that BIS' progress icon disappears.
8. Destroy artillery secondary mission tweaked to encourage actual firing of artillery shells.
9. Enemy CAS lessened slightly. Should reduce instances of multiple enemy CAS in the air, unless there is a lot of player Air.
10. 50% chance ambient AI spawns will prefer players with high scores.
11. Tweaked custom smoke screen deployment (will only run on clients within 2km of smoke deployment).
067
---
NEW
1. Added reward point values chart to map diary. Reward points are modified by the difficulty setting, and also by the skill level of the unit killed, so this may not be consistent from game to game, but is rather a base value.
TWEAKS
1. Overhaul of opforAwarenessDaemon script to improve performance.
2. Increased readability of dynamic text on map (spotted vehicle time codes, player titles, vehicle despawn and delock timers)
3. Default grenadier loadout for basic NATO: sand tracer magazine changed to black tracer magazine. Default autorifleman for NATO: added 1 tracer 100-round magazine.
4. Removed Secure Intelligence Documents subobjective as wonky
5. Added more vests to Western Arsenal
6. Tweaks to enemy CAS support
7. Overhauled enemy reinforcements code for performance and minor errors
8. Tweaked position / distance / opacity for in-world player name tags, especially for wounded players. Wounded players will now be visible up to 200m. Your squad mates are visible up to 60m. Other non-wounded team members are visible up to 20m.
FIXES
1. Underbarrel-launched smoke grenades were bouncing contrary to intended behaviour.
2. Fix to cleanup script accidentally removing non-dead vehicles.
3. VIPER crew able to fly CAS helicopter alone, fixed, requires full crew in helicopter
4. Fixes to reward point donation.

To be fixed next version
 
 
Investigating for next version.
 
 
Not sure why this isn't working, reviewing the code, it's supposed to give you a notice that you've TK'd.
 
 
Yep, will review
 
 
I'll look into adding a button to the IA4 menu to allow you to join/leave the Air channel.

To be fixed next version
 
 
Investigating for next version.
 
 
Not sure why this isn't working, reviewing the code, it's supposed to give you a notice that you've TK'd.
 
 
Yep, will review
 
 
I'll look into adding a button to the IA4 menu to allow you to join/leave the Air channel.

To be fixed next version
 
 
Investigating for next version.
 
 
Not sure why this isn't working, reviewing the code, it's supposed to give you a notice that you've TK'd.
 
 
Yep, will review
 
 
I'll look into adding a button to the IA4 menu to allow you to join/leave the Air channel.

Hi folks,
 
I recognize that a lot of the development work on IA4 is kind of done in a black void, so I thought I'd share some data on optimization generated over last Friday's beta test.
 

 
This graph shows server performance per minute, relative to the number of players connected and the number of AI units present in the mission.  If you played on Friday you noticed that performance really began to tank at around the two hour mark.  Your first instinct might be to think, "well, the mission's been running for 2 hours, there's probably a lot of clutter, lots of units running around, it's probably making the mission slower".  But in fact, that's not the case.  The key metric that's slowing down the mission...?  The number of players connected!
 
Arma's actually quite efficient when it comes to running units, the trouble is when you have a mission that is running any kind of custom script (as both 3 and 4 do) in order to manage how the mission plays, and to give any special instructions to the AI units.  In the case of 4, there's one special script called opforAwarenessDaemon, whose sole purpose is to give instructions to patrolling AI units based on their knowledge of player units.  Put another way: if you're shooting at the AI, the script will let the AI respond to your shots rather than just sit there and take it.  It'll have them change their patrol path, call in support from other units, or even call in air support.
 
Here's another version of the chart that's a bit easier to read when it comes to player count / FPS;

What we're seeing in the graph is that when the player count is below 30 players, everything is working fairly well - average server FPS (the green line) hovers between 20-47 FPS, which is excellent.  And it's doing so whether the number of AI is low or high. But when we get over 30 players, server performance tanks quickly (see the chart between the 100 and 150 minutes mark).  This is because with more players, there are more enemy units, and they're taking longer to do their opforAwareness check.  And since Arma's internal design philosophy is that if the program can't complete a script in a certain amount of time, it gets bumped to the next cycle, which just pushes the problem further down the line... until eventually the program crashes.
 
(the spikes, if you're wondering, are generally when new AOs are spawning and a bunch of new AI units are populated.)
 
So, how does one address this?
 
1. Less AI units?  IA4 scales the number of enemy units to the number of players, so that there are plenty of targets for the players to engage and make the mission fun.  If I reduce the number of units, I'll hear more feedback of "I just got the AO and it ended".  And since on its own, Arma is pretty efficient at running units, that's not the preferred option.
2. Optimize opforAwarenessDaemon?  Definitely the preferred direction.  Data like this helps me identify methods for improving the efficiency of the code in question.  In the script there are a few factors to be decided in figuring out what targets the enemy AI units will prioritize, as I've laid out in this decision tree: to summarize, every 20 seconds, an enemy group leader will assess their known targets, and decide whether one of them is a threat worth leaving their patrol route to attack.

There are certainly things I do (ie., corners I can cut) which give similar results to what I'm looking for, that are more efficient in doing so. But the long and the short of it is the same.  If there are more players to assess, and more enemy groups to do the assessing, then that's more work being performed by the server.
 
3. Cut opforAwarenessDaemon?  It has to be a consideration; while the intent of IA4 is to create a more intelligent mission, if the performance requirements to do so exceed the playability of the mission, then it's just not worth it to pursue, and maybe it'll have to go back on the shelf and await a more capable engine (Arma 4, here we come?).
 
So that's a look at how the sausage gets made - if you have comments or suggestions, I'm always happen to discuss.
 
- R

Hi folks,
 
I recognize that a lot of the development work on IA4 is kind of done in a black void, so I thought I'd share some data on optimization generated over last Friday's beta test.
 

 
This graph shows server performance per minute, relative to the number of players connected and the number of AI units present in the mission.  If you played on Friday you noticed that performance really began to tank at around the two hour mark.  Your first instinct might be to think, "well, the mission's been running for 2 hours, there's probably a lot of clutter, lots of units running around, it's probably making the mission slower".  But in fact, that's not the case.  The key metric that's slowing down the mission...?  The number of players connected!
 
Arma's actually quite efficient when it comes to running units, the trouble is when you have a mission that is running any kind of custom script (as both 3 and 4 do) in order to manage how the mission plays, and to give any special instructions to the AI units.  In the case of 4, there's one special script called opforAwarenessDaemon, whose sole purpose is to give instructions to patrolling AI units based on their knowledge of player units.  Put another way: if you're shooting at the AI, the script will let the AI respond to your shots rather than just sit there and take it.  It'll have them change their patrol path, call in support from other units, or even call in air support.
 
Here's another version of the chart that's a bit easier to read when it comes to player count / FPS;

What we're seeing in the graph is that when the player count is below 30 players, everything is working fairly well - average server FPS (the green line) hovers between 20-47 FPS, which is excellent.  And it's doing so whether the number of AI is low or high. But when we get over 30 players, server performance tanks quickly (see the chart between the 100 and 150 minutes mark).  This is because with more players, there are more enemy units, and they're taking longer to do their opforAwareness check.  And since Arma's internal design philosophy is that if the program can't complete a script in a certain amount of time, it gets bumped to the next cycle, which just pushes the problem further down the line... until eventually the program crashes.
 
(the spikes, if you're wondering, are generally when new AOs are spawning and a bunch of new AI units are populated.)
 
So, how does one address this?
 
1. Less AI units?  IA4 scales the number of enemy units to the number of players, so that there are plenty of targets for the players to engage and make the mission fun.  If I reduce the number of units, I'll hear more feedback of "I just got the AO and it ended".  And since on its own, Arma is pretty efficient at running units, that's not the preferred option.
2. Optimize opforAwarenessDaemon?  Definitely the preferred direction.  Data like this helps me identify methods for improving the efficiency of the code in question.  In the script there are a few factors to be decided in figuring out what targets the enemy AI units will prioritize, as I've laid out in this decision tree: to summarize, every 20 seconds, an enemy group leader will assess their known targets, and decide whether one of them is a threat worth leaving their patrol route to attack.

There are certainly things I do (ie., corners I can cut) which give similar results to what I'm looking for, that are more efficient in doing so. But the long and the short of it is the same.  If there are more players to assess, and more enemy groups to do the assessing, then that's more work being performed by the server.
 
3. Cut opforAwarenessDaemon?  It has to be a consideration; while the intent of IA4 is to create a more intelligent mission, if the performance requirements to do so exceed the playability of the mission, then it's just not worth it to pursue, and maybe it'll have to go back on the shelf and await a more capable engine (Arma 4, here we come?).
 
So that's a look at how the sausage gets made - if you have comments or suggestions, I'm always happen to discuss.
 
- R

Hi folks,
 
I recognize that a lot of the development work on IA4 is kind of done in a black void, so I thought I'd share some data on optimization generated over last Friday's beta test.
 

 
This graph shows server performance per minute, relative to the number of players connected and the number of AI units present in the mission.  If you played on Friday you noticed that performance really began to tank at around the two hour mark.  Your first instinct might be to think, "well, the mission's been running for 2 hours, there's probably a lot of clutter, lots of units running around, it's probably making the mission slower".  But in fact, that's not the case.  The key metric that's slowing down the mission...?  The number of players connected!
 
Arma's actually quite efficient when it comes to running units, the trouble is when you have a mission that is running any kind of custom script (as both 3 and 4 do) in order to manage how the mission plays, and to give any special instructions to the AI units.  In the case of 4, there's one special script called opforAwarenessDaemon, whose sole purpose is to give instructions to patrolling AI units based on their knowledge of player units.  Put another way: if you're shooting at the AI, the script will let the AI respond to your shots rather than just sit there and take it.  It'll have them change their patrol path, call in support from other units, or even call in air support.
 
Here's another version of the chart that's a bit easier to read when it comes to player count / FPS;

What we're seeing in the graph is that when the player count is below 30 players, everything is working fairly well - average server FPS (the green line) hovers between 20-47 FPS, which is excellent.  And it's doing so whether the number of AI is low or high. But when we get over 30 players, server performance tanks quickly (see the chart between the 100 and 150 minutes mark).  This is because with more players, there are more enemy units, and they're taking longer to do their opforAwareness check.  And since Arma's internal design philosophy is that if the program can't complete a script in a certain amount of time, it gets bumped to the next cycle, which just pushes the problem further down the line... until eventually the program crashes.
 
(the spikes, if you're wondering, are generally when new AOs are spawning and a bunch of new AI units are populated.)
 
So, how does one address this?
 
1. Less AI units?  IA4 scales the number of enemy units to the number of players, so that there are plenty of targets for the players to engage and make the mission fun.  If I reduce the number of units, I'll hear more feedback of "I just got the AO and it ended".  And since on its own, Arma is pretty efficient at running units, that's not the preferred option.
2. Optimize opforAwarenessDaemon?  Definitely the preferred direction.  Data like this helps me identify methods for improving the efficiency of the code in question.  In the script there are a few factors to be decided in figuring out what targets the enemy AI units will prioritize, as I've laid out in this decision tree: to summarize, every 20 seconds, an enemy group leader will assess their known targets, and decide whether one of them is a threat worth leaving their patrol route to attack.

There are certainly things I do (ie., corners I can cut) which give similar results to what I'm looking for, that are more efficient in doing so. But the long and the short of it is the same.  If there are more players to assess, and more enemy groups to do the assessing, then that's more work being performed by the server.
 
3. Cut opforAwarenessDaemon?  It has to be a consideration; while the intent of IA4 is to create a more intelligent mission, if the performance requirements to do so exceed the playability of the mission, then it's just not worth it to pursue, and maybe it'll have to go back on the shelf and await a more capable engine (Arma 4, here we come?).
 
So that's a look at how the sausage gets made - if you have comments or suggestions, I'm always happen to discuss.
 
- R

Hi folks,
 
I recognize that a lot of the development work on IA4 is kind of done in a black void, so I thought I'd share some data on optimization generated over last Friday's beta test.
 

 
This graph shows server performance per minute, relative to the number of players connected and the number of AI units present in the mission.  If you played on Friday you noticed that performance really began to tank at around the two hour mark.  Your first instinct might be to think, "well, the mission's been running for 2 hours, there's probably a lot of clutter, lots of units running around, it's probably making the mission slower".  But in fact, that's not the case.  The key metric that's slowing down the mission...?  The number of players connected!
 
Arma's actually quite efficient when it comes to running units, the trouble is when you have a mission that is running any kind of custom script (as both 3 and 4 do) in order to manage how the mission plays, and to give any special instructions to the AI units.  In the case of 4, there's one special script called opforAwarenessDaemon, whose sole purpose is to give instructions to patrolling AI units based on their knowledge of player units.  Put another way: if you're shooting at the AI, the script will let the AI respond to your shots rather than just sit there and take it.  It'll have them change their patrol path, call in support from other units, or even call in air support.
 
Here's another version of the chart that's a bit easier to read when it comes to player count / FPS;

What we're seeing in the graph is that when the player count is below 30 players, everything is working fairly well - average server FPS (the green line) hovers between 20-47 FPS, which is excellent.  And it's doing so whether the number of AI is low or high. But when we get over 30 players, server performance tanks quickly (see the chart between the 100 and 150 minutes mark).  This is because with more players, there are more enemy units, and they're taking longer to do their opforAwareness check.  And since Arma's internal design philosophy is that if the program can't complete a script in a certain amount of time, it gets bumped to the next cycle, which just pushes the problem further down the line... until eventually the program crashes.
 
(the spikes, if you're wondering, are generally when new AOs are spawning and a bunch of new AI units are populated.)
 
So, how does one address this?
 
1. Less AI units?  IA4 scales the number of enemy units to the number of players, so that there are plenty of targets for the players to engage and make the mission fun.  If I reduce the number of units, I'll hear more feedback of "I just got the AO and it ended".  And since on its own, Arma is pretty efficient at running units, that's not the preferred option.
2. Optimize opforAwarenessDaemon?  Definitely the preferred direction.  Data like this helps me identify methods for improving the efficiency of the code in question.  In the script there are a few factors to be decided in figuring out what targets the enemy AI units will prioritize, as I've laid out in this decision tree: to summarize, every 20 seconds, an enemy group leader will assess their known targets, and decide whether one of them is a threat worth leaving their patrol route to attack.

There are certainly things I do (ie., corners I can cut) which give similar results to what I'm looking for, that are more efficient in doing so. But the long and the short of it is the same.  If there are more players to assess, and more enemy groups to do the assessing, then that's more work being performed by the server.
 
3. Cut opforAwarenessDaemon?  It has to be a consideration; while the intent of IA4 is to create a more intelligent mission, if the performance requirements to do so exceed the playability of the mission, then it's just not worth it to pursue, and maybe it'll have to go back on the shelf and await a more capable engine (Arma 4, here we come?).
 
So that's a look at how the sausage gets made - if you have comments or suggestions, I'm always happen to discuss.
 
- R

Short answer: you never noticed.
 
Long answer: we have had public consultation in the past regarding direction, both internally and externally.  Please don't ask me to drag it all up because it was done through a combination of forum posts, Telegram (which we no longer use), and Discord, which is a pain in the ass to navigate historically.  I'm willing to bet there are forum posts here as well if someone where to search for them.  One thing I will tell you, is that there have been (and continue to be) mutually exclusive hopes, wishes and expectations for a successor to 3.  One excellent example is the FOB system from 3.  Some people love it, other people hate it (we've had multiple people pine back to I&A2's system with just a central base, and decided to work off of that).  At some point you have to make a decision and run with it, hopefully that accommodates the majority of players, or you might as well pack up your things and go home.
 
What I've learned: if you try to develop a mission through public opinion and concensus, it'll never get done.  And it'll certainly never please everyone.  Most of the time it's because the revision cycle is a merciless process of people saying "I don't like that" but not saying how that could be done differently or better, leaving it up to the mission designer to take stabs in the dark with different approaches.  Which other people now don't like.
 
What I've also learned is that people who take the time to write responses are people I want to hear from, because they obviously care about what's being developed.  Unfortunately I can't accommodate everyone's desires, and as I'm sure you're well aware, the Arma engine isn't capable of everything we want to do.  But I will say that every feature that's in there is there for a reason - most often to address a specific deficiency from how IA3 was designed, or to address gameplay issues from how we see the mission played.
 
 
I would say that at least I'm being consistent.  I'll harken back to what I've mentioned earlier in this post: you are entitled, and encouraged, to give your opinions, your earnest criticism, the whole thing.  I have no ego to bruise.  But if it's general feedback, I can only respond with general changes. For example, when you say
 
 
... it's up to me to interpret what you say in order to make any kind of changes.  Is it the squad system?  The role-specific arsenal?  The mission structure?  Rewards?  The direction of the mission?  I can infer a lot based on how 3 works, but unless you say something like "I don't like how the squads are set up", or better yet, "I want there to be nothing but custom squads" then it's up to me to just take deep breaths and try something else.

Hi folks,
 
I recognize that a lot of the development work on IA4 is kind of done in a black void, so I thought I'd share some data on optimization generated over last Friday's beta test.
 

 
This graph shows server performance per minute, relative to the number of players connected and the number of AI units present in the mission.  If you played on Friday you noticed that performance really began to tank at around the two hour mark.  Your first instinct might be to think, "well, the mission's been running for 2 hours, there's probably a lot of clutter, lots of units running around, it's probably making the mission slower".  But in fact, that's not the case.  The key metric that's slowing down the mission...?  The number of players connected!
 
Arma's actually quite efficient when it comes to running units, the trouble is when you have a mission that is running any kind of custom script (as both 3 and 4 do) in order to manage how the mission plays, and to give any special instructions to the AI units.  In the case of 4, there's one special script called opforAwarenessDaemon, whose sole purpose is to give instructions to patrolling AI units based on their knowledge of player units.  Put another way: if you're shooting at the AI, the script will let the AI respond to your shots rather than just sit there and take it.  It'll have them change their patrol path, call in support from other units, or even call in air support.
 
Here's another version of the chart that's a bit easier to read when it comes to player count / FPS;

What we're seeing in the graph is that when the player count is below 30 players, everything is working fairly well - average server FPS (the green line) hovers between 20-47 FPS, which is excellent.  And it's doing so whether the number of AI is low or high. But when we get over 30 players, server performance tanks quickly (see the chart between the 100 and 150 minutes mark).  This is because with more players, there are more enemy units, and they're taking longer to do their opforAwareness check.  And since Arma's internal design philosophy is that if the program can't complete a script in a certain amount of time, it gets bumped to the next cycle, which just pushes the problem further down the line... until eventually the program crashes.
 
(the spikes, if you're wondering, are generally when new AOs are spawning and a bunch of new AI units are populated.)
 
So, how does one address this?
 
1. Less AI units?  IA4 scales the number of enemy units to the number of players, so that there are plenty of targets for the players to engage and make the mission fun.  If I reduce the number of units, I'll hear more feedback of "I just got the AO and it ended".  And since on its own, Arma is pretty efficient at running units, that's not the preferred option.
2. Optimize opforAwarenessDaemon?  Definitely the preferred direction.  Data like this helps me identify methods for improving the efficiency of the code in question.  In the script there are a few factors to be decided in figuring out what targets the enemy AI units will prioritize, as I've laid out in this decision tree: to summarize, every 20 seconds, an enemy group leader will assess their known targets, and decide whether one of them is a threat worth leaving their patrol route to attack.

There are certainly things I do (ie., corners I can cut) which give similar results to what I'm looking for, that are more efficient in doing so. But the long and the short of it is the same.  If there are more players to assess, and more enemy groups to do the assessing, then that's more work being performed by the server.
 
3. Cut opforAwarenessDaemon?  It has to be a consideration; while the intent of IA4 is to create a more intelligent mission, if the performance requirements to do so exceed the playability of the mission, then it's just not worth it to pursue, and maybe it'll have to go back on the shelf and await a more capable engine (Arma 4, here we come?).
 
So that's a look at how the sausage gets made - if you have comments or suggestions, I'm always happen to discuss.
 
- R

Hi folks,
 
I recognize that a lot of the development work on IA4 is kind of done in a black void, so I thought I'd share some data on optimization generated over last Friday's beta test.
 

 
This graph shows server performance per minute, relative to the number of players connected and the number of AI units present in the mission.  If you played on Friday you noticed that performance really began to tank at around the two hour mark.  Your first instinct might be to think, "well, the mission's been running for 2 hours, there's probably a lot of clutter, lots of units running around, it's probably making the mission slower".  But in fact, that's not the case.  The key metric that's slowing down the mission...?  The number of players connected!
 
Arma's actually quite efficient when it comes to running units, the trouble is when you have a mission that is running any kind of custom script (as both 3 and 4 do) in order to manage how the mission plays, and to give any special instructions to the AI units.  In the case of 4, there's one special script called opforAwarenessDaemon, whose sole purpose is to give instructions to patrolling AI units based on their knowledge of player units.  Put another way: if you're shooting at the AI, the script will let the AI respond to your shots rather than just sit there and take it.  It'll have them change their patrol path, call in support from other units, or even call in air support.
 
Here's another version of the chart that's a bit easier to read when it comes to player count / FPS;

What we're seeing in the graph is that when the player count is below 30 players, everything is working fairly well - average server FPS (the green line) hovers between 20-47 FPS, which is excellent.  And it's doing so whether the number of AI is low or high. But when we get over 30 players, server performance tanks quickly (see the chart between the 100 and 150 minutes mark).  This is because with more players, there are more enemy units, and they're taking longer to do their opforAwareness check.  And since Arma's internal design philosophy is that if the program can't complete a script in a certain amount of time, it gets bumped to the next cycle, which just pushes the problem further down the line... until eventually the program crashes.
 
(the spikes, if you're wondering, are generally when new AOs are spawning and a bunch of new AI units are populated.)
 
So, how does one address this?
 
1. Less AI units?  IA4 scales the number of enemy units to the number of players, so that there are plenty of targets for the players to engage and make the mission fun.  If I reduce the number of units, I'll hear more feedback of "I just got the AO and it ended".  And since on its own, Arma is pretty efficient at running units, that's not the preferred option.
2. Optimize opforAwarenessDaemon?  Definitely the preferred direction.  Data like this helps me identify methods for improving the efficiency of the code in question.  In the script there are a few factors to be decided in figuring out what targets the enemy AI units will prioritize, as I've laid out in this decision tree: to summarize, every 20 seconds, an enemy group leader will assess their known targets, and decide whether one of them is a threat worth leaving their patrol route to attack.

There are certainly things I do (ie., corners I can cut) which give similar results to what I'm looking for, that are more efficient in doing so. But the long and the short of it is the same.  If there are more players to assess, and more enemy groups to do the assessing, then that's more work being performed by the server.
 
3. Cut opforAwarenessDaemon?  It has to be a consideration; while the intent of IA4 is to create a more intelligent mission, if the performance requirements to do so exceed the playability of the mission, then it's just not worth it to pursue, and maybe it'll have to go back on the shelf and await a more capable engine (Arma 4, here we come?).
 
So that's a look at how the sausage gets made - if you have comments or suggestions, I'm always happen to discuss.
 
- R

Hi folks,
 
I recognize that a lot of the development work on IA4 is kind of done in a black void, so I thought I'd share some data on optimization generated over last Friday's beta test.
 

 
This graph shows server performance per minute, relative to the number of players connected and the number of AI units present in the mission.  If you played on Friday you noticed that performance really began to tank at around the two hour mark.  Your first instinct might be to think, "well, the mission's been running for 2 hours, there's probably a lot of clutter, lots of units running around, it's probably making the mission slower".  But in fact, that's not the case.  The key metric that's slowing down the mission...?  The number of players connected!
 
Arma's actually quite efficient when it comes to running units, the trouble is when you have a mission that is running any kind of custom script (as both 3 and 4 do) in order to manage how the mission plays, and to give any special instructions to the AI units.  In the case of 4, there's one special script called opforAwarenessDaemon, whose sole purpose is to give instructions to patrolling AI units based on their knowledge of player units.  Put another way: if you're shooting at the AI, the script will let the AI respond to your shots rather than just sit there and take it.  It'll have them change their patrol path, call in support from other units, or even call in air support.
 
Here's another version of the chart that's a bit easier to read when it comes to player count / FPS;

What we're seeing in the graph is that when the player count is below 30 players, everything is working fairly well - average server FPS (the green line) hovers between 20-47 FPS, which is excellent.  And it's doing so whether the number of AI is low or high. But when we get over 30 players, server performance tanks quickly (see the chart between the 100 and 150 minutes mark).  This is because with more players, there are more enemy units, and they're taking longer to do their opforAwareness check.  And since Arma's internal design philosophy is that if the program can't complete a script in a certain amount of time, it gets bumped to the next cycle, which just pushes the problem further down the line... until eventually the program crashes.
 
(the spikes, if you're wondering, are generally when new AOs are spawning and a bunch of new AI units are populated.)
 
So, how does one address this?
 
1. Less AI units?  IA4 scales the number of enemy units to the number of players, so that there are plenty of targets for the players to engage and make the mission fun.  If I reduce the number of units, I'll hear more feedback of "I just got the AO and it ended".  And since on its own, Arma is pretty efficient at running units, that's not the preferred option.
2. Optimize opforAwarenessDaemon?  Definitely the preferred direction.  Data like this helps me identify methods for improving the efficiency of the code in question.  In the script there are a few factors to be decided in figuring out what targets the enemy AI units will prioritize, as I've laid out in this decision tree: to summarize, every 20 seconds, an enemy group leader will assess their known targets, and decide whether one of them is a threat worth leaving their patrol route to attack.

There are certainly things I do (ie., corners I can cut) which give similar results to what I'm looking for, that are more efficient in doing so. But the long and the short of it is the same.  If there are more players to assess, and more enemy groups to do the assessing, then that's more work being performed by the server.
 
3. Cut opforAwarenessDaemon?  It has to be a consideration; while the intent of IA4 is to create a more intelligent mission, if the performance requirements to do so exceed the playability of the mission, then it's just not worth it to pursue, and maybe it'll have to go back on the shelf and await a more capable engine (Arma 4, here we come?).
 
So that's a look at how the sausage gets made - if you have comments or suggestions, I'm always happen to discuss.
 
- R

Hi folks,
 
I recognize that a lot of the development work on IA4 is kind of done in a black void, so I thought I'd share some data on optimization generated over last Friday's beta test.
 

 
This graph shows server performance per minute, relative to the number of players connected and the number of AI units present in the mission.  If you played on Friday you noticed that performance really began to tank at around the two hour mark.  Your first instinct might be to think, "well, the mission's been running for 2 hours, there's probably a lot of clutter, lots of units running around, it's probably making the mission slower".  But in fact, that's not the case.  The key metric that's slowing down the mission...?  The number of players connected!
 
Arma's actually quite efficient when it comes to running units, the trouble is when you have a mission that is running any kind of custom script (as both 3 and 4 do) in order to manage how the mission plays, and to give any special instructions to the AI units.  In the case of 4, there's one special script called opforAwarenessDaemon, whose sole purpose is to give instructions to patrolling AI units based on their knowledge of player units.  Put another way: if you're shooting at the AI, the script will let the AI respond to your shots rather than just sit there and take it.  It'll have them change their patrol path, call in support from other units, or even call in air support.
 
Here's another version of the chart that's a bit easier to read when it comes to player count / FPS;

What we're seeing in the graph is that when the player count is below 30 players, everything is working fairly well - average server FPS (the green line) hovers between 20-47 FPS, which is excellent.  And it's doing so whether the number of AI is low or high. But when we get over 30 players, server performance tanks quickly (see the chart between the 100 and 150 minutes mark).  This is because with more players, there are more enemy units, and they're taking longer to do their opforAwareness check.  And since Arma's internal design philosophy is that if the program can't complete a script in a certain amount of time, it gets bumped to the next cycle, which just pushes the problem further down the line... until eventually the program crashes.
 
(the spikes, if you're wondering, are generally when new AOs are spawning and a bunch of new AI units are populated.)
 
So, how does one address this?
 
1. Less AI units?  IA4 scales the number of enemy units to the number of players, so that there are plenty of targets for the players to engage and make the mission fun.  If I reduce the number of units, I'll hear more feedback of "I just got the AO and it ended".  And since on its own, Arma is pretty efficient at running units, that's not the preferred option.
2. Optimize opforAwarenessDaemon?  Definitely the preferred direction.  Data like this helps me identify methods for improving the efficiency of the code in question.  In the script there are a few factors to be decided in figuring out what targets the enemy AI units will prioritize, as I've laid out in this decision tree: to summarize, every 20 seconds, an enemy group leader will assess their known targets, and decide whether one of them is a threat worth leaving their patrol route to attack.

There are certainly things I do (ie., corners I can cut) which give similar results to what I'm looking for, that are more efficient in doing so. But the long and the short of it is the same.  If there are more players to assess, and more enemy groups to do the assessing, then that's more work being performed by the server.
 
3. Cut opforAwarenessDaemon?  It has to be a consideration; while the intent of IA4 is to create a more intelligent mission, if the performance requirements to do so exceed the playability of the mission, then it's just not worth it to pursue, and maybe it'll have to go back on the shelf and await a more capable engine (Arma 4, here we come?).
 
So that's a look at how the sausage gets made - if you have comments or suggestions, I'm always happen to discuss.
 
- R

Hi folks,
 
I recognize that a lot of the development work on IA4 is kind of done in a black void, so I thought I'd share some data on optimization generated over last Friday's beta test.
 

 
This graph shows server performance per minute, relative to the number of players connected and the number of AI units present in the mission.  If you played on Friday you noticed that performance really began to tank at around the two hour mark.  Your first instinct might be to think, "well, the mission's been running for 2 hours, there's probably a lot of clutter, lots of units running around, it's probably making the mission slower".  But in fact, that's not the case.  The key metric that's slowing down the mission...?  The number of players connected!
 
Arma's actually quite efficient when it comes to running units, the trouble is when you have a mission that is running any kind of custom script (as both 3 and 4 do) in order to manage how the mission plays, and to give any special instructions to the AI units.  In the case of 4, there's one special script called opforAwarenessDaemon, whose sole purpose is to give instructions to patrolling AI units based on their knowledge of player units.  Put another way: if you're shooting at the AI, the script will let the AI respond to your shots rather than just sit there and take it.  It'll have them change their patrol path, call in support from other units, or even call in air support.
 
Here's another version of the chart that's a bit easier to read when it comes to player count / FPS;

What we're seeing in the graph is that when the player count is below 30 players, everything is working fairly well - average server FPS (the green line) hovers between 20-47 FPS, which is excellent.  And it's doing so whether the number of AI is low or high. But when we get over 30 players, server performance tanks quickly (see the chart between the 100 and 150 minutes mark).  This is because with more players, there are more enemy units, and they're taking longer to do their opforAwareness check.  And since Arma's internal design philosophy is that if the program can't complete a script in a certain amount of time, it gets bumped to the next cycle, which just pushes the problem further down the line... until eventually the program crashes.
 
(the spikes, if you're wondering, are generally when new AOs are spawning and a bunch of new AI units are populated.)
 
So, how does one address this?
 
1. Less AI units?  IA4 scales the number of enemy units to the number of players, so that there are plenty of targets for the players to engage and make the mission fun.  If I reduce the number of units, I'll hear more feedback of "I just got the AO and it ended".  And since on its own, Arma is pretty efficient at running units, that's not the preferred option.
2. Optimize opforAwarenessDaemon?  Definitely the preferred direction.  Data like this helps me identify methods for improving the efficiency of the code in question.  In the script there are a few factors to be decided in figuring out what targets the enemy AI units will prioritize, as I've laid out in this decision tree: to summarize, every 20 seconds, an enemy group leader will assess their known targets, and decide whether one of them is a threat worth leaving their patrol route to attack.

There are certainly things I do (ie., corners I can cut) which give similar results to what I'm looking for, that are more efficient in doing so. But the long and the short of it is the same.  If there are more players to assess, and more enemy groups to do the assessing, then that's more work being performed by the server.
 
3. Cut opforAwarenessDaemon?  It has to be a consideration; while the intent of IA4 is to create a more intelligent mission, if the performance requirements to do so exceed the playability of the mission, then it's just not worth it to pursue, and maybe it'll have to go back on the shelf and await a more capable engine (Arma 4, here we come?).
 
So that's a look at how the sausage gets made - if you have comments or suggestions, I'm always happen to discuss.
 
- R

Short answer: you never noticed.
 
Long answer: we have had public consultation in the past regarding direction, both internally and externally.  Please don't ask me to drag it all up because it was done through a combination of forum posts, Telegram (which we no longer use), and Discord, which is a pain in the ass to navigate historically.  I'm willing to bet there are forum posts here as well if someone where to search for them.  One thing I will tell you, is that there have been (and continue to be) mutually exclusive hopes, wishes and expectations for a successor to 3.  One excellent example is the FOB system from 3.  Some people love it, other people hate it (we've had multiple people pine back to I&A2's system with just a central base, and decided to work off of that).  At some point you have to make a decision and run with it, hopefully that accommodates the majority of players, or you might as well pack up your things and go home.
 
What I've learned: if you try to develop a mission through public opinion and concensus, it'll never get done.  And it'll certainly never please everyone.  Most of the time it's because the revision cycle is a merciless process of people saying "I don't like that" but not saying how that could be done differently or better, leaving it up to the mission designer to take stabs in the dark with different approaches.  Which other people now don't like.
 
What I've also learned is that people who take the time to write responses are people I want to hear from, because they obviously care about what's being developed.  Unfortunately I can't accommodate everyone's desires, and as I'm sure you're well aware, the Arma engine isn't capable of everything we want to do.  But I will say that every feature that's in there is there for a reason - most often to address a specific deficiency from how IA3 was designed, or to address gameplay issues from how we see the mission played.
 
 
I would say that at least I'm being consistent.  I'll harken back to what I've mentioned earlier in this post: you are entitled, and encouraged, to give your opinions, your earnest criticism, the whole thing.  I have no ego to bruise.  But if it's general feedback, I can only respond with general changes. For example, when you say
 
 
... it's up to me to interpret what you say in order to make any kind of changes.  Is it the squad system?  The role-specific arsenal?  The mission structure?  Rewards?  The direction of the mission?  I can infer a lot based on how 3 works, but unless you say something like "I don't like how the squads are set up", or better yet, "I want there to be nothing but custom squads" then it's up to me to just take deep breaths and try something else.

The point of the Zeus squad is that it's intended for Staff players to deliberately recuse themselves from gameplay.  You don't show up on the map, enemy AI won't target you, and you get a whack of reward points that you can use to reward individual players.
 
Not being in the Zeus squad in no way impairs staff's ability to use Zeus powers.  It's tied to your UID, not your squad.  So if you are playing, and you need to pop into Zeus to fix something, you are able to do so.
 
 
If someone - anyone - can point me to anything that prevents this issue - namely, all Zeus users being kicked at random intervals - I'll gladly implement it.  We've asked Bohemia, notable coders, everyone's stumped.  Yes, there are some drawbacks with the system I've implemented to get around that - namely, that a Zeus module is dynamically generated when you ask for one - and you've hit the main one, that when you leave Zeus, your module is destroyed, along with the links to items that you've spawned.  That said, there's nothing that stops you from using Achilles to add objects in Zeus to bring them right back into your interface.
 
 
It's to clean up the interface, following a theme of simplicity.  Also, putting it in the admin menu gives me a lot more flexibility to do things like respawn specific vehicles, sent hint messages to players, etc.  Stuff I can't do within the context of the scroll menu without several layers of sub-menus.
 
 
See above
 
 
Feel free to elaborate.  We've already eased a whole lot of restrictions we started with based on feedback, and if you can point to specific things, I'm happy to discuss them.  Many of the things people do complain about (long spawn times, role-based gear restrictions) are there for long-debated and resolved reasons, but if you have new points to consider, don't hesitate.
 
 
Please elaborate... I find the paperwork comment very confusing
 
 
As of ... two versions ago?  This is no longer the case.  All role-specific purchasable weapons are now by default "purchased" which means they can be armed straight from the arsenal.  Based on a discussion we all had, no less...
 
 
It's never been my intention to force people into absolutely predetermined squads, that's why I have the custom squads functionality.  It's not something I can test on my own for obvious reasons, so every beta test I am responding to how it chooses to break (and it almost always does).  Custom naming of squads had led us into more than one ban situation thanks to people's creative choice of naming, or using the names for advertisement, and apart from the lolz, I can't see a great reason to have something which is just one more thing we have to enforce.  If people don't want to play here because they can't name their custom squad D1CK BOIZ I'm not sure we're worse of without them.
 
 
There's no great way for me to determine who's "participating" in the mission or not, apart from their proximity to the bad guys.  And generally, if they're sniping targets or destroying vehicles from over a kilometer away (the current threshold for when you are participating or not), you're outside the AI's capacity to engage you back, so I don't know if that's worth rewarding.  You'll still get points for kills, you just won't get your share of the mission objective reward points, which frankly, aren't going to be as much as vehicle kill points anyway.
 
 
The part that says Beta test is there for a reason... optimization is where we are right now, and it gets a little better every version.  This is a long discussion but suffice it to say I don't want 4 running at lower frame rates, the whole point here was for better performance by culling old/bad code, and if it's a matter of streamlining / removing features to get back to good performance, than that's what happens.
 
 
See above... by default, all role-specific gear is considered purchased at mission start.  Gear like non-faction weaponry still needs to be purchased at this point, but I suppose if there's overwhelming demand that you should be able to leave the NATO base decked out in complete CSAT gear and weaponry, well, we can go there.
 
 
I'm not an expert with UI, and Arma doesn't give you a ton of options.  If someone's got a better flair for it than me, I welcome the assistance to overhaul it.  What I'm most concerned with is creating an interface that is easy to understand and intuitive.  I clearly have not gotten there, because we get the question every session, how do I join a role? despite several layers of hints, suggestions and tooltips.  Remember that the whole point of this system is so that people don't have to go back to the lobby to take a different role, which is a major perk in my opinion, as well it is a bit more stable (in some ways) than Arma's stock system.  (and yes, much more unstable in others, I will fully concede).
 
 
Well, this is the hardest part of balancing the mission, I've got Xwatt saying we need to not punish players for being outside the AO, and you suggesting we need to reduce the reward for players being inside the AO   Neither of you is wrong, it's just a matter of balancing how to reward players.  I welcome your suggestions.
 
 
Ah yes.

The point of the Zeus squad is that it's intended for Staff players to deliberately recuse themselves from gameplay.  You don't show up on the map, enemy AI won't target you, and you get a whack of reward points that you can use to reward individual players.
 
Not being in the Zeus squad in no way impairs staff's ability to use Zeus powers.  It's tied to your UID, not your squad.  So if you are playing, and you need to pop into Zeus to fix something, you are able to do so.
 
 
If someone - anyone - can point me to anything that prevents this issue - namely, all Zeus users being kicked at random intervals - I'll gladly implement it.  We've asked Bohemia, notable coders, everyone's stumped.  Yes, there are some drawbacks with the system I've implemented to get around that - namely, that a Zeus module is dynamically generated when you ask for one - and you've hit the main one, that when you leave Zeus, your module is destroyed, along with the links to items that you've spawned.  That said, there's nothing that stops you from using Achilles to add objects in Zeus to bring them right back into your interface.
 
 
It's to clean up the interface, following a theme of simplicity.  Also, putting it in the admin menu gives me a lot more flexibility to do things like respawn specific vehicles, sent hint messages to players, etc.  Stuff I can't do within the context of the scroll menu without several layers of sub-menus.
 
 
See above
 
 
Feel free to elaborate.  We've already eased a whole lot of restrictions we started with based on feedback, and if you can point to specific things, I'm happy to discuss them.  Many of the things people do complain about (long spawn times, role-based gear restrictions) are there for long-debated and resolved reasons, but if you have new points to consider, don't hesitate.
 
 
Please elaborate... I find the paperwork comment very confusing
 
 
As of ... two versions ago?  This is no longer the case.  All role-specific purchasable weapons are now by default "purchased" which means they can be armed straight from the arsenal.  Based on a discussion we all had, no less...
 
 
It's never been my intention to force people into absolutely predetermined squads, that's why I have the custom squads functionality.  It's not something I can test on my own for obvious reasons, so every beta test I am responding to how it chooses to break (and it almost always does).  Custom naming of squads had led us into more than one ban situation thanks to people's creative choice of naming, or using the names for advertisement, and apart from the lolz, I can't see a great reason to have something which is just one more thing we have to enforce.  If people don't want to play here because they can't name their custom squad D1CK BOIZ I'm not sure we're worse of without them.
 
 
There's no great way for me to determine who's "participating" in the mission or not, apart from their proximity to the bad guys.  And generally, if they're sniping targets or destroying vehicles from over a kilometer away (the current threshold for when you are participating or not), you're outside the AI's capacity to engage you back, so I don't know if that's worth rewarding.  You'll still get points for kills, you just won't get your share of the mission objective reward points, which frankly, aren't going to be as much as vehicle kill points anyway.
 
 
The part that says Beta test is there for a reason... optimization is where we are right now, and it gets a little better every version.  This is a long discussion but suffice it to say I don't want 4 running at lower frame rates, the whole point here was for better performance by culling old/bad code, and if it's a matter of streamlining / removing features to get back to good performance, than that's what happens.
 
 
See above... by default, all role-specific gear is considered purchased at mission start.  Gear like non-faction weaponry still needs to be purchased at this point, but I suppose if there's overwhelming demand that you should be able to leave the NATO base decked out in complete CSAT gear and weaponry, well, we can go there.
 
 
I'm not an expert with UI, and Arma doesn't give you a ton of options.  If someone's got a better flair for it than me, I welcome the assistance to overhaul it.  What I'm most concerned with is creating an interface that is easy to understand and intuitive.  I clearly have not gotten there, because we get the question every session, how do I join a role? despite several layers of hints, suggestions and tooltips.  Remember that the whole point of this system is so that people don't have to go back to the lobby to take a different role, which is a major perk in my opinion, as well it is a bit more stable (in some ways) than Arma's stock system.  (and yes, much more unstable in others, I will fully concede).
 
 
Well, this is the hardest part of balancing the mission, I've got Xwatt saying we need to not punish players for being outside the AO, and you suggesting we need to reduce the reward for players being inside the AO   Neither of you is wrong, it's just a matter of balancing how to reward players.  I welcome your suggestions.
 
 
Ah yes.

The point of the Zeus squad is that it's intended for Staff players to deliberately recuse themselves from gameplay.  You don't show up on the map, enemy AI won't target you, and you get a whack of reward points that you can use to reward individual players.
 
Not being in the Zeus squad in no way impairs staff's ability to use Zeus powers.  It's tied to your UID, not your squad.  So if you are playing, and you need to pop into Zeus to fix something, you are able to do so.
 
 
If someone - anyone - can point me to anything that prevents this issue - namely, all Zeus users being kicked at random intervals - I'll gladly implement it.  We've asked Bohemia, notable coders, everyone's stumped.  Yes, there are some drawbacks with the system I've implemented to get around that - namely, that a Zeus module is dynamically generated when you ask for one - and you've hit the main one, that when you leave Zeus, your module is destroyed, along with the links to items that you've spawned.  That said, there's nothing that stops you from using Achilles to add objects in Zeus to bring them right back into your interface.
 
 
It's to clean up the interface, following a theme of simplicity.  Also, putting it in the admin menu gives me a lot more flexibility to do things like respawn specific vehicles, sent hint messages to players, etc.  Stuff I can't do within the context of the scroll menu without several layers of sub-menus.
 
 
See above
 
 
Feel free to elaborate.  We've already eased a whole lot of restrictions we started with based on feedback, and if you can point to specific things, I'm happy to discuss them.  Many of the things people do complain about (long spawn times, role-based gear restrictions) are there for long-debated and resolved reasons, but if you have new points to consider, don't hesitate.
 
 
Please elaborate... I find the paperwork comment very confusing
 
 
As of ... two versions ago?  This is no longer the case.  All role-specific purchasable weapons are now by default "purchased" which means they can be armed straight from the arsenal.  Based on a discussion we all had, no less...
 
 
It's never been my intention to force people into absolutely predetermined squads, that's why I have the custom squads functionality.  It's not something I can test on my own for obvious reasons, so every beta test I am responding to how it chooses to break (and it almost always does).  Custom naming of squads had led us into more than one ban situation thanks to people's creative choice of naming, or using the names for advertisement, and apart from the lolz, I can't see a great reason to have something which is just one more thing we have to enforce.  If people don't want to play here because they can't name their custom squad D1CK BOIZ I'm not sure we're worse of without them.
 
 
There's no great way for me to determine who's "participating" in the mission or not, apart from their proximity to the bad guys.  And generally, if they're sniping targets or destroying vehicles from over a kilometer away (the current threshold for when you are participating or not), you're outside the AI's capacity to engage you back, so I don't know if that's worth rewarding.  You'll still get points for kills, you just won't get your share of the mission objective reward points, which frankly, aren't going to be as much as vehicle kill points anyway.
 
 
The part that says Beta test is there for a reason... optimization is where we are right now, and it gets a little better every version.  This is a long discussion but suffice it to say I don't want 4 running at lower frame rates, the whole point here was for better performance by culling old/bad code, and if it's a matter of streamlining / removing features to get back to good performance, than that's what happens.
 
 
See above... by default, all role-specific gear is considered purchased at mission start.  Gear like non-faction weaponry still needs to be purchased at this point, but I suppose if there's overwhelming demand that you should be able to leave the NATO base decked out in complete CSAT gear and weaponry, well, we can go there.
 
 
I'm not an expert with UI, and Arma doesn't give you a ton of options.  If someone's got a better flair for it than me, I welcome the assistance to overhaul it.  What I'm most concerned with is creating an interface that is easy to understand and intuitive.  I clearly have not gotten there, because we get the question every session, how do I join a role? despite several layers of hints, suggestions and tooltips.  Remember that the whole point of this system is so that people don't have to go back to the lobby to take a different role, which is a major perk in my opinion, as well it is a bit more stable (in some ways) than Arma's stock system.  (and yes, much more unstable in others, I will fully concede).
 
 
Well, this is the hardest part of balancing the mission, I've got Xwatt saying we need to not punish players for being outside the AO, and you suggesting we need to reduce the reward for players being inside the AO   Neither of you is wrong, it's just a matter of balancing how to reward players.  I welcome your suggestions.
 
 
Ah yes.

The point of the Zeus squad is that it's intended for Staff players to deliberately recuse themselves from gameplay.  You don't show up on the map, enemy AI won't target you, and you get a whack of reward points that you can use to reward individual players.
 
Not being in the Zeus squad in no way impairs staff's ability to use Zeus powers.  It's tied to your UID, not your squad.  So if you are playing, and you need to pop into Zeus to fix something, you are able to do so.
 
 
If someone - anyone - can point me to anything that prevents this issue - namely, all Zeus users being kicked at random intervals - I'll gladly implement it.  We've asked Bohemia, notable coders, everyone's stumped.  Yes, there are some drawbacks with the system I've implemented to get around that - namely, that a Zeus module is dynamically generated when you ask for one - and you've hit the main one, that when you leave Zeus, your module is destroyed, along with the links to items that you've spawned.  That said, there's nothing that stops you from using Achilles to add objects in Zeus to bring them right back into your interface.
 
 
It's to clean up the interface, following a theme of simplicity.  Also, putting it in the admin menu gives me a lot more flexibility to do things like respawn specific vehicles, sent hint messages to players, etc.  Stuff I can't do within the context of the scroll menu without several layers of sub-menus.
 
 
See above
 
 
Feel free to elaborate.  We've already eased a whole lot of restrictions we started with based on feedback, and if you can point to specific things, I'm happy to discuss them.  Many of the things people do complain about (long spawn times, role-based gear restrictions) are there for long-debated and resolved reasons, but if you have new points to consider, don't hesitate.
 
 
Please elaborate... I find the paperwork comment very confusing
 
 
As of ... two versions ago?  This is no longer the case.  All role-specific purchasable weapons are now by default "purchased" which means they can be armed straight from the arsenal.  Based on a discussion we all had, no less...
 
 
It's never been my intention to force people into absolutely predetermined squads, that's why I have the custom squads functionality.  It's not something I can test on my own for obvious reasons, so every beta test I am responding to how it chooses to break (and it almost always does).  Custom naming of squads had led us into more than one ban situation thanks to people's creative choice of naming, or using the names for advertisement, and apart from the lolz, I can't see a great reason to have something which is just one more thing we have to enforce.  If people don't want to play here because they can't name their custom squad D1CK BOIZ I'm not sure we're worse of without them.
 
 
There's no great way for me to determine who's "participating" in the mission or not, apart from their proximity to the bad guys.  And generally, if they're sniping targets or destroying vehicles from over a kilometer away (the current threshold for when you are participating or not), you're outside the AI's capacity to engage you back, so I don't know if that's worth rewarding.  You'll still get points for kills, you just won't get your share of the mission objective reward points, which frankly, aren't going to be as much as vehicle kill points anyway.
 
 
The part that says Beta test is there for a reason... optimization is where we are right now, and it gets a little better every version.  This is a long discussion but suffice it to say I don't want 4 running at lower frame rates, the whole point here was for better performance by culling old/bad code, and if it's a matter of streamlining / removing features to get back to good performance, than that's what happens.
 
 
See above... by default, all role-specific gear is considered purchased at mission start.  Gear like non-faction weaponry still needs to be purchased at this point, but I suppose if there's overwhelming demand that you should be able to leave the NATO base decked out in complete CSAT gear and weaponry, well, we can go there.
 
 
I'm not an expert with UI, and Arma doesn't give you a ton of options.  If someone's got a better flair for it than me, I welcome the assistance to overhaul it.  What I'm most concerned with is creating an interface that is easy to understand and intuitive.  I clearly have not gotten there, because we get the question every session, how do I join a role? despite several layers of hints, suggestions and tooltips.  Remember that the whole point of this system is so that people don't have to go back to the lobby to take a different role, which is a major perk in my opinion, as well it is a bit more stable (in some ways) than Arma's stock system.  (and yes, much more unstable in others, I will fully concede).
 
 
Well, this is the hardest part of balancing the mission, I've got Xwatt saying we need to not punish players for being outside the AO, and you suggesting we need to reduce the reward for players being inside the AO   Neither of you is wrong, it's just a matter of balancing how to reward players.  I welcome your suggestions.
 
 
Ah yes.

The point of the Zeus squad is that it's intended for Staff players to deliberately recuse themselves from gameplay.  You don't show up on the map, enemy AI won't target you, and you get a whack of reward points that you can use to reward individual players.
 
Not being in the Zeus squad in no way impairs staff's ability to use Zeus powers.  It's tied to your UID, not your squad.  So if you are playing, and you need to pop into Zeus to fix something, you are able to do so.
 
 
If someone - anyone - can point me to anything that prevents this issue - namely, all Zeus users being kicked at random intervals - I'll gladly implement it.  We've asked Bohemia, notable coders, everyone's stumped.  Yes, there are some drawbacks with the system I've implemented to get around that - namely, that a Zeus module is dynamically generated when you ask for one - and you've hit the main one, that when you leave Zeus, your module is destroyed, along with the links to items that you've spawned.  That said, there's nothing that stops you from using Achilles to add objects in Zeus to bring them right back into your interface.
 
 
It's to clean up the interface, following a theme of simplicity.  Also, putting it in the admin menu gives me a lot more flexibility to do things like respawn specific vehicles, sent hint messages to players, etc.  Stuff I can't do within the context of the scroll menu without several layers of sub-menus.
 
 
See above
 
 
Feel free to elaborate.  We've already eased a whole lot of restrictions we started with based on feedback, and if you can point to specific things, I'm happy to discuss them.  Many of the things people do complain about (long spawn times, role-based gear restrictions) are there for long-debated and resolved reasons, but if you have new points to consider, don't hesitate.
 
 
Please elaborate... I find the paperwork comment very confusing
 
 
As of ... two versions ago?  This is no longer the case.  All role-specific purchasable weapons are now by default "purchased" which means they can be armed straight from the arsenal.  Based on a discussion we all had, no less...
 
 
It's never been my intention to force people into absolutely predetermined squads, that's why I have the custom squads functionality.  It's not something I can test on my own for obvious reasons, so every beta test I am responding to how it chooses to break (and it almost always does).  Custom naming of squads had led us into more than one ban situation thanks to people's creative choice of naming, or using the names for advertisement, and apart from the lolz, I can't see a great reason to have something which is just one more thing we have to enforce.  If people don't want to play here because they can't name their custom squad D1CK BOIZ I'm not sure we're worse of without them.
 
 
There's no great way for me to determine who's "participating" in the mission or not, apart from their proximity to the bad guys.  And generally, if they're sniping targets or destroying vehicles from over a kilometer away (the current threshold for when you are participating or not), you're outside the AI's capacity to engage you back, so I don't know if that's worth rewarding.  You'll still get points for kills, you just won't get your share of the mission objective reward points, which frankly, aren't going to be as much as vehicle kill points anyway.
 
 
The part that says Beta test is there for a reason... optimization is where we are right now, and it gets a little better every version.  This is a long discussion but suffice it to say I don't want 4 running at lower frame rates, the whole point here was for better performance by culling old/bad code, and if it's a matter of streamlining / removing features to get back to good performance, than that's what happens.
 
 
See above... by default, all role-specific gear is considered purchased at mission start.  Gear like non-faction weaponry still needs to be purchased at this point, but I suppose if there's overwhelming demand that you should be able to leave the NATO base decked out in complete CSAT gear and weaponry, well, we can go there.
 
 
I'm not an expert with UI, and Arma doesn't give you a ton of options.  If someone's got a better flair for it than me, I welcome the assistance to overhaul it.  What I'm most concerned with is creating an interface that is easy to understand and intuitive.  I clearly have not gotten there, because we get the question every session, how do I join a role? despite several layers of hints, suggestions and tooltips.  Remember that the whole point of this system is so that people don't have to go back to the lobby to take a different role, which is a major perk in my opinion, as well it is a bit more stable (in some ways) than Arma's stock system.  (and yes, much more unstable in others, I will fully concede).
 
 
Well, this is the hardest part of balancing the mission, I've got Xwatt saying we need to not punish players for being outside the AO, and you suggesting we need to reduce the reward for players being inside the AO   Neither of you is wrong, it's just a matter of balancing how to reward players.  I welcome your suggestions.
 
 
Ah yes.

In case this helps anyone; class names introduced in the 1.94 expansion.  This isn't necessarily an exhaustive list, but it is pretty thorough.
 
Weapons: ["launch_RPG32_green_F", "launch_RPG32_camo_F", "launch_I_Titan_eaf_F", "launch_B_Titan_olive_F", "srifle_DMR_06_hunter_F", "srifle_DMR_06_hunter_khs_F", "LMG_Mk200_black_F", "LMG_Mk200_black_ACO_pointer_F", "LMG_Mk200_black_LP_BI_F", "LMG_Mk200_black_BI_F", "hgun_Pistol_heavy_01_green_F", "hgun_Pistol_heavy_01_green_F", "arifle_AK12_lush_F", "arifle_AK12_arid_F", "arifle_AK12_GL_lush_F", "arifle_AK12_GL_arid_F", "arifle_RPK12_F", "arifle_RPK12_lush_F", "arifle_RPK12_arid_F", "arifle_AK12U_F", "arifle_AK12U_lush_F", "arifle_AK12U_arid_F", "arifle_AK12_lush_arco_snds_pointer_F", "arifle_AK12_lush_snds_pointer_F", "arifle_AK12_lush_arco_snds_pointer_bipod_F", "arifle_AK12_GL_lush_arco_snds_pointer_F", "arifle_AK12_GL_lush_holo_snds_pointer_F", "arifle_AK12U_lush_holo_snds_pointer_F", "arifle_AK12U_lush_snds_pointer_F", "arifle_RPK12_lush_arco_snds_pointer_F", "arifle_RPK12_lush_holo_snds_pointer_F", "arifle_AK12_lush_arco_pointer_F", "arifle_AK12_GL_lush_arco_pointer_F", "arifle_AK12_GL_lush_holo_pointer_F", "arifle_AK12U_lush_holo_F", "arifle_AK12U_lush_holo_pointer_F", "arifle_AK12U_lush_holo_pointer_F", "arifle_RPK12_lush_arco_pointer_F", "arifle_MSBS65_F", "arifle_MSBS65_Mark_F", "arifle_MSBS65_GL_F", "arifle_MSBS65_UBS_F", "arifle_MSBS65_black_F", "arifle_MSBS65_Mark_black_F", "arifle_MSBS65_GL_black_F", "arifle_MSBS65_UBS_black_F", "arifle_MSBS65_sand_F", "arifle_MSBS65_Mark_sand_F", "arifle_MSBS65_GL_sand_F", "arifle_MSBS65_UBS_sand_F", "arifle_MSBS65_camo_F", "arifle_MSBS65_Mark_camo_F", "arifle_MSBS65_GL_camo_F", "arifle_MSBS65_UBS_camo_F", "arifle_MSBS65_ico_F", "arifle_MSBS65_black_ico_F", "arifle_MSBS65_GL_ico_F", "arifle_MSBS65_UBS_ico_F", "arifle_MSBS65_black_ico_F", "arifle_MSBS65_GL_black_ico_F", "arifle_MSBS65_UBS_black_ico_F", "arifle_MSBS65_black_ico_F", "arifle_MSBS65_black_ico_F", "arifle_MSBS65_ico_pointer_f", "arifle_MSBS65_GL_ico_pointer_f", "arifle_MSBS65_UBS_ico_pointer_f", "arifle_MSBS65_UBS_snds_ico_pointer_F", "arifle_MSBS65_black_ico_pointer_f", "arifle_MSBS65_GL_black_ico_pointer_f", "arifle_MSBS65_UBS_black_ico_pointer_f", "arifle_MSBS65_Mark_SOS_LP_BI_F", "sgun_HunterShotgun_01_F", "sgun_HunterShotgun_01_sawedoff_F"] Optics/Muzzles/Bipods: ["optic_ico_01_f", "optic_ico_01_black_f", "optic_ico_01_sand_f", "optic_ico_01_camo_f", "bipod_02_F_lush", "bipod_02_F_arid", "muzzle_snds_B_lush_F", "muzzle_snds_B_arid_F", "optic_Holosight_lush_F", "optic_Holosight_arid_F", "optic_Arco_lush_F", "optic_Arco_arid_F", "optic_Arco_AK_lush_F", "optic_Arco_AK_arid_F", "optic_DMS_weathered_F", "optic_DMS_weathered_Kir_F", "optic_MRD_black"] Helmets: ["H_HelmetHBK_F","H_HelmetHBK_headset_F","H_HelmetHBK_ear_F","H_HelmetHBK_chops_F","H_HelmetAggressor_F","H_HelmetAggressor_cover_F","H_HelmetAggressor_cover_taiga_F","H_Beret_EAF_01_F","H_Booniehat_mgrn","H_Booniehat_taiga","H_Booniehat_eaf","H_Booniehat_wdl","H_MilCap_grn","H_MilCap_taiga","H_MilCap_wdl","H_MilCap_wdl","H_HelmetB_plain_wdl","H_HelmetB_light_wdl","H_HelmetSpecB_wdl","H_HelmetCrew_I_E","H_Tank_eaf_F","H_PilotHelmetFighter_I_E"] Vests: ["V_CarrierRigKBT_01_EAF_F","V_CarrierRigKBT_01_light_EAF_F","V_CarrierRigKBT_01_heavy_EAF_F","V_CarrierRigKBT_01_Olive_F","V_CarrierRigKBT_01_light_Olive_F","V_CarrierRigKBT_01_heavy_Olive_F","Vest_Camo_Base","Vest_Camo_Base","V_SmershVest_01_F","V_SmershVest_01_radio_F","V_PlateCarrier1_wdl","V_PlateCarrier2_wdl","V_PlateCarrierGL_wdl","V_PlateCarrierSpec_wdl"] Items: ["C_UavTerminal"] Vehicles: ["I_E_Offroad_01_covered_F", "I_E_Offroad_01_comms_F", "B_GEN_Offroad_01_covered_F", "B_GEN_Offroad_01_comms_F", "C_Offroad_01_covered_F", "C_Offroad_01_comms_F", "Tractor_01_base_F", "C_Tractor_01_F", "Truck_01_base_F", "Truck_01_base_F", "B_Truck_01_flatbed_F", "B_T_Truck_01_flatbed_F", "B_Truck_01_cargo_F", "B_T_Truck_01_cargo_F"] UAVs / backpack things: ["B_UGV_02_Science_F", "B_UGV_02_Demining_F", "O_UGV_02_Science_F", "O_UGV_02_Demining_F", "I_UGV_02_Science_F", "I_E_UGV_02_Science_F", "I_UGV_02_Demining_F", "I_E_UGV_02_Demining_F", "C_IDAP_UGV_02_Demining_F", "B_W_Static_Designator_01_weapon_F", "B_CombinationUnitRespirator_01_F", "B_SCBA_01_F", "B_UGV_02_Science_backpack_F", "B_UGV_02_Demining_backpack_F", "O_UGV_02_Science_backpack_F", "O_UGV_02_Demining_backpack_F", "I_UGV_02_Science_backpack_F", "I_E_UGV_02_Science_backpack_F", "I_UGV_02_Demining_backpack_F", "I_E_UGV_02_Demining_backpack_F", "C_IDAP_UGV_02_Demining_backpack_F", "I_E_UAV_01_backpack_F", "I_E_UAV_06_backpack_F", "I_E_UAV_06_medical_backpack_F"] Units: ["B_W_Soldier_A_F", "B_W_Soldier_AAR_F", "B_W_Support_AMG_F", "B_W_Support_AMort_F", "B_W_Soldier_AAA_F", "B_W_Soldier_AAT_F", "B_W_Soldier_AR_F", "B_W_Medic_F", "B_W_Crew_F", "B_W_Engineer_F", "B_W_Soldier_Exp_F", "B_W_soldier_mine_F", "B_W_Soldier_GL_F", "B_W_Support_GMG_F", "B_W_Support_MG_F", "B_W_Support_Mort_F", "B_W_Helicrew_F", "B_W_Helipilot_F", "B_W_soldier_M_F", "B_W_Soldier_AA_F", "B_W_Soldier_AT_F", "B_W_Officer_F", "B_W_Soldier_Repair_F", "B_W_Soldier_F", "B_W_Soldier_LAT_F", "B_W_Soldier_LAT2_F", "B_W_Soldier_SL_F", "B_W_Soldier_TL_F", "B_W_Soldier_CBRN_F", "B_W_RadioOperator_F", "B_W_Survivor_F", "B_W_Soldier_UAV_F", "B_W_soldier_UGV_02_Science_F", "B_W_soldier_UGV_02_Demining_F", "B_W_Soldier_universal_F", "B_W_Soldier_unarmed_F", "O_R_Soldier_TL_F", "O_R_Soldier_GL_F", "O_R_soldier_exp_F", "O_R_Soldier_AR_F", "O_R_soldier_M_F", "O_R_medic_F", "O_R_Soldier_LAT_F", "O_R_JTAC_F", "O_Soldier_F", "O_R_recon_TL_F", "O_R_recon_exp_F", "O_R_recon_AR_F", "O_R_recon_M_F", "O_R_recon_medic_F", "O_R_recon_LAT_F", "O_R_recon_LAT_F", "O_R_recon_JTAC_F", "B_CBRN_Man_Oversuit_01_MTP_F", "B_CBRN_Man_Oversuit_01_Tropic_F", "B_CBRN_Man_Oversuit_01_Wdl_F", "I_CBRN_Man_Oversuit_01_AAF_F", "I_E_CBRN_Man_Oversuit_01_EAF_F", "C_CBRN_Man_Oversuit_01_Blue_F", "C_CBRN_Man_Oversuit_01_White_F", "I_E_Uniform_01_F", "I_E_Uniform_01_tanktop_F", "I_E_Uniform_01_shortsleeve_F", "I_E_Uniform_01_officer_F", "I_E_Uniform_01_sweater_F", "I_E_Uniform_01_coveralls_F", "I_E_Soldier_base_F", "I_E_Soldier_F", "I_E_Soldier_unarmed_F", "I_E_Soldier_A_F", "I_E_Soldier_AAR_F", "I_E_Soldier_AR_F", "I_E_Soldier_lite_F", "I_E_Soldier_GL_F", "I_E_soldier_M_F", "I_E_Officer_F", "I_E_Soldier_SL_F", "I_E_Soldier_TL_F", "I_E_Survivor_F", "I_E_RadioOperator_F", "I_E_Soldier_AA_F", "I_E_Soldier_AT_F", "I_E_Soldier_LAT_F", "I_E_Soldier_LAT2_F", "I_E_Soldier_AAA_F", "I_E_Soldier_AAT_F", "I_E_Support_GMG_F", "I_E_Support_MG_F", "I_E_Support_Mort_F", "I_E_Support_AMG_F", "I_E_Support_AMort_F", "I_E_Soldier_Pathfinder_F", "I_E_Engineer_F", "I_E_Soldier_Exp_F", "I_E_soldier_Mine_F", "I_E_Soldier_Repair_F", "I_E_Soldier_CBRN_F", "I_E_Scientist_F", "I_E_Scientist_Unarmed_F", "I_E_Medic_F", "I_E_Soldier_MP_F", "I_E_Crew_F", "I_E_Helipilot_F", "I_E_Helicrew_F", "I_E_Soldier_UAV_F", "I_E_soldier_UAV_06_F", "I_E_soldier_UAV_06_medical_F", "I_E_soldier_UGV_02_Science_F", "I_E_soldier_UGV_02_Demining_F", "I_E_Soldier_universal_F", "O_R_Patrol_Soldier_TL_F", "O_R_Patrol_Soldier_AR_F", "O_R_Patrol_Soldier_AR2_F", "O_R_Patrol_Soldier_GL_F", "O_R_Patrol_Soldier_A_F", "O_R_Patrol_Soldier_M_F", "O_R_Patrol_Soldier_M2_F", "O_R_Patrol_Soldier_Medic", "O_R_Patrol_Soldier_Engineer_F", "O_R_Patrol_Soldier_LAT_F" ] Vehicles: ["I_E_UAV_01_F"] Backpacks: ["B_RadioBag_01_wdl_F", "B_RadioBag_01_mtp_F", "B_RadioBag_01_tropic_F", "B_RadioBag_01_black_F", "B_RadioBag_01_hex_F", "B_RadioBag_01_oucamo_F", "B_RadioBag_01_hex_F", "B_RadioBag_01_digi_F", "B_RadioBag_01_eaf_F", "B_Carryall_green_F", "B_Carryall_taiga_F", "B_Carryall_wdl_F", "B_Carryall_eaf_F", "B_FieldPack_green_F", "B_FieldPack_taiga_F", "B_AssaultPack_wdl_F", "B_AssaultPack_eaf_F", "B_Carryall_eaf_IEAmmo_F", "B_Carryall_eaf_IEAAR_F", "B_Carryall_eaf_IEAAA_F", "B_Carryall_eaf_exp_F", "B_Carryall_eaf_exp_F", "B_Carryall_eaf_Mine_F", "B_Carryall_eaf_IEAAT_F", "B_Fieldpack_green_IEAA_F", "B_Fieldpack_green_IEAT_F", "B_Fieldpack_green_IELAT_F", "B_Fieldpack_green_IELAT2_F", "B_AssaultPack_eaf_IEPathfinder_F", "B_AssaultPack_eaf_Repair_F", "B_Fieldpack_green_IELAT_F", "B_AssaultPack_eaf_IELAT2_F", "B_Fieldpack_green_IEMedic_F", "B_RadioBag_01_eaf_FAK_F", "B_RadioBag_01_wdl_FAK_F", "B_Carryall_wdl_BWAmmo_F", "B_Carryall_wdl_Mine", "B_Carryall_wdl_BWAAA_F", "B_Carryall_wdl_BWAAT_F", "B_AssaultPack_wdl_BWMedic_F", "B_AssaultPack_wdl_BWRepair_F", "B_AssaultPack_wdl_BWLAT_F", "B_AssaultPack_wdl_BWLAT2_F", "B_AssaultPack_wdl_BWReconMedic", "B_Carryall_taiga_Exp_F", "B_Carryall_green_exp_F", "B_FieldPack_taiga_Medic_F", "B_FieldPack_taiga_RPG_AT_F", "B_FieldPack_green_Exp_F", "B_FieldPack_green_Medic_F", "B_FieldPack_green_RPG_AT_F", "B_Patrol_Carryall_green_Ammo_F", "B_Patrol_Carryall_taiga_medic_F", "B_Patrol_FieldPack_green_eng_F"] Supply boxes: ["Box_EAF_Wps_F", "Box_EAF_WpsSpecial_F", "Box_EAF_WpsLaunch_F", "Box_EAF_Ammo_F", "Box_EAF_Equip_F", "Box_EAF_Grenades_F", "Box_EAF_AmmoOrd_F", "Box_EAF_Support_F", "Box_EAF_AmmoVeh_F", "Box_EAF_Uniforms_F", "I_EAF_supplyCrate_F", "I_E_CargoNet_01_ammo_F"] Statics: ["Land_FeedShack_01_F", "Land_DeerStand_01_F", "Land_DeerStand_02_F", "Land_Anthill_01_F", "Land_Bark_Beetle_Trap_01_F", "Land_Bark_Beetle_Trap_02_F", "Land_Bark_Beetle_Trap_03_F", "Land_DeerSkeleton_damaged_01_F", "Land_DeerSkeleton_full_01_F", "Land_DeerSkeleton_pile_01_F", "Land_DeerSkeleton_skull_01_F", "Land_FeedRack_01_F", "Land_WoodenLog_02_F", "Land_GarbageBin_03_F", "Land_MapBoard_Enoch_F", "Land_MapBoard_01_Wall_Enoch_F", "Land_WoodenBox_02_F", "Land_WoodenWindBreak_01_F", "Land_Map_Enoch_F", "Land_Map_unfolded_Enoch_F", "Book_01_F", "Book_02_F", "Newspaper_01_F", "AluminiumFoil_01_F", "Land_PortableLight_02_single_olive_F", "Land_PortableLight_02_single_yellow_F", "Land_PortableLight_02_single_black_F", "Land_PortableLight_02_single_sand_F", "Land_PortableLight_02_double_olive_F", "Land_PortableLight_02_double_yellow_F", "Land_PortableLight_02_double_black_F", "Land_PortableLight_02_double_sand_F", "Land_PortableLight_02_quad_olive_F", "Land_PortableLight_02_quad_yellow_F", "Land_PortableLight_02_quad_black_F", "Land_PortableLight_02_quad_sand_F", "Land_PortableLight_02_folded_olive_F", "Land_PortableLight_02_folded_yellow_F", "Land_PortableLight_02_folded_black_F", "Land_PortableLight_02_folded_sand_F", "Land_PortableLight_02_single_folded_olive_F", "Land_PortableLight_02_single_folded_yellow_F", "Land_PortableLight_02_single_folded_black_F", "Land_PortableLight_02_single_folded_sand_F", "SatelliteAntenna_01_Mounted_Olive_F", "SatelliteAntenna_01_Mounted_Black_F", "SatelliteAntenna_01_Mounted_Sand_F", "SatelliteAntenna_01_Small_Mounted_Olive_F", "SatelliteAntenna_01_Small_Mounted_Black_F", "SatelliteAntenna_01_Small_Mounted_Sand_F", "Land_TripodScreen_01_dual_v1_sand_F", "Land_TripodScreen_01_dual_v2_sand_F", "Land_TripodScreen_01_large_sand_F", "Land_PortableGenerator_01_sand_F", "Land_Tablet_02_sand_F", "Land_TripodScreen_01_dual_v1_black_F", "Land_TripodScreen_01_dual_v2_black_F", "Land_TripodScreen_01_large_black_F", "Land_PortableGenerator_01_black_F", "Land_Tablet_02_black_F", "DeconShower_01_F", "DeconShower_02_F", "SpinalBoard_01_orange_F", "SpinalBoard_01_white_F", "SpinalBoard_01_black_F", "Sponge_01_dry_F", "Sponge_01_Wet_F", "Broom_01_yellow_F", "Broom_01_grey_F", "Brush_01_yellow_F", "Brush_01_green_F", "TrashBagHolder_01_F", "WalkingFrame_01_F", "StretcherRollerSystem_01_F", "AntidoteKit_01_F", "DeconKit_01_F", "DrainageDeck_01_F", "SCBACylinder_01_F", "SCBACylinder_01_CUR_F", "LiquidSpraySystem_01_F", "LiquidSpraySystem_01_Extended_F", "Tarp_01_Large_Yellow_F", "Tarp_01_Large_Green_F", "Tarp_01_Large_Red_F", "Tarp_01_Large_Black_F", "Tarp_01_Small_Yellow_F", "Tarp_01_Small_Green_F", "Tarp_01_Small_Red_F", "Tarp_01_Small_Black_F", "WaterSpill_01_Small_New_F", "WaterSpill_01_Small_Foam_F", "WaterSpill_01_Small_Old_F", "WaterSpill_01_Medium_New_F", "WaterSpill_01_Medium_Foam_F", "WaterSpill_01_Medium_Old_F", "WaterSpill_01_Large_New_F", "WaterSpill_01_Large_Foam_F", "WaterSpill_01_Large_Old_F", "WaterTrail_01_New_F", "WaterTrail_01_Old_F", "WaterTrail_01_Foam_F", "HazmatBag_01_F", "HazmatBag_01_empty_F", "HazmatBag_01_roll_F", "CBRNContainer_01_yellow_F", "CBRNContainer_01_olive_F", "CBRNContainer_01_closed_yellow_F", "CBRNContainer_01_closed_olive_F", "CBRNLid_01_yellow_F", "CBRNLid_01_olive_F", "CBRNCase_01_F", "PressureHose_01_Roll_F", "PressureHose_01_StraightLong_F", "PressureHose_01_StraightShort_F", "PressureHose_01_SBend_F", "PressureHose_01_Corner_F", "PressureHose_01_CurveLong_F", "PressureHose_01_CurveShort_F", "PressureHose_01_Step_F", "LayFlatHose_01_Roll_F", "LayFlatHose_01_StraightLong_F", "LayFlatHose_01_StraightShort_F", "LayFlatHose_01_SBend_F", "LayFlatHose_01_Corner_F", "LayFlatHose_01_CurveLong_F", "LayFlatHose_01_CurveShort_F", "LayFlatHose_01_Step_F", "PowerCable_01_Roll_F", "PowerCable_01_StraightLong_F", "PowerCable_01_StraightShort_F", "PowerCable_01_SBend_F", "PowerCable_01_Corner_F", "PowerCable_01_CurveLong_F", "PowerCable_01_CurveShort_F", "PowerCable_01_Step_F", "Land_MultiScreenComputer_01_olive_F", "Land_MultiScreenComputer_01_black_F", "Land_MultiScreenComputer_01_sand_F", "Land_MultiScreenComputer_01_closed_olive_F", "Land_MultiScreenComputer_01_closed_black_F", "Land_MultiScreenComputer_01_closed_sand_F", "Land_IPPhone_01_olive_F", "Land_IPPhone_01_black_F", "Land_IPPhone_01_sand_F", "Land_Laptop_03_olive_F", "Land_Laptop_03_black_F", "Land_Laptop_03_sand_F", "Land_laptop_03_closed_olive_F", "Land_laptop_03_closed_black_F", "Land_laptop_03_closed_sand_F", "Land_PortableServer_01_olive_F", "Land_PortableServer_01_black_F", "Land_PortableServer_01_sand_F", "Land_PortableServer_01_cover_olive_F", "Land_PortableServer_01_cover_black_F", "Land_PortableServer_01_cover_sand_F", "Land_Computer_01_olive_F", "Land_Computer_01_black_F", "Land_Computer_01_sand_F", "Land_Router_01_olive_F", "Land_Router_01_black_F", "Land_Router_01_sand_F", "Land_PortableSolarPanel_01_olive_F", "Land_PortableSolarPanel_01_sand_F", "Land_PortableSolarPanel_01_folded_olive_F", "Land_PortableSolarPanel_01_folded_sand_F", "Land_SolarPanel_04_olive_F", "Land_SolarPanel_04_black_F", "Land_SolarPanel_04_sand_F", "Land_BatteryPack_01_open_olive_F", "Land_BatteryPack_01_open_black_F", "Land_BatteryPack_01_open_sand_F", "Land_BatteryPack_01_closed_olive_F", "Land_BatteryPack_01_closed_black_F", "Land_BatteryPack_01_closed_sand_F", "Land_BatteryPack_01_battery_olive_F", "Land_BatteryPack_01_battery_black_F", "Land_BatteryPack_01_battery_sand_F", "House_Small_F", "Land_GarbageBarrel_02_F", "Land_GarbageBarrel_02_buried_F", "House_Small_F", "Land_BurntGarbage_01_F", "Land_PlasticCase_01_large_black_F", "Land_PlasticCase_01_large_black_CBRN_F", "Land_PlasticCase_01_medium_black_F", "Land_PlasticCase_01_medium_black_CBRN_F", "Land_PlasticCase_01_small_black_F", "Land_PlasticCase_01_small_black_CBRN_F", "Land_PlasticCase_01_large_olive_F", "Land_PlasticCase_01_large_olive_CBRN_F", "Land_PlasticCase_01_medium_olive_F", "Land_PlasticCase_01_medium_olive_CBRN_F", "Land_PlasticCase_01_small_olive_F", "Land_PlasticCase_01_small_olive_CBRN_F", "Land_PlasticCase_01_large_CBRN_F", "Land_PlasticCase_01_medium_CBRN_F", "Land_PlasticCase_01_small_CBRN_F", "Land_Bare_boulder_01_F", "Land_Bare_boulder_02_F", "Land_Bare_boulder_03_F", "Land_Bare_boulder_04_F", "Land_Bare_boulder_05_F", "Land_R_rock_general1", "Land_R_rock_general2", "Land_R_rock_general3", "Land_RM_boulder1", "Land_RM_boulder2", "Land_RM_boulder3", "Land_RM_boulder4", "Land_RM_boulder5", "Land_Sinkhole_01_F", "I_E_Quadbike_01_F", "I_E_Truck_02_F", "I_E_Truck_02_transport_F", "I_E_Truck_02_fuel_F", "I_E_Truck_02_Ammo_F", "I_E_Truck_02_Box_F", "I_E_Truck_02_Medical_F", "I_E_Truck_02_MRL_F", "I_E_UGV_01_F", "I_E_UGV_01_rcws_F", "UGV_02_ExternalDetector_F", "UGV_02_Wheel_F", "UGV_02_Tracks_F", "I_E_Van_02_vehicle_F", "I_E_Van_02_transport_F", "I_E_Van_02_transport_MP_F", "I_E_Van_02_medevac_F", "B_W_Static_Designator_01_weapon_F", "Land_StoneWell_01_F", "Land_ConcreteWell_02_F", "Land_DryToilet_01_F", "Land_Hutch_01_F", "Land_ChickenCoop_01_F", "Land_FirewoodPile_01_F", "Land_BusStop_02_shelter_ruins_F", "Land_BusStop_02_shelter_F", "Land_BusStop_02_sign_F", "Land_GasMeterCabinet_01_F", "Land_TreeGuard_01_F", "Land_TreeGrate_01_F", "Land_ConcreteTreePlanter_01_F", "Land_ConcreteTreePlanter_02_F", "Land_MysteriousBell_01_F", "Land_Camp_House_01_brown_ruins_F", "Land_Camp_House_01_brown_F", "Land_Caravan_01_green_F", "Land_Caravan_01_rust_F", "Land_Scaffolding_New_F", "Land_House_1B01_ruins_F", "Land_House_1B01_F", "Land_House_1W01_ruins_F", "Land_House_1W01_F", "Land_House_1W02_ruins_F", "Land_House_1W02_F", "Land_House_1W03_ruins_F", "Land_House_1W03_F", "Land_House_1W04_ruins_F", "Land_House_1W04_F", "Land_House_1W05_ruins_F", "Land_House_1W05_F", "Land_House_1W06_ruins_F", "Land_House_1W06_F", "Land_House_1W07_ruins_F", "Land_House_1W07_F", "Land_House_1W08_ruins_F", "Land_House_1W08_F", "Land_House_1W09_ruins_F", "Land_House_1W09_F", "Land_House_1W10_ruins_F", "Land_House_1W10_F", "Land_House_1W11_ruins_F", "Land_House_1W11_F", "Land_House_1W12_ruins_F", "Land_House_1W12_F", "Land_House_1W13_ruins_F", "Land_House_1W13_F", "Land_House_2B01_ruins_F", "Land_House_2B01_F", "Land_House_2B02_ruins_F", "Land_House_2B02_F", "Land_House_2B03_ruins_F", "Land_House_2B03_F", "Land_House_2B04_ruins_F", "Land_House_2B04_F", "Land_House_2W01_ruins_F", "Land_House_2W01_F", "Land_House_2W02_ruins_F", "Land_House_2W02_F", "Land_House_2W03_ruins_F", "Land_House_2W03_F", "Land_House_2W04_ruins_F", "Land_House_2W04_F", "Land_House_2W05_ruins_F", "Land_House_2W05_F", "Land_HealthCenter_01_ruins_F", "Land_HealthCenter_01_F", "Land_PoliceStation_01_ruins_F", "Land_PoliceStation_01_F", "Land_Shed_09_ruins_F", "Land_Shed_09_F", "Land_Shed_10_ruins_F", "Land_Shed_10_F", "Land_Shed_11_ruins_F", "Land_Shed_11_F", "Land_Shed_12_ruins_F", "Land_Shed_12_F", "Land_Shed_13_ruins_F", "Land_Shed_13_F", "Land_Shed_14_ruins_F", "Land_Shed_14_F", "Land_FuelStation_03_prices_F", "Land_FuelStation_03_pump_F", "Land_FuelStation_03_roof_F", "Land_FuelStation_03_shop_F", "Land_VillageStore_01_ruins_F", "Land_VillageStore_01_F", "Land_CastleRuins_01_bastion_F", "Land_CastleRuins_01_wall_10m_F", "Land_CastleRuins_01_wall_d_L_F", "Land_CastleRuins_01_wall_d_R_F", "Land_Grave_08_F", "Land_Grave_09_F", "Land_Grave_10_F", "Land_Grave_11_F", "Land_Tombstone_04_F", "Land_Tombstone_05_F", "Land_Tombstone_06_F", "Land_Tombstone_07_F", "Land_Tombstone_08_F", "Land_Tombstone_08_damaged_F", "Land_Tombstone_09_F", "Land_Tombstone_10_F", "Land_Tombstone_11_F", "Land_Tombstone_11_damaged_F", "Land_Tombstone_12_F", "Land_Tombstone_13_F", "Land_Tombstone_14_F", "Land_Tombstone_15_F", "Land_Tombstone_16_F", "Land_Tombstone_17_F", "Land_GraveFence_01_F", "Land_GraveFence_02_F", "Land_GraveFence_03_F", "Land_GraveFence_04_F", "Land_Cross_01_small_F", "Land_Chapel_02_base_ruins_F", "Land_Chapel_02_white_ruins_F", "Land_Chapel_02_yellow_ruins_F", "Land_Church_04_F", "Land_Church_04_small_F", "Land_Church_04_damaged_F", "Land_Church_04_lightblue_F", "Land_Church_04_lightblue_damaged_F", "Land_Church_04_lightyellow_F", "Land_Church_04_lightyellow_damaged_F", "Land_Church_04_red_F", "Land_Church_04_red_damaged_F", "Land_Church_04_white_F", "Land_Church_04_white_damaged_F", "Land_Church_04_white_red_F", "Land_Church_04_white_red_damaged_F", "Land_Church_04_yellow_F", "Land_Church_04_yellow_damaged_F", "Land_Church_04_small_damaged_F", "Land_Church_04_small_lightblue_F", "Land_Church_04_small_lightblue_damaged_F", "Land_Church_04_small_lightyellow_F", "Land_Church_04_small_lightyellow_damaged_F", "Land_Church_04_small_red_F", "Land_Church_04_small_red_damaged_F", "Land_Church_04_small_white_F", "Land_Church_04_small_white_damaged_F", "Land_Church_04_small_white_red_F", "Land_Church_04_small_white_red_damaged_F", "Land_Church_04_small_yellow_F", "Land_Church_04_small_yellow_damaged_F", "Land_Church_05_F", "Land_OrthodoxChurch_02_F", "Land_OrthodoxChurch_03_ruins_F", "Land_OrthodoxChurch_03_F", "Land_Statue_03_F", "Land_Monument_02_F", "Land_OldSculpture_01_F", "Land_ConcretePanels_01_base_F", "Land_ConcretePanels_01_single_F", "Land_ConcretePanels_01_F", "Land_ConcretePanels_01_end1_F", "Land_ConcretePanels_01_end2_F", "Land_Roads_decals_01_base_F", "Land_roads_patch_01_F", "Land_roads_patch_02_F", "Land_roads_patch_03_F", "Land_roads_patch_04_F", "Land_roads_patch_05_F", "Land_roads_patch_06_F", "Land_roads_patch_07_F", "Land_roads_patch_08_F", "Land_roads_patch_09_F", "Land_roads_patch_10_F", "Land_roads_patch_11_F", "Land_roads_patch_12_F", "Land_roads_cracks_01_F", "Land_roads_cracks_02_F", "Land_roads_cracks_03_F", "Land_roads_cracks_04_F", "Land_roads_cracks_05_F", "Land_Decal_damage_long1_F", "Land_Decal_damage_long2_F", "Land_Decal_damage_long3_F", "Land_Decal_damage_long4_F", "Land_Decal_damage_long5_F", "Land_Decal_damage_medium1_F", "Land_Decal_damage_medium2_F", "Land_Decal_roads_ars_01_F", "Land_Decal_roads_ars_02_F", "Land_Decal_roads_ars_03_F", "Land_Decal_roads_ars_04_F", "Land_Decal_roads_ars_05_F", "Land_Decal_roads_ars_06_F", "Land_Decal_roads_oil_stain_01_F", "Land_Decal_roads_oil_stain_02_F", "Land_Decal_roads_oil_stain_03_F", "Land_Decal_roads_oil_stain_04_F", "Land_dirt_road_damage_long_01_F", "Land_dirt_road_damage_long_02_F", "Land_dirt_road_damage_long_03_F", "Land_dirt_road_damage_long_04_F", "Land_dirt_road_damage_long_05_F", "Land_dirt_road_rocks_01_F", "Land_dirt_road_rocks_02_F", "Land_dirt_road_rocks_03_F", "Land_dirt_road_rocks_04_F", "Land_VehicleTrack_01_base_F", "Land_VehicleTrack_01_straight_v1_F", "Land_VehicleTrack_01_straight_v2_F", "Land_VehicleTrack_01_straight_start_F", "Land_VehicleTrack_01_straight_end_F", "Land_VehicleTrack_01_left_v1_F", "Land_VehicleTrack_01_left_v2_F", "Land_VehicleTrack_01_left_crossing_F", "Land_VehicleTrack_01_right_v1_F", "Land_VehicleTrack_01_right_v2_F", "Land_VehicleTrack_01_right_crossing_F", "Land_DirtPatch_05_F", "Land_Drainage_01_F", "Land_HayBale_01_F", "Land_HayBale_01_decayed_F", "Land_HayBale_01_packed_F", "Land_HayBale_01_stack_F", "Land_Trough_01_F", "Land_SilageStorage_01_F", "Land_ManurePile_01_F", "Land_FeedStorage_01_ruins_F", "Land_FeedStorage_01_F", "Cargo_base_F", "Land_Cargo20_EMP_F", "Land_Cargo20_EMP_Training_F", "Land_CementWorks_01_base_F", "Land_CementWorks_01_brick_F", "Land_CementWorks_01_grey_F", "Land_CoalPlant_01_MainBuilding_F", "Land_CoalPlant_01_Conveyor_F", "Land_CoalPlant_01_LoadingHouse_F", "Land_DPP_01_mainFactory_old_F", "Land_Barn_02_ruins_F", "Land_Barn_02_F", "Land_Barn_03_small_ruins_F", "Land_Barn_03_small_F", "Land_Barn_03_large_ruins_F", "Land_Barn_03_large_F", "Land_Barn_04_ruins_F", "Land_Barn_04_F", "Land_StrawStack_01_F", "Land_WaterTower_02_ruins_F", "Land_WaterTower_02_F", "Land_Cowshed_01_A_ruins_F", "Land_Cowshed_01_A_F", "Land_Cowshed_01_B_ruins_F", "Land_Cowshed_01_B_F", "Land_Cowshed_01_C_ruins_F", "Land_Cowshed_01_C_F", "Land_Greenhouse_01_ruins_F", "Land_Greenhouse_01_F", "Land_Greenhouse_01_damaged_F", "Land_GarageOffice_01_ruins_F", "Land_GarageOffice_01_F", "Land_GarageRow_01_large_ruins_F", "Land_GarageRow_01_large_F", "Land_GarageRow_01_small_ruins_F", "Land_GarageRow_01_small_F", "Land_Factory_02_F", "Land_WaterStation_01_ruins_F", "Land_WaterStation_01_F", "Land_Workshop_01_ruins_F", "Land_Workshop_01_F", "Land_Workshop_01_grey_F", "Land_Workshop_02_ruins_F", "Land_Workshop_02_F", "Land_Workshop_02_grey_F", "Land_Workshop_03_ruins_F", "Land_Workshop_03_F", "Land_Workshop_03_grey_F", "Land_Workshop_04_ruins_F", "Land_Workshop_04_F", "Land_Workshop_04_grey_F", "Land_Workshop_05_ruins_F", "Land_Workshop_05_F", "Land_Workshop_05_grey_F", "Land_TimberLog_01_F", "Land_TimberLog_02_F", "Land_TimberLog_03_F", "Land_TimberLog_04_F", "Land_TimberLog_05_F", "Land_TimberPile_02_F", "Land_TimberPile_03_F", "Land_TimberPile_04_F", "Land_TimberPile_05_F", "Land_WoodPile_02_F", "Land_WoodPile_03_F", "Land_WoodPile_04_F", "Land_Mine_01_conveyor_10m_F", "Land_Mine_01_conveyor_begin_F", "Land_Mine_01_conveyor_end_F", "Land_Mine_01_heap_F", "Land_Mine_01_hopper_silo_F", "Land_Mine_01_minecart_F", "Land_Mine_01_rail_track_end_F", "Land_Mine_01_rail_track_F", "Land_Mine_01_rail_track_switch_F", "Land_Mine_01_warehouse_F", "Land_IndPipe3_big_9_F", "Land_IndPipe3_big_18_F", "Land_IndPipe3_big_18ladder_F", "Land_IndPipe3_big_ground1_F", "Land_IndPipe3_big_ground2_F", "Land_IndPipe3_big_support_F", "Land_IndPipe3_bigL_L_F", "Land_IndPipe3_bigL_R_F", "Land_IndPipe3_Small_9_F", "Land_IndPipe3_Small_ground1_F", "Land_IndPipe3_Small_ground2_F", "Land_IndPipe3_SmallL_L_F", "Land_IndPipe3_SmallL_R_F", "Land_PowerStation_01_ruins_F", "Land_PowerStation_01_F", "Land_Substation_01_ruins_F", "Land_Substation_01_F", "Land_Sawmill_01_ruins_F", "Land_Sawmill_01_F", "Land_Sawmill_01_illuminati_tower_F", "Land_IndustrialShed_01_ruins_F", "Land_IndustrialShed_01_F", "Land_Smokestack_01_ruins_F", "Land_Smokestack_01_F", "Land_Smokestack_01_off_F", "Land_Smokestack_01_factory_ruins_F", "Land_Smokestack_01_factory_F", "Land_Smokestack_01_factory_off_F", "Land_Smokestack_01_factory_base_F", "Land_Smokestack_01_factory_lower_F", "Land_Smokestack_01_factory_middle_F", "Land_Smokestack_01_factory_upper_F", "Land_Smokestack_02_ruins_F", "Land_Smokestack_02_F", "Land_Smokestack_03_ruins_F", "Land_Smokestack_03_F", "Land_Smokestack_03_off_F", "Land_Highway_Pillar_01_F", "Land_Highway_Pillar_01_garage_F", "Land_ConcreteKerb_01_2m_v2_F", "Land_ConcreteKerb_01_4m_v2_F", "Land_ConcreteKerb_01_8m_v2_F", "Land_PowerLine_02_pole_small_end_F", "Land_PowerLine_02_pole_small_end_A_F", "Land_PowerLine_02_pole_junction_A_F", "Land_PowerLine_02_pole_small_lamp_F", "Land_PowerLine_02_pole_small_lamp_off_F", "Land_PowerLine_02_pole_small_F", "Land_PowerLine_02_pole_small_A_F", "Land_PowerLine_02_pole_small_hook_F", "PowerLines_Small_base_F", "PowerLines_Small_base_F", "PowerLines_Small_base_F", "PowerLines_Small_base_F", "Land_TelephoneLine_01_wire_50m_main_F", "Land_PowerLine_03_pole_F", "Land_PowerLine_03_pole_end_F", "Land_PowerLine_03_pole_junction_F", "Land_Power_Pole_Wood1", "Land_Power_Pole_Wood1_Amp", "Land_Power_Pole_Wood1_Lamp", "Land_Power_Pole_Wood1_Lamp_Amp", "Land_Power_Pole_Wood2", "Land_Power_Pole_Wood3", "Land_Rail_Bridge_40_F", "Land_Rail_ConcreteRamp_F", "Land_Rail_Crossing_Barrier_F", "Land_Rail_LineBreak_Iron_F", "Land_Rail_Platform_Cross_F", "Land_Rail_Platform_Segment_F", "Land_Rail_Platform_Start_F", "Land_Rail_Signals_F", "Land_Rail_Station_Big_ruins_F", "Land_Rail_Station_Big_F", "Land_Rail_Station_Small_ruins_F", "Land_Rail_Station_Small_F", "Land_Rail_Track_25_F", "Land_Rail_Track_Down_25_F", "Land_Rail_Track_Down_40_F", "Land_Rail_Track_L25_10_F", "Land_Rail_Track_LB_RE_F", "Land_Rail_Track_LB1_RE_F", "Land_Rail_Track_LE_RB_F", "Land_Rail_Track_LE1_RB_F", "Land_Rail_Track_Passing_10_F", "Land_Rail_Track_Passing_25_F", "Land_Rail_Track_Passing_25NOLC_F", "Land_Rail_Track_R25_10_F", "Land_Rail_Track_SP_F", "Land_Rail_Track_TurnOutL_F", "Land_Rail_Track_TurnOutR_F", "Land_Rail_Track_Up_25_F", "Land_Rail_Track_Up_40_F", "Land_Rail_TrackE_2_F", "Land_Rail_TrackE_4_F", "Land_Rail_TrackE_8_F", "Land_Rail_TrackE_8NOLC_F", "Land_Rail_TrackE_25_F", "Land_Rail_TrackE_25NOLC_F", "Land_Rail_TrackE_40_F", "Land_Rail_TrackE_40NOLC_F", "Land_Rail_TrackE_L25_5_F", "Land_Rail_TrackE_L25_10_F", "Land_Rail_TrackE_L30_20_F", "Land_Rail_TrackE_R25_5_F", "Land_Rail_TrackE_R25_10_F", "Land_Rail_TrackE_R30_20_F", "Land_Rail_TrackE_TurnOutL_F", "Land_Rail_TrackE_TurnOutR_F", "Land_Rail_Warehouse_Small_ruins_F", "Land_Rail_Warehouse_Small_F", "Land_SewerCover_04_F", "Land_ConcretePanels_02_four_F", "Land_ConcretePanels_02_single_dmg_F", "Land_ConcretePanels_02_single_v1_F", "Land_ConcretePanels_02_single_v2_F", "Land_CobblestoneSquare_01_2m_F", "Land_CobblestoneSquare_01_4m_F", "Land_CobblestoneSquare_01_8m_F", "Land_CobblestoneSquare_01_32m_F", "Land_CobblestoneSquare_01_edge_2m_v1_F", "Land_CobblestoneSquare_01_edge_2m_v2_F", "Land_CobblestoneSquare_01_edge_32m_v1_F", "Land_CobblestoneSquare_01_edge_32m_v2_F", "Land_CobblestoneSquare_01_edge_4m_v1_F", "Land_CobblestoneSquare_01_edge_4m_v2_F", "Land_CobblestoneSquare_01_edge_8m_v1_F", "Land_CobblestoneSquare_01_edge_8m_v2_F", "Land_ServiceHangar_01_base_F", "Land_ServiceHangar_01_L_F", "Land_ServiceHangar_01_R_F", "Land_ControlTower_02_ruins_F", "Land_ControlTower_02_F", "Land_GuardBox_01_base_ruins_F", "Land_GuardBox_01_green_ruins_F", "Land_GuardBox_01_brown_ruins_F", "Land_GuardBox_01_smooth_ruins_F", "Land_GuardBox_01_base_F", "Land_GuardBox_01_green_F", "Land_GuardBox_01_brown_F", "Land_GuardBox_01_smooth_F", "Land_ControlTower_01_ruins_F", "Land_ControlTower_01_F", "Land_Barracks_02_ruins_F", "Land_Barracks_02_F", "Land_Barracks_03_ruins_F", "Land_Barracks_03_F", "Land_Barracks_04_ruins_F", "Land_Barracks_04_F", "Land_Barracks_05_ruins_F", "Land_Barracks_05_F", "Land_Barracks_06_ruins_F", "Land_Barracks_06_F", "Land_GuardHouse_02_ruins_F", "Land_GuardHouse_02_F", "Land_GuardHouse_02_grey_F", "Land_GuardHouse_03_ruins_F", "Land_GuardHouse_03_F", "Land_GuardTower_01_F", "Land_GuardTower_02_F", "Land_Bunker_02_double_F", "Land_Bunker_02_left_F", "Land_Bunker_02_right_F", "Land_Bunker_02_light_double_F", "Land_Bunker_02_light_left_F", "Land_Bunker_02_light_right_F", "CamoNet_wdl_F", "CamoNet_wdl_open_F", "CamoNet_wdl_big_F", "CamoNet_wdl_Curator_F", "CamoNet_wdl_open_Curator_F", "CamoNet_wdl_big_Curator_F", "CargoPlaftorm_01_green_F", "CargoPlaftorm_01_green_ruins_F", "CargoPlaftorm_01_brown_F", "CargoPlaftorm_01_brown_ruins_F", "CargoPlaftorm_01_jungle_F", "CargoPlaftorm_01_jungle_ruins_F", "CargoPlaftorm_01_rusty_F", "CargoPlaftorm_01_rusty_ruins_F", "Land_DomeParts_01_panel_white_F", "Land_DomeParts_01_panel_white_stack_F", "Land_DomeParts_01_struts_stack_F", "Land_DomeParts_01_white_openstack_F", "Flag_EAF_F", "Flag_Enoch_F", "Banner_01_EAF_F", "Land_Radar_01_airshaft_F", "Land_Radar_01_cooler_F", "Land_Radar_01_antenna_F", "Land_Radar_01_antenna_base_F", "Land_Radar_01_kitchen_ruins_F", "Land_Radar_01_kitchen_F", "Land_Radar_01_HQ_ruins_F", "Land_Radar_01_HQ_F", "Land_MobileRadar_01_generator_F", "Land_MobileRadar_01_radar_ruins_F", "Land_MobileRadar_01_radar_F", "Land_ShellCrater_01_decal_F", "Land_ShellCrater_01_F", "Land_ShellCrater_02_small_F", "Land_ShellCrater_02_large_F", "Land_ShellCrater_02_extralarge_F", "Land_ShellCrater_02_decal_F", "Land_ShellCrater_02_debris_F", "Land_ShootingPos_Roof_01_F", "House_F", "Land_DisturbedSoil_01_decal_F", "Land_DisturbedSoil_02_decal_F", "CraterLong_02_F", "CraterLong_02_small_F", "Land_ChurchRuin_01_F", "Land_HouseChimney_Ruin_01_F", "Land_HouseRuin_Big_01_F", "Land_HouseRuin_Big_01_half_F", "Land_HouseRuin_Big_02_F", "Land_HouseRuin_Big_02_half_F", "Land_HouseRuin_Big_03_F", "Land_HouseRuin_Big_03_half_F", "Land_HouseRuin_Big_04_F", "Land_HouseRuin_Big_05_F", "Land_HouseRuin_Small_01_F", "Land_HouseRuin_Small_01_half_F", "Land_HouseRuin_Small_02_F", "Land_HouseRuin_Small_03_F", "Land_HouseRuin_Small_04_F", "Land_HouseWallRuin_Corner_01_F", "Land_HouseWallRuin_Corner_02_F", "Land_HouseWallRuin_Door_01_F", "Land_OldFactorySign_01_F", "Land_OldFactorySign_01_graffiti_F", "Land_VergePost_02_v1_F", "Land_VergePost_02_v2_F", "Land_sign_entry_en_pl_F", "Land_sign_leave_en_pl_F", "Land_Sign_noentry_big_en_pl_F", "Land_sign_noentry_small_en_pl_F", "Land_sign_uwaga_pl_1_F", "Land_sign_uwaga_pl_2_F", "Land_BrickWall_01_l_5m_d_F", "Land_BrickWall_01_l_5m_F", "Land_BrickWall_01_l_corner_F", "Land_BrickWall_01_l_pole_F", "Land_BrickWall_01_l_end_F", "Land_BrickWall_02_l_5m_d_F", "Land_BrickWall_02_l_5m_F", "Land_BrickWall_02_l_corner_v1_F", "Land_BrickWall_02_l_corner_v2_F", "Land_BrickWall_02_l_end_F", "Land_BrickWall_03_l_5m_v1_d_F", "Land_BrickWall_03_l_5m_v1_F", "Land_BrickWall_03_l_5m_v2_d_F", "Land_BrickWall_03_l_5m_v2_F", "Land_BrickWall_03_l_gate_F", "Land_BrickWall_03_l_pole_F", "Land_BrickWall_04_l_5m_d_F", "Land_BrickWall_04_l_5m_F", "Land_BrickWall_04_l_5m_old_d_F", "Land_BrickWall_04_l_5m_old_F", "Land_BrickWall_04_l_pole_F", "Land_BrickWall_04_l_pole_old_F", "Land_SilageWall_01_l_5m_F", "Land_SilageWall_01_l_pole_F", "Land_SilageWall_01_l_d_F", "Land_ConcreteWall_03_m_pole_F", "Land_ConcreteWall_03_m_2m_F", "Land_ConcreteWall_03_m_6m_F", "Land_CamoConcreteWall_01_l_4m_d_v1_F", "Land_CamoConcreteWall_01_l_4m_d_v2_F", "Land_CamoConcreteWall_01_l_4m_v1_F", "Land_CamoConcreteWall_01_l_4m_v2_F", "Land_CamoConcreteWall_01_l_end_v1_F", "Land_CamoConcreteWall_01_pole_v1_F", "Land_GameProofFence_01_l_5m_F", "Land_GameProofFence_01_l_d_F", "Land_GameProofFence_01_l_gate_F", "Land_GameProofFence_01_l_pole_F", "Land_NetFence_03_m_3m_d_F", "Land_NetFence_03_m_3m_F", "Land_NetFence_03_m_3m_hole_F", "Land_NetFence_03_m_9m_F", "Land_NetFence_03_m_3m_corner_F", "Land_NetFence_03_m_pole_F", "Land_PipeFence_03_m_gate_l_F", "Land_PipeFence_03_m_gate_r_F", "Land_PipeFence_04_m_gate_l_F", "Land_PipeFence_04_m_gate_r_F", "Land_PipeFence_05_m_gate_l_F", "Land_PipeFence_05_m_gate_r_F", "Land_PipeFence_06_m_gate_l_F", "Land_PipeFence_06_m_gate_r_F", "Land_PoleWall_02_3m_v1_F", "Land_PoleWall_02_3m_v2_F", "Land_PoleWall_02_end_F", "Land_PoleWall_03_5m_v1_F", "Land_PoleWall_03_5m_v2_F", "Land_PoleWall_03_end_F", "Land_StoneWall_02_s_10m_F", "Land_WoodenWall_03_s_5m_v1_F", "Land_WoodenWall_03_s_5m_v2_F", "Land_WoodenWall_03_s_d_5m_v1_F", "Land_WoodenWall_03_s_d_5m_v2_F", "Land_WoodenWall_03_s_gate_F", "Land_WoodenWall_03_s_pole_F", "Land_WoodenWall_03_s_d_pole_F", "Land_WoodenWall_04_s_5m_F", "Land_WoodenWall_04_s_d_5m_F", "Land_WoodenWall_04_s_end_v1_F", "Land_WoodenWall_04_s_end_v2_F", "Land_WoodenWall_04_s_gate_F", "Land_WoodenWall_04_s_pole_F", "Land_WoodenWall_05_m_4m_v1_F", "Land_WoodenWall_05_m_4m_v2_F", "Land_WoodenWall_05_m_d_4m_F", "Land_WoodenWall_05_m_end_F", "Land_WoodenWall_05_m_pole_F", "Land_Mi8_wreck_F", "Land_PowerGenerator_wreck_F", "Land_TrailerCistern_wreck_F", "Land_V3S_wreck_F"] Goggles (cfgGlasses): ["G_AirPurifyingRespirator_01_F","G_AirPurifyingRespirator_01_F","G_AirPurifyingRespirator_02_black_F","G_AirPurifyingRespirator_02_black_F","G_AirPurifyingRespirator_02_olive_F","G_AirPurifyingRespirator_02_olive_F","G_AirPurifyingRespirator_02_sand_F","G_AirPurifyingRespirator_02_sand_F","G_RegulatorMask_F","G_Blindfold_01_white_F","G_Blindfold_01_black_F"]  

Just  for say thanks you for the work :=)

You're absolutely right. My concern about binding it to T was that vehicle operators might run into the same problem when targeting vehicles, but if that gets spotting used more often, maybe that's not a bad thing.  And it makes zero difference to ground units.  So maybe I'll shift the default to T.
 
Well, the way I see it, in 2035 I am imagining that a compass is a bit out of date.  For game functionality, having it attached to every player's screen makes team play much more feasible.  Some players don't even know the compass exists.  This is all about bridging the gap between the ease of communication in real life, where I can just point to something and the guy on my left knows what I'm talking about, and in-game, where we don't even share the same context.  As for disabling the crosshair, I don't see that as being part of the same issue.  We also haven't gotten a single complaint about the crosshair being absent.
 
Most people will not do this, and again, not a single complaint about the compass.  Once you change your preference it's saved to profileNameSpace, ie., you won't have to change it again when you visit again.
 
I'd agree with this if you didn't give the user tools to change their interface.  99% of the users will not explore beyond the default settings, and thus, wouldn't know that there was a compass to turn on, etc.
 
Yeah, I have to fix that white whale.

1) picking up backpack from enemy will treat it as a weapon you dont have training for - making you only walk
please whitelist all backpacks by default, so we can take/swap from dead enemy
 
2) I like how AI is performing hunting missions for players now, but it does not work very well for VEHICLES.
today I destroyed vehicle in new AO with titan AT, being about 500m from the AO perimeter,
in about 2 minutes 2x technical rolled on me, followed by Marid, Tigris and eventually 2 MBTs
 
since I was hidden in bushes, they just threw a party, circling in very close proximity
 
Even when friendly Hitman arrived on nearby Hill and started destroying them, they ignored it completely, driving around trying to locate me
 
The "hunting" routine works ok for infantry, but needs to be tweaked for vehicles, because it makes them act rly stupid, congregating on 1 spot where they will get stuck, unless they manage to kill who they came for
- perhaps some time limit after which they return to normal patrolling pattern ?
 

It was most definitely a bug. I tried a new tactic for dealing with an exploit to get stuff out of saved loadouts, and I think the unintentional side effect was that purchased gear items were getting removed immediately.  I didn't find it in local testing as "zeus" users are exempted from gear restrictions... long story short, it's on the list.
 
 
That's not a bad idea.
 
 
So that's a classic problem.  What happened the AO spawned with 40 people on it, and then people started to disconnect because it was getting late, and now we have a fully-stocked AO full of bad guys, and half the players needed to deal with them.  Even with 20 players, between Vortex and people afk, or getting geared up, there were only ~5 players actually in the field... ouch.
 
I'm not sure what the answer is to this; I'm hesitant to try and implement something where enemy squads disappear or despawn in relation to player numbers, because that would also imply they should spawn in response to an increase in player numbers.