Just to be clear..... on FGU.

[i3ullseye]

There are still some issues on FGU, we are all aware of that. But some things have fundamentally changed. And I want to be sure that our expectations for how something works is still the same, so as to call out actual problems and not intended changes. The biggest part of this is combat automation.

Specifically..... when multiple 'enemies' surround a PC, and use an attack flagged as Melee, is the game supposed to automatically apply the correct Gang Up bonus? Or under FGU is this now an effect button we need to hit each time.

Further, is someone has an edge making them immune to said Gang Up bonus, is that coded? I tried @GangUp -4 (with and without square brackets) added as a new item under abilities, and neither prevented the Gang Up bonus when the effect button for Gang Up was clicked.

There are some who would prefer everything to be a clickable button anyway, to prevent any automation from doing something the GM might not like. But I have a feeling that isn't the intent, and these items are just broken under Unity.

[fubeca150]

The gang-up bonus has been correctly applying in my FGU games, and has correctly reduced gang up based on ally being adjacent. I'm playing SWADE, if that matters.

[Doswelk]

Just checking, you are aware of how gang bonus is calculated in SWADE is different to SWD/SWEX?

To grant gang up bonus now you cannot be threaten by an opponent, I like to think in terms of blood bowl tackle zones, if you are in a tackle zone, you do not grant a bonus.

[Lonewolf]

This gets complicated and there is of course Unity Beta to worry about. So lets beak this down into bite sized pieces and we see where it goes. One step at a time...


Specifically..... when multiple 'enemies' surround a PC, and use an attack flagged as Melee, is the game supposed to automatically apply the correct Gang Up bonus? Or under FGU is this now an effect button we need to hit each time.

Further, is someone has an edge making them immune to said Gang Up bonus, is that coded? I tried @GangUp -4 (with and without square brackets) added as a new item under abilities, and neither prevented the Gang Up bonus when the effect button for Gang Up was clicked.

There are some who would prefer everything to be a clickable button anyway, to prevent any automation from doing something the GM might not like. But I have a feeling that isn't the intent, and these items are just broken under Unity.

I have already tested this for someone else in FG classic. The reason why I use classic here is because it removes the "is this just a unity issue" part of the question. If it does not work here it is rules set issue and if it does work we looking at unity error. If that makes sense.

So in the test combat. Gang up is automatically being applied with no extra effort. The targets do have ability that counter acts the bonus. @Gang Up -1 via the Block Edge. So that covers your follow up question.


Got warn everyone here. It is 1:43 in the morning and I doing maths. This is dangerous ! :pirate:
Here is a PC and NPC soldier in the attached picture. Both have block. There get jumped by 7 Goblins and a wolf.
First Goblin gets a Joker and aces on attack. Total to hit rolled 10 + 2 = 12. Add in a gang up of + 3 and thats 15.
PC has parry of 5, +1 for the block. Cancel one from gang up.
Output is to hit 14 vs 6. Hit with raise.

Our NPC is more lucky. To hit is a 3. +3 for gang up for a total of 6.
Soldier is Parry 5, +1 for block. Cancel 1 from gang up.
Output is 5 vs 6. Block edge saves him.

YMMV. Setting it up just right takes time and there a whole new set functionality on the CT just been rolled out. So it worth it to keep checking. A single test is no proof.

36796

Next go duplicate the exactly same conditions in unity. If the answer is not the same then it is a possible bug. If the answer is the same check user errors.

Once that is solved. Try and break it again with scrum rule where automated gang should get nerfed by friendly forces standing next to you.

To test teamwork blocking flanking. We will first confirm the script in classic again as a base line. First Goblin attack is 3 vs 1. PC has block edge to drop the bonus by 1.
Second attack. An NPC runs into tackle zone and screws things up for the Goblins. Attack is now 2 v 1 and block edge nerfs that to no bonus at all.
Teamwork wins.

36811

Will fire up Unity stand by :p

Ok final edit. Run the same test in Unity. Notice that dungeon walls are casting shadows. That's unity at work and not classic.

Same routine. Goblin ambush of 3 v 1 on PC with Block edge. So we can check gang up and protection script.
First attack is 1 on the die. With + 2 gang up bonus added automatically. The Block Edge nerfs this to +1 So the total result is 2 and goblin fails to get passed parry.
Second try is again screwed up by an NPC jumping into the fight. Rolls a 2 but automatic bonus is now just 1. This is a 2 v 1 fight now. The bonus is again nerfed by block edge and the goblins get nothing but the two on the die.

36812

It is looking like myth busted on coding errors. However I am still game to test more ! If I had to guess at why it gets broken for some people. Money would be on forgeting to set up the map grid which will disable a lot of automated scripts. Including this one. It is very easy to over look this set up step.

[Dr0W]

Also, I'd like to add that gang up bonus works a bit crazy when using anything different from square grid.

I actually enjoy playing on Unity using Hex grid, turning their visibility off and turning snap to grid off, so I move my tokens in analogical directions. The problem is that Ganging Up doesn't go well with Hex, so we turn that off and simply apply that one modifier manually.

So, also make sure you're not using Hex. And I'm pretty sure it works weirdly on FGC too.

[Moon Wizard]

If you're turning off the grid visibility and grid snap anyways, why not just leave it as a square grid?

JPG

[Lonewolf]

Also in grid issues where the user does something odd.
[SavageWorlds] Gang-up is not calculated correctly in specific sized grid maps. Fix in test branch right now. v5.2.6 beta.

[Dr0W]

If you're turning off the grid visibility and grid snap anyways, why not just leave it as a square grid?

JPG

Three reasons:

The most important one being Square diagonals. While it does produce good results, sometimes it feels weird when moving diagonally and there's a spike. If somehow you move perfectly diagonally, you can change directly from 1 to 3, but usually you will move quickly almost skipping number two. So it just feels wonky, specially when you want to move your token (We are drawing arrows for measurements before moving tokens)

For Squares the tokens need to be real close. I like to consider the tokens in melee range when they are close enough. You can see in the attached picture of the same situation that Hex rules it as distance 1, whereas the square says it's distance 2.

Asthetics. Hex grids gives us this neat round effects around the tokens instead of squareish ones using squares.

So, I think it's worth giving up ganging up automation for that. It feels more natural when moving and aiming diagonally using squares.

That's not to say that I wouldn't hate if there was an implementation on FGU to play Savage Worlds (and perhaps other rulesets?) without being restrained to any kind of grid, and getting distances measured by pixels, at some point in the future :bandit:
36822

[Lonewolf]

@Dr0W that other thread report on Gang up is excellent. It appears broken in some client side actions. Bug hunt successful :D

EDIT: It is edge case with the NPC effects but it does have bearing here.

[i3ullseye]

Sorry, was away from the PC for a few days. Thanks for all this feedback. Today I am going to try hosting instead of my friend and compare my results to his. Eliminating all variables and all that. I was running Hex for a while, but going back to square grid after this feedback.