Autonomous Ground Force Tasking

[Sierra99]

OK I got two stupid Questions...

 

First, I want to use the Staging version NOT spawning...Do I remove the spawning version or leave it in the script?

 

B.) To set it up for RED and Blue should it look something like this:

 

autogft.TaskForce:new()

:setCountry(country.id.RUSSIA)

:addBaseZone("STAGING1")

:addTargetZone("Combat3")

:addTargetZone("Combat2")

:addTargetZone("Combat1")

:addUnitSpec(1, "ZIL-131 KUNG")

:addUnitSpec(8, "T-80UD")

:addUnitSpec(1, "ZSU-23-4 Shilka")

:addUnitSpec(1, "BMP-3")

:reinforce()

:setTargetUpdateTimer(120)

:setReinforceTimer(300)

 

autogft.TaskForce:new()

:setCountry(country.id.USA)

:addBaseZone("STAGING1")

:addTargetZone("Combat3")

:addTargetZone("Combat2")

:addTargetZone("Combat1")

:addUnitSpec(1, "M-113")

:addUnitSpec(10, "M-1 Abrams")

:addUnitSpec(1, "Hummer")

:addUnitSpec(1, "Vulcan")

:reinforce()

:setTargetUpdateTimer(120)

:setReinforceTimer(300)

 

Thanks in advance

 

Sierra

Edited December 26, 2016 by Sierra99

[wfg.Reaper]

Yes comment the spawning section out.

 

I have my Base Zones set like STAGING1 and STAGING2 and it works fine for me.

[SUNTSAG]

Hi Gromit190,

 

Thank you for this superb addition to the scripting environment....I am having fun exploring the capabilities. To this end I have a couple of questions

 

1. Is it possible to have this script function in an urban combat environment. I have tried this with the staging vehicles but they don't seem want to use the road network?

 

2. Is it at all possible to include multiple vehicle types in the groups used in either the spawn or staging scenarios? for example lead vehicle in group =T90 the rest being a mix of say IFVs or unarmed vehicles?

 

I realise I may be being greedy here and asking for something that is simply not possible but I thought it worth asking anyway. I really appreciate all your hardwork that went into this so thank you in advance. :thumbup:

[Pikey]

FWIW....my first attempt to make something substantial and DCS crashes to desktop every time without fail (reproduceable) with the same basic crash log as above bar differing memory addresses each time. I'm concerned we are in an unsupported environment, but if not, would appreciate a moderator submitting my mission to ED for looking at. Pretty sure its to do with the route calculations.

 

Update: If I start with half the units it doesn't crash...

Update2: I split up the sections. Its just before the third set it crashes. seems DCS can't handle being told to find routes over long distances, still trying to work out if theres a correlation between amount of units in group, dif units altogether, distance you send them and so forth. Either way, things explode reliably with any attempt to spawn groups and task them on any scale.

Edited December 26, 2016 by Pikey
update; update2

[gromit190]

Really appreciate the feedback, guys! Thank you :)

 

 

I cannot wait to try this on Sunday! Any chance of doing something like this for Helicopters?

 

Sierra

 

We've planned to make autonomous combat air patrols, but the system will probably be somewhat different so it requires us to do some re-thinking of things. As to helicopters I'm not sure if it can be integrated into the existing system or if it will be a part of "the next one". I'm going to do some testing and maybe I'll get some ideas. (Link to issue)

 

 

Wow, this is really fantastic work dude! Love it! Can you maybe consider popping onto the Moose forums and linking up with other great minds to see if it can be built into the Moose framework as a module? Other than that, I'd love to see more options on the spawning front, otherwise this is massive.

 

Thanks! I'm a little involved with the MOOSE framework, already. Currently, this utility have somewhat different applications (goals) from MOOSE so I'd like to keep it independent for now. The projects may seem to have somewhat similar goals but this project is (currently) only concerned with making automatic AI battles while MOOSE is more of a completely improved way of scripting missions altogheter. But we'll see, maybe MOOSE can absorb this project some day :-)

 

 

