End Game MP Mode - Feedback

[das attorney 858]

I liked the new variable download speed when obtaining intel.

Really fast paced mission - little bit of desync when we were going back to the offroad but I think that was Arma being Arma and not the mission :)

[runekn 3]

Good session.

Don't know if it was only me, but it seemed that spawn point names were given out randomly.

[das attorney 858]

Yeah the spawns seem a bit random, would be less chaotic if it was on the leader only or squad vehicle or something. I ended up being able to spawn anywhere (which you could abuse).

[millhauz 11]

Good session.

Don't know if it was only me, but it seemed that spawn point names were given out randomly.

Respawn is still WIP for this mod. Currently not working asi it should.

[Griff762 10]

This was my first time playing ARMA 3 multiplayer as there is a lack of causal game modes to play. This afternoon was loads of fun even for a newb like myself! A few more modes that are easy to pick up and get into without hours of walking about and getting lost on Altis would be great.

[Jona33 51]

Just had a game of this as well as my first ever game of actual MP (despite having had the game for well over a year), first impressions are very good. Even with only four of us (all on the same side) it was still relatively interesting, having the AI enemy is a nice move, means you can have fun even on small servers. Interested to see how this turns out.

[L3TUC3 32]

I played with about 8 players and it devolved into a pretty terrible spawn/die loop when you keep spawning on teammates. It's a good idea to restrict it when there's enemies nearby.

[galzohar 31]

Is there any documentation for how to use the group management system in other missions?

In which patch is the group management system supposed to hit main branch?

Some features that would be necessary to allow most game modes to transition to this system:

1. Allow leader to promote a new group leader. Fix bugs related to poor propagation of group leader changes across the network (make "who is group leader" properly synchronized in MP without needing additional scripts to do so).

2. Allow naming of groups.

