Final Rule on Withdrawal

[Max 86]

Guys,

I am almost finished with updating the manual and wanted to clarify the dreaded withdrawal rule. Current in the manual is this,

"Any unit in a Withdrawal Posture MUST withdraw (W/D) during the Withdrawal Phase. (Exception: Withdrawing units with no enemy units adjacent are never forced to withdraw.) A Withdrawal is a move from an EZOC hex into a Non-EZOC hex.
Withdrawal occurs in two ways:
• A unit may be forced to Withdraw as a result of combat.
• A unit that adopted a Withdrawal Posture during the Movement Phase must W/D during the Withdrawal Phase (unless accepted as above).
A defensive unit that adopted a Withdrawal Posture during the Assault Designation Phase must withdraw during the Withdrawal Phase.
During the Withdrawal Phase, the Phasing Player always withdraws their units first.
Withdrawing units are given no more than 15 MPs with which to carry out their withdrawals. Depending on a unit’s Disruption Level, it may be forced to spend all 15 MPs or any number up to 15MPs. A withdrawing unit may always move one hex, regardless of the MPs required to enter that hex.
Any opposing unit in an Attack Posture adjacent to a hex vacated during the Withdrawal Phase may advance into that hex. Such a unit is known in these rules as an Advancing Unit.
Withdrawing units never have to spend additional MPs for exiting an EZOC. During their Withdrawal, however, a withdrawing unit may not enter an EZOC. If a unit cannot withdraw due to the presence of EZOCs or enemy units, it takes a Withdrawal Check, assumes a Defensive Posture, and remains in place. It loses any previous Fort Levels.
At the end of a Withdrawal, a withdrawing unit automatically assumes an Attack Posture.

Any unit that must withdraw will be highlighted. Select a highlighted unit and its withdrawal path and final withdrawal hexes will be displayed. The unit must end its withdrawal in one of the green hexes. The red hexes show the rout it must take to reach a green hex. The Player can either withdraw the unit one hex at a time, or withdraw the unit at once by clicking on a green hex. (If no green hex is displayed for a withdrawing unit, then it must withdraw until it has 0 MPs remaining. In this case, it may end its withdrawal in a red hex, so long as it has no MPs remaining.) Units that must withdraw have a dashed highlight. The currently selected withdrawing unit has a solid highlight. The Player can select and de-select units by clicking on them. (Keep in mind that the act of withdrawing may cause further disruption and physical damage. The game will inform you of this at the beginning of the Withdrawal Phase.) To end a unit’s withdrawal prior to the unit expending all MPs (when its withdrawal ends automatically), click “Finished Withdrawing” to go to the next withdrawing unit (if any)."

How much of this is still valid? What else needs to be said regarding W/Ds?

Thanks

[Fred98]

The rules have not changed

"A withdrawing unit may always move one hex, regardless of the MPs required to enter that hex. "-


That makes it clear it has not been working properly

-

[Wolfe1759]

My understanding of the Withdrawal rules as written in the manual after many readings and re-readings is that when a unit is in a withdrawal posture either through being placed in a withdrawal posture as an order or through combat results it then MUST and WILL withdraw, the ONLY exceptions to this is if a unit is totally surrounded by enemy units or EZOCs in which case it takes a withdrawal check, suffers the results and is put in a defensive posture or if in the withdrawal phase it is not adjacent to an enemy unit then the withdrawal is cancelled. The ONLY effect of the passing or failing of a withdrawal attempt is the additional Disruption, Hits or potential Elimination that the withdrawing unit suffers or avoids.

If this worked as written then I think we would probably solve all the problems with D4 units standing to the last man, attackers not being able to make breakthroughs and Advance after combat etc.

[sabre1]

Seeeee, I told all you guys, that withdrawal was munged, but NOOOOOO, you wouldn't listen to me. [:'(][;)][:D]

[Obsolete]

(Exception: Withdrawing units with no enemy units adjacent are never forced to withdraw.)

