Engineers/AVLB support

[tonystowe]

While play Washington I had in a stack 2x M1, 1x SP Mortar, 1x Inf National (wheeled), 1x Supply Truck and 1x M728 engineer vehicle.

Their mission was to cross the river in the SE end of the state to provide overwatch on that corner. I gave the order to proceed and focused my attention elsewhere. When I returned to check on these units I found that my M728 had successful made it across the river while the remainder of the stack was still north of the river.

The solution was to manually instruct the M728 to construct the bridge - only then did I successfully get the stack across the river.

SUGGESTION: I would like to see an engineer/AVLB unit understand its roll when it is part of a stack and perform the necessary tasks to complete the given mission.

Tony

[Balthagor]

Good suggestion, I'll make sure it is on our list (I believe it already is).

[Balthagor]

Well, I mentioned this to George before adding it to our tasks and after discussing it we've come up with a few problems. The question becomes, it what case should an engineering unit be given an order by the AI to perform "bridging".

The first element of your suggestion that breaks our current rules is that you're issuing a "move" order. If the AI decided that it needed a unit to bridge a hex along their path, it would not give the engineer in that group the order because it already has an existing order to move. When the AI issues orders, in most cases it finds a unit without any current orders to give it too.

Second, you need to look at what currently happens when you issue that order. In your example, the M728 is the only amphibious unit you have so the other units will only move to the hex before the water if they cannot find another way around. If there is no other way around and they are stopped on one side of the river this could be a case where the AI issues a "bridging" order to a capable unit, but it will again go to find a unit with no standing orders. This would only address the issue when there is no other way around, not when you are looking for a more efficient way across.

If your above example included for example a LAV, it might get more complicated. Should the LAV stop at the river and wait for a bridge even though it is amphibious? What if you need the LAV and M728 to cross first in an attempt to take the hex on the other side?

Anyway, you did get us thinking about the issue which I'll assume is the key purpose of the post . If my comments spark more ideas be sure to post them.

[tonystowe]

Thanks for looking into this as I believe it will streamline, or improve (IMO), the military aspect of the game in terms of Combat Support.

First I want to say that I like the current option of having control of building the number/type of engineer units as I can be more flexible in my strategy.

Second, we all understand that an Engineer unit is a support entity of the battlefield and conducts mobility, counter-mobility and survivability tasks in support of the combat element to ensure completion of the overall mission. Which in my case was crossing a river.

On to my responses:

The question becomes, it what case should an engineering unit be given an order by the AI to perform "bridging".

I am making this comparison to that of an escort mission for an aircraft. Is it possible to give a similar, yet less cumbersome, "escort" order to an engineer unit that would remove it from the 7x stack rule and make the engineer unit understand that once that element it is supporting nears an obstacle the engineer will move forward and provide the necessary support. Once all units of that stack have crossed the obstacle then the engineer will move back into its support role.

The engineer unit in this structure would have limited offensive capabilities and nowhere near the levels as seen in the current model. I do believe, however, that an engineer unit would provide additional defensive values as a part of a combined arms stack.

The first element of your suggestion that breaks our current rules is that you're issuing a "move" order. If the AI decided that it needed a unit to bridge a hex along their path, it would not give the engineer in that group the order because it already has an existing order to move. When the AI issues orders, in most cases it finds a unit without any current orders to give it too.

Again using aircraft as my basis, how does an aircraft returning to its base for fuel locate and utilize the KC-135? Can an engineer unit be given a similar radius of support and all other units programmed to request its support when an obstacle it encountered? I am sure there is a better solution; however, the AI understanding the engineer's role on the combat field as that of Combat Support, instead of combat, would place a better light on that unit type.

Second, you need to look at what currently happens when you issue that order. In your example, the M728 is the only amphibious unit you have so the other units will only move to the hex before the water if they cannot find another way around. If there is no other way around and they are stopped on one side of the river this could be a case where the AI issues a "bridging" order to a capable unit, but it will again go to find a unit with no standing orders. This would only address the issue when there is no other way around, not when you are looking for a more efficient way across.

