Zipper5

Hey everyone. :) Thanks to your feedback, we've recently published a few changes to the Development Branch targeted specifically at improving the management of difficulty settings for "Apex Protocol", the co-operative campaign we released as part of Apex. These new difficulty options focus on 2 key areas: Respawn and Revive. Lobby Leaders can choose from a range of options for each setting, which will be applied for all clients and carry over between sessions. These settings are as follows: Respawn: Always - Players will always be able to respawn after being killed. Limited - A maximum of 3 Respawn Tickets are shared between all players. Tickets are awarded by completing Tasks. Disabled - Upon death, players will only be permitted to spectate those who are still alive. Revive: Always - Everyone can revive each other with no limitations. First Aid Kit - Reviving a player requires a First Aid Kit, which will be consumed upon their revival. Medic Only - Only units with a Medikit can revive. Disabled - Revive will be disabled entirely. As such, we've made changes to both the Campaign Lobby and Respawn Menu (pictured above) to support these changes. Though fully functional, their presentation is still work-in-progress. For now, we would like to ask you to focus specifically on balance; at any point during your session, does the mission feel too difficult? Or, alternatively, too easy? If so, please send us your feedback. We'd like to ask you to include the mission(s) you were playing and your chosen settings in your post, so that we can better narrow-down the problem and focus on any potential improvements. We are currently targeting the upcoming 1.64 Update for the deployment of these improvements to the default branch. Thanks! :)

Yes. The presence of the Medikit in the Paramedic's inventory means that, so long as he keeps it, any First Aid Kit he has on his person will not be consumed upon reviving someone. :) From a purely technical perspective, every unit that has a Medikit will be considered a "medic" when playing with this setting. However, from a practical perspective, the only class that has a Medikit on them is the Paramedic class. Since player corpses are deleted when they respawn, the only way for a unit other than a Paramedic to get a Medikit is if they manage to loot his body in the period between his death and respawn, or if the Paramedic gives it away for whatever reason. At this point in time, we're satisfied with either of these situations being possible. In fact, if there is enough co-ordination between players to be naturally sharing their Medikits, we consider that to be a cool example of co-operative gameplay. :)

In fact, thanks to your guys' reports, we discovered that Revive was incorrectly configured. The default bleed out time was set to 20 seconds instead of 2 minutes. This should be fixed in the next patch. As always, thanks for your guys' diligence. :)

Just to reassure you all that we're still listening, a lot of you have made some very good arguments. While I can't say for sure what will or won't change at this stage, I can say that work does not stop at Apex's launch. When there are changes and improvements made in future, you'll be the first to hear about them. You guys taking the time to test the campaign in its work-in-progress state on devbranch means a lot to us, so please keep the feedback coming. :)

Actually, I agree with your point about having to restart the mission from the beginning if you simply took a break, for example. This is an area where the lack of saving hurts. :( However, the intention is indeed for the campaign to be completed in a single playsession. Looking at the feedback so far from here and elsewhere, it seems some people have been lightning fast at burning through them. Faster than we expected in some cases. Again, though it's far from perfect, we hope that the shorter missions help mitigate the impact of saving being disabled for the vast majority of the players. I personally regret that it doesn't turn out that way for everyone, nonetheless.

We've always had a problem with what we call "Content Discoverability" in Arma 3. A large portion of our playerbase pre-Apex appeared to not even know Arma 3 had official content. Part of this was definitely due to the fact that all 3 episodes of The East Wind came out after Arma 3 launched, and most of the singleplayer Showcase missions existed in the Alpha and Beta. For Apex, we took a long, hard look at other reasons for this, coming to a few conclusions. These conclusions included: the UI and UX of the Main Menu did not draw players towards official content, there was far too little official multiplayer content, and there were no official servers. That's where the new Main Menu, Apex Protocol itself, and our official servers have come from, respectively. As part of this initiative, we intend to host Apex Protocol on our official servers for players to join as they please, playing with people they know and/or people they don't. This is why Dedicated Server support was important to us this time around. It's not so much that the design focused around players joining your server; rather, it was focused around players joining you. You should be able to play Apex Protocol on any server you please and your friends should be able to join you. :) This is where the other points I mentioned factor in. You're right, the sharing of saves between the different environments doesn't matter so much at this stage. :) However, all the other flaws in the design still stand: Clients, i.e. everyone if played on a Dedicated Server, have no indication that the server is in the process of saving. The game is entirely paused as saving occurs, which means clients are given the impression that they're having network troubles or the server crashed. This misconception was quite often the case in Arma 2 when a host would save. Saves are only stored on the server, meaning they'd be quite a hassle to access unless you have your own private Dedicated Server. Not much of a hassle for a server hosted on a player's machine, but it would still always require that player to host each time you wanted to resume from where you left off, which is not great. Referring back to my point about working within confines, we had to determine our priorities when considering which systems to overhaul and which to leave as they are. Though it's personally disappointing to me that we couldn't tackle the saving issue for Apex, I concede that it is a task best reserved for a full fledged game, less so an expansion.

