Welcome to the LnLP Forums and Resource Area

We have updated our forums to the latest version. If you had an account you should be able to log in and use it as before. If not please create an account and we look forward to having you as a member.

engineering works

Kurt

Member
Joined
Jan 4, 2015
Messages
896
Points
28
Age
57
Location
England
Engineers , pionere , sappers , etc . At the moment in CO2 these guys just build and destroy bridges , oh and we use them as infantry . Some such units are equipped with flame throwers which gives them a boost in short range combat . This falls short of what these experts can actually do in RL , I will list a few things they could be doing in CO2 in the future ;

Laying / removing minefields - Probably the most popular request .

Create / place crossing points - This would give greater flexibility than the fixed crossing points we have at present . Perhaps some specialist ferry units that remain in place and allow other units to cross / pass through them .

Fortify - When equipped with the right tools and materials , they can build / dig advanced defensive positions if given the time .

Breach - With flame throwers , explosives , and other specialist tools they can crack open enemy fortifications , tunnel complexes , industrial / factory positions and most urban environments .

Build / repair / damage roads - And rail lines .

Lay / remove tank obstacles - A felled tree or crater on a road is a simple quick method for obstructing vehicular traffic , " Dragons Teeth " take a little longer to construct !

Clear snow / debris - Roads function much better when they are kept clear of snow and rubble .

Clear / fell trees - to create clear areas !

Feel free to contribute :watching:
 

Rob

Member
Joined
Oct 22, 2014
Messages
154
Points
18
Location
Vancouver BC, Canada
Engineers , pionere , sappers , etc . At the moment in CO2 these guys just build and destroy bridges , oh and we use them as infantry . Some such units are equipped with flame throwers which gives them a boost in short range combat . This falls short of what these experts can actually do in RL , I will list a few things they could be doing in CO2 in the future ;

Laying / removing minefields - Probably the most popular request .

Create / place crossing points - This would give greater flexibility than the fixed crossing points we have at present . Perhaps some specialist ferry units that remain in place and allow other units to cross / pass through them .

Fortify - When equipped with the right tools and materials , they can build / dig advanced defensive positions if given the time .

Breach - With flame throwers , explosives , and other specialist tools they can crack open enemy fortifications , tunnel complexes , industrial / factory positions and most urban environments .

Build / repair / damage roads - And rail lines .

Lay / remove tank obstacles - A felled tree or crater on a road is a simple quick method for obstructing vehicular traffic , " Dragons Teeth " take a little longer to construct !

Clear snow / debris - Roads function much better when they are kept clear of snow and rubble .

Clear / fell trees - to create clear areas !

Feel free to contribute :watching:


That's a pretty comprehensive list!

I like 'em all.

Watch Dave say we can only have 3 and must choose.....:D:eek: (just kidding)

Rob. :)
 

Kurt

Member
Joined
Jan 4, 2015
Messages
896
Points
28
Age
57
Location
England
Started learning LUA recently , its a steep learning curve ! The last time I wrote a program was 1982 , in BASIC . So don't hold your breath :hilarious:
 

hubee0

Member
Joined
Dec 7, 2017
Messages
65
Points
8
Location
UK
IMHO the priority should be destruct/repair functionality for eng. units. Why? First, it shouldn't be much work to implement. Second, it was primary activity for the engineering units in II WW.
It could be really simple in the UI - 2 additional order buttons. After selecting dest/rep button one could select an area for the activity. The existing unit footprint selection box could be used for that. As a result, existing terrain movement coeff. for the area is lowered (damage) or restored (repair). It could be a gradual process - longer the unit stays at the location, bigger the modification. But for simplicity a one-off process would be acceptable I think. Just like a transition from deployed to dug-in state, which also requires some time at the same location for an unit. Engineering capability of the unit could be used to determine how much time is needed to modify the terrain.
I love them all. Please send code! ;)
Send me an API please :)
But seriously, I imagine it shouldn't be very complicated. Just recalc the movement tables when the order has been finished. As you do already, when a bridge is build or blow up.
 

Dave 'Arjuna' O'Connor