This goes along with my above comments about a radius of support. The engineer unit would have to understand the need of the units and its potential to support those units in their mission - in this case "Move from Point A to Point B". Just because it can cross the obstacle doesn't mean it should do so and in so much the engineer should focus its attention on "support" instead of simply crossing the obstacle and leaving its combat elements behind.

If your above example included for example a LAV, it might get more complicated. Should the LAV stop at the river and wait for a bridge even though it is amphibious? What if you need the LAV and M728 to cross first in an attempt to take the hex on the other side?

In a case where a mix of amphious and non-amphibious units were mixed in a stack then the concept of "assault river crossing" would be even more possible. The amphibious combat vehicles should understand its purpose to move quickly across the obstacle and establish far security for the crossing operation. The engineer units, once again understanding its support role, would facilitate the crossing of the remaining units by bridging the river. Once everyone is across and the engineer unit recovers then it would provide additional support in the offense/defense mission of the units in which it is associated.

Another angle is the amphibious units need to understand the threat in the adjoining hex and not get caught up in a fight that it would lose without the other units.

In closing I believe that reworking the engineer's use in the game would add a more defined and better playing option than the current role that is being played. I am not insinuating that the current unit is bad, I am simply suggesting that the roles of Combat, Combat Support, and Combat Service Support are defined a little more. All of this further ties in with the supply system that you currently are using and will change the military concepts considerably, I think.

Thanks

Tony

[Draken]

Not to metion what would happens if the crossing point is in the ZOC of an enemy unit or in range of enemy artillery...

Even though I like the idea of this "Smart" movement option, I prefer to do rivers crossings manually...

This idea would be very interesting if formations are implemented... Assigning diferent roles to the formation's units and "tactical behaviors" to the formation would be very cool (Advance to contact, Assault, Tactical river crossing, Static Defense, etc)

[tonystowe]

Not to metion what would happens if the crossing point is in the ZOC of an enemy unit or in range of enemy artillery...

Draken,

I appreciate your reply as you always have sound advice concerning SR.

The enemy ZOC is already handled in game as to how your units are going to react and I don't believe this change would affect that area of game play.

This added concept would add a needed angle and while the option to micro-manage the crossing would remain it would remove this one aspect of that management and allow you to focus on the combat effort.

I recently conducted a over micro-managed river crossing in which I utilized air superiority, airborne insertion at four locations four hexes beyond the river (including abn arty), engineer support for the crossing, and finally the crossing and capture of the territory. That was alot of fun.

Tony

[Draken]