Actually, all missions are available right from the start. Though I strongly recommend playing them in order, you're free to start anywhere you like. This post by Silxnl on Reddit (warning: potential spoilers) includes a screenshot that illustrates this quite nicely, if you haven't had a chance to check it out for yourself just yet. The scaling is quite complex. Pretty much every engagement in the campaign handles it individually, though there are instances where a general balancing framework has been applied. In some instances, the accuracy of the enemy is adjusted on the fly, triggered by players connecting and disconnecting. In others, units are spawned and deleted as the mission progresses based upon the player count at the time these parts of the missions begin. Nonetheless, if you point us in the direction of a particular engagement or mission that feels wrong, we'll be able to isolate it. :)

Hi everyone. :) I'd like to start by saying thanks to you all for your feedback so far. Believe me, we're watching and we're listening. As zozo wrote in his original post, we're still hard at work on Apex Protocol, even with only a few days left to go. It seems that there's already a few topics of discussion popping up which I'd like to try my hand at addressing. Respawn vs. Saving In the early stages of development we made the decision that Apex Protocol would only be playable, from a purely technical standpoint, in a "multiplayer environment." What we mean by that is: even when you're playing alone, you're playing on a server of some kind. If you click the "PLAY IN SINGLEPLAYER" button, a LAN server is automatically created, which you're then connected to and the chosen mission is launched. We made this choice first and foremost because it allows friends to join you while the mission is in progress, something we want to strongly encourage in Apex Protocol. To a lesser (but still important) extent, it also allows us to focus on maintaining one version of all systems, mechanics and missions, rather than both singleplayer and multiplayer variants like we did before (which always led to both versions facing unfortunate compromises that negatively impacted the quality of the final product). However, you can see how this led us to 2 interesting questions: How do we handle respawn? Do we want a save system? We've overhauled various systems on the Road to Apex but, as it is an expansion to Arma 3, we still had to work within certain confines and adhere to some existing standards. Using the multiplayer version of the Firing From Vehicles showcase as an example of our existing co-op missions, we made it so players can respawn on their group leader or at specific respawn locations unlocked as the mission progresses. Both feedback from the community and internal feedback revealed that it wasn't clear to many players how respawning on group leaders worked, often leading to confusion and players becoming chaotically spread out and disorganized. Along with the improvements to the Respawn Menu, we made the decision that Apex Protocol would allow respawning on all players while maintaining the mechanic of respawn positions unlocking as players progressed. So far, we feel that players understand the system significantly better thus keeping them together and co-operating with each other. Nonetheless, some of you have already reported areas where respawn positions are perhaps unlocking too soon. We'll get right on those. :) However, we had to approach the question of saving differently. Apex Protocol is designed to be finished in a single playsession and, although it depends on your playstyle :D , each mission tends to be a little shorter. Going back to the Firing From Vehicles example, the mission simply failed when all players were dead at the same time. Though Apex Protocol is a co-op campaign, we did not want to lock out players who choose to play alone; that's where the decision was made to introduce scaling based on player count, something we've not really tried to do before. But it also introduced an interesting conflict with failing the missions when all players are dead, as that would mean a solo player would fail the mission each time they were killed. They wouldn't have a chance to call a friend for help, and they'd have to play through the whole mission again. This was indeed the case in Firing From Vehicles, and we felt this was definitely not how we wanted to facilitate solo play in Apex Protocol. Some of you have rightly addressed that Arma 2 had a multiplayer saving mechanic for Harvest Red, Operation Arrowhead and Operation Black Gauntlet (Arma 2: PMC's 2-player co-op campaign). I mentioned before that we have had to work within some existing confines, so it came naturally that we evaluated this existing system right at the start of development. While there were many reasons why this solution was far from optimal - saves were shared between both SP and MP (which still causes issues in Arma 2 to this day), clients could not see when a mission was saving, only the server had access to the save files, etc. - what ultimately made us decide not to use it was it lacked design for use on Dedicated Servers, and understandably so; all of Arma 2's MP campaigns could only be hosted on a player's machine with the host forced to occupy a specific player slot, typically the main character (e.g. Cooper in Harvest Red). While forcing the host into a slot is far from ideal in itself, we knew from the very beginning that Apex Protocol had to be playable on Dedicated Servers in order to get it out there, to the masses, and for it to support our new Quick Play feature. This was the nail in the coffin for re-using Arma 2's multiplayer saving. In the end, we hope that the support for players joining in progress, combined with respawn, the overhauled Respawn Menu, the Revive mechanic, the dynamic difficulty scaling based on player count, and the somewhat shorter length of the missions help to mitigate the impact that a lack of saving has on each player's experience. :) However, we do understand that it isn't perfect, especially for solo play. Solo Play and the "Commanding Question" On first glance, it may seem logical that unoccupied player slots would simply be filled with AI subordinates in Apex Protocol, with you as their commander. Admittedly, this is how the vast majority of our previous official attempts at multiplayer content have handled it, and was definitely where we started from. However, we are no stranger to both the impressive strengths and unfortunate weaknesses of our Commanding system and AI. These are perhaps the most commonly criticized aspects of the Arma franchise, aside from performance and controls. While they are no doubt capable of feats perhaps considered impossible in other games, it's sometimes difficult for many players to look past their weaknesses. Early on in Apex's development we decided to focus all our energy on players co-operating with each other, and have Commanding sit this one out this time. This did, however, open us up to a new design conflict: how do we minimize the impact that (a potential minimum of) 1 player has on the plausibility of them being deployed on a super important mission, as a member of an elite special forces group? In fact, this is where Riker, Grimm, Salvo and Truck came from; we decided to have our story follow 1 squad - CTRG Group 15, callsign "Raider" - with the squad leader (Riker) and his immediate subordinates (Grimm, Salvo and Truck) making up 1 fireteam (Raider 1), and the player(s) making up the other (Raider 2). Along the way, we definitely discovered areas where this approach wasn't entirely perfect (how do we keep Raider 1 from doing all the work for the players, for example?) but, although there are indeed lessons to be learned, we feel this was a good decision overall. In some solo play instances I can indeed see how it might feel like 1 person against the world, but this is where the scaling depending on player count should come in. I'd like to thank everyone who has already reported specific areas where this doesn't quite seem to be working as intended at the moment, and I'd encourage everyone to continue letting us know about any instances where missions feel too difficult and/or unbalanced. I hope this answers some of your questions, while clearing up where we've come from and where we're planning to take Apex Protocol. Believe me, there's still some work ahead of us. Thanks again for your feedback and support. :)

Frequently Asked Questions About ARMA 2 Patches If you have anything you wish to add to or change about this FAQ, feel free to post it below and it'll be modified accordingly. What patch do I need? That depends on which version of ARMA 2 you have. Thankfully you have a one-stop shop for all your ARMA 2 patching needs, which you can find HERE. Each available patch is listed there, as well as descriptions of what they do and what versions they are for. Keep in mind that the patch for ARMA 2: Operation Arrowhead is the same for ARMA 2: Combined Operations. I have ARMA 2: Combined Operations, but I only see patches for ARMA 2 and ARMA 2: Operation Arrowhead. Do I need to install both? No, you only need to install the patch for ARMA 2: Operation Arrowhead as it includes the patch for ARMA 2 in it. How can I tell if my DLCs are up-to-date? For the time-being, there are 3 ways you can do this: Check the date that the latest patch for the DLC was released, as well as the last date one of your DLC PBOs was modified. If the date it was modified is before the release of the patch, then you need to update. Download the latest patch, which you can find HERE, for the DLC and see if it wants to update. If not, then it is up-to-date. Check the changelog of the latest patch for the DLC and check for the same changes in-game with DLC additions. If they aren't there, then you need to update. I hear there is a public beta patch testing process? Yes! Beta patches are released regularly on the beta patch portal, which can be found HERE. Keep in mind that these are beta patches, so don't be surprised if you run into some issues when using them, but if you want to have the newest possible publicly available version of your game, then using the beta patches is the way to go. Note that each new beta patch released from now on will require ARMA 2: Operation Arrowhead or ARMA 2: Combined Operations. When I install a beta patch, I get an error when I try to launch the game, and the game does not start. When using beta patches you must change your shortcut to point towards the beta exe, and you must also make it run the beta patch folder as a mod. The target line of your shortcut has to include something similar to this: "C:\Program Files\Bohemia Interactive\ArmA 2\Expansion\beta\arma2oa.exe" -mod=Expansion\beta;Expansion\beta\expansion How can I know when a new patch is released? Keep an eye on these forums for all news on new patches. If you are looking for the latest beta patches, keep an eye on THIS section of the forum, as a new thread will be made for each new beta patch, and/or regularly check the beta patch portal. Textures on some units are low quality, no matter what my texture settings are! This is because of the DLC Lite policy. To ensure multiplayer compatibility with the release of DLC for ARMA 2: Operation Arrowhead, a Lite version of each DLC pack is included in the official patches so that you can play with people who own the full DLC. This Lite package of the DLC restricts the resolution of the textures, the quality of the sounds, and the length of any missions included, but only to content which would otherwise come with owning the DLCs. Previous final patches have slightly increased the quality of these Lite packages, so you can expect this to be a reoccurring change! What should I do if my version is on Steam? Steam should automatically update your version of the game to the latest final patch. However, you can still install and use the latest beta patches which you can get from the beta patch portal located HERE. You will now have to launch the game by going to the folder where the Steam version of the game is installed, which you can find within ...\Steam\steamapps\common, and use the new exe located in the folder ...\Expansion\beta. See the above beta patch section, and adjust your shortcut accordingly. I'm sure I have the latest final patch, but many vanilla multiplayer servers show up as having a different version than me. I'm not running any unofficial mods either, so what is the problem? This is typically due to the aforementioned beta patch process. If you are running, for example, v1.57 Final of ARMA 2: Operation Arrowhead and the server you are trying to join shows up as having a different version, so long as the server is not running, for example, v1.58, you should be able to join it with minimal issues. If you want to eliminate this problem all together, then visit the beta patch portal HERE and download and install the latest beta patch.

I recommend you take a look at two of my posts located here and here. We hope to get some official documentation up in the future. :) Edit: Seems Jona33 beat me to the punch.

