Autonomous CAP and GCI AI fighter script

[Stonehouse]

Lol Snafu, yes it is a love hate relationship and it's tending to the hate side a bit at present. I feel at least I need to clean up where things are for people so they have something usable but it is likely I might take a long break afterwards and actually fly the damn planes for a bit ;D or at least move onto to something new script wise. Maybe lukrop will be the new custodian and rewrite it from scratch. He needs to be willing to support it properly if he does though.

[tovivan]

At the end of the day I realized, you can get fairly randomized fighter intercepts with triggers and ingame solutions in far less time.

 

I've done quite a bit of mission making and even scripting in Operation Flashpoint and Arma2, but DCS ME is the most anti-intuitive system I've met yet.

 

Could you please give me a few tips on how to set up fighter intercepts with triggers or at least some tutorial online?

 

I made and am maintaining a fighter mission because a friend of mine and I like to fly together, without the lag from online servers, and this script was it's lifeblood. Would very much like to get rid of it and go over to something simpler and not broken by DCS updates. :)

 

Thanks. :beer:

[Stonehouse]

Depends what you want tovivan. Simplest scheme is some enemy aircraft parked on a runway somewhere with late activation ticked and orders to search and engage in a zone (you'd probably make it a largish zone over some objective that you are tasked to attack or at least go near to win the mission) or some aircraft with a plotted flight plan with same orders but with instructions to cycle the first few waypoints (some distance from the zone) until a condition is met. Then set up a continuous trigger something like part of your coalition in zone and have it set up so when it is true the late activation aircraft are activated or the patrol group stops cycling waypoints and starts flying the rest of their route. Also set up a continuous trigger to evaluate whether the enemy group is dead. If it is true use action mist.respawnGroup('whatever the enemy group is called', true) to respawn them. The above is off the top of my head and I don't have DCS available to check that I'm exactly accurate but the concepts I describe are fine and able to be done reasonably simply and there would be other ways to do it as well as others could tell you. You won't get the degree of randomness and systematic feel from the enemy etc as GCI CAP but you get roughly something like it if you are only wanting a simplistic mission. Of course you can expand the concept with a lot more triggers etc to make it more sophisticated but it means then that you have a lot of mission editor work to do and maintain. GCICAP did that for you with the trade off as you noted that sometimes an update breaks it or I introduce a new feature plus bugs which mucks up your mission.

[tovivan]

Depends what you want tovivan....snipped...

 

Yeah, that's what I pretty much want, thanks! :beer:

 

Just some easy and simple A-A fighting until the new GCICAP script is out :)

 

One last thing: if I want the game to choose randomly between three different plane types to spawn, is that possible to set up with triggers or is that already script territory?

[lukrop]

In my opinion though it really needs not to have people rewrite completely different versions unless they want to take over working on and supporting the script completely (which is fine by me). Rather I would have them enhance what is there using the script as it is now in a co-ordinated fashion.

 

As I have always stated, it's a rewrite (working in 1.5). I completly support your point regarding rewrites and the co-ordinated enhancement of stuff that is already there.

Initially I wanted to do exactly that, enhance/fix the original version.

I don't want to offend anyone, as I'm sure everyone here is doing their best (in their freetime, for a long while) but I thought it would be easier to rewrite the script instead of analyzing the code as it seemd a bit overcomplicated.

 

The problem (as I see it) with things like Lukrop has done is since his version is so radically different, retrofitting anything he does back into the "real" version will take more work to analyse and rework his code so it fits the existing script. You cannot just cut and paste from his version to the main one. ie it actually increases the effort required.

I see no benefit in selectively merging code of the fork back into the original version since it's a complete rewrite. Besides that, as you have already stated, it would take even more time (still I wouldn't see a reason behind it)

 

But the rewrite is written with backwards-compatibility in mind. In most cases you can use it as a drop-in replacement.

 

I see two options:

 

• The fork superseeds the original.
  
• I rename the fork and it lives as seperate project.
  