I'm not sure this is the way to look at it. IIRC a unit next to you that's at D4 because it's so badly mauled up, isn't going to exert a ZoC, and if your unit is not in an E-ZoC then you are by no means forced to withdraw, even if you had chosen to do so before hand. I don't have a problem with the original statement, though I can see players assuming that if a unit is adjacent to theirs, then they are forced to withdraw, which is NOT ALWAYS the case.

Alright, I guess this means another case of investigation & scenario testing for me to officially prove it one way or another again  

I may return at 6 am with my analysis...

[PirateJock]

Alright, I guess this means another case of investigation & scenario testing for me to officially prove it one way or another again

I've also been having another look at how withdrawals occur. I've been running a test map with controlled situations and it seems to work the way I'd expect it to - with withdrawals happened as planned. What I'm having problems with is why in some games it doesn't appear to do the same thing ... and annoyingly I can't replicate it! I will preserver! ... well until I get bored anyway.

Cheers

[Fred98]

ORIGINAL: Joe 98

"A withdrawing unit may always move one hex, regardless of the MPs required to enter that hex. "-


That makes it clear it has not been working properly

And with Beta 1.02 withdrawl is still not working.

-

[sabre1]

^ Yep...

[PirateJock]

Think I might have tracked down what could be preventing withdrawals. As expected it's to do with presence of blocking units. Looks like their EZoC is more than the adjacent hex in some instances ...

[PirateJock]

Done some more testing, trying to think of ways of overiding the withdrawal blocking. Unfortunately had no success! What I've tried is:

• Putting units between the unit I want to withdraw and the blocker - no good
• Increasing disruption of blocking unit - no good
• Getting blocker to take direct fire - no good

So *really* need Michael to come back and confirm if this is working as intended OR it's a bug.

Cheers

[Obsolete]

Thanks Pirate, I will forward the issue to Michael. In the meantime, I did do some of my own testing on some E-ZoC issues, and ran into an issue that also seems to be a bit off to me. Basically, place more than one allied unit to an Axis, and tell them all to withdraw during the movement phase. So far, it seems everything retreats as expected, until you finish withdrawing the SECOND LAST unit. At that point, the engine thinks withdrawal phase is 100% complete, and I get a message stating that the (second last unit to be moved) is no longer in E-ZoC.

Why the last unit to be  removed from the enemy counter ends up being pinned there I have a SUSPICION is a glitch, but again we'll have Michael take a look at it.



And on a side-note, I realized that despite there is an option in the editor to set up tanks as a FLAIL tank, I don't ever recollect in any of the official manuals what exactly entails a flail tank (though I think I can guess ). I will probably do some more investigation on those as well to be 100% sure.

[MichaelCooney]

I'm still here, checking for any munginess.

I don't know if this will help or confuse things further, but let me explain the withdraws from the code's perspective.  Here's the algorithm:

     - Each unit is checked at the start of the Withdraw Phase.  If it's in Withdraw posture, then a "withdrawing" flag is checked.
     - For each unit marked withdrawing, the game checks if it's in an EZOC.  If not, the withdrawing flag is cleared (back to Attack posture).  These are the criteria for a unit NOT exerting a ZOC into another unit's hex:
          - Unit is from the same side/army
          - Unit is not adjacent
          - Unit is in Travel posture
          - Unit has a disruption of 3 or greater
          - Unit is dispersed
          - Unit must be able to move into the hex otherwise (so wheeled units don't exert a ZOC over a river)
     - Withdraw Check takes place, which can result in hits or added disruption.  Fort Levels are removed.
     - Minimum and Maximum Withdraw Movement Points are assigned
     - The "Movement Grid" is established, which blocks all hexes containing enemy units and their ZOCs.
     - A withdrawing unit is then selected and the allowed movement is highlighted.  These criteria will block a hex for withdraw movement:
          - Movement Grid shows it as an enemy hex or ZOC.
          - Unit cannot physically move into/over that terrain (normal movement rules)
          - Stacking rules would be violated
          - The new hex is not further from the enemy than the old hex
     - After all the potential movement hexes are mapped out, a check is made to see if the unit can fully withdraw (green hexes).  If not, another Withdraw Check is made (more potential withdraw and/or hits).

That pretty much covers it. 

So what jumps out at me is the "The new hex is not further from the enemy than the old hex".  Looking at the "should have withdrawn but didn't" example above, the unit can only move south to get out of the EZOCs, where it is two hexes from the nearest enemy.  From there, it can only move Southwest or South, but both of these are also two hexes from the enemy, so these would both be invalid hexes according to the code.  That would prevent a full withdraw, which would prevent any withdraw.

I assume that that one test scenario is repeatable?  I'll try to test this theory out tonight (can't at the moment).  If that's the problem, it's an easy(ish) fix.  The check is in there to prevent units from basically circling an enemy to burn their required withdraw movement points, but if the only option is to parallel enemy units (given the limitations of hexes) then I would think it should be allowed.

