_[BUG] (BRC4) Ilegal Charge

[TheGrayMouser]

Screenshot is from FOGVB
selected Hoplite is legally allowed to charge enemy Persian A, it CANNOT legally charge B nor does FOGVB allow this.

No screenshot but same sceanrio in FOGU the Unity version will allow you to chose A or B to impact charge which is incorrect.+

[cothyso]

Can you point me to the FoG(RB) manual (or FoG TT manual) rule that says why the selected BG it is not allowed charge EBG b, please?

[TheGrayMouser]

Can you point me to the FoG(RB) manual (or FoG TT manual) rule that says why the selected BG it is not allowed charge EBG b, please?

Its likly not one rule but a combo of the TT rules etc

Basically a BG can ONLY charge fwrd and attack a enemy in its frontal arc UNLESS it can pivot
A drilled unit could change facing and move BUT cannot charge a unit in its NEW frontal arc
so...as in the pic
Since an enemy BG A is there to be charged frontally the BG cant pivot and thus cant chose which one to attack
(imagine we arnt dealing with hexes but rather free flowing terrain, the unit cant "pivot" to hit B because its left flank would, in the arc of the pivot, hit A FIRST anyhow...)

[cothyso]

fixed in revision 686

// modified GP.bgGetEnemyBGImpactList() to prevent charging of EBGs outside BG's turn phase start FA

the rule was there, "// GAMEPLAY RULE - [Combat][Charge][Pursuit]: unless pursuing, a BG can not charge an enemy BG from outside its own front arc" but the code was only testing for the charge hex to be in BG's FA, not for the charged EBG too.

[cothyso]

Actually, after completing the fix, and doing some more tests, it seems that the FoG(RB) behavior is actually more (and unnecessary) complicated: if EBG A would not be there, you actually could charge the EBG B, even if it is outside charging BG's FA..

in these conditions, letting a BG charge any EBG, as long as the hex on which it ends is inside his own FA, might seem a better way to deal with this.

[Blathergut]

This (as long as you end in your forward arc) sounds a lot easier/simpler. Why not try this?

[cothyso]

It is already implemented as so in bRC4 (to charge an EBG, the final charge hex must be inside BG's FA)

[TheGrayMouser]

It is already implemented as so in bRC4 (to charge an EBG, the final charge hex must be inside BG's FA)

Uhh I really suggest not changing this unless some serious playtesting is done as I believe it was done that way for a reason

basically you are giving players way to much unhistorical control of which bg they get to attack, way too much maneuverability Basically if you really MUST attack BG B you need to change facing (taking a turn) and then charging the next turn.....


Never mind, I reread your posts and I think you mean you are changing it back to the way it is in FOGVB?

[cothyso]

you've re-read my post wrongly, I was referring to Blathergut's suggestion as to why not try it like that (charge only requirement to be the final charge hex to be situated in BG's turn phase start FA)..

anyway, in the mean time, I've added some more code, and a new rule "// GAMEPLAY RULE - [Combat][Charge][Pursuit]: unless pursuing, a BG can not charge an outside its own front arc enemy BG, unless the charged EBG is neighbor with BG's FA, and the charged hex doesn't have any insideFA EBG neighbors"

modified in revision 686

// modified GP.bgGetEnemyBGImpactList() to prevent charging of EBGs outside BG's turn phase start FA, unless the charged EBG is neighbor with BG's FA, and the charged hex doesn't have any insideFA EBG neighbors

Though, this is at least questionable.. I am not seeing this as giving too much freedom. In battle, when a unit was ordered to do something, even if dangerous, like turning against an enemy unit and opening its own flank by doing so, most of the units would do it, at least in a regular trained army (ie no barbarians).. They must not stand it too long, but they would do it nevertheless..

And turning and waiting another turn to do the charge won't change the result situation at all (as the BG will still charge an EBG, leaving its own flank open to the charge of the secondary EBG which "prevented" the charge in the previous turn)..

[TheGrayMouser]

Actually, after completing the fix, and doing some more tests, it seems that the FoG(RB) behavior is actually more (and unnecessary) complicated: if EBG A would not be there, you actually could charge the EBG B, even if it is outside charging BG's FA..

in these conditions, letting a BG charge any EBG, as long as the hex on which it ends is inside his own FA, might seem a better way to deal with this.

Dan, after playing some games in the current build , I highly believe this routine should be changed back to the way it was in FOG VB as it currently gives the attacker way to much choice and control and leads to gamey advantages. Heck, even the screenie I took illustrates that as I have the choice in the unity version to impact the Persian B on the flank I would ALWAYS do so to avoid the 2 missle Dice which would be denied as Im hitting the BG B in the flank. You would never impact the unit actually in your frontal arc(in this case Persian A).

Not withstanding the specific example up above, but what if Persian B was fragged or a light foot? Even more reason to never charge A if you have the choice. Too much control imho.

I noticed this a lot in the OOF L lists where so many infantry units have LF or MF bow support. Its a lot easier to crack a line of spears with this option.

Would RBS or Bates be able to comment on this? I realize without Hexwar to explain why things were done it is difficult to understand if this was just a programming thing or if there was a real gameplay reason to do so. In this instance I think it was done on purpose to match up to the TT rules, as best as could be, considering going from a free form terrain, BG's with actual frontage and depth, to a hex based one...

As is in Unity currently, units are approaching the freedom of impact/"attack" like they have in Panzer General! ( a game I love BTW, but its not right for an ancients game)

[cothyso]

anyway, in the mean time, I've added some more code, and a new rule "// GAMEPLAY RULE - [Combat][Charge][Pursuit]: unless pursuing, a BG can not charge an outside its own front arc enemy BG, unless the charged EBG is neighbor with BG's FA, and the charged hex doesn't have any insideFA EBG neighbors"

modified in revision 686

// modified GP.bgGetEnemyBGImpactList() to prevent charging of EBGs outside BG's turn phase start FA, unless the charged EBG is neighbor with BG's FA, and the charged hex doesn't have any insideFA EBG neighbors

Though, this is at least questionable.. I am not seeing this as giving too much freedom. In battle, when a unit was ordered to do something, even if dangerous, like turning against an enemy unit and opening its own flank by doing so, most of the units would do it, at least in a regular trained army (ie no barbarians).. They must not stand it too long, but they would do it nevertheless..

And turning and waiting another turn to do the charge won't change the result situation at all (as the BG will still charge an EBG, leaving its own flank open to the charge of the secondary EBG which "prevented" the charge in the previous turn)..

I do not understand your point. It was already implemented exactly like in the old FoG(RB) (so EBG b can not be charged) back from revision 686 (now we're at 818), even if I find it quesionable still..

[TheGrayMouser]

LOL, my bad, BUT a few posts back you did say you were going to leave IT! Also I swear I saw the behavior in a current MP game but likely I am wrong Perception is > than reality haha.

[cothyso]

check it then, you might have seen a bug related with it.

[cothyso]

Checked it and found some problems: it was possible to force the charge of an not chargeable EBG using the state switch detector LALT key (even if the not chargeable EBG was not displaying its combat sword UI indicator).

modified for revision 823

// fixed a problem in GP.bgGetEBGImpactList() causing some BGs to be added more than once
// added GP.hGetEBGImpactList() and GP.hGetEBGImpact() methods
// modified GP.bgMPathComputeEBG() and GMonHex.MouseOver() BG movement end code section to use the new GP.hGetEBGImpact() instead of GP.hGetAdjacentEBG()