Any chance you can add a finite limit to the reinforce() function, something like reinforce(100) to allow a 100 unit pool? I see you handled reinforcing vs respawning, the only limitations in the "all units at start" scenario is the numbers of units in the mission at one time.

 

I could add a function to set a maximum number of reinforced units (issue).

I should have documented it (documentation is coming soon), but the functions "setReinforcementTimer" and "setRespawnTimer" actually both takes a extra parameters to set maximum time. When the parameter is unset (like in the example), it means it will run for infinity. You can use it like this:

 

 :setRespawnTimer(300, 3600) --   <-- Respawn dead units every 300 seconds, for a maximum of 3600 seconds (1 hour)
 -- or 
 :setReinforceTimer(300, 3600) --   <-- Reinforce dead units (from staging area) every 300 seconds, for a maximum of 3600 seconds (1 hour)

 

I'll probably add separate functions to set maximum respawn/reinforcing time pretty soon. Something like "setTimerMax"...

 

 

Great script! Just having a slight problem with it. No changes made to the example mission other that adding a Mi-8 or Uh-1 to the mission will case a CTD. The mission loads and as soon as I hit "Fly" it will CTD

The strange part, is adding the SA342 or Ka-50 no problem and everything works great.

Has anyone else come across this? Just wonder if it's something on my end or Belsimtek helicopters not playing nice with the script.

 

Hmm, I'll look into that ASAP (issue link). I suspect it has something to do with generating waypoints. This project uses MIST to generate waypoints, so maybe other MIST users are experiencing the same issue. Have you tried a different mission with Mi-8/Uh-1 and autogft in it? If yes, did it work?

 

 

Hi Gromit190,

 

Thank you for this superb addition to the scripting environment....I am having fun exploring the capabilities. To this end I have a couple of questions

 

1. Is it possible to have this script function in an urban combat environment. I have tried this with the staging vehicles but they don't seem want to use the road network?

 

2. Is it at all possible to include multiple vehicle types in the groups used in either the spawn or staging scenarios? for example lead vehicle in group =T90 the rest being a mix of say IFVs or unarmed vehicles?

 

I realise I may be being greedy here and asking for something that is simply not possible but I thought it worth asking anyway. I really appreciate all your hardwork that went into this so thank you in advance. :thumbup:

 

Thanks!

 

1. I actually deliberately disabled the use of roads in waypoints, but I'll add a function so you can make a task force use roads. Something like "useRoads()" will be added.

 

2. If I understand your question correctly, then yes this is possible. In the example mission, for instance, a single US task force consists of 4+3 M-1 Abrams and 4 LAV-25s (link)

 

 

FWIW....my first attempt to make something substantial and DCS crashes to desktop every time without fail (reproduceable) with the same basic crash log as above bar differing memory addresses each time. I'm concerned we are in an unsupported environment, but if not, would appreciate a moderator submitting my mission to ED for looking at. Pretty sure its to do with the route calculations.

 

Update: If I start with half the units it doesn't crash...

Update2: I split up the sections. Its just before the third set it crashes. seems DCS can't handle being told to find routes over long distances, still trying to work out if theres a correlation between amount of units in group, dif units altogether, distance you send them and so forth. Either way, things explode reliably with any attempt to spawn groups and task them on any scale.

 

Okay, I'll look into this (issue). Yes, I've noticed route calculations are very expensive. If there's a correlation between amount of units (or, groups), I have an idea of how to fix it using scheduling. If the crash occurs even for a single group, then maybe I can add a feature that makes the unit generate only a portion of the distance before advancing (then if the set "target update timer" has a very high time interval, units might be "stuck" while the timer is waiting).

Edited December 27, 2016 by gromit190

[Pikey]

Update on this....it's all DCS related, I don't think your script has anything wrong with it, but DCS is certianly something that needs worked around.

