Zipper5

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. :)

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! :)

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. :)

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.