From Facebook posted here at Si's request.
The basis of the question is whether a Supporting File which has enemy within 1BW to its front can charge those enemy, and indeed if it is of a troop type subject to Forced Charge whether it is forced to do so or be held.
The relevant comments are:
Quote from: badhabum
I got a question for the forced charge . It seems to me that if a base is in a supporting file and could charge an enemy TUG within 1 BW it is still subject to forced charge ! In the text it is suggested that supporting files are not subject to forcd charges !
Quote from: nikgaukroger
Page 119 3rd bullet "If some part of an UG is blocked or already engaged in combat, it may still charge with other files ..."
A supporting file is engaged in combat - see Engaged Bases in the glossary on page 215 - and so is not "other files".
Quote from: badhabum
same bullet "and may still have to forced charge" ! so files as supporting files may have forced charge
Quote from: nikgaukroger
that is still referring to the "other" files, it is not an exception.
Quote from: badhabum]
What I meant is that in your feed back it seemed that you implied that supporting files were not subject to forced charges 🙂 and they are subject to it . So a misunderstanding
[/quote]
[quote="nikgaukroger"]
they are not subject to Forced Charge for the reason I have mentioned - to repeat, Supporting Files are an engaged base and it is "other" bases who may charge and if subject to the criteria the "other" bases (i.e. not Supporting Files)would be Forced Charges.
[/quote]
[quote="Badhabum
I read it differently : "it" is the file or the UG . I read it that the file, even if engaged as support file is subject to forced charges ..interesting
Quote from: nikgaukroger"]
the "it" is clearly ref
they are not subject to Forced Charge for the reason I have mentioned - to repeat, Supporting Files are an engaged base and it is "other" bases who may charge and if subject to the criteria the "other" bases (i.e. not Supporting Files)would be Forced Charges.
[quote="Badhabum
I read it differently : "it" is the file or the UG . I read it that the file, even if engaged as support file is subject to forced charges ..interesting
[quote="nikgaukroger"]
the "it" is clearly referring to the UG as a whole; might be a language thing, something getting lost in translation?
however, IMO, the key bits are "blocked or engaged in combat" and "other"; the latter is everything not covered by the former and the former includes Supporting Files by the glossary definition mentioned.
One way of thinking about it is to see the mechanism as a way of allowing files to roll combat dice that otherwise wouldn't be able to due to some geometric tactic similar to the sort employed back in the DBM days
[/quote]
What about in a situation (which occurred for me yesterday) where a pursuing enemy unit followed up into one of my units after the melee phase. It engaged frontally three of my files, leaving one file without frontal contact, which obviously could count as support in the next melee phase. However that file had an enemy within 1 BW straight ahead. (happened to be a flank) Could it charge?
It had not yet fought as a supporting file as no combat between the UGs had yet occurred. So do they count as 'fighting' at the moment of contact, in which case I guess the other file couldn't charge, or do they only count as fighting once dice have been rolled?
It may be more helpful to just post the question and the answer.
My response to "Can a Supporting File be subject to forced charge" would be no. 9.4B (page 116/7) doesn't have any exception for UGs in combat and 9.4E (3rd bullet on page 119) makes it clear they do but restricts the move to 1BW directly ahead. However supporting files are "engaged in combat".
Note: UGs charge but that doesn't have to be every file in the UG charges if some of those files are blocked or already engaged in combat.
I subsequently noted that section 8, Universal rules point 20, states "files that are not engaged frontally. The use of the word "engaged" rather than "contacted" would support this interpretation.
Richard
(modified after comment by Nik Gaukroger, and further modified)