1) NTTR is much more robust in creating routes than Caucasus, lots of things to get stuck on in Georgia and longer distances.

2) CTD in Caucausus occurs around the third tasking with multiple groups, haven't found the right correlation, but its the routes and these deffo get jammed when off road. Making legs will help, but sounds complex to hell.

 

Suggestion to alleviate some of this would be to prevent a route recalculation on the heartbeat if the task is still the same. The net impact on re tasking every x seconds is that the group will stop, reformate, fiddle around, then set off again.

 

You also have the dreaded "circling bug" to work through. Sometimes groups have one member that for reasons best known to itself, decides it is going to do laps round a lamp post or something...

 

I've tried to space out the tasking elements, I went as far as running each :setCountry(country.id.AGGRESSORS) as a DO SCRIPT then spacing it by x seconds, up to 20, and i still get a massive hang at script start or a CTD with the issue someone else reported. As you say, its horribly expensive, perhaps we hit a scaling wall with DCS live. NTTR and smaller objectives around 2 groups, 4 vehicles x 3 single objectives for each side (total 18 vehicles) behaved OK. When I tried a full scale invasion of Georgia using 25 objectives, 5 taskforces, each 8 vehicles with two opposing ones also (total 39 vehicles) , the thing would reliably fall over at kickoff. I can get over 400 vehicles no worries or 100vs 100 moving and with stutter so it should be an OK number to use.

 

Happy to continue feeding back, the concept has massive promise.

[gromit190]

Update on this....it's all DCS related, I don't think your script has anything wrong with it, but DCS is certianly something that needs worked around.

1) NTTR is much more robust in creating routes than Caucasus, lots of things to get stuck on in Georgia and longer distances.

2) CTD in Caucausus occurs around the third tasking with multiple groups, haven't found the right correlation, but its the routes and these deffo get jammed when off road. Making legs will help, but sounds complex to hell.

 

Suggestion to alleviate some of this would be to prevent a route recalculation on the heartbeat if the task is still the same. The net impact on re tasking every x seconds is that the group will stop, reformate, fiddle around, then set off again.

 

Great suggestion, I'll be adding a condition to check if it is necessary to calculate routes. For units that have arrived at the zone they are attacking, I'll think I'll actually keep re-calculation because wouldn't want them to just "stay still" when they are clearing a zone for enemy units. Also since the routes will be very short, it shouldn't really matter.

 

 

... Making legs will help, but sounds complex to hell.

 

Sorry, can elaborate on what you mean by "Making legs"?

 

 

You also have the dreaded "circling bug" to work through. Sometimes groups have one member that for reasons best known to itself, decides it is going to do laps round a lamp post or something...

 

Yes, I'm not quite sure if it's the generated waypoints that are "incorrect" or if its the pathfinding algorithms of units advancing to their next waypoint. The bug appeared quite seldom for us, so I've been ignoring it, but I'll try to investigate it some more (issue link).

 

 

I've tried to space out the tasking elements, I went as far as running each :setCountry(country.id.AGGRESSORS) as a DO SCRIPT then spacing it by x seconds, up to 20, and i still get a massive hang at script start or a CTD with the issue someone else reported. As you say, its horribly expensive, perhaps we hit a scaling wall with DCS live. NTTR and smaller objectives around 2 groups, 4 vehicles x 3 single objectives for each side (total 18 vehicles) behaved OK. When I tried a full scale invasion of Georgia using 25 objectives, 5 taskforces, each 8 vehicles with two opposing ones also (total 39 vehicles) , the thing would reliably fall over at kickoff. I can get over 400 vehicles no worries or 100vs 100 moving and with stutter so it should be an OK number to use.

 

Hmm. I think I'll make route calculations happen at different time intervals for each group in a task force. Also, I'll try to constrain the distance of routes, so the routes will only be a portion of the distance to the "target position".

 

I really appreciate your efforts Pikey! Would you be interested in helping out with testing it further, when I've made the modifications I've planned? Then I can upload some untested versions of autogft to a shared Google Drive folder