It is currently tied to the whether "HUD show group" is enabled in your Difficulty settings. :)

To quickly add it to your mission, add the following lines to your mission's description.ext file: respawn = 3; respawnDelay = 15; respawnTemplates[] = {"Revive", "MenuPosition"}; respawnOnStart = -1; Now, for more in-depth information, I recommend you check out the post I made here. Hope that helps. :)

I'm sorry that you had to experience this. We discovered that there was the off-chance that one or both of the friendly AI squads would prioritize engaging enemies left in the town over boarding the extraction helicopter. This is why you faced it but OMAC and others, for example, did not. It has already been fixed in preparation for the next update but, unfortunately, the update itself isn't out yet. Once it is out, however, I hope you can give the mission another go.

We decided that affording the player the ability to instantly interrupt the revive process is one of the highest priorities of the system. This is why, currently, the player does not play any animation while they are reviving a unit. We are looking at different possibilities for improvement in this area. Correct, this is one of the main reasons we decided to go this route. To ensure our desired experience for the majority of players when they use this official revive system in future, we feel that this design is most consistent with our vision. As such, our current plan is to let players mod the system themselves should they want to limit it to just medics, for example. However, our objective is also to provide mission makers with a stable, unified revive system and provide incentives for them to use it in their own content, so we do believe that it has to support a certain level of flexibility to cover an appropriate range of potential uses. This is most likely because you need to also define respawnOnStart=-1; in your mission's description.ext, as this is the only mode currently guaranteed to work. I do wish to throw out the disclaimer again that the system is currently only guaranteed to work in End Game. ;)

