Jump to content

Autonomous CAP and GCI AI fighter script


SNAFU

Recommended Posts

  • Replies 1.1k
  • Created
  • Last Reply

Top Posters In This Topic

Looks to me (as Grimes thought) that this line is the culprit

 

local onboard_num = template_unit_data.onboard_num - 1

 

in function spawnFighterGroup

 

So theoretically if you ensure that the tail numbers are numeric on the template aircraft it should work??

 

Checking lukrop's profile he hasn't been on here since early December 2016 but probably try sending him a PM to see if he will fix his code to cater for alpha as well as numeric. I assume he is trying to make sure that the aircraft in spawned groups have different sequential tail numbers but not really sure. His code is quite different to the original version of the script.

 

I did some checking...Several of th template aircraft had "Blank" Tail# slots. I edited them to have only numbers and Im running a test...May have just been user error.

 

Sierra

[sIGPIC][/sIGPIC]

Primary Computer

ASUS Z390-P, i7-9700K CPU @ 5.0Ghz, 32GB Patriot Viper Steel DDR4 @ 3200Mhz, ZOTAC GeForce 1070 Ti AMP Extreme, Samsung 970 EVO M.2 NVMe drives (1Tb & 500 Gb), Windows 10 Professional, Thrustmaster Warthog HOTAS, Thrustmaster Warthog Stick, Thrustmaster Cougar Throttle, Cougar MFDs x3, Saitek Combat Rudder Pedals and TrackIR 5.

 

-={TAC}=-DCS Server

Gigabyte GA-Z68XP-UD3, i7-3770K CPU @ 3.90GHz, 32GB G.SKILL Ripjaws DDR3 @ 1600Mhz, ZOTAC GeForce® GTX 970.

Link to comment
Share on other sites

That probably is the issue but "user error" not so much. It is legitimate for aircraft to now have alpha tail numbers (will become more so the more WW2 aircraft we get) so the script needs to be updated to accommodate this or else you have to start saying to people that they can't use particular aircraft or historically correct markings to allow GCICAP to work. So I would still ask you to send a PM to lukrop to see if he is willing to do something about it. Worse case in the longer term I might try to work out a one off fix to the code but I'm fairly reluctant to do so under the circumstances and even more so as it's no longer code I am familiar with.

 

I did some checking...Several of th template aircraft had "Blank" Tail# slots. I edited them to have only numbers and Im running a test...May have just been user error.

 

Sierra


Edited by Stonehouse
Link to comment
Share on other sites

Thanks for the explanation Pikey!

 

Sierra

 

Maybe contact me if you are interested.

I am not going to advertise here the framework, avoiding to step on unwanted toes, but just send me a PM if you're interested what we are working on...

 

FC

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

  • 2 weeks later...

Hey FC and other GCICAP users. I'm completely script owner agnostic and have nothing to win with any promoting of scripts or whatever, I only dwell on functionality and what i can achieve, and having said that I need to say, that after two years of being a GCICAP power user, I moved recently to MOOSE SPAWN for my AI CAP work.

 

That was a big move for me as change is disrupting and alien. But i have to say you can get respawning CAP so simply with it with a supported script that's under multiple user development and public contribution. It can also be moved dynamically in the mission or stopped completely. Or started on a trigger. ANd the template aircraft respond much more intelligently, since you can set them up with advanced actions like engage parameters, AB use, weapons dropping. I also attach mine to the warehouse system so I can change the rate of spawn mid mission by closing or limiting aircraft supply. In case anyone had panics about MOOSE being complex you simply write three lines for one spawn like this: (random example in Notepad++ on my right);

 

local Spawn_L39CAS = SPAWN:New("L39CAS"):InitLimit( 2, 0 )

Spawn_L39CAS:InitRepeatOnEngineShutDown()

Spawn_L39CAS:SpawnScheduled(300,0)

 

Which are in docs and if anyone needs a hand to create one and ask question's I could help out.

 

Just saying, GCICAP was two years awesome but it's a big beast and being left to rot now for quite some months.

 

Maybe contact me if you are interested.

I am not going to advertise here the framework, avoiding to step on unwanted toes, but just send me a PM if you're interested what we are working on...

 

FC

___________________________________________________________________________

SIMPLE SCENERY SAVING * SIMPLE GROUP SAVING * SIMPLE STATIC SAVING *

Link to comment
Share on other sites