I would highly appreciated the first variant. This could be achieved by either, me sending you a pull-request Stonehouse, which would effectively replace the old version, or we link to the repository of the fork everywhere.

 

For someone professional or with a background in scripting, I guess it would be best to start from the scratch. But then again, thinking about the hundreds of hours you spent (and I already spent about maybe 200hrs work and more testing into this) I feel a little guilty since I started this [...]

Again, I really do feel you guys. I've been there myself.

 

Maybe lukrop will be the new custodian and rewrite it from scratch. He needs to be willing to support it properly if he does though.

I have a simple policy regarding that. I use a bug tracking system. In this case the issue tracker of github, for bug reports and feature requests. Both the developers and the users benefit from a decent bug tracking system and honestly, I don't know why ED is going through the hassel of handling all the public bug tracking, for the OpenBeta and the OpenAlpha, on the forums.

Of course I would look into a forum thread now and then but for the most part a good README, maybe some wiki entries (also github) and the issue tracker should suffice.

 

If you deceide to pull the changes into your repository, you would need to give me the appropriate permissions to the repo for supporting it (e.g. push, manage issue tracker and so on).

 

But in the case you want me to I can always rename the fork and create a seperate forum thread. Supporting the fork as I wrote above.

Edited December 5, 2015 by lukrop

[tovivan]

Lukrop, when I try to use your version with 1.5 and latest MIST, I get the following error.

 

But when I try to edit it a little to eliminate friendly CAPS I start getting errors about template problems in line 867 and so on.

[lukrop]

Lukrop, when I try to use your version with 1.5 and latest MIST, I get the following error.

 

But when I try to edit it a little to eliminate friendly CAPS I start getting errors about template problems in line 867 and so on.

 

Please follow these instructions or take a closer look at the showcase mission. If you still have problems you can open a new ticket here.

 

It looks like the script is called too early. Didn't experience any problems with the trigger singleton until now. Please check if the showcase mission is working. You should double check your units names regarding the template errors. But let's not hijack this thread just yet. ;)

[Quax456]

Dear lukrop,

 

Is it possible that your Script does'nt work wit the openalpha.