3. Allow locking and unlocking a group (is that the "private" checkbox? If it is, it's not a very good name for it).

4. Allow not only recruiting friends into the group, but also have others able to request joining your group in case it is locked ("private"?).

5. Allow enabling and disabling the option to open up the interface easily with a script (and when disabled, if it is open, it will be immediately closed).

6. Allow kicking players from your group.

7. Allow assigning fire teams (either through the menu or by commanding and setting team colors) and visualize it in the interface.

8. [Engine] Make it so while squad leader is waiting for respawn, nobody else becomes a temporary squad leader, so that he cannot mess up the group management. Only promote replacement squad leader upon squad leader death in missions with no respawns.

[Electricleash 133]

With regards to the respawn issue; Instead of players spawing on the group leader, maybe he can choose to place down a 'RALLY POINT' (RP), marked by a cluster of rucksacks and an ammo box or something.

Similar to the way the respawn backpacks work for longer games with the tent and the sleeping bag.

[Jona33 51]

Anyone else having an issue where they can't select any slot? Get into the server fine but then clicking on a slot does nothing, the only reference I can find to the bug is from the alpha days.

[royaltyinexile 175]

Is there any documentation for how to use the group management system in other missions?

Not currently. Since we've released the system in an early state, we wouldn't expect to publish any documentation until it's in a more 'final' version. Although it can be used in any given scenario, right now, we only really 'support' the system via this specific MP mode.

In which patch is the group management system supposed to hit main branch?

It will hit main branch with Marksmen DLC; we hope by this time it will be in a better state for reuse by content creators. However, depending on how things go, its modular nature may not be fully fleshed out - it's a scripted prototype of functionality we'd look to support in engine as we move towards the expansion, which means there will be certain accepted limitations in the short term.

1. Allow leader to promote a new group leader. Fix bugs related to poor propagation of group leader changes across the network (make "who is group leader" properly synchronized in MP without needing additional scripts to do so).

2. Allow naming of groups.

3. Allow locking and unlocking a group (is that the "private" checkbox? If it is, it's not a very good name for it).

4. Allow not only recruiting friends into the group, but also have others able to request joining your group in case it is locked ("private"?).

6. Allow kicking players from your group.

All of these features are part of the current implementation, although, of course, we see room for improvement on several aspects. Did you find the time to try the system yet? It would be great to get some feedback on how these things are performing compared to your expectations.

Of those not there, handing respawn more effectively is in particular something we'd like to do. The first step will come with the planned introduction of the Revive scripted proof-of-concept and, again, more low-level stuff in the longer term.

Best,

RiE

[ussmarines 18]

Sorry Wrong topic, too much work xD

ussmarines

Edited March 15, 2015 by ussmarines

[Healbeam 10]

The gamemode is quite fun, although, for my taste, a bit too fast-paced. From my experience, you had to rush to the FOB, then rush to the intel, then rush to the schematics, then rush to the... uh... ending... location... thingy.

Whilst it shows that ArmA 3 can in fact be fast-paced (something I was actually quite surprised about), I didn't really like this approach. Maybe you can keep the pacing, but move the objectives closer to each other instead of the whole area of Kavala?

I really like the concept of a Coop-Mission gradually shifting to a PvP mission. However, I was really disapointed with the execution of the initial phase of establishing the FOB. At least on BLUFOR (Never played on OPFOR), you literally just run over a hill, shoot a couple of guys and... get an FOB? Uh, okay? I'd have preferred if the Coop-aspect was more pronounced, with a lot more enemies, but also a bigger reward upon actually establishing the FOB, such as a large weapon cache like there is in the intel locations.

But again, I really enjoyed the gamemode, a lot more than KOTH, Wasteland and similar missions. It's a fantastic concept.

[superxpdude 1]

One thing I think might help the ending stage of the mission is to have it so that it takes time for someone to upload the schematics. As it stands right now, you can rush in with a vehicle, hop out, and upload the intel in less than 5 seconds. This way it gives the enemy team a chance to disrupt the upload and secure the schematics for themselves.

Other than that it's a fantastic gamemode. Really fun to play once you can get some people online.

[royaltyinexile 175]

The gamemode is quite fun, although, for my taste, a bit too fast-paced. From my experience, you had to rush to the FOB, then rush to the intel, then rush to the schematics, then rush to the... uh... ending... location... thingy.

Thanks a lot for the feedback, Healbeam, and sorry for having to kick you out of my group - I think there was a bug with Dynamic Groups! Will try to repro on Monday (you were 'in my group', but not under my squad command, or group chats scope).

Whilst it shows that ArmA 3 can in fact be fast-paced (something I was actually quite surprised about), I didn't really like this approach. Maybe you can keep the pacing, but move the objectives closer to each other instead of the whole area of Kavala?

Actually, in later iterations of the mode, we thought it might be interesting to experiment with moving the objectives further away. As it stands, although there is an innate pace to the mode, with proper co-op play, it does reward intelligent planning (divide into squad, plan and assign objectives, and react to the enemy movement) - perhaps just not enough to count.

Without changing any of the logic of the mission, it should be possible to achieve more strategic gameplay by fiddling with the distances and means of transport alone. A larger scale will not be to everyone's taste, of course, but, once some of the basic gameplay is locked down (better handling of download and carrier mechanics), it should be fairly simple to create different variants that cater to players that want to plan and coordinate more.

I really like the concept of a Coop-Mission gradually shifting to a PvP mission. However, I was really disapointed with the execution of the initial phase of establishing the FOB.

I agree. Again, not to make excuses, but we've been focused on developing the mid and end game mechanics. The basic function of phase one is to group players together around one simple objective, offering some immediate action, before opening the scale up with multiple intel tasks. As it stands, I agree, it's a bit unsatisfying and lends itself to simple rush tactics.

We've tossed around the idea of making Phase 1 more like a very small sector control. Imagine one small-ish location, with sectors A B and C. To establish the FOB, the side should assault and secure each sector (optimally, by forming teams (dynamic groups) and tackling objectives in parallel (shared objectives)). It's also something like a small training / orientation stage (particularly with the planned introduction of scripted revive mechanics) before the scale ramps up in Phase 2.

However, since we're focusing on some other areas for now - and since it would mean having to change at least BLUFOR's start point - we're planning to come back to it later, if possible. The guys are also focused upon the MP systems themselves, trying to make sure they fit for re-use in community missions more generally (see an above post for those notes), so we don't want to over-burden them too much!

One thing I think might help the ending stage of the mission is to have it so that it takes time for someone to upload the schematics.

Yes, I believe Neo was working on this quite recently. Perhaps he'll be able to update you guys with the current plan!

Best,

RiE

Edited March 15, 2015 by RoyaltyinExile

[Sterlingarcherz101 15]

Royal I have not played it but will do today.

So this idea may be useless. But what about having a weapons storage for both sides.

Then have convoy missions. one side needs to guard its convoy, the other plan and execute a convoy ambush.

Both teams something to gain or lose.

Maybe have Intel situations where an Intel objective gives away the location of one sides assets or next objective location. Forcing one side to destroy this Intel the other to capture it. Leading a further battle dowb the line if the Intel falls into wrong hands.

[komalt 10]

With regards to the respawn issue; Instead of players spawing on the group leader, maybe he can choose to place down a 'RALLY POINT' (RP), marked by a cluster of rucksacks and an ammo box or something.

Similar to the way the respawn backpacks work for longer games with the tent and the sleeping bag.

I like this, I think this is the best idea suggested to fix re-spawning in this thread. Allow multiple rally points that must be spaced out a certain distance so that spawn camping doesn't become a problem if someone finds it.

[bad benson 1733]

I like this, I think this is the best idea suggested to fix re-spawning in this thread. Allow multiple rally points that must be spaced out a certain distance so that spawn camping doesn't become a problem if someone finds it.

if you find it you should be able to destroy it. or maybe it could even self destruct invalidating itself. could also be an interesting mechanic so it can't be placed it territory with too many enemies nearby.

[Sterlingarcherz101 15]

Not really the mission flaw. But playing today one of the ai I shot him at point blank range. Emptied 2 clips in his face nothing, 2 frags by him nothing, he was clearly getting impacted by the bullets, eventually another few shots in his face he died.

Mission is kinda fun when you get good teamwork going. Still manages to get clusterfuck and all over the place with current spawning. But believe that already being looked at.

Needs more variations in tasks get Intel get Intel upload download.

[2nd ranger 282]

Since there is an objective to get intel from dead officers, does this mean there will be intelligence inventory objects again (documents, photos, etc)? It would benefit the game as a whole to have such things, rather than the kind of hacky action menu solution that is currently the only option for 'get intel from the dead guy' without using addons.

[galzohar 31]

It will hit main branch with Marksmen DLC; we hope by this time it will be in a better state for reuse by content creators. However, depending on how things go, its modular nature may not be fully fleshed out - it's a scripted prototype of functionality we'd look to support in engine as we move towards the expansion, which means there will be certain accepted limitations in the short term.

All of these features are part of the current implementation, although, of course, we see room for improvement on several aspects. Did you find the time to try the system yet? It would be great to get some feedback on how these things are performing compared to your expectations.

I wanted to perhaps prepare my missions to make use of this system in advance. Since we don't actually play on the dev branch it would be difficult to put to the true test (let the simple user who doesn't know how it works try to use it and see what happens). Of course, at least some basic example and useful function API will be needed to make some kind of use of it. In any case, I doubt any of our regular players that play in our events would be attracted to the new game mode, as our players are mostly either really hating to play against the AI, or play against AI way too much elsewhere and come to our events for the pure PvP action.

Some more questions:

Were any engine changes made to support the new group management system? Bug fixes? Group handling tweaks? Or is it currently 100% script? I ask because I found some issues with the engine in how it handles groups that I had to add dirty scripted work arounds (which I've later noticed were done by other mission/mod makers in a similar fashion to avoid same issues), and also that I need to know if any existing group scripts may break with the patch.

Is the plan to eventually do the group management in engine instead of the scripted solution? The only real benefit I can see for having it in engine is to work around and/or fix the current issues with scripted group management.

As for respawns, getting it right in PvP is really tough. I solved it by making a mission with no respawns and make it short-duration round-based, and tweak a lot of stuff to get that to work. TacBF tried to do a lot of tweaking to get respawn working but in the end it still gets pretty dirty pretty fast when players who know what they're doing are playing (spawn camping and knowing how to spawn much closer to the objectives than the less-informed opponents). Some missions (like EUTW) just let you spawn right next to combat in a lot of situations, giving more action but with the cost of losing a lot of potential tactical play (since spawning as fast as possible and running back in as quickly as possible is the most effective strategy 99% of the time, similar but less severe than what you see in TacBF).

Basically, as long as you have respawns, you will have the "who can get faster from respawn to combat" race along with the "by the time I regrouped with my squad, they died, and by the time they regrouped with me, I died, so we never got to play together" issues. Getting to play together with your squad will generally slow you down way too much resulting in a loss against a team who doesn't do the same.

[zozo 104]

Hello,

Were any engine changes made to support the new group management system? Bug fixes? Group handling tweaks? Or is it currently 100% script?

Now, the system is purely scripted. The purpose is to have the system easy-to-modify. We are able to react more easily to the players' requests. If is it in engine, we cannot simply change it without affecting other stuff (i.e. backwards compatibility is the issue). Once we are sure the system does fit our and your requirements we will start to implement it into the engine. Perhaps, we will need do some changes/fixes to the current groups handling.

Thus, no public documentation so far. It will come once the system is hardwired.

[galzohar 31]

I've had quite a few issues with group management scripts that use the simple existing joinSilent and selectLeader commands. Nothing fancy, just actions that execute said commands with the appropriate parameters.

So far the main issues I've had with group management which required dirty work around tricks were:

- Deleting of empty groups is difficult, but is necessary due to the maximum group count limit and overall trash cleaning. This is rather tricky since locality of groups is rather unpredictable, and non-local group seem to be impossible to delete. Deleting an empty group on a client seems to also cause issues (some players end up not seeing some of the groups correctly).

- Synchronization of group leader across the network - Sometimes change of group leader is not synchronized, some will see one leader while others see another.

Some more issues I haven't resolved:

- On rare occasions, player will join a group but some will still see him as if he's not in the group, while others and himself will see him as being in the group.

- Locking groups on server-side while handling scripts that rely on groups to not change. For example, iterating over all groups will usually cause unexpected behavior if a player switches groups during the script's execution. For example, a loop that assigns each player in each group to a seat in the group's vehicle - It will break if between assigning group 1 to assigning group 2, a player just happened to switch from group 2 to group 1 - He will not be assigned any vehicle seat!

I'll post again if I come up with any additional issues I've encountered that are impossible/difficult to work around with scripting.

[eriktrak 76]

Royal I have not played it but will do today.

So this idea may be useless. But what about having a weapons storage for both sides.

Then have convoy missions. one side needs to guard its convoy, the other plan and execute a convoy ambush.

Both teams something to gain or lose.

Maybe have Intel situations where an Intel objective gives away the location of one sides assets or next objective location. Forcing one side to destroy this Intel the other to capture it. Leading a further battle dowb the line if the Intel falls into wrong hands.

I like the idea to have more different types of intel missions like convoy guarding-convoy ambush, rescue operation, MEDEVAC etc.

This type of MP mode is really fun. Never knows when a fight against AI turns into a PvP. Congrats for the developers!

[neokika 62]

I've had quite a few issues with group management scripts that use the simple existing joinSilent and selectLeader commands. Nothing fancy, just actions that execute said commands with the appropriate parameters.

So far the main issues I've had with group management which required dirty work around tricks were:

- Deleting of empty groups is difficult, but is necessary due to the maximum group count limit and overall trash cleaning. This is rather tricky since locality of groups is rather unpredictable, and non-local group seem to be impossible to delete. Deleting an empty group on a client seems to also cause issues (some players end up not seeing some of the groups correctly).

- Synchronization of group leader across the network - Sometimes change of group leader is not synchronized, some will see one leader while others see another.

Some more issues I haven't resolved:

- On rare occasions, player will join a group but some will still see him as if he's not in the group, while others and himself will see him as being in the group.

- Locking groups on server-side while handling scripts that rely on groups to not change. For example, iterating over all groups will usually cause unexpected behavior if a player switches groups during the script's execution. For example, a loop that assigns each player in each group to a seat in the group's vehicle - It will break if between assigning group 1 to assigning group 2, a player just happened to switch from group 2 to group 1 - He will not be assigned any vehicle seat!

I'll post again if I come up with any additional issues I've encountered that are impossible/difficult to work around with scripting.

These notes are great, thanks a lot for this piece of feedback!

I would strongly discourage jumping to our early version right away, the current version of Dynamic Groups is not yet considered stable or close to feature complete. Much may change/be added.

With that out of the way, expect proper documentation on how it works and how to use it when a more stable version becomes available. At that point we will make a public announcement somewhere on the forums.

The basic intent for the current version of Dynamic Groups was to make sure clients have no authority over the actual groups data, and only the server.

So the clients only send certain requests to the server, then server just validates each request, modifies the data and synchronizes the data with everyone connected.

So, because groups are only created, deleted, managed in the server, the behavior should be accurate for every connected client.

For example, the selectLeader command seems to be reliable where the group is local, so I make sure of that in the following line:

// Set the new leader has the actual group instance leader, must be executed where group is local
[[_groupInstance, _newLeader], "selectLeader", _groupInstance, false] call BIS_fnc_mp;

While we haven't found any of the issues you've just reported to have come across with, it doesn't mean they don't exist.

Check BIS_fnc_dynamicGroups for more info.

Again, thanks for your great feedback. ;)