Autonomous CAP and GCI AI fighter script

[Stonehouse]

Yep but that's a DCS setting. In the M-E have a look at Customize, mission options and F10 view options. You can embed what you want the clients to see and override their settings there. Lot of other stuff too.

[tovivan]

Yep but that's a DCS setting. In the M-E have a look at Customize, mission options and F10 view options. You can embed what you want the clients to see and override their settings there. Lot of other stuff too.

 

Thanks. I was so focused on ME, scripts, triggers, conditions, dynamic weather and all that BS that my brain hadn't managed to disengage from the complex stuff and reboot to remember the basics. I wonder how I managed to put my shirt on correctly during that time, lol.

 

Anyway, my little mission is working wonderfully with your new version, Stone, kudos!

Edited December 11, 2015 by tovivan

[Stonehouse]

Lol well it's more a new old version considering it's still the jan code but glad to hear it is working ok anyway.

[Pikey]

Had a wee shot with 1.5. Found something interesting. I wanted to know what happened when you captured a base. What happens is that the base tries to spawn a new pair of cap, but they despawn after a while with some cleanup and then the other base spawns a pair. Process continues forever! Can;t see if it stops past swarms of enemy aircraft!

[Stonehouse]

Which script? Sept one had it partially in, Jan one doesn't cope well at all WIP (which admittedly you don't have) one has it properly implemented.

Lukrop's version no idea although a passing glance at his code makes me think it might trap it as an error if it was the last base for a faction as does the Jan version

Edited December 12, 2015 by Stonehouse

[Stonehouse]

Hi Lukrop,

Was using your script in a mission where I had no ground based EWR only an A50 and an E2D. Unfortunately as far as I can tell it seems that as previously AWACS don't work with isTargetDetected. ie no CAPs or GCIs launched because nothing seemed to get detected.

 

So if I am correct then AWACS aircraft still don't perform for the purposes of this script without special logic being added. That's why Snafu and I tried to add them, found they didn't work and removed them. I think it has to do with them being a special class using the AWAC enroute task and not the EWR one and not having a detection range on the map. Similarly (and unfortunately) the same as ships like CVNs although hopefully at least CVNs get updated to have the EWR task for when the F18 comes out.

Edited December 12, 2015 by Stonehouse

[Pikey]

Your January quickfix one.

The reason I was testing, I was hoping once an airbase was captured it woudl stop producing a cap. I never expected the real result!

[Stonehouse]

Well even in the wip version it switches sides and starts to operate for the capturing side. Part of the change would be to eventually introduce a configurable condition (eg time delay etc) to control how quickly the planes of the capturing faction start to use the base. The January one has a fairly static table of bases so you get launches from captured bases but the clean up etc logic doesn't know about the change in ownership. Eventually all sorts of weird stuff happens and if you take the last base on a side I would expect something to break in the Jan version. Sept version went a bit further but not the whole route and it would react better (except for it's other problems) but still eventually fall on it's face. WIP version doesn't care how many or how few bases you have per side and just deals with it. No bases = no CAPs or GCIs. Take a base and it starts generating launches. I had very, very long term goals in mind that went well past just CAPs and GCIs.

Edited December 12, 2015 by Stonehouse

[tovivan]

Hm, I may have hit a problem with your script, Stone.

 

After the first wave of aircraft, the second CAP refuses to spawn (on ramp). Haven't tried GCI yet because I put Patriots on the map and thus getting close to the spawn points is just a dream. :D

 

Will try to select spawning type as "in air", remove the patriots to see if GCI works and enable debugging.

 

To make sure: the size of the trigger zone with the name of an airfield is also the zone in which an enemy triggers a GCI? Or is the GCI engagement range defined elsewhere?

[Stonehouse]

Hi tovivan,

It is still the old January code and nothing materially has changed. I guess I assumed you were familiar with it since it has been around for 12 months - it is not a new version of the code as such just one that is slightly tweaked to work for DCS1.5/2.0.

 

The airfield trigger zone does nothing except identify that airfield as being one GCICAP will use. The triggering mechanism for intercepts is (depending on whether you have borders on or off) either detection by EWR and the enemy aircraft being inside your territory or just detection by EWR.

 

Theoretically GCIs spawn when all CAPs are busy (either intercepting, RTB or en-route to CAP zone) but I know there are issues in the Jan code such that GCIs launch less frequently and most of the time CAPs will do the work. For your reference the old Jan doco is here

 

https://github.com/457Stonehouse/GCICAP/tree/master

 

Please take heed that the lua at the above is not quite the same as the one I posted a day or so ago here http://forums.eagle.ru/showpost.php?p=2592463&postcount=566 and therefore the demo mission needs to be updated to use the GCICAP2015JanDCS2.lua

 