Officially, you can try it out for yourself in End Game. Unofficially, you can look above for how it's enabled in missions, though do keep in mind the earlier disclaimer that the current state of the system is only guaranteed to work flawlessly in End Game. Players enter an incapacitated state instead of dying, where they can turn their heads but are otherwise immobilized. From here, they can choose to force their respawn or bleed out over time. Damage dealt to the unit is also subtracted from their "blood level" while they bleed out. Meanwhile, non-incapacitated players see an icon hovering over the incapacitated unit, and can move to revive them should they choose to. As a player approaches an incapacitated unit, a prompt to press Space will appear on-screen and the icon will be supplemented with "REVIVE" in white text. While the player holds Space, a progress bar fills for the duration of the revive, pausing the incapacitated unit's "bleeding" (damage is still subtracted). The incapacitated unit is also told who is reviving them. Should a player die while incapacitated, they will see the regular respawn screen. Units carrying Medikits (Medics/Combat Life Savers have them by default) currently receive a significant buff to their revive time, indicated via special revive icons and a symbol next to the progress bar as they revive someone. We chose not to limit the ability to revive to a specific unit or unit type as we felt that everyone having the ability is the best way for the mechanic to organically foster teamwork among any group of players, with a special emphasis on those operating in smaller groups/squads. However, we still want to encourage role specialization, hence the aforementioned Medikit buff. The system will operate like the other Respawn Templates, allowing for different (controlled) combinations. It is currently fully compatible with the MenuPosition and MenuInventory templates. However, there are already ways to customize some aspects of the system via parameters in your mission's description.ext file. They are as follows: reviveDelay - The time it takes to revive an incapacitated unit (default: 6 seconds). Having a Medikit will halve this time. reviveForceRespawnDelay - The time it takes for an incapacitated unit to force their respawn (default: 3 seconds). reviveBleedOutDelay - The time it takes for a unit to bleed out (default: 2 minutes). You can also prevent a unit from ever becoming incapacitated by executing: _unit setVariable ["BIS_revive_disableRevive", true, true] Replacing _unit with the variable assigned to the affected unit. With this variable, they will go straight to the respawn menu when killed.