I was just pointing out one of the difficulties of implementing this... For some reason engeeniers crossing a river are very vulnerable... And, assuming your idea is implemented (don't get me wrong, I do like it), if you issue the movement order to the stack containing the eng btn and it is in the zoc of an previously unseen enemy unit, well, you will run into troubles... Perhaps I'm just thinking like the goats but they like to proctect us againts this kind of things

[Balthagor]

The engineer unit in this structure would have limited offensive capabilities and nowhere near the levels as seen in the current model. I do believe, however, that an engineer unit would provide additional defensive values as a part of a combined arms stack.

The idea of having one unit affect the stats of another has been considered a few times (in fact came up in discussions again just this morning) but is currently not supported by the engine and has been repeatedly rejected. I could see adding a rule that units on escort will do a bridging command if their escort needs across a river, but this would not always solve the issue. If you ordered a unit to move from A to B (B is on the other side of a river) it will still look for a path, find no direct route across (no one is currently bridging the river) and path all the way around. The pathing is calculated based on units currently there, not what will be there when it wants to cross.

Again using aircraft as my basis, how does an aircraft returning to its base for fuel locate and utilize the KC-135?

Poorly?

Not sure how the code is done re: tankers, but I’m fairly certain there is some extra code in there making the aircraft see the tanker as a flying airstrip. (Buildings in the game are actually “units” found in the equipment file.)

But in your suggestion, the engineer would arrive too late. When an aircraft needs fuel, it checks how far it can travel and looks around for a supply point (base or tanker) in range with valid path. When the land unit is told to move it looks for a currently available path. It does not know if there is an engineer available to make a bridge for it. Also, the engineer is not a "bridge" until it is on the river, the tanker is always a tanker.

The engineer can only know a unit “needs” a bridge if the unit found no other way so made its way to the river as a closest alternative.

Also, while the stats for the engineer are being discussed elsewhere, the current stats of an engineer certainly make it both combat and support. The M728 is intended as combat as well as support;

http://www.globalsecurity.org/military/ ... d/m728.htm

I still support the concept, I just don’t know how we should apply it due to order of operations when resolving a unit’s orders.

I recently conducted a over micro-managed river crossing in which I utilized air superiority, airborne insertion at four locations four hexes beyond the river (including abn arty), engineer support for the crossing, and finally the crossing and capture of the territory. That was alot of fun.

Examples of what you did and didn't do, how units reacted to orders and what worked effectivly during this assault would be some useful information (and probably a good AAR!)

[tonystowe]

The idea of having one unit affect the stats of another has been considered a few times (in fact came up in discussions again just this morning) but is currently not supported by the engine and has been repeatedly rejected. I could see adding a rule that units on escort will do a bridging command if their escort needs across a river, but this would not always solve the issue. If you ordered a unit to move from A to B (B is on the other side of a river) it will still look for a path, find no direct route across (no one is currently bridging the river) and path all the way around. The pathing is calculated based on units currently there, not what will be there when it wants to cross.

Your team are definitely on the right track and I appreciate the time you have taken to answer my question(s). Everything you wrote above makes clear sense to me and I, among others, really can't see the forest because of the trees. What I mean is that we simply do not know the limitations of the engine nor the unbelievable work involved in making these units do what we would like for them to. Thanks

. . . the engineer would arrive too late. When the land unit is told to move it looks for a currently available path. It does not know if there is an engineer available to make a bridge for it. Also, the engineer is not a "bridge" until it is on the river, the tanker is always a tanker. The engineer can only know a unit “needs” a bridge if the unit found no other way so made its way to the river as a closest alternative.

I still support the concept, I just don’t know how we should apply it due to order of operations when resolving a unit’s orders.

Is it possible to code the engineer in a manner that it assists a stack of units by checking its selected route and stepping up to say "Hey, I can get you there quicker by crossing here!" Very simple minded statement but I hope the point is taken. All of this is likely to be moving into the arena of TO&E and organization for the military.

Examples of what you did and didn't do, how units reacted to orders and what worked effectivly during this assault would be some useful information (and probably a good AAR!)

I hadn't thought of an AAR for a specific battle, however it might be entertaining and a way for me to look back into my strategy for options. Thanks

Tony

[Balthagor]

Glad my answers helped.

I've sent your quesiton to George since only he could answer it but he's gone to E3 so won't get an answer for a bit (plus, he may need to poke around the code to give me an answer.

To againt give you a view of the forrest , I do forsee a problem in this as I suspet the pathing code testes a series of paths (actually, I know it does) until it gets blocked then tries a new path until it reaches a path to its destination. If it encountres a river hex that is blocking it, it does not know if the river is one or two hexes wide so it won't know if an engineer can help it cross.

[Eldin]

This might be a stupid question but..

When you sea transport a land unit how does the land unit find a path then?
As I understand it the land unit orders the closest available transport to transport it. Cant you do this for engineers too?
I'm sorry if this makes no sense to you, I'm not really good at explaining things

[Balthagor]

Actually, this does make some sense, and there may well be a solution in here.

With sea transport it is however a two part order;
- move to a port/pier
- load into cargo unit (cargo unit is told to unload at destination)

We could have a "move by bridge" order which would make it two part;
- move to shore
- move across bridging unit

but you would see this as an advanced order option in any hex you right click, even if there is no river between the two points. And you would need to give this order...

[tonystowe]

This might be a stupid question but..

When you sea transport a land unit how does the land unit find a path then?
As I understand it the land unit orders the closest available transport to transport it. Cant you do this for engineers too?
I'm sorry if this makes no sense to you, I'm not really good at explaining things

Eldin, great point. I had not considered that as a compariable item. Thanks

Tony