What some people seem to forget is the fact that these models stand for complete squads 20 to 100 men . Now if you tell me that if one or two squad of of any armies finest foot troops can't take out one squad of tanks then we better all run and hide. For the Nation that has all tanks on the battle field will win. LOL didn't any one see what happed in Desert Strom.
I vote leave as is for if you send all tanks and no foot troops to support them, then you will never make officer rank and stay a buck pvt. lol Tanks were desinged for support rolls not to run people over, that is what drunk drivers do. lol
----- Original Message -----
From: Peter Ramos
To: netepic_at_egroups.com
Sent: Wednesday, February 16, 2000 7:04 PM
Subject: [NetEpic ML] Re: R: Vehicle close combat
Hi!
Heheh, it seems that the tide is turning to leave as is, which is okay since there was a bare majority to this anyway.
Any more opinions for against.
Peter
Hi!
>The first issue to resolve is how vehicles engage in close combat.
>Simply put, when a vehicle charges it uses the printed CAF listed in the
rules (overrun >attack). When the vehicle itself is charged use the half the
printed CAF's value (round >down).
I desagree because this change makes vehicules too vulnerable; usually
speaking about CAF we can immagine that it shows how hard their armor is in
close combat; in epic, generally, this factor is underestimated and we have
that most vehicules have a good save (i.e. 2+) but lower CAF (i.e. a land
raider has an armor of 2+ and a caf of +3), this fact, IMHO, rappresent the
vulnerability of the vehicule when assaulted all around and immobile, not
its real defence factor, if we consider a mobile vehicule this factor should
be rised.
IMHO if we want simulate the overrun attack we have to rise the basic CAF.
Stefano
----------------------------------------------------------------------------
------------------------------------------------------------------------------
eGroups.com Home:
http://www.egroups.com/group/netepic
www.egroups.com - Simplifying group communications
Received on Thu Feb 17 2000 - 04:35:18 UTC