Unfortunatly it doesnt recognize the Airports :-(

Edited December 5, 2015 by Quax456

[tovivan]

Dear lukrop,

 

Is it possible that your Script does'nt work wit the openalpha.

Unfortunatly it doesnt recognize the Airports :-(

 

This is a new error I'm getting. Maybe a new thread should be created so we don't pollute this one. Btw., where is the gcicap.log dumped?

Edited December 6, 2015 by tovivan

[Stonehouse]

One last thing: if I want the game to choose randomly between three different plane types to spawn, is that possible to set up with triggers or is that already script territory?

 

Hi tovivian,

 

that is probably getting into script territory although I think you could do it in the ME with enough effort and some DO SCRIPT actions. If not wanting to use scripting at all I would just have different plane sets under late activation and use trigger conditions and flags to end up with the set being activated done randomly. You may need more than one base to make it look good I guess. Another alternative idea might be to have multiple concentric zones going from very large to smaller over your objective and launch increasingly challenging aircraft sets as you get closer to the objective. You don't say what era you are looking at but the last would work well for Korean War or WW2 when tied into my flak script. You could increase lethality of flak as you get closer to objective. I'd probably use different styles of flak - so outer zone just use the fill flak which just puts up random bursts and by the time you get to the objective use flak batteries which track you and put up box barrages. Just be careful with the last as it is quite deadly and you will need to constantly jink to stay alive. Even modern aircraft can be shot down if they are low enough to be in range and don't take it seriously.

 

RagnarDa had a simple GCIscript a few years ago which worked quite well but stopped working in 2013 (for me anyway). I didn't investigate further because Snafu's script came along but a search to find the download and some work by you might get it going. It could even have just needed a new version of Mist to make it work. Another alternative is a Ajax's scramble CAP script which ties in with his (very good) AWACs script. The AWACs script is working under 1.5 not sure about the CAP script. Look here http://www.159thgar.com/forums/viewtopic.php?f=47&t=8228

[Stonehouse]

Hi lukrop,

Not offended or concerned by what you are doing although as I said I feel it would have been a courtesy to touch base with Snafu or myself before setting out. No problems at all though and I really don't have an ego going in this regard and my efforts were a donation to the community and being honest a benefit to my own virtual squadron. Mainly at present I am feeling that I don't want to waste my free time continuing to work on the current script if you are definitely going to pursue your current course of rewriting the whole thing as there seems little point in doing so.

 

It could just be my inexperience with lua but I'm afraid I don't see that your "drop in replacement" comment will actually work as you have changed all the variable and table names and therefore it would take work to adjust the current script to use your functions or vice versa. Additionally the current script has a heavy interdependency between functions and in fact that is likely the cause of my current headaches with interceptors as I changed the activeCAPtable logic significantly in the WIP version. Again though in the long term it doesn't matter if you are rewriting things fully.

 

Anyway, I need to know if you are going to go the whole route and end up giving people a fully fledged replacement or not so I can decide what I am going to do. I still will probably continue to the point (although placing less priority on it) I can release the WIP version "as is" so the community gets to see it and then I'll stop. If you say you will commit to continue through to generating a full replacement then just get Snafu to update the links in the first post to point to your github location and it's all yours from that point on. When my last version is ready I will just make it a general fyi post in the thread. Please do check with Snafu via PM as well to ensure he is ok with this as the other main copyright holder.

 

I would respectfully suggest that your proposed support scheme doesn't seem to me to be sufficient to cover what is one of the most popular scripts here (judging by the fact the thread is stickied which is unusual - not by my request fyi - and is one of the most viewed) and if you look back through the thread you'll see that I check this thread basically daily and very actively offer support and help to people to the level of them sending me WIP missions to help them figure out what has gone wrong.

 

I can see from your script that you are quite a bit more advanced in using lua than me so believe it could be the best thing for you to rewrite the script and do honestly wish you success but don't want to see people left in a mess either because I don't finish the WIP version and then you decide to not finish the rewrite.

 

Cheers,

Stonehouse

[goosemilk]

I've been testing this out with 2.0 and WWII planes. The AI take off from correct airports (when set to take off).

GCI is a hit or miss. I'm using EWR, once in a while I will get a spawned GCI plane.

I notice I had to make my CAP zone larger 60,000 or more. Smaller CAP zones and the planes will fly off and form circle on the south side of the map, causing more CAP to spawn due to them flying out of the CAP zone.

 

I lowered the logistic # to 4 groupsupply

 

When I go multiplayer things get strange. AI for some reason won't engage (most of the times). Take off from airport results in planes facing each other stuck (I playing with lowering the stuck timer), no GCI so far I seen in multiplayer.

 

I will try to keep the test mission up and running on the server. Server name starts with Goosemilk. I will throw CAP test in the title or description. .

 

I really do like the CAP feature, I could live without GCI. I just want spawned in CAP for WWII planes.

 

Thanks for your hard work on this!!!!!

[Stonehouse]

Hi goosemilk,

You will have to state which version of the script you are using in order to get support I'm sorry.

 

Lukrop's or the one I've been working on.

 

They are completely different even if they have the same conceptual aims.

 

If you are using the one I've been working on then please be aware that the September release has significant issues and shouldn't be used. The January 2015 version was running generally ok under 1.2.16 with some long standing issues but doesn't work out of the box under 1.5/2.0. I am/was working on a new version compatible with 1.5/2.0 and trying to also address the same long standing issues plus add a couple of new features that had been on the list for some time. Unfortunately while it got to beta testing stage it hit some real problems that meant I needed to rework things so release is still pending. In lieu of the script perhaps see a post I made to tovivian a few up with some suggestions to give you a simple CAP/GCI type response using triggers etc in the M-E.

 

Cheers,

Stonehouse

[tovivan]

Hi tovivian,

 

that is probably getting into script territory although ... snipped

 

Thanks, man, much appreciated!

[Pikey]

Just as an outsider, I don't see how forks can be complete rewrites and if the burden of support lies on the burden of how much code one writes then i'm tending to believe the new work should be a new project entirely but done with the inspiration 'nod'. The reasoning is entirely based on who can support the code, not the objective of the code.

 

And FWIW rewrites aren't a bad thought, i'd hate to inherit and understand thousands of lines, I can understand not wanting to go there.

 

Hey i'm a customer of a free product, it doesn't matter what I think, but I really do like it and I know Stonehouse (and SNAFU) were here helping out for a long time and that made a difference to me.

[Stonehouse]

Just as a helping hand to people, I did a very quick minimum update to the old Jan 2015 version and got it running on 1.5 and tentatively 2.0. Generally with about an hour's testing it seems ok - well as good as the Jan 2015 code was anyway -although for 2.0 I found the mission ran very slowly and I quickly got an out of memory error. No idea if it is something bad in the script interacting with something wrong in 2.0 or even if the slowness is just my old graphics card bogging down (660Ti so probably is).

 

You must use the 4.0.57 version of Mist or later and understand that all the issues that existed in the Jan 2015 version are there in glowing technicolour still plus anything else that quirks of 1.5/2.0 may have triggered.

 

I am still waiting to hear from Lukrop if he is going to take over the development of this script so work on my other WIP version is on hold. I don't really want to do improvements or fixes on the attached version as it seems better to work on the new one if I continue with it so it's a kind of take it warts and all type deal. Hope people are ok with that and I guess if it turns out it doesn't work then people are no worse off than they are now. My fingers are crossed that it serves as a stop gap for those who miss being able to use it. I will still try to help users obviously if they have basic mission setup issues but I don't want to spend hours finding bugs in old code when there is a new one in the works one way or the other.

 

Cheers,

Stonehouse

GCICAP2015JanDCS2.lua

[lukrop]

First of all, sorry for the late answer. Had some very busy days at work.

 

It could just be my inexperience with lua but I'm afraid I don't see that your "drop in replacement" comment will actually work as you have changed all the variable and table names and therefore it would take work to adjust the current script to use your functions or vice versa. Additionally the current script has a heavy interdependency between functions and in fact that is likely the cause of my current headaches with interceptors as I changed the activeCAPtable logic significantly in the WIP version.

 

If a user has a mission running with the original GCICAP ideally he could just change the trigger to include the forked GCICAP script (instead of the original one, hence the "drop in replacement") and everything should work as before but including improvements (performance, GCI/CAP limits and so on). Keep in mind though this only works as long as the user didn't change any variables (talking about zone count, group count for example). Of course if the user did so, he has to change the same variables in the forked version too.

 

Anyway, I need to know if you are going to go the whole route and end up giving people a fully fledged replacement or not so I can decide what I am going to do.

 

The master branch on github contains a version which is almost feature complete. The only thing missing is the airport cleanup code if AI goes mad and collides or gets stuck (they do get removed if they correctly park and shutdown their engines). So I would consider the current version a fully fledged replacement.

 

I would respectfully suggest that your proposed support scheme doesn't seem to me to be sufficient to cover what is one of the most popular scripts here (judging by the fact the thread is stickied which is unusual - not by my request fyi - and is one of the most viewed) and if you look back through the thread you'll see that I check this thread basically daily and very actively offer support and help to people to the level of them sending me WIP missions to help them figure out what has gone wrong.

 

[..] but don't want to see people left in a mess either because I don't finish the WIP version and then you decide to not finish the rewrite.

I really have a great deal of respect for your commitment to this project, to this extent and over this long period of time. But I can't and (this might sound harsh but please don't take it the wrong way) do not really want to bring up all that energy to search through pages and pages of posts to filter out bug reports, dupes and build missions for other users.

What I will do: (regardless of what you decide to do with the original version)

Try to fix issues reported on github in a timely fashion.

Check on a forum thread but maybe not as frequently as you did.

 

I really don't want you to think that I want to toss you my code and burden you with the support of it.

 

Honestly I'm not sure what would be the best way to handle this. As I stated I can provide support only the way I mention before. But I really see it the same way as you regarding you putting more time into the original script. I think I would like the idea of just adding the link to my repository in the OP and add some comment about how I would handle support, keeping the name of the script and keeping this thread for discussion about it. But I'm not in the place to decide that.

If you think the way I would handle support is not enough I would just open a new thread and probably rename the "fork"/rewrite. :)

 