So to use the demo mission at the above github link you would need to download the mission, open it in M-E and delete the old Jan GCICAP script on the mission start trigger and replace it with the GCICAP2015JanDCS2.lua version.

 

The pdf doc at the above github link is correct for the GCICAP2015JanDCS2.lua version

 

As I said earlier the GCICAP2015JanDCS2.lua version recently posted is only meant as a stop gap until Lukrop's version takes over.

 

If I was to do more changes to the code it would be on the WIP one that has not yet been released and not the old Jan one.

 

@Lukrop, still haven't seen your PM to Snafu yet to switch the links in the first post. Are you still planning to take charge of this script or have you changed your mind?

 

PS Tovivan, if you still can't get it working feel free to post up your mission and I'm still happy to have a quick look to see if you have setup issues causing your problems. I just don't want to spend time making more code changes on an obsolete version.

Edited December 12, 2015 by Stonehouse
PS

[Marioshata]

Lukrop doesn't seem very active. I opened an issue on Github about the CAP and GCI flights IAS being too low, but still no response. Anyway, the performance increase in the forked script is what makes me stick with it for now.

[lukrop]

Got Lukrop's script working.

 

What I basically did was take his script showcase mission, deleted or changed most of the stuff and kept only the basics that are needed for planes to spawn. Then moved the spawn points and cap points and changed/added other little things to my liking to have the mission I had before. Yes, this mission will only be used for private flying.

 

This mission is, as the rest of the repository, licensed under a slightly modified MIT license. Do whatever you please with it as long as you move inside the license terms. :) The license basically (too put simplified) just restricts making money off of the stuff inside the repository.

 

Sadly, Lukrop, it's not a drop-in replacement. I had all kind of issues and errors.

 

One of them are the templates that Stonehouse mentioned.

Yeah, this is because the version in github, which i forked was a failed release IIRC. I'll fix those default values.

 

I'm also not sure if naming in the NAME box has any role in it (Blue Template Group), but when I created a "Blue Template Group 2" and named that first plane - PILOT box - "__TMP__blue5" (because 4 was taken in original group) that plane never spawned.

The pilot name is all that matters. If you don't change the default value of 4 template units the script will never use the template unit 5. You would have to set:

gcicap.template_count = 5

edit: Actually I already fixed this.

I also don't know if it's needed like this, but it seemed strange to me that blue side had 4 planes in one group, while red side 4 groups with 1 plane each. If you changed one plane in blue group, they would all become that, so no mixed groups.

This was just to demonstrate that it's possible to have them in one group or seperate. Both is possible since only the unit's (pilot) name matters to the script.

 

Hi Lukrop,

Was using your script in a mission where I had no ground based EWR only an A50 and an E2D. Unfortunately as far as I can tell it seems that as previously AWACS don't work with isTargetDetected. ie no CAPs or GCIs launched because nothing seemed to get detected.

 

So if I am correct then AWACS aircraft still don't perform for the purposes of this script without special logic being added.

Thanks! Noted. :)

 

Lukrop doesn't seem very active. I opened an issue on Github about the CAP and GCI flights IAS being too low, but still no response. Anyway, the performance increase in the forked script is what makes me stick with it for now.

 

Just noticed that my email notifications were turned off. Sorry!

 

@Lukrop, still haven't seen your PM to Snafu yet to switch the links in the first post. Are you still planning to take charge of this script or have you changed your mind?

As you see, sometimes I need longer to respond and this might not change the next weeks since I'm fixed up pretty good at work right now (one doesn't rebuild an entire network infrastructure everyday). If you, as current project leader, think this would still work out I'll take over. ;)

 

 

Cheers!

Edited December 14, 2015 by lukrop

[Stonehouse]

As you see, sometimes I need longer to respond and this might not change the next weeks since I'm fixed up pretty good at work right now (one doesn't rebuild an entire network infrastructure everyday). If you, as current project leader, think this would still work out I'll take over. ;)

 

I think it is a fait accompli - you rewrote it, offered it up and people are using it - so regardless of what I think or feel about it I can't see the old script being used again unless you fail to support what you are offering properly or there are so many issues with what you provide that people lose interest in using it.

 

 

PS Suggestion - don't hardcode waypoint speeds parameterise them. WW2 aircraft and modern jets don't work the same and this script needs to fit everyone so you need to always consider that. Do what is in the version I haven't delivered yet, a different parameter for CAP and GCI and RTB speeds. Mission author sets up the values. Consider too more clearly grouping and identifying the parameters that a user should play around with in your script. Many of the support issues I had were due to people changing things they shouldn't have and then wondering why it didn't work anymore. Sometimes these were very hard to find from their written description of the problem as often it was the change that wasn't mentioned that caused the issue and would require me to get a copy of their mission to sort out what had caused the problem. Also from my own 27 years of designing and building software - test more thoroughly before you release things else it will bite you. See my own Sept release where I ignored my own professional experience so people got something quickly.

