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.

Not sure if you've read this already but it may assist http://wiki.hoggit.us/view/DCS_editor_Randomization

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.

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.

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

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.

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.

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

Could you add a DO SCRIPT as a trigger action and have do Unit.getByName('whatever tu160 unit name is'):destroy() end destroy() was how I was cleaning up planes that had taxied in and shutdown after landing in GCICAP. They just disappear. <edit> lol you posted that you had an answer just as I posted.

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.

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

Thinking you will need to probably use mist and mist.dynAddStatic on a "do script" action. So you will need to figure out the vec 2 co-ordinates of the location you want to spawn it at plus the other stuff and on a trigger action put do mist.dynAddStatic blah blah end You will also need to load mist on a mission start trigger using a do script file. There probably are other ways but this is what comes to mind first. You can probably get most or all of the info the co-ords etc by placing a CH53 where you want it in an empty mission, save it and then find the .miz file and unzip it using something like 7zip and use notepad++ or similar to edit the file called mission. If you look through it you should find the info you need based on the static object you placed.

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

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

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

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.

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.

Like I said previously there is a problem with interceptions and targets getting multiple interceptors allocated that slowly results in CAPs spamming the mission. At inspection the code Snafu has written looks ok and should work which means that the only way to find the issue is slow and tedious debugging essentially using the old print line method to tell you the trace of lines executed and display variable values. Unfortunately as does everyone I have higher priorities like work and family so working on the script falls down to when there is time and - being honest - energy. I design and build software for a living and sometimes after a day at work the last thing I want to do is do more coding especially when there are no real tools to assist you. If someone very clever with lua and the windows environment (FSF Ian are you there?) wanted to help us script builders my wish would be for them to build a real time interactive debug tool where I can see the code of a chosen script from those in a mission in a window and step execution through each line one at a time or choose break points to stop execution as well as displaying the list of variables and tables and their values and allow me to choose which data items I want to see. I have the equivalent to that at work for a different language and environment and it really helps productivity and bug squashing. So short answer to your question it is in progress and it will come out as soon as I can get it done. It would be great to have more people work on this script as it has been basically just me for near 2 years for quite a complicated piece of software. Especially as I had to learn lua along the way. 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. 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. If it is any comfort my own squadron mates are hounding me for the next version too. Of course they want all of our group to fly too so there is another priority problem. I haven't been able to fly for a long time as it is a choice to work on this script or fly a mission as there is only so much free time. My flights tend to be 5 mins here and there to work on scripts or check if a mod works under DCS 1.5/2.0. Perhaps I should just do the bare minimum to get the January 2015 version working under 1.5 even though it has other issues instead of the version I am working on now? What do the users say? It will still take time to do that of course if that is what the majority wants.

FYI works fine under DCS 2.0 Alpha

FYI works fine under DCS 2.0 Alpha

Hi lukrop, Probably would have been nice to have been contacted first but from my viewpoint I believe you've acted within the scope of the copyright notice so I wish you luck and success with your version. I do suggest that you contact Snafu before going much further as he is the original owner of the intellectual content and may have a different view of matters entirely. I cannot speak for him or give you permission to proceed. Just as an fyi the version you forked was a failed release and should really have been removed from github and I would suggest looking at the prior one. Only other thought at the moment is that your script internally is vastly different to the one I've worked on and therefore I can't really help people who use your version. It would make sense for you to begin a new thread for yours to avoid confusion when people need help and support. In the end I guess if your version supersedes this one I'll retire and get a lot more flying in lol and use it myself.

I have seen something for Saitek X52 users and perhaps other high end HOTAS with scripting behind them like a Warthog could do the similar. Hijack came up with it for trim http://forums.eagle.ru/showthread.php?t=82773

countries is a table/list of entries so eg: countries = {"UK","USA","AUS"} gives you the skin under UK, Australia and US force pools assuming the aircraft is available to that country. Is the F-15C a plane you can choose for the UK in the mission editor? If not then it's quite a bit more work to add an aircraft to a country and you'll need to mod some other lua files internal to the game. It's definitely doable but not controlled by the livery. A search in the mods or mission builder sub forums should turn up past posts. Ideally you'd make it a JSGME mod so you could easily turn it on and off and not get clobbered by DCS updates.

Yeah it's a good idea and can go on the list but I don't think I will attempt it this time around. Now work is starting to calm down a bit I've started looking at the script again in the last couple of days and fixed up a few things but the over targeting of intruders bug is still doing my head in and that is the show stopper for this version. I am starting to think I might have to rewrite the allocation of interceptors to targets section of the script but need to be careful. Already my changes to the way the table recording active and available CAP groups is handled has caused knock on issues that then require investigation and more fixes. I don't want to get myself to the point of major rewrites on a 5000 line script or you won't see anything for months.

It would be really great to get static object variants for all sorts of things from buildings to ships. eg static aircraft in semi-destroyed state, after belly landing, parked with panels open for maintenance so you can see the engines etc. Likewise it would be very useful to get smoke objects of various shapes, colours (eg grey, black, off white) and size and fire objects in a similar style that would burn or smoke for a very long time. It would also be nice to be able to set the destroyed state of map objects in the editor wherever it is possible to destroy the object in mission. eg Bridge half destroyed or destroyed.