Panther Games Designer
Joined
Jul 31, 2014
Messages
3,332
Points
113
Location
Canberra, Australia
Website
www.panthergames.com
hubee0, thanks for the post. For now, I'll ignore the comment about "it shouldn't be very complicated". What RL capability are you trying to model with this proposed functionality.? What is to be damaged and/or repaired? Are you referring to roads? If so, what if none exists in the designated area? How do we record damaged areas/objects? How do we display that? What are the limits in terms of movement enhancement? Are we going to allow them to improve the movement rate beyond the rate of a current highway? If a road is damaged, what should the AI do in terms of tasking its engineer units? What priority should be used in assigning eng resources to this function as opposed to bridges and combat support? Should combat engineers have a full capacity or a reduced capacity for this vis a vis construction engineers? Do we interrupt an attack for instance to await for the repair of a road?

I've got more questions. But that should keep you going for now. :)
 

hubee0

Member
Joined
Dec 7, 2017
Messages
65
Points
8
Location
UK
Thank you Dave for the prompt answer.
(...)What RL capability are you trying to model with this proposed functionality.? What is to be damaged and/or repaired?
On 'regular' terrain - building obstacles, laying minefields, digging AT trenches, damaging drainage. On roads - the same, plus damaging crossroads, small bridges etc. Similar in villages, towns even woodlands. On tactical level that can be really complicated to model, I admit. But on the operational scale one can simplify it a lot. ANY kind of damage/minefield/obstacle in ANY terrain just limits movement ability below normal for the unmodified terrain. How much? It should depend on several factors like the original movement level, terrain type, engineering capabilities and size of the unit, time spent on the activity.
How do we record damaged areas/objects? How do we display that?
Ideally, it could be another table besides terrain profile table (if I am right) and movement tables. Its role is to modify the movement tables, by a factor 0..1. How to display? Well, eventually it would be another overlay to show. But I think for start it could be just additional item in terrain info.
What are the limits in terms of movement enhancement? Are we going to allow them to improve the movement rate beyond the rate of a current highway?
I think a movement modifier caused by eng. work even when 0.0 shouldn't make the effective movement to go 0%. Maybe 3% should be the minimum. Repair works could raise the "damage modifier" to 1.0 which effectively restores the original movement for the given terrain.
If a road is damaged, what should the AI do in terms of tasking its engineer units? What priority should be used in assigning eng resources to this function as opposed to bridges and combat support? Should combat engineers have a full capacity or a reduced capacity for this vis a vis construction engineers? Do we interrupt an attack for instance to await for the repair of a road?
I don't expect AI to be very sophisticated in using eng. units. I imagine It should try to assign an eng. unit to advance party during move or assault (FUP phase) if there is a repair work to do. If impossible, then it won't differ (for the AI) from any other slow movement terrain. If it is too complicated for the AI to use eng. units for making damages, one could live without it I think.
Dave, I don't suggest it's jast a weekend of work! But compared to existing and planned functionalities I can't see it as something hard to implement. I may be wrong of course.
 
Last edited:

hubee0

Member
Joined
Dec 7, 2017
Messages
65
Points
8
Location
UK
My main motivation for the proposed change is the fact, that in most scenarios, eng, units are almost useless which is very far from realism. Moreover, In RL they are too precious to be used as infantry (what we do) unless in absolute emergency.
 

Ron L Wilson

Member
Joined
Mar 10, 2018
Messages
15
Points
3
Age
71
Location
USA
Just adding the ability for engineers to lay and clear mines might be a good start.

That said I imagine the AI required to make add that all work would not be trivial.
 
Joined
Oct 20, 2014
Messages
1,099
Points
63
Age
74
Location
Livonia, MI (Detroit-area suburb)
Just adding the ability for engineers to lay and clear mines might be a good start.

That said I imagine the AI required to make add that all work would not be trivial.
I think you'd find that most major counter mobility efforts during the game time frame constructed on broad front applications (West Wall / Siegfried LIne, North Sea Landing Zones, Maginot Line, Al Amein, etc.) are included in the development of the combat map as "existing" at the time the scenario started as opposed to being constructed during the duration of the scenario.

It would be nice to have a counter mobility capability assigned to appropriate engineer units to deny passage through valleys and mountain passes, but I'm hard pressed to determine which of existing scenarios would benefit from having the "ad hoc" capability to construct counter mobility defenses would make a significant difference in the game outcome.
 

Ron L Wilson

Member
Joined
Mar 10, 2018
Messages
15
Points
3
Age
71
Location
USA
You may be right in that mine laying capability would not be all that useful in most scenarios.

And I imagine would require a lot of code for the AI.
 
Top