Modified for rev1032 (v2.5.00.1032 GM2 build)
see
_[BUG] rev818 bRC6u03 [Gameplay] Rout & evade problems
_[NAB] rev881 bRC7 [Gameplay] Evade at map edge
_[BUG] rev881 bRC7 [Gameplay] Odd evade behaviour
[FDB] rev977 [Gameplay] Evaders movement path
_[BUG] rev 991 GC3b [Gameplay] Disappearing unit in melee
[FDB] rev ?!! [Gameplay] Routing units
[FDB] rev 1030 [Gameplay] Rout and Evade behavior
Moderators: Slitherine Core, FoG PC Moderator, NewRoSoft
-
ianiow
- Lieutenant Colonel - Fw 190A
- Posts: 1198
- Joined: Fri Apr 27, 2007 11:24 am
- Location: Isle of Wight, UK
Re: [FDB] rev 1030 [Gameplay] Rout and Evade behavior
Sorry Dan, but evade paths still don't follow a logical direction when being attacked from oblique angles. Skirmishers between two enemy lines should primarily evade behind their friendly front line, not horizontally between the opposing lines.
Also, the speed of combat is still 10 times faster than I am comfortable with.
Sorry to be a grumpy old g#t but I really do want your new Fog2 to be as awesome as possible
Keep up the good work!
Also, the speed of combat is still 10 times faster than I am comfortable with.
Sorry to be a grumpy old g#t but I really do want your new Fog2 to be as awesome as possible
Keep up the good work!
Re: [FDB] rev 1030 [Gameplay] Rout and Evade behavior
Sorry mate, but I think you might be mistaken.
FoG(RB) evade (and initial rout, immediately after routing) was set as one of the paths allowing the furthest movement from all enemy BGs possible. This is plainly wrong, from a lot of reasons:
- the rules actually specify that the evading/routing unit is moving as far away as possible from the attacking enemy BG, not from all enemy BGs
- the code was taking into consideration all enemy BGs, including the ones from under FoW, or camps, for example
- historically speaking, units skirmishing between closing battlelines were moving to escape towards the edges, not through their own units (which would even repel them see Zama for example) - well, unless special empty space would have been reserved between main battleline's units exactly for this (again see Zama)
FoG(U) modified evading/routing code will have the evading/routing BG moving as fast and as far away from the attacking enemy unit in the opposite direction of that attack.
The previous code was computing an exact opposite direction (meaning that a Front Left (FL) attack would have caused an evade/rout towards the Back Right (BR) direction), resulting in units evading at an angle (BR/BL) from he main battleline, and in the inability of these units in having too much of a choice regarding empty/friendly occupied hexes.
The current iteration of the code is computing a general opposite direction, ie a FL/FR attack will result in a Back while a BL/BR attack will result in a Front evade/rout direction. OF course, R -> L and L -> R was also valid for both variants. This results in proper from-battleline evade/rout directions.
PS: the gameplay speed code was (again and hopefully for the last time) modified in the latest rev 1034. you might want to check it out, mate
FoG(RB) evade (and initial rout, immediately after routing) was set as one of the paths allowing the furthest movement from all enemy BGs possible. This is plainly wrong, from a lot of reasons:
- the rules actually specify that the evading/routing unit is moving as far away as possible from the attacking enemy BG, not from all enemy BGs
- the code was taking into consideration all enemy BGs, including the ones from under FoW, or camps, for example
- historically speaking, units skirmishing between closing battlelines were moving to escape towards the edges, not through their own units (which would even repel them see Zama for example) - well, unless special empty space would have been reserved between main battleline's units exactly for this (again see Zama)
FoG(U) modified evading/routing code will have the evading/routing BG moving as fast and as far away from the attacking enemy unit in the opposite direction of that attack.
The previous code was computing an exact opposite direction (meaning that a Front Left (FL) attack would have caused an evade/rout towards the Back Right (BR) direction), resulting in units evading at an angle (BR/BL) from he main battleline, and in the inability of these units in having too much of a choice regarding empty/friendly occupied hexes.
The current iteration of the code is computing a general opposite direction, ie a FL/FR attack will result in a Back while a BL/BR attack will result in a Front evade/rout direction. OF course, R -> L and L -> R was also valid for both variants. This results in proper from-battleline evade/rout directions.
PS: the gameplay speed code was (again and hopefully for the last time) modified in the latest rev 1034. you might want to check it out, mate