Edited December 27, 2016 by gromit190

[71st_AH Rob]

Yes, I've noticed route calculations are very expensive. If there's a correlation between amount of units (or, groups), I have an idea of how to fix it using scheduling. If the crash occurs even for a single group, then maybe I can add a feature that makes the unit generate only a portion of the distance before advancing (then if the set "target update timer" has a very high time interval, units might be "stuck" while the timer is waiting).

 

This would fix another issue, currently forces are charging blindly at the objective, in reality they would alternatively move and take up a defensive position while covering other units while they move. A simple abstraction could be to divide the 'force' into thirds with only one third moving at a time.

 

In reality we call this movement overwatch or fire and movement and the distance that a unit moves before stopping is one tactical bound. There is no set distance but they move from one good position to another. For the purpose of this though if you limited bounds to 1km it would be fine for simulated movement of armored forces.

[gromit190]

This would fix another issue, currently forces are charging blindly at the objective, in reality they would alternatively move and take up a defensive position while covering other units while they move. A simple abstraction could be to divide the 'force' into thirds with only one third moving at a time.

 

In reality we call this movement overwatch or fire and movement and the distance that a unit moves before stopping is one tactical bound. There is no set distance but they move from one good position to another. For the purpose of this though if you limited bounds to 1km it would be fine for simulated movement of armored forces.

 

Noted, great idea.

 

Probably I'll be renaming the function "setTargetUpdateTimer" to "setAdvanceTimer", and this function should do two things:

1. check wether a zone is captured (i.e. update target zone)

2. (if units have stopped/reached their destination, or the target is changed from previous route calculation) calculate a new route 1 km towards the target zone

[ESAc_matador]

That would be a much better solution. Less work for the CPU I guess, and you are updating orders... Nice work.

[gromit190]

Came back to do some testing today, and it seems the newest DCS update has actually broken reinforcing (by staging areas) while I was away ... I'm working on a fix, hopefully I can get it working ASAP

[Pikey]

Legs was my term for shorter waypoint distances. The circling bug occurs in larger groups and infrequently but its been in dcs for many patches now. You can directly control a unit and stop it. Sometimes a recalc works. I will pass a mission to demo the ctd and you might get why its so costly at the start.

 

Happy to help although my skill in breaking things is a double edged sword!

Great suggestion, I'll be adding a condition to check if it is necessary to calculate routes. For units that have arrived at the zone they are attacking, I'll think I'll actually keep re-calculation because wouldn't want them to just "stay still" when they are clearing a zone for enemy units. Also since the routes will be very short, it shouldn't really matter.

 

 

 

 

Sorry, can elaborate on what you mean by "Making legs"?

 

 

 

 

Yes, I'm not quite sure if it's the generated waypoints that are "incorrect" or if its the pathfinding algorithms of units advancing to their next waypoint. The bug appeared quite seldom for us, so I've been ignoring it, but I'll try to investigate it some more (issue link).

 

 

 

 

Hmm. I think I'll make route calculations happen at different time intervals for each group in a task force. Also, I'll try to constrain the distance of routes, so the routes will only be a portion of the distance to the "target position".

 

I really appreciate your efforts Pikey! Would you be interested in helping out with testing it further, when I've made the modifications I've planned? Then I can upload some untested versions of autogft to a shared Google Drive folder

[gromit190]

Legs was my term for shorter waypoint distances. The circling bug occurs in larger groups and infrequently but its been in dcs for many patches now. You can directly control a unit and stop it. Sometimes a recalc works. I will pass a mission to demo the ctd and you might get why its so costly at the start.

 

Happy to help although my skill in breaking things is a double edged sword!

 

Great!

 