Just as an outsider, I don't see how forks can be complete rewrites and if the burden of support lies on the burden of how much code one writes then i'm tending to believe the new work should be a new project entirely but done with the inspiration 'nod'. The reasoning is entirely based on who can support the code, not the objective of the code.

 

It actually started out as a fork but quickly became a rewrite. I'm using the word fork to prevent confusion between the GCICAP scripts and to some extent to make clear who came up with the initial idea.

 

 

On a side note: the community should be glad that it has members like you Stonehouse. Not many people would show that much dedication. (probably including me. :D)

 

This is a new error I'm getting. Maybe a new thread should be created so we don't pollute this one. Btw., where is the gcicap.log dumped?

GCICAP is logging to the DCS logfile which can be found in your Saved Games\DCS\Logs directory. Looks like you are missing MIST. Maybe you didn't "load" it before GCICAP or missed it altogether.

Edited December 10, 2015 by lukrop
typos

[Stonehouse]

Hi Lukrop,

Ok the "drop in replacement" thing is clear now - you meant at the mission level where I thought you meant at the script level.

 

On the support side of things - I meant my comment only as a suggestion so you knew what you are taking on. It is one of the top 3 viewed threads in the mission builders sub forum so it is obvious people are very interested in it and I believe they expect a lot from it because it automates a big complex chunk of mission building work. I guess that is also the reason you got interested yourself. From my experience of the current script there is a high degree of support needed for users but maybe your new version will require less. Most probably ensuring you have a very complete and accurate user guide will mitigate support burdens.

 

