GAC Join and Leave

"BobcatSkywalker;c-2064850" wrote:

"Rath_Tarr;c-2064845" wrote:

"AvatarofCynicism;c-2064822" wrote:

"Vos_Landeck;c-2064799" wrote:
This has already been asked and answered numerous times. There are a few threads asking about this probably every week that GAC is active. From the last Dev Q&A:


The change was made because mods were not locking and people were able to swap mods during GAC rounds, effectively putting their best speed mods on all teams they used on offense. That was a much bigger problem than a few people not paying attention when they "join" the GAC and having to fight 3 rounds without an extra gear tier on 1 toon.

I don't think this is entirely right.... There were two issues I thought.

1) you could swap mods on offensive characters after roster lock via loadouts

2) the system would lock each roster individually when the cutoff time hit, meaning that one account would be locked "first" and one account would be locked "last". Apparently there was enough time elapsed between the first and last account that some people were swapping mods after lock, but the swapped mods were inadvertently captured.

They fixed the loadout issue first. Then some people were still having trouble with missing/poor mods on their teams, so they changed roster lock to the join button instead of a standard time for everyone (presumably to keep too many locks happening at once so mod swapping after lock wouldn't affect mods).

This. People are conflating the two issues.

Idk if that's true... they fixed the roster lock initially to avoid the mod swapping work around.

Then you could still use loadouts to swap mods after the fix so they again changed the roster lock again this time to be complete and upon initial registration.

The "roster lock failure" was actually a problem with the client user interface flows where if you navigated from the squad assembly screen to the squad management screen and selected a pre-canned squad, you got a copy of the current state of those toons not the locked state. It didn't matter on defense because once you sent the squad composition to the server, it used the locked roster copies. On offense however, the client dumbly used the current copies.

The mod swap during matchmaking bug was about CG apparently implementing the roster lock and matchmaking together as a single-pass batch job, creating opportunities for problems if people shifted mods around after they thought the rosters had locked but before matchmaking was complete.

"Rath_Tarr;c-2064856" wrote:

"BobcatSkywalker;c-2064850" wrote:

"Rath_Tarr;c-2064845" wrote:

"AvatarofCynicism;c-2064822" wrote:

"Vos_Landeck;c-2064799" wrote:
This has already been asked and answered numerous times. There are a few threads asking about this probably every week that GAC is active. From the last Dev Q&A:


The change was made because mods were not locking and people were able to swap mods during GAC rounds, effectively putting their best speed mods on all teams they used on offense. That was a much bigger problem than a few people not paying attention when they "join" the GAC and having to fight 3 rounds without an extra gear tier on 1 toon.

I don't think this is entirely right.... There were two issues I thought.

1) you could swap mods on offensive characters after roster lock via loadouts

2) the system would lock each roster individually when the cutoff time hit, meaning that one account would be locked "first" and one account would be locked "last". Apparently there was enough time elapsed between the first and last account that some people were swapping mods after lock, but the swapped mods were inadvertently captured.

They fixed the loadout issue first. Then some people were still having trouble with missing/poor mods on their teams, so they changed roster lock to the join button instead of a standard time for everyone (presumably to keep too many locks happening at once so mod swapping after lock wouldn't affect mods).

This. People are conflating the two issues.

Idk if that's true... they fixed the roster lock initially to avoid the mod swapping work around.

Then you could still use loadouts to swap mods after the fix so they again changed the roster lock again this time to be complete and upon initial registration.

The "roster lock failure" was actually a problem with the client user interface flows where if you navigated from the squad assembly screen to the squad management screen and selected a pre-canned squad, you got a copy of the current state of those toons not the locked state. It didn't matter on defense because once you sent the squad composition to the server, it used the locked roster copies. On offense however, the client dumbly used the current copies.

The mod swap during matchmaking bug was about CG apparently implementing the roster lock and matchmaking together as a single-pass batch job, creating opportunities for problems if people shifted mods around after they thought the rosters had locked but before matchmaking was complete.

Your second paragraph was a fix to address the bug in your first paragraph where people can re use mods on offense.

"BobcatSkywalker;c-2064876" wrote:

"Rath_Tarr;c-2064856" wrote:

"BobcatSkywalker;c-2064850" wrote:

"Rath_Tarr;c-2064845" wrote:

"AvatarofCynicism;c-2064822" wrote:

"Vos_Landeck;c-2064799" wrote:
This has already been asked and answered numerous times. There are a few threads asking about this probably every week that GAC is active. From the last Dev Q&A:


The change was made because mods were not locking and people were able to swap mods during GAC rounds, effectively putting their best speed mods on all teams they used on offense. That was a much bigger problem than a few people not paying attention when they "join" the GAC and having to fight 3 rounds without an extra gear tier on 1 toon.

I don't think this is entirely right.... There were two issues I thought.

1) you could swap mods on offensive characters after roster lock via loadouts