I think Flight Control is pretty keen to end up with all the equivalent functionality of GCICAP in MOOSE. I do wish that something along the lines of ARMA3 modules (thinking the A.L.i.V.E. stuff here) were available in DCS so a user could drop a say GCICAP module onto their DCS map. Link a few airbases from each coalition and some template aircraft to the placed module and then set some module parameters and the rest happened under the covers. It would help a lot of people who are not at ease adding scripts or dealing with lua make high quality missions. It would take some big editor changes though so even if it was on the to do list somewhere it would be down near the very bottom, quite understandably considering some of the other stuff in development.

 

As an alternative having the full GCI and CAP functionality in a framework like MOOSE is the long term way to go.

 

Just be aware though if you go with the current MOOSE functionality that there are differences (see posts about this in MOOSE thread) and the experience you get in mission will not be quite the same and will require a different set up as far as where and how many air groups are placed to get a similar effect. Particularly for pre on-board air-intercept radar era scenarios (eg WW2, Korea).

Link to comment
Share on other sites

I think Flight Control is pretty keen to end up with all the equivalent functionality of GCICAP in MOOSE. I do wish that something along the lines of ARMA3 modules (thinking the A.L.i.V.E. stuff here) were available in DCS so a user could drop a say GCICAP module onto their DCS map. Link a few airbases from each coalition and some template aircraft to the placed module and then set some module parameters and the rest happened under the covers. It would help a lot of people who are not at ease adding scripts or dealing with lua make high quality missions. It would take some big editor changes though so even if it was on the to do list somewhere it would be down near the very bottom, quite understandably considering some of the other stuff in development.

 

As an alternative having the full GCI and CAP functionality in a framework like MOOSE is the long term way to go.

 

Just be aware though if you go with the current MOOSE functionality that there are differences (see posts about this in MOOSE thread) and the experience you get in mission will not be quite the same and will require a different set up as far as where and how many air groups are placed to get a similar effect. Particularly for pre on-board air-intercept radar era scenarios (eg WW2, Korea).

 

Guys... Please let us put our minds at rest. Life is too short.

 

GCICAP is a valuable script in the community.

 

MOOSE is a framework in development. It contains today components to execute CAP, PATROL and CAS in a zone. This is just the beginning of the story. MOOSE is a modular framework. More modules and capabilities will come. The goal is to provide flexibility to mission designers and to increase the fun part making missions.

It is just a question of time. GCICAP will not be blindly copied, the approach will be different so the same functionality can be mimicked, but others things will be possible too...

 

I think stone house and myself are in the same level. Just time is needed to get to that point as explained above.

 

So, my advice is for the moment: You want to have a GCICAP functionality that you know today? Use the known GCICAP script.

Wanna try out something different? Have a look at the MOOSE framework or other frameworks. It is as simple as that. The suggestion from Pikey is a lot of fun. So is the one from Delta. At the end it is about your choices, time available and whether you want to invest your time.


Edited by FlightControl

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

Yep definitely agree FlightControl. In the long term I think MOOSE will give the overall functionality of GCICAP even if it gets there in a different way. For now GCICAP brings a certain combination of things to a mission, MOOSE for now gives some of that. For now pick the one that suits the mission being built is the message. All I was trying to say was that you'll get different results from MOOSE to GCICAP and you need to factor that in. It isn't yet a direct plug out/plug in. MOOSE is definitely growing however so it is worth trying to see what you (the mission builder) can do with it.

Link to comment
Share on other sites

Overall differences explained https://forums.eagle.ru/showpost.php?p=3032772&postcount=409

 

Basically at minimum means you need more CAP groups with MOOSE than GCICAP to achieve the same coverage due to lack of EWR guidance. Particularly large impact for WW2, Korean, Vietnam era. Even to some extent modern scenarios as the EWR detection range greatly exceeds on-board radar in most cases I think.

 

Interesting you mention ROEs etc for template aircraft. My last wip version of the old script which I didn't release had that (red and blue parameters that could be set for CAPs and GCIs individually) and I thought lukrop had included it. Guess he never got around to doing so after all from what you are saying. It isn't a difficult thing to implement if he was willing to do so.

 

Possibly worth emphasizing the differences between the two somewhere, but I'll not talk anymore about it, I know much of this is down to individual flavour.
Link to comment
Share on other sites

Ah go on, you tempted me... :) I just read your take on it and Sven provided the simplistic view in his models and videos, it's kindda complex to watch but easy to implement and build on. I've gone much further as a designer because GCICAP taught me about all the things I needed plus all the things I wanted on top of that. So in the end I set out to recreate it and hence I came further.

 