Shit, man, when are you just gonna let that go? ;) Thanks for helping out with the test.

The config.cpp file tells the game to treat the folder as an addon. This alternate method of missions and campaigns is also referred to as "the addon format" for this very reason. I made a test campaign using your config.cpp and description.ext and it worked fine on my end, so I believe your problem is not in either of those files. It could be something going wrong when you pack the folder. May I ask what tool you're using? Personally, for you guys, I'd recommend that you use what I call "The Editor Trick" for packing files. It works as follows: Take your addon folder and add a world name to the end, as if it were a mission. e.g. IP_CMP_MERCS.Altis Move the folder to your Editor missions folder, typically found at C:\Users\<your user>\Documents\Arma 3 Other Profiles\<your profile>\missions Load the "mission" in the Editor. You will get a warning about the file being read-only, but that's because there's no mission.sqm. You can ignore this Select Save As. In the drop-down menu, select Export to single missions and hit OK Now navigate to your Arma 3 Missions folder, typically located at C:\Program Files (x86)\Steam\SteamApps\common\Arma 3\Missions You should see your packed addon sitting there waiting for you. In this case, it'll be IP_CMP_MERCS.Altis.pbo Remove the world name from the PBO's name, e.g. IP_CMP_MERCS.pbo Essentially, you trick the game into thinking it's packing a mission, and it packs it for you. I've been using it since OFP. :) Try packing it this way and see if that fixes your problem.