Edited December 14, 2015 by Stonehouse
PS

[lukrop]

I think it is a fait accompli - you rewrote it, offered it up and people are using it - so regardless of what I think or feel about it I can't see the old script being used again unless you fail to support what you are offering properly or there are so many issues with what you provide that people lose interest in using it.

Just sent SNAFU a PM. ;)

 

Lukrop's version no idea although a passing glance at his code makes me think it might trap it as an error if it was the last base for a faction as does the Jan version

If a airbase changes its coalition it won't be listed anymore by coalition.getAirbase(side) of the given side so my script would just ignore the airbase. As if you placed the triggerzone at a neutral airbase. The script checks for airbases roughly every 30 seconds (if using default gcicap.interval).

[lukrop]

PS Suggestion - don't hardcode waypoint speeds parameterise them. WW2 aircraft and modern jets don't work the same and this script needs to fit everyone so you need to always consider that. Do what is in the version I haven't delivered yet, a different parameter for CAP and GCI and RTB speeds. Mission author sets up the values. Consider too more clearly grouping and identifying the parameters that a user should play around with in your script. Many of the support issues I had were due to people changing things they shouldn't have and then wondering why it didn't work anymore. Sometimes these were very hard to find from their written description of the problem as often it was the change that wasn't mentioned that caused the issue and would require me to get a copy of their mission to sort out what had caused the problem. Also from my own 27 years of designing and building software - test more thoroughly before you release things else it will bite you. See my own Sept release where I ignored my own professional experience so people got something quickly.

 

Good idea and good point. Though I actually didn't release something per se as of yet. If we are super correct this is bleeding edge software. :P Actually I'm thinking of drafting a release in the next few days. After sorting out/identifying this issue.

 

whoops, sry for the double post.

[Stonehouse]

Sorry to disagree but if there is a link on the forum then it's released and will generate support calls. I used to test my versions with a small group of beta testers and was therefore usually confident that if I put up a link to a new version it would not cause me grief. I didn't do this with Sept despite my own experience and the results are plain to see.

 

Question for you. I see your definitions are all gcicap.blah - is this just to ensure uniqueness as you've made them global or does putting gcicap. limit the scope in lua? Either way I believed that making things global where not strictly necessary caused performance issues and if the nomenclature of putting "gcicap." implies a local value be aware that some variables like supply and borders should be global so they can be manipulated by triggers and other scripts in game.

[Stonehouse]

PS Noticed through the other thread that you are doing group:destroy on landing - for better logistics tracking and look and feel in game I'd moved to individual airframes ie unit:destroy. Numerous people had complained that the whole group despawning didn't look right and irritated them. I also thought the same as well as wanting to improve the supply handling side so that through other mechanisms outside GCICAP supply of airframes could go up and down. Tracking at a group level was clumsy and unrealistic.

[lukrop]

Sorry to disagree but if there is a link on the forum then it's released and will generate support calls. I used to test my versions with a small group of beta testers and was therefore usually confident that if I put up a link to a new version it would not cause me grief. I didn't do this with Sept despite my own experience and the results are plain to see.

This might be me hairsplitting but posting a link to a github repository is no release in my opinion. First of all it generates user feedback. If I draft a release (aka tagging) on github I found the code at that specific time to be mature enough to use it in a production environment mission. There is always the possibility of tracking the master branch's latest commit and might get some fixes faster, at the expense of the changes not being thoroughly tested, until another release is drafted. :)

 

Question for you. I see your definitions are all gcicap.blah - is this just to ensure uniqueness as you've made them global or does putting gcicap. limit the scope in lua? Either way I believed that making things global where not strictly necessary caused performance issues and if the nomenclature of putting "gcicap." implies a local value be aware that some variables like supply and borders should be global so they can be manipulated by triggers and other scripts in game.

 

gcicap is a global table. Child elements of this table like gcicap.red or gcicap.blue.cap are tables too. Every function is a global function as of now. This is something I still have to change because external code shouldn't mess around with most of them, though some still need to be global (init, main and some others). Currently it's possible to read (and alter) any of those variables from "outside" the script. For example one could tamper with gcicap[side].cap.flights and remove/add flights without proper handling and so on which needs to be addressed by making them local to the script scope. After that is done one could use getters to make those variables values accessible to export scripts for storing them somewhere for persistence. As you see there is still very much room for improvement.

 