So far the only three things I haven't achieved are the matching of intercept numbers, which is handled in GCICAP as an option to dynamically change the intercepting group. Also using EWR to link to detection and response, and the other one is the borders, which are possibly the best part of GCICAP, but Sven does an engagement zone which is pretty much the same thing in inverse. I never got Intercepts to work in latter version of GCICAP anyway so its moot for me.

 

The rest I've done with a bit of adding here and there. Triggers for spawning are easily manageable based on another detection criteria. I could use mist to do a detection list for EWR but its too much really. Warehousing and airport availability is handled identically to GCICAP, both types of spawing have maximum numbers and pull from the Resource Management system so if no airfield. no planes. If supply syttem is made, then it uses it. However not sure if GCICAP tries after it failed. MOOSE does.

 

Spawning however in GCICAP is static form the start, you can't move the cap zones or change the way it works once it starts, which is a major limitation. For MOOSE, you can simply stop the spawn with a trigger one liner, which is incredibly powerful. You can then break out the periodicy of the spawns or location with much more control, if you really wanted, something that when I ran my campaign, despite the front line moving, I couldnt change a CAP zone at all, it stayed where ever it was put first. Moose I simply model the moving of the CAP zone by having them all done, then trigger ewach one with a 3 line which goes into the embedded section DO SCRIPT, not even worth making a file out of it.

 

ROE's are the tip of the iceberg. In MOOSE it reuses the existing templates advanced actions, so you can implement engagement distance, dropping fuel tanks or not, ECM and chaff use and radar use or whatever. It's somewhat countered by his CAP module which is a patrol zone and you can lose some effect if you force the AI to do things, hence I use the native MOOSE spawn and then work in triggers for more control. Horses for courses, some people like the patrol zones.

 

The big part that is missing is "Anything else but CAP" It's been cried out for to use that engine to do CAS or Helicopters, or well ships, planes and infantry. But just focusing on, say a CAS flight, its the same process, you have a fully managed spawn, with a runway cleanup which is the most attractive part of these scripts, yet, GCICAP was specialised here and didn't do it. CAS zones? nope. :( Single engine for managing all your spawning, right there.

 

AS I said, GCICAP was my bread and butter go to script for years, but I'm finding i can achieve a lot more now in MOOSE and the stuff I lose is either minor or I can work around.

 

Overall differences explained https://forums.eagle.ru/showpost.php?p=3032772&postcount=409

 

Basically at minimum means you need more CAP groups with MOOSE than GCICAP to achieve the same coverage due to lack of EWR guidance. Particularly large impact for WW2, Korean, Vietnam era. Even to some extent modern scenarios as the EWR detection range greatly exceeds on-board radar in most cases I think.

 

Interesting you mention ROEs etc for template aircraft. My last wip version of the old script which I didn't release had that (red and blue parameters that could be set for CAPs and GCIs individually) and I thought lukrop had included it. Guess he never got around to doing so after all from what you are saying. It isn't a difficult thing to implement if he was willing to do so.

___________________________________________________________________________

SIMPLE SCENERY SAVING * SIMPLE GROUP SAVING * SIMPLE STATIC SAVING *

Link to comment
Share on other sites

lol tempted you hey? I agree with what you say and really the main thing is the EWR issue - as I said particularly for WW2 scenarios.

 

However also GCICAP is a module in itself so for people not up on scripting and using frameworks adding it to a mission in it's simplest form is just adding a few trigger zones without any other attached triggers or complexity, sticking in some template aircraft, adding a mission start trigger to load mist and GCICAP and you are done. You might need to set some parameters in the script header if the defaults are not what you want. The last bit is definitely not ideal. The ideal would be to have a way of telling the editor that the GCICAP module (or the Moose equivalent) is in the mission - perhaps represent a module as an editor placed object - and being able to double click on the module or select it some way to bring up a GUI dialog to allow these parameters to be chosen in drop down lists, tick boxes etc. This of course is very much the ideal but would make it much easier for non technical people to create complicated missions using combinations of drop in modules.

 

If you could encapsulate everything you've done so it was a simple plug in for people and eventually Flight Control adds EWR guided intercepts and borders you can chuck GCICAP in the bin of history. Actually even without the EWR and borders it would be ok for modern scenarios.......the thing you need to do if you want to open up mission building to the masses is avoid all the learning and tinkering you've had to do. This thought was behind most of my changes to GCICAP eg putting a zone over an airbase to designate it as a GCICAP airbase. Before that you had to hand edit the script. Ditto with template aircraft, loadouts etc. Before I added that it was all hand editing and getting CLSIDs right. That sort of thing is a huge barrier to people using these tools to build missions.

 

The sort of concepts I have in my head are from my experiences with the Arma series of games and one of the best representatives for an equivalent of GCICAP in Arma3 space (although it's much bigger and more powerful in terms of functionality) is http://alivemod.com/wiki/index.php/Main_Page . That's the sort of thing that would be good to have way off in the future if it was possible.


Edited by Stonehouse
Link to comment
Share on other sites

Guys, really... Don't waste your time discussing this :))

 

Pikey, you are right, Stone house, you are right.

Why?

 

A couple of reasons:

 

1. Moose is a component based framework. It allows great flexibility, but requires some programming skills (about 20% lua knowledge).

 

2. Moose has now a couple of building blocks that allow airplanes and helicopters to patrol in a zone, to cap in a zone and cas in a zone, including various options...

 

3. These building blocks are the first step towards something bigger. Overarching components are in the make that will use these building blocks.

 

4. Skilled programmers are able however as of today, to utilize the event handling mechanisms to achieve fancy things, extending and building on the default mechanisms.

 

So, as I said earlier.

 

GCICAP is a valued script in the community. Those who want a quick plug-in to have CAP functionality should use this. Those who like to play and try out new stuff, can have a peek into the AI_PATROL_ZONE and AI_CAP_ZONE and AI_CAS_ZONE classes. Those people with more programing skills can even combine these with other moose capabilities to create some nice little CAP behavior to their own design.

 

Will there be a time when there is a more high-level plugin in Moose. Of course there will. But with a different design and offering plus minus the same functionality, but more flexible, and extendible. However, am right now working on something different in the framework. Can only do one thing at the time... And I am taking my time for that to have a good design.

 

FC

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

That's ok FC Pikey and I are just nattering. It's not an argument or even slightly heated discussion. You are correct though it is really just having a chat rather than advancing things much although from what I've been reading Pikey is doing excellent out of the box thinking over in autonomous ground force tasking land. Meant to say that was clever work there Pikey by the way!!

Link to comment
Share on other sites

  • 3 weeks later...

GCI CAP crash

 

Hello,

 

I'm currently working on a mission which uses GCI/CAP and had several crashes, but after many trials an error it seems that the following may cause crash.

 

1) Check airports names for respawn. Also check that the airport is not to far away from MOA or CAP zones.

 

2) Most important if you make changes to script then you must rename file and re-assign to your mission. For some reason after making changes and saving that it doesn't update mission (weird).

 