2) the system would lock each roster individually when the cutoff time hit, meaning that one account would be locked "first" and one account would be locked "last". Apparently there was enough time elapsed between the first and last account that some people were swapping mods after lock, but the swapped mods were inadvertently captured.

They fixed the loadout issue first. Then some people were still having trouble with missing/poor mods on their teams, so they changed roster lock to the join button instead of a standard time for everyone (presumably to keep too many locks happening at once so mod swapping after lock wouldn't affect mods).

This. People are conflating the two issues.

Idk if that's true... they fixed the roster lock initially to avoid the mod swapping work around.

Then you could still use loadouts to swap mods after the fix so they again changed the roster lock again this time to be complete and upon initial registration.

The "roster lock failure" was actually a problem with the client user interface flows where if you navigated from the squad assembly screen to the squad management screen and selected a pre-canned squad, you got a copy of the current state of those toons not the locked state. It didn't matter on defense because once you sent the squad composition to the server, it used the locked roster copies. On offense however, the client dumbly used the current copies.

The mod swap during matchmaking bug was about CG apparently implementing the roster lock and matchmaking together as a single-pass batch job, creating opportunities for problems if people shifted mods around after they thought the rosters had locked but before matchmaking was complete.

Your second paragraph was a fix to address the bug in your first paragraph where people can re use mods on offense.

No, the problem in the first paragraph was fixed in an earlier update.

The problem in the second paragraph manifested as people missing mods / having them on the wrong toons because they had been moving them around after they believed that the GA rosters had been locked. It would not allow for mod re-use.

Frankly the whole thing was a confusing mess with a lot of misinformation & misconceptions flying around.

Or maybe just maybe when you hit the join button it just adds you into the GAC. Then after the time runs out it locks your roaster... Kinda like the text in game describing how it works.

"Debuff;c-2066143" wrote:
Or maybe just maybe when you hit the join button it just adds you into the GAC. Then after the time runs out it locks your roaster... Kinda like the text in game describing how it works.

Or maybe just maybe when you hit the join button it just asks you for confirmation. Just one more window...one more click.

And removal of the ‘countdown to Lock’ would be a nice 2nd step considering it’s completely false.

They did the leave / join button in tw.
So I think it is possible to reproduce the exact same behaviour in gac?

"CosmicJ;c-2066146" wrote:
Join/Leave is obviously the ideal but if this can't be implemented easily, then they should just add a confirm button after you hit the join button.

"Are you sure you want to join the GAC?"

Then if you fat finger twice, thats on you. ;)

This. Jfc, how hard is it to program a confirm prompt?

"CosmicJ;c-2066146" wrote:
Join/Leave is obviously the ideal but if this can't be implemented easily, then they should just add a confirm button after you hit the join button.

"Are you sure you want to join the GAC?"

Then if you fat finger twice, thats on you. ;)

This! Absolutely this!

Just add a confirmation when hit the GAC join button.

"Are you sure you wish to join GAC now?"

This would save us a lot of headache.

I've just accidentally joined GAC with no mods on some of my most important characters.... I've effectively wrecked my chances at success this round.

Please CG, please listen to us on this.

At least they should have programmed a CONFIRMATION QUESTION:
Are you sure to want to JOIN with the current status of your Roster?
As the JOIN button accidentally hit by dozens of players (as devices screen is very sensitive nowadays).
Really unfair to let people lose valuable resources due to that.
Kyle

Just seen that I replicated the latest post :)