As I said in my earlier post, if you wish to be responsible for future development then all you need to do is send a PM to Snafu to ask him to edit the first post and to ensure that he's ok with you taking over running with it. If you could cc me that would be good so I know you've taken that step and I'm not responsible for support anymore. I assume as per the terms of the copyright you will continue to credit the past developers in your new version of the script and not try to sell or use GCICAP for material gains without gaining our permission. So all you need to do now is type up the PM and send it.

 

In a lot of ways when Snafu and I and the others drafted the copyright terms we had people like you in mind as this is meant to be a true community resource and I wish you every success with your tenure. I also look forward to using your version myself. For completeness sake I will stick up an fyi post with my last version of the old script attached at some point in the future.

 

My thanks go to all the users of the old script and their patience over the last few years. I hope the experience of using it was generally a good one.

 

Cheers,

Stonehouse

 

PS Lukrop, noticed that due to the version you forked you've ended up with the __TMP__ prefix on the template aircraft. This was meant as a temporary thing for the Sept version. The most popular way from the user viewpoint was to have a __CAP__ and a __GCI__ set of template aircraft so CAPs and GCIs could have differences according to their role eg lot of people set up GCIs as more sprinters with a lighter A-A loadout whereas CAPs tended to get drop tanks etc. Also allowed different skins and countries for each role too. The Jan2015 version had CAP and GCI template aircraft and so does the current WIP version so I am guessing if you did something similar you would make a lot of your audience happy.

Edited December 10, 2015 by Stonehouse
PS

[lukrop]

On the support side of things - I meant my comment only as a suggestion so you knew what you are taking on.

And I'm glad you mentioned/suggested it. Maybe I underestimated the support side and got intimidated by it for a second. :)

 

PS Lukrop, noticed that due to the version you forked you've ended up with the __TMP__ prefix on the template aircraft. This was meant as a temporary thing for the Sept version. The most popular way from the user viewpoint was to have a __CAP__ and a __GCI__ set of template aircraft so CAPs and GCIs could have differences according to their role eg lot of people set up GCIs as more sprinters with a lighter A-A loadout whereas CAPs tended to get drop tanks etc. Also allowed different skins and countries for each role too. The Jan2015 version had CAP and GCI template aircraft and so does the current WIP version so I am guessing if you did something similar you would make a lot of your audience happy.

 