Then all should work fine. My current mission runs for about 3hrs and no crashes after 20 or so flights.

 

FYI - Using development mist that came with GCI/CAP script download.

 

Hope this helps someone and sorry if breaking into another conversation.

 

Spoiler

System Specs: MB - MSI ACEX570S, AMD 5950X, 64GB 3600 NEO RAM, 3090 TI 24GB

__

A-10C2 Wisconsin 176th (TFS) 128th (TFW) - Repaint

Link to comment
Share on other sites

.....

2) Most important if you make changes to script then you must rename file and re-assign to your mission. For some reason after making changes and saving that it doesn't update mission (weird).

......

 

 

 

The way it works is that adding a script or picture or sounds etc to a mission, DCS makes a copy of the file you nominate and includes it in the .miz file. The .miz file is essentially a zipped up collection of files and folders and if you use something 7zip you can actually unzip the .miz file and see what is inside.

Long and the short of it is that DCS doesn't know about changes to these files and to get them reflected in the mission you need to refresh the copy DCS has made. Same as a zip file, if you zip some files and then edit the same files outside the zip the contents of the zipped package will not change automatically and you need to update things manually.

Link to comment
Share on other sites

There's some tips and tricks kicking around for some of the things you ran into, unfortuantely, the forum is a mountain of information and not easy to search through.

 

One tip with scripting is to refer to a local copy of your lua on your harddrive using loadfile. You can then make changes to it without doing the "reload dance", in fact you can edit it and press CRTL-R, restart the mission and get there much faster, then when done, refer to it as a static script in the normal way. Had I known that years back I'd have saved myself a considerable amount of hours in testing.

 

Bit offtopic for GCICAP, but you came a cross a general ME issue and if I can save your hours of your life, it was worth it.

Thanks Stonehouse for clarifying. My hope is that it helps others like myself new to mission building and maybe solve some false bugs about scripts and use.

___________________________________________________________________________

SIMPLE SCENERY SAVING * SIMPLE GROUP SAVING * SIMPLE STATIC SAVING *

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...