PDA

View Full Version : Breacher/Engineer oddities



kbluck
05 Sep 03, 12:28
I've noticed some "unexpected behavior" with Breacher and Engineer attributes.

For units with the "Breacher" attribute, if they encounter an obstacle of sufficiently shallow depth (like 10m), the unit appears to just "blow through" without respecting the breach time. This seems related to a general phenomenon where when a Breacher first encounters an obstacle, a shallow breach is apparently formed immediately, and then the Breacher starts breaching for real, often in a slightly different direction than the "impact" breach.

Very slow Breacher rates < 0.5m/s seem to be respected, but show up in the Vehicle Specs as 0.5m/s.

For units with both Breacher and Engineer attributes for different obstacle types, the Breacher works but Engineer doesn't. For example: Suppose I have a unit defined as a Wire Breacher and a Mine Engineer. The unit will breach any wire it finds, but when it comes to a minefield it is stuck and won't initiate its Engineer breach. I suspect it is checking the Breacher attribute first and when it finds it can't Breach that kind of obstacle, is just giving up without going on to check its Engineer attribute.

Thanks,

--- Kevin

Pat Proctor
06 Sep 03, 11:16
In what situation would a vehicle be both a breacher and an engineer (MCLiC or AVLB type deployable breaching)?

kbluck
08 Sep 03, 11:28
In what situation would a vehicle be both a breacher and an engineer (MCLiC or AVLB type deployable breaching)?

Some ROW engineer vehicles include both line charges for breaching minefields and blades for breaching craters and ditches and stuff. Actually, even in the US inventory it is quite common to hitch a MiCLiC to an M9. Also, sappers with wirecutters and bags full of TNT could be represented as both wire breachers and mine engineers. They could also be carrying bangalores which they would use first and then fall back to the cutters.

So, I think deployable breaching should be used before fixed breaching assets, and they both should be checked when an obstacle is encountered.

--- Kevin

Pat Proctor
08 Sep 03, 20:46
Fair enough.