That is, unfortunately, correct. I imagine you're currently using "\Campaigns\<your campaign>\" to refer to your campaign's directory? This will no longer be usable when you convert it to the addon format. However, fixing it should be very simple, by way of Notepad++ and Replace All. I took the liberty of checking your MERCS campaign, as I presume that's where your worry is. You're using "\Campaigns\IP_CMP_MERCS\" every time you refer to your campaign's directory. This helps a lot, as that means no variation, which means it's very simple to use Notepad++'s Replace All function. When moving your campaign to the addon format, you'll have to define a class called CfgPatches within your addon's config (config.cpp, to be precise). This will tell the game how you want your addon to merge with all the other content. Inside CfgPatches, you define a class that refers to the addon's directory. Just like "\Campaigns\<your campaign>\" refers to the campaign's directory, "<your addon directory>\" will refer to the addon's directory. You might be able to see where I'm going with this already. So I'd recommend you define the addon directory in CfgPatches as IP_CMP_MERCS. It's nice and unique, so it's very unlikely conflicts will ever arise from it. Then you'll just want to launch Notepadd++, hit Search > Find in Files... and define the search criteria as such: Find what: \Campaigns\IP_CMP_MERCS\ Replace with: IP_CMP_MERCS\IP_CMP_MERCS\ Directory: <path to the root folder of your campaign> In theory, that should replace every instance as required. The replacement path might seem a bit weird, but this is because this is the easiest method. You'll just have move your entire campaign folder as it exists into the root of the new addon folder, in the same location as the config file. As such, if you keep the same file structure as your current campaign, everything should then work as desired. We actually intend to release an example campaign in the addon format sometime soon. If you find this a bit too confusing right now, I'd recommend you take a look at the example campaign when it's available. It should hopefully make things clearer.

That was the solution to disabling Arma 2's dynamic conversation system. However, that is no longer present in Arma 3, so this code will have no effect. For Arma 3, I recommend using the command enableSentences. This disables all dynamic radio protocol, in 3D and 2D space, letting only conversations play. However, I believe it will disable messages sent through sideChat/groupChat/etc. as well, so you'll want to look at using kbTell instead.

We are not using dead body cleanup scripts, especially not in this one. I made it.

The development branch is the development branch. You are given a warning about possible issues with it on each loading screen when using it. You are free to cry foul if/when it appears in the default branch. :)

This is incorrect. In the game right now, there are the following official MP missions: COOP 07 Headhunters COOP 08 Combined Arms COOP 10 Escape from Stratis COOP 10 Escape from Altis COOP 10 Tanks DEFEND 10 Defend Kamino DEFEND 10 Defend Syrta SEIZE 10 Seize Edoris SEIZE 10 Seize Feres And it's no secret that we have been hinting towards an upcoming multiplayer reveal of some kind.

After a quick investigation, the issue was caused by the introduction of a problem in the logic of the function handling the quotations you see at the start of the mission, and was actually affecting all missions. This has been fixed and will be in the next development branch update. However, this issue is only present if you are subscribed to the development branch. It is not a problem in default branch.

No, as of Arma 3, this applies to Regular difficulty as well. I'll investigate to see if there's actually a problem on the mission's end, but it's strange that it's only appearing now.

Unlimited saves as a difficulty option are disabled by default on Regular difficulty and above. If you want unlimited saves, please make sure this difficulty option is enabled.