Regarding me not getting the utility to work since I updated DCS: Been doing some tests, seems Unit.isExist is broken in the newest version of DCS (I'm using the Steam version) which is causing reinforcing in autogft to be broken atm.

 

EDIT: Fixed, version 1.2 is now available for download (see initial post)

Edited December 28, 2016 by gromit190

[Los]

If I have a mission that already loads Mist (so I can use CTLD) will running this script as the first script negate me having to run script after? Will running this and then script cause any hinkiness? Thanks.

 

Los

[gromit190]

If I have a mission that already loads Mist (so I can use CTLD) will running this script as the first script negate me having to run script after? Will running this and then script cause any hinkiness? Thanks.

 

Los

 

I don't think it will. It might be a problem if CTLD uses a different version of mist, but I guess it doesn't and won't. Wether you load CTLD or autogft first should not matter either.

 

I'm hoping to make this project independent of MIST alltogether at some point, as we're only using some small bits of code from MIST.

 

Let me know if you run into any problems, then I'll focus on substituting the functions we're using MIST for.

[Pikey]

I noticed in the DCS logs that MIST was called twice with different versions. Coudlnt say what the effects might be but have CTLD and this and some other things sharing Mist so depends how the functions are being used, globally or locally in each. what order of calling MIST, CTLD, GCICAP and AutoGFT would be best in missions?

[gromit190]

I don't think it will. It might be a problem if CTLD uses a different version of mist, but I guess it doesn't and won't. Wether you load CTLD or autogft first should not matter either.

 

I'm hoping to make this project independent of MIST alltogether at some point, as we're only using some small bits of code from MIST.

 

Let me know if you run into any problems, then I'll focus on substituting the functions we're using MIST for.

 

I noticed in the DCS logs that MIST was called twice with different versions. Coudlnt say what the effects might be but have CTLD and this and some other things sharing Mist so depends how the functions are being used, globally or locally in each. what order of calling MIST, CTLD, GCICAP and AutoGFT would be best in missions?

 

I don't think there's really a best order, because either it will work in any order (all scripts using comatible versions) or one or more of the scripts will fail to run regardless of which order you choose.

 

With that said, I've planned to replace the functions I'm using in MIST with a somewhat different approach. So MIST won't be loaded by AutoGFT in the future.

 

 

 

EDIT:

Any chance you can add a finite limit to the reinforce() function, something like reinforce(100) to allow a 100 unit pool? I see you handled reinforcing vs respawning, the only limitations in the "all units at start" scenario is the numbers of units in the mission at one time.

 

I could add a function to set a maximum number of reinforced units (issue).

I should have documented it (documentation is coming soon), but the functions "setReinforcementTimer" and "setRespawnTimer" actually both takes a extra parameters to set maximum time. When the parameter is unset (like in the example), it means it will run for infinity. You can use it like this:

 

 :setRespawnTimer(300, 3600) --   <-- Respawn dead units every 300 seconds, for a maximum of 3600 seconds (1 hour)
 -- or 
 :setReinforceTimer(300, 3600) --   <-- Reinforce dead units (from staging area) every 300 seconds, for a maximum of 3600 seconds (1 hour)

 

I'll probably add separate functions to set maximum respawn/reinforcing time pretty soon. Something like "setTimerMax"...

 

Just wanted to add that I've added documentation (not complete, but the key features are documented). Regarding the parameter to set maximum time, it is documented here:

https://birgersp.github.io/dcs-autogft/autogft_TaskForce.html##(autogft_TaskForce).setRespawnTimer

Edited December 29, 2016 by gromit190

[gromit190]

Update on this....it's all DCS related, I don't think your script has anything wrong with it, but DCS is certianly something that needs worked around.

1) NTTR is much more robust in creating routes than Caucasus, lots of things to get stuck on in Georgia and longer distances.

2) CTD in Caucausus occurs around the third tasking with multiple groups, haven't found the right correlation, but its the routes and these deffo get jammed when off road. Making legs will help, but sounds complex to hell.

 

This would fix another issue, currently forces are charging blindly at the objective, in reality they would alternatively move and take up a defensive position while covering other units while they move. A simple abstraction could be to divide the 'force' into thirds with only one third moving at a time.

 

