Jump to content

Zipper5

Former Developer
  • Content Count

    5418
  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by Zipper5


  1. If you choose first aid kit only, will the medic still be able to revive using his med kit?

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

     

    Does that mean that only units with unit trait medic can revive, or every unit with Medikit? The first one would make more sense.

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

    • Like 6

  2. 86Z8Kqk.jpg 8GESG5P.jpg

     

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

    • Like 21

  3. even just making the revive bleed out time much longer could help a lot since then you wouldn't respawn as much. but the current setup just makes no sense. the short time and the infinite respawn totally negates the need for revive at all. should be a no brainer. not trying to sound condescending. i just want this to happen quickly so i can finally go play it before no one is hosting it anymore.

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

    • Like 7

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

    • Like 15

  5. However, if you decide to quit for the day and continue tomorrow you'd have to start the mission a new with the respawn system (unless there's an in-mission progress tracking, not that I've noticed it).

    with the save game system you could pick off from where you left, and in some extreme cases like the ones you've mentioned you'd be forced to restart the mission (which is again, no worse than what the respawn system offers).

     

    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.

    • Like 2

  6. Zipper5, I'm quite interested why is dedicated server support is so important for a coop campaign?

    I find it hard to imagine dedicated servers are going to run 4 player missions, not to mention the entire campaign design is to host a client-server even when you play in singleplayer so friends can join you.

     

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

     

    As for the other point about saves being shared between MP and SP, didn't you already solve that by forcing the coop campaign into MP mode only?

    Enabling saves would also allow for players to fail a mission by dying without forcing them to replay the entire mission.

     

    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.

    • Like 1

  7. 1. will progress be saved on the profile so you can continue another time? basically which of the missions from that apex protocol lobby are completed. not mission internal progress. if not, that would be a must imho. otherwise you always need to play the entire thing to reach where you left off. that would be ridiculous.

    would be great, if the missions you choose from are based on the hosts saved progress. which of the missions he/she has completed while being the host and also as a client before. pretty much liek any other coop game.

     

    2. what exactly is being scaled? enemy numbers or only skills?

     

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

    • Like 3

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

    1. How do we handle respawn?
    2. 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. :)

    • Like 14

  9. 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.


  10. Is there any plan to add animations to the revive system

    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.

    Yes, please add the ability, to limit revive to medics only.
    Having made a few publicly published missions where originally the medic was the only class capable of reviving players I can tell you that one of the most common pieces of feedback I received was that these scenarios made the medic into a proverbial golden goose and gameplay was hampered in instances where either the medic was incapacitated or was unable to perform their role effectively.

    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.

    Also, I have activated the system now, but on mission start, every player spawns in the sea. Is there any way around this? I tried to set respawnPosition modules and also a marker names "respawn_west".

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


  11. Can anyone elaborate on how this revive system works in-game?

    Does it simply freeze "dead" players in a downed state until help arrives?

    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.

    ... are there plans to potentially limit this to Medics only? Or anyone with a medical kit?

    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.

    Additionally are there plans to have this implemented into a module in the editor that a mission creator can place and customise to some degree via module options?

    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.


  12. what's the config.cpp for?

    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.

    Though I still hope Zipper throws in a few words on my problem on the first page.

    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:

    1. Take your addon folder and add a world name to the end, as if it were a mission. e.g. IP_CMP_MERCS.Altis
    2. Move the folder to your Editor missions folder, typically found at C:\Users\<your user>\Documents\Arma 3 Other Profiles\<your profile>\missions
    3. 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
    4. Select Save As. In the drop-down menu, select Export to single missions and hit OK
    5. Now navigate to your Arma 3 Missions folder, typically located at C:\Program Files (x86)\Steam\SteamApps\common\Arma 3\Missions
    6. You should see your packed addon sitting there waiting for you. In this case, it'll be IP_CMP_MERCS.Altis.pbo
    7. 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.


  13. I've heard from others that hardcoded file paths refering to the "Campaigns" dir are different in the addon version. Is that correct?

    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:

    1. Find what: \Campaigns\IP_CMP_MERCS\
    2. Replace with: IP_CMP_MERCS\IP_CMP_MERCS\
    3. 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.


  14. 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.


  15. Just to put this out there, suppressors don't seem to slow down bullets anymore in devbranch.

    Just putting that out there.

    Yep.

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


  16. To date , from BIS we have Zero, none nada.

    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.


  17. 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.


  18. Losing squadmates in Survive is almost never a consequence of the player's actions as he is not the squad leader. It is unfair, and frustrating for most, to punish them in the next mission because their squadmates couldn't take care of themselves. Plus, each mission was designed to provide the best experience with a set number of people in the player's squad, something that is vital when it is many players' first contact with the game.

    However, you will notice if you look at your team as you progress, that squadmates who die are never with you again. You don't have fewer people in your squad, but they are different people. This includes your squad leader as well, which is made more obvious if you hover over your squad's marker on the map and see who's leading you after your squad leader died.

×