Fixed and pushed to github. Still need to update the showcase mission reflecting those changes, though.

[tovivan]

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.

 

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.

 

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.

 

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.

 

Another problem was that as soon as I disabled red groups spawning in the script (before I used your showcase mission and changed nothing in the script) I started getting script warnings and not even blue sides would spawn. I get that even when I created a new mission, not just tried to drop the script into the old one.

 

I'm now playing with your modified showcase mission and it's working great (aside of MiG-25 and 31's being absolutely stupid :P - flying low and slow and getting into dogfight with F-15's), so thank you for your work!

 

Lukrop, noticed that due to the version you forked you've ended up with the __TMP__ prefix on the template aircraft.

 

Stonehouse, I will try to drop your newest update into my old mission and see how it behaves. Thank you for your work!

 

GCICAP is logging to the DCS logfile which can be found in your Saved Games\DCS\Logs directory. Looks like you are missing MIST. Maybe you didn't "load" it before GCICAP or missed it altogether.

 

Actually discovered on my own that ME simply didn't save MIST into the mission file, even though I specifically and carefully included it in the triggers in the exact same way as you did.

 

Have no clue why, but then again ME has been going absolutely crazy and stupid batshit crazy stuff in 1.5.

 

But when I put MIST into the file physically I started getting other script errors. At that point I simply gave up and modified your showcase.

[Quax456]

@lukrop

 

it made me crazy to sort it out when I use your gcicap script it will throw errors when there are other Nations then Russia used in the red coalition......

 

When closing the mission another error appear in the despawn.eventhandler due to the fact that a user is leaving... :cry:

 

And by the way: in your showcase mission the red SU27 CAP despawn after some minutes...havend took a deeper look why. But I think maybe they crash in the mountains due to less given altitude!?

 

Anyway....you have made a great piece of script code, so have done also Stonhouse

 

Best Regards

[tovivan]

Yup, Stonehouse's newest edit works in 1.5, thanks! :joystick:

 

Now to get that blasted Spam-bait, er, I mean Tu-160, to start respawning after it lands. :(

Edited December 10, 2015 by tovivan

[tovivan]

Also set up a continuous trigger to evaluate whether the enemy group is dead. If it is true use action mist.respawnGroup('whatever the enemy group is called', true) to respawn them.

 

An Idea: how difficult would it be to convert GCICAP to spawn CAS groups that would attack ground targets in trigger zones? Even if it means it would be a CAS-only script, instead of GCICAPCAS?

 

Thanks

 

EDIT: is a message in upper right corner about Combined Ops from this script or am I missing something?

Edited December 10, 2015 by tovivan
deleted a question, cause I figured it out

[Stonehouse]

The messages only work properly when you are in cockpit as a player. Outside in game master etc it spams the screen. It was a DCS 1.5 change that affected something in Mist and made it work differently depending on your view point - at least that is as my last conversation with Grimes possibly the Mist addmessage has been updated since then. The GCICAP script I was working on will clean up wrecks within a given distance of faction airbases - it actually is common code for stuck planes and wrecks. Doesn't do a map wide clean up though. Not sure about Lukrop's new one but I assume it does or will do something similar in concept. DCS will clean up after a period of time (30mins???? not sure).

 

I replied on an idea how to do a clean up of the tu160 in your other thread.

 

If the messages bug you then turn them off and use Ajax's AWACs script - it is what I've been doing and I tend to use the GCI messages as an easy debug. Ajax's script does the job so much better.

 

Cheers,

Stonehouse

[tovivan]

The messages only work properly when you are in cockpit as a player.

 

Thanks for your reply!

 

A not-connected question: is it possible to turn off seeing range circles of AA, radars plus units themselves in F10 when hosting a mission? I set them to "hidden" in editor, but can still see their icons on map and it's kinda annoying cause there's a lot of stuff shown.