[PirateJock]

Hi Michael

Thanks for the response ... very useful information on withdrawal.

Reading through the criteria that blocks a hex for withdrawal, the one about new hex is not further from the enemy certainly looks a likely candidate. On the test scenario the lack of withdrawal is every time, so repeatable. Additionally you need to move the blocking unit a long way south before the withdraw is allowed. I've uploaded the scenario to my Google site - here - if you want to give it a go.

Cheers

[PirateJock]

Basically, place more than one allied unit to an Axis, and tell them all to withdraw during the movement phase. So far, it seems everything retreats as expected, until you finish withdrawing the SECOND LAST unit. At that point, the engine thinks withdrawal phase is 100% complete, and I get a message stating that the (second last unit to be moved) is no longer in E-ZoC.

I've tried this on my test map - getting 3 Axis units on a single hex and putting all in Withdraw posture ... all of them withdraw [&:]

Could you upload your test scenario to see if I can replicate it?

Cheers

Edit - just thought was the unit left behind undisrupted? Would that have any effect on whether the withdrawal occurs?

[Obsolete]

Ahah! I was going to test the Stack method because I figured there was a small chance stacks may actually work. In any case, I just went and re-confirmed that. Yes, sure enough it seems that when moving the last unit in a STACK there is no problem. But when units are scattered AROUND an enemy in single-unit stacks then the issue seems to appear.

[Obsolete]

A picture is worth a thousand words... so:

Notice how my Infantry #7, is the last that should be able to withdraw, but instead I don't get the option to move it, and it just gets stuck where it is. I'm not so sure the text panel is making 100% sense either here.

[Max 86]

Is this going to be looked at? Revised/fixed in upcoming patch?

[PirateJock]

Hope so [:)]

Cheers

[Obsolete]

ORIGINAL: Max 86

Is this going to be looked at? Revised/fixed in upcoming patch?

Of course it will, it has, and is coming.

Michael is pretty damn good in what he does and still never fails to impress me.

Now, usually I try to tell people not to quote me on stuff because I want to be 100% correct, and at the same time I try to prevent quoting emails because I never know when someone feels I am publicly invading their privacy but in this case I think I can give a snippet of a snippet in one of my replies from Mr. Cooney [sic]:

Absolutely brilliant illustration of this error. It was something I never would have found in code just by looking at it. Here's the snippet:

int f = ActiveUnit;
if (field.GridHexCanMoveTo(hex.x,hex.y) || field.GridHexCanInfiltrateTo(hex.x,hex.y))
{
MovementHandler(pDC, hex);
SetUnitStats(ActiveUnit);
if (a[f]->CurrMovement() == 0)
{ .... end phase ....}

It turned out that MovementHandler was assigning ActiveUnit the value of the next withdrawing unit, but I was still using 'f' to see if there was any movement left. So you're right - the last unit was being skipping due to this. Actually, it may be that only one unit would ever withdraw, now that I'm thinking about it.

Anyways, got it fixed. I'll check the other "hex further away" logic, check for anything else people don't like and then kick out a 1.03 patch.

...

[PirateJock]

Thanks for the update ... and BIG thanks to you and Michael for working on this [:)]

Cheers