The first thing would be writing a decent logger since I'm tired of those if statements everywhere, which I'm currently at, amongst other things. (hint: I didn't push as of yet but I got a repo for all that stuff called MSE. I hope to push some useful tools for us mission designers/scripters there.)

 

PS Noticed through the other thread that you are doing group:destroy on landing - for better logistics tracking and look and feel in game I'd moved to individual airframes ie unit:destroy. Numerous people had complained that the whole group despawning didn't look right and irritated them. I also thought the same as well as wanting to improve the supply handling side so that through other mechanisms outside GCICAP supply of airframes could go up and down. Tracking at a group level was clumsy and unrealistic.

 

I think you just lead me onto a bug in my script. The logistics counter just gets increased by one where it should be increased by the group size. Regarding despawn of the whole group: IMO every removal of a aircraft on the ramp breaks immersion if a player sees it. But sadly we have to do it for the scope of this script. Maybe we could delay the removal of each unit differently so they won't get removed all at the same time if this helps some as you stated. Even more sophisticated would be a check if a player unit is inside a given radius of the unit to despawn. If there is a player the despawn gets delayed again and the check is run again later. This way we could make sure players would almost never see the despawn (excluding F10/F2 and other external views).

Edited December 15, 2015 by lukrop

[Stonehouse]

This might be me hairsplitting but posting a link to a github repository is no release in my opinion.

 

Not disagreeing with the principal you are espousing however I am telling you how it works here in reality. If you don't want it to be a release don't post the link.

 

Understood about gcicap, just wondered if the syntax had any special implications to scope. One of the major changes I was making was to change from Snafu's original approach of nearly everything being a global table or variable to slowly change to making most stuff local except for some specific variables like border and supply. The intent there was to make it possible to trigger a change in GCICAP behaviour by a condition being meet in the mission. eg remove the borders after a trigger condition in the M-E is met or supply being increased because a ship reaches harbour safely and some others. In other words directly manipulate a GCICAP variable on the trigger action. Wasn't for persistence beyond the mission.

 

I think you just lead me onto a bug in my script.

 

Not necessarily, supply was originally implemented at the group level so adding one was correct as per the version you came from. ie logistics number was the number of groups as per the variable name not the number of units.

 

However numerous complaints were received that it looked wrong to have whole flights despawn as the first aircraft taxied in and shutdown. Despawning individually on the ramp as they shutdown is perceived by your users as better. You need to be careful about delaying despawn too much however as per your user radius idea as when things get very busy on a limited number of ramp slots you can cause changes to the battle because aircraft get jammed up and can't recover or take off.

 

Also losing the entire flight because the last aircraft got in a traffic jam and didn't take off wasn't right from a reality or look and feel point of view.

I took that on board in my last version and also moved to change everything over to tracking individual airframes rather than groups as that made better sense as to where I'd planned for the script to go and for individual aircraft despawns. For the spawning/despawning side of things I simply shifted to using events to increase or decrease supply once accounting was at the individual unit.

 

By the way on the airbases side having a time delay to rebuild the lists will cause issues where people will capture a base and still get a enemy flight launching if the timing is wrong. Either rebuilding the list just prior to use or trapping the event id for base capture to rebuild the lists would be better.

Edited December 15, 2015 by Stonehouse

[SNAFU]

Updated first post.

[Pikey]

Hate to be moany, its not meant that way and i do read the thread, but the interim September demo missions do not spawn anything Stonehouse. Gonna try the other scripts too.

Edit: this is on 1.5.2 and i tried updating mist to 4.0.57 and starting the gcicap a few seconds after.

2nd EDIT: Works if you set scripts to Once rather than Misison start, then it spawns, sorry! Bet that someone else foudn that out huh...

Edited December 15, 2015 by Pikey
didnt try as hard as I should have.

[Pikey]

3rd edit, the airfields continue spawning contiuously until each side had 15 planes (may have missed one they were moving). I experienced something similar with the January one too. Not sure that's intended behaviour?

[Pikey]

Hi Lukrop,

Your script worked then for some reason failed in MP. Any idea what the error below is for and if we can chase down how to fix that?

[Stonehouse]

Pikey if you want to put up the mission using the old script I'm happy to look at it to try to help out by checking for incorrect setup. But generally no not intended behaviour. You actually require 4.0.57 to get things working properly on 1.5.2 and all the tests I do always use mission start. I do not like doing once time more for Mist and GCICAP as the mission has loaded by the time it executes. mission start executes the script before anything spawns etc.

You are also trying the new one too so your choice as to which way you push forward.

Edited December 15, 2015 by Stonehouse

[Pikey]

i'm only using 4.0.57. I haven't gotten any of the scripts working, not Lukrops, not your two.

 

Folks don't seem to test on a dedicated server. These work when you run from mission editor, you have to run them on another server to understand all the broken crap that came with 1.5. It's OK. thanks.

 

Pikey if you want to put up the mission using the old script I'm happy to look at it to try to help out by checking for incorrect setup. But generally no not intended behaviour. You actually require 4.0.57 to get things working properly on 1.5.2 and all the tests I do always use mission start. I do not like doing once time more for Mist and GCICAP as the mission has loaded by the time it executes. mission start executes the script before anything spawns etc.

You are also trying the new one too so your choice as to which way you push forward.