In reality we call this movement overwatch or fire and movement and the distance that a unit moves before stopping is one tactical bound. There is no set distance but they move from one good position to another. For the purpose of this though if you limited bounds to 1km it would be fine for simulated movement of armored forces.

 

I've added a modifier to task forces to set a "max route distance" for task forces.

 

If set, this number constrains how far groups of the task force will move between each move command (advancement). When units are moving towards a target, units will stop at this distance and wait for the next movement command. This prevents lag when computing routes over long distances.

 

I've released version 1.3 with the following upgrades:

 

• Added task force speed modifier
  
• Added ability for task forces to use roads
  
• Added task force maximum route distance between movement
  
• Various code cleanup / fixes
  
• Updated example mission script to show new features
  
• Added docs
  

 

Huge thank you to Pikey for helping out with extensive tests today!

[xcom]

Really nice stuff, reminds me of something I did a while back but on a much smaller scale.

Hope DCS limitation will be lifted soon with a dedicated server, cuz right now ground warfare is kind of limited with many players - created lag :(.

[Stonehouse]

Ciribob perhaps makes a local copy of mist in CTLD eg local _mist = mist and then all calls to mist are made using the local copy as this improves performance (local versus global is quicker)

eg _mist.utils.tableShow

[Pikey]

I believe Grommit is breaking out MIST functions as part of his to do list, which I've somewhat made larger, but for the good of all! Generally the performance of the script is fine, it's limited by DCS, with 1.3 it now handles route finding much better when DCS decides to route things into the sea or down a crevass. It will not fix the AI pathing in groups and blocking bridges, some bridges being worse than others (Batumi I'm looking at you) but with using roads it generally works, plus the addition of shorter legs.

 

Thing to watch out for on 1.3 after testing in the most awkward of places, dont set legs over 20nm or legs with sea in between, or massive mountains or large rivers without bridges, as the route calculation to look for these will impact performance, instead be careful when doing larger distances and set interim objectives that force AI to path sensibly. TLDR; be a little bit clever about how you set this up and it will work fine.

 

Ciribob perhaps makes a local copy of mist in CTLD eg local _mist = mist and then all calls to mist are made using the local copy as this improves performance (local versus global is quicker)

eg _mist.utils.tableShow

[gromit190]

Really nice stuff, reminds me of something I did a while back but on a much smaller scale.

Hope DCS limitation will be lifted soon with a dedicated server, cuz right now ground warfare is kind of limited with many players - created lag :(.

 

Thanks! I'd like to work out how to prevent lags. Are you using the latest version? Also, would you mind sharing your script (or at least the part that is invoking the functions in AutoGFT)?

 

Ciribob perhaps makes a local copy of mist in CTLD eg local _mist = mist and then all calls to mist are made using the local copy as this improves performance (local versus global is quicker)

eg _mist.utils.tableShow

 

Thanks for the suggestion. As Pikey said, I'm hoping to stop using MIST in the project, at some point.

 

If anyone has any problems with integrating AutoGFT with other scripts using MIST then please let me know and I'll make an update to fix it.

 

 

Happy new years everyone! :)

[NECK]

Excellent work gromit190!

Thank you for you contribution to the DCS community!

[wfg.Reaper]

Any way to get helicopters working with this?

[Pikey]

I believe Xcom is refering to the general use of moving and tasking ground units in large scale MP. The type of lag he's mentioning doesn't get solved, its a DCS thing, but its also not too bad for smaller squadrons doing in house stuff, like say up to 12 players online.

Thanks! I'd like to work out how to prevent lags. Are you using the latest version? Also, would you mind sharing your script (or at least the part that is invoking the functions in AutoGFT)?

 

 

 

Thanks for the suggestion. As Pikey said, I'm hoping to stop using MIST in the project, at some point.

 

If anyone has any problems with integrating AutoGFT with other scripts using MIST then please let me know and I'll make an update to fix it.

 

 

Happy new years everyone! :)