SNAFU

Hi folks, After 123 days at sea, I am back ashore. I am happy you picked up the mess I left, Stonehouse, and I hope I get around to some scripting again in the near future and take a look at what is happening here, trying to catch up. Just wanted to let you know, that I really appreciate you continue and that I am back to help, if I can. After such a long break I have to start all over again, but that is how things are.

@Stonehouse: Sorry, from your description your assumption concerning the breaking CAP script looks reasonable. I cannot help you at the moment. I recommend to switch on the debugging messages and copy the debuggingline with distinctive messages between the syntax lines, where you assume the error, to see in which line the script stops. Then you see the last text message and pinpoint the error, which might be just a missing dot somewhere. @Rivvern: Thanks for the feedback. 1. So the ME editor given speed is IAS? But I don´t know if that is related, the AI fuel/Speed management was always beyond my understanding. 2. With BARO altitude the AI was reported to go directly into the mountains in some cases, so I switched it to RADIO. I didn´t consider the side effect. 3. Line 2457 checks if the CAP is still in its zone after the arrival. Maybe the flight left the zone and was detected as "not on station" and a new flight was spawned. The 1.2 in this line defines the radios of the circle around the triggerzone center as "On station". Maybe this value requires some tuning... but this is only my first thought. 4. Ok, I only tested the runway start before I implemented the airborne start. Maybe that broke the runway takeoff. This would need a closer looking. Is the "ramp start" still working? Anyhow, I am sorry that I have to discontinue the progress on this script for a while and that I cannot help out at the moment. Please note that I will only be irregularly online for the next 6 months (depending on where I will be) but will be back in autumn/winter. I am taking a break from the life I used to live. :pilotfly:

Sorry, didn´t mean to sound rude, I am no native engish speaker, so might be the language barrier... In my years in business I saw enough efforts going down the drain, because of some minor misunderstandings, due to seemingly similar words, with fundamental different meanings. And as said, I like that bird...

Is the "eventually" in "Warning: This is a proof of concept, it´s not even started as a project, but eventually will be part of our DCS collection" a translation error? Just wondering...in German "eventuell" means 'maybe', could be similar in other languages... Anyhow, I like this generation of airplanes and the Cheetah surely looks great.

Hi Eno, I just had time for brief look at the parameters you changed. Line 14: local redCAPzone = 'redcapzone1','redcapzone2' Must be local redCAPzone = 'redcapzone' The scipt adds the number to the string, by defining the number of CAP zones you have, so if you set local numberofredCAPgroups = 2 it will automatically add 1 and 2 to the strings. In your version the script looks for triggerzones with the names: 'redcapzone11','redcapzone12','redcapzone21','redcapzone22', and cannot find this triggerzones. Same with line 15, just add in the name of the CAP triggerzone without the number 1. In the ME you still have to name the zones 'redcapzone1','redcapzone2', 'bluecapzone1' but not in the script here just the 'redcapzone' and then define the number of zones you want to use. Should have described this more clearly. And I will make a new example mission, when I get the chance. Deleting the SU-30 in the CAP spawn should be ok, as you edited the randomnumber range too. Don´t know now, if this causes some error in another function, but you will see... ;) You might want to edit the GCI spawn the same way.

Did you try the advanced waypoint action "Reaction to threat" set to "no reaction" or something? (Or doesn´t this work and you ask for another way?)

For the GCI the script checks a table of triggerzone centrepositions and gets the closest one relative to the intruder. It than gets the airdrome ID of the airfield with the same name as the triggerzone and spawns a GCI flight on that airdrome. For the CAP the spawn airfield is choosen randomly. If you choose to just use 2 airfields or 1, you have to slightly modify the script by commenting lines in a table of the airfields you don´t want to use. --names of red interceptorbases local redAF = {} redAF[1] = {name = 'Beslan'} --Exact name of airfield with the triggerzone of the same name between 'xxx' redAF[2] = {name = 'Nalchik'} --Exact name of airfield with the triggerzone of the same name between 'xxx' --redAF[3] = {name = 'Sochi-Adler'} --Exact name of airfield with the triggerzone of the same name between 'xxx' --names of blue interceptorbases local blueAF = {} blueAF[1] = {name = 'Batumi'} --Exact name of airfield with the triggerzone of the same name between 'xxx' --blueAF[2]= {name = 'Kobuleti'} --Exact name of airfield with the triggerzone of the same name between 'xxx' blueAF[3]= {name = 'Kutaisi'} --Exact name of airfield with the triggerzone of the same name between 'xxx' This should work anyhow The safest approach would be, to just use 2 triggerzones with the corresponding airfield names in ME and just repeat the name in the script lines like f.e. --names of red interceptorbases local redAF = {} redAF[1] = {name = 'Beslan'} --Exact name of airfield with the triggerzone of the same name between 'xxx' redAF[2] = {name = 'Sochi-Adler'} --Exact name of airfield with the triggerzone of the same name between 'xxx' redAF[3] = {name = 'Sochi-Adler'} --Exact name of airfield with the triggerzone of the same name between 'xxx' --names of blue interceptorbases local blueAF = {} blueAF[1] = {name = 'Batumi'} --Exact name of airfield with the triggerzone of the same name between 'xxx' blueAF[2]= {name = 'Kobuleti'} --Exact name of airfield with the triggerzone of the same name between 'xxx' blueAF[3]= {name ='Kobuleti'} --Exact name of airfield with the triggerzone of the same name between 'xxx' This would double the chance of a CAP spawn at Kobuleti or Sochi as a side effect, but this should be all...

Uploaded new version in the first post. It is now easier to observe to behavior of the CAPs since the first CAP is already on station with mission start. Changelog updated with: b6: -changed waypoint alt type from BARO to RADIO -first CAPs in mission will spawn in air in the CAP zone -randomized flightsize of the CAP and interceptor fligths, they will now consist randomly either of 4 or of 2 planes or of choice, GCI might also spawn in the same size as the interuder group

Yes, I could do a little testing too on this weekend. The CAP is set to ROE "Return Fire" and that is basically what they do, as it seems. I had the impression that they are not controlled by the "generateTask" function as they should be. I have to investigate into the function in detail. So far I have changed and tested, the take off option ramp/runway/air, in the new version this should work. I have implemted an option to set the strength of the CAP and GCI flight to 2/4/random/dynamic. Dynamic means that the GCI flight should consist of the same number of planes, as the flight the GCI shall intercept. But I must still solve the CAP issue...

Thanks guys for the feedback. I wish I had more time and could do longer testing and fine tuning of the waypoint actions. I do not have TACVIEW, thinking about getting it, but on the other hand, I doubt I have the chance to use it properly... Looks like the new ROE settings in the CAP waypoints are overruling the taskgeneration somehow. Did you by any chance know, if the first intruder was detected before the CAP reached the CAP triggerzone? In this case the CAP is not flagged as "on station" and therefore not available for intercept tasking and a GCI is ordered. Or was the CAP already on station in the triggerzone, when you entered the hostile airspace?

Uff, thanks for the heads up. That`s what happens, when you quickly try to fix an issue by just reading a script... :cry: Uploaded the fixed version b5_2 in first post.

Ah, Thanks for the feedback Rivvern. There I had an error in the logic, basically like: 1. check if acitve number below/equal limit 2. if ok, spawn fighter 3. add one to counter, start at 1 So you see the smaller/equal (<=) was wrong at this place, should have be simply a samller check. Should be corrected now in version b5_1, see first post.

PS: Also note that the CAP flights will not be considered for an interception job by script, if they are not on sation - inside the triggerzone defining the CAP zone. If an intruder enters the other airspace before the CAP flight is "on station", an GCI will be triggered and interceptors should spawn at the airfield closest to the intruder. In my testing I had this case a few times.

No, doesn´t matter what you do with the group. The script goes through every unit on the map and checks if it is of certain type, than it is checked if this unit detects any aircraft inside the borderline assigned to the side.

Updated 1st post with new version b5. Changes: -added option for CAP and interceptors to take off from runway, suggested by "Quip", or spawn in the air, but I didn´t test the air spawn option, since they spawn with speed 0, this might not work -added option to limit number of interceptors spawned, if a certain amount of intercepts are ongoing -added function which shall remove AI plane/helicopter groups, which have a damaged unit on the ground in the triggerzones created around the airfields General Note: If tested the script with airfields lacking the right planes as rescources and experienced some really weird behavior of endless fighter spawns in the air around the airfield, so I would suggest to set the airfield resources to unlimited for starters. @Rivvern: The script only considers the following radar types as EWR system: -55G6 EWR, 1L13 EWR for red -Hawk sr, Patriot str on blue side If you want to include more radar types into the script you have to add or possibleEWRunittype == "insert name of unit" to line 266 for red and line 286 for blue. I checked the your miz file, but couldn´t find anything wrong. I just changed the the borderline unit to invisble and set them to hold, so they don´t move all over the map and exchanged the b2 version with the actual b5 version and tested it. In my testing the CAP flights engaged intruder after being engaged, so the 'generatetask' function has an issue there, if you watched the CAP not engaging actively. That is my next point of testing, I didn´t have the time for further testing yesterday. If you want to disable the GCI the easiest way would be do comment the line 3840 (b5) so it looks like --spawninterceptor(side) Attached you find you miz file with the latest script version. Let me know if the CAP still does not intercept. MA_BASE v0.108_CAP_mod.miz

I thought about this for planes and helicoperts, for exact the same reason as Quip showed, but the only way I found, was to remove the whole group, if one of its elements fail.

The easiest approach would be limit the number of active intercepts, so that if f.e. only 2 intercepts are active at the same time. The limit would be a simple variable which has to be set by the user. This is something I actually wanted to do since the beginning, and it should be fairly easy. More complicated would be to check, if the intruder group has a playername and is therefore a client and then to only spawn one interceptor, or to create a "bubble" (sphere) around the intruder and check the number of intruders inside this "bubble" and then to intercept only this "bubble"... Well, I think I will go with the first... :P

I will check you mission, when I get the chance. Did you try the b4 version? Since I always considered carrier operations in the Black Sea as a pretty SciFi-theme, since no bigger carrier group would dare to get into combat operations in such a confined water, I didn´t really think about that point. Basically you need to find out the "airfield ID" and the "airfield name", since the takeoff waypoint in the script need the ID of the airfield the fighter is supposed to take off and land. If you give a fighter a takeoff point from a carrier and safe the miz.file you can get the airfield ID of the carrier - supposed the CV has something as an airfield ID. Then you have to modify the function getAFtable, which returns the data of the airfield closest to a specific point. If you only need one US and one RU carrier this will be simple. Ok, this should be fairly easy to test, just clean up the ressources of the airfields and run script.

Yes, but that changes the max. number CAP flights on station at the same time, I think GGTharos asked a randomization of the number of planes in each flight.

The number of elements of one spawned flight can be changed and randomized or made dependent on the number of elements of the intruder group. Second would need some variable to be integrated into the table, but its possible. Actually you can set the number of CAP flights active at one time, but I didn´t implement a maximum number of planes or flights available. For every intrudergroup one interceptor flight will spawn, as long as no other interceptor or CAP flight is tasked to intercept the intruder. There is no limit of planes or interceptors yet. I do not think the ressource system is considering dynamically added units and weapons. Could be tested, by taking all weapons from the airfields and check if the flights still spawn with weapons. In my experience the ressource system only limits clients, not AI units, but I didn´t take a look deeper into this

Yes, that`s the first version. Good to know, that it is of use. ;)

No, I don´t use TacView. You are right that things get messy with too much time acceleration, but I found 6x is still ok, as long as not too many AI units are on the move. Did you also try the b4 version? What are your experiences, also in regard to the problems with dynamically added units and the memory bug of DCS?

Yesterday I let the script run in a mission for about 2 hours with 6x time acceleration. I notices some random behavior of the CAP flights I could not really reproduce. Sometimes an intruder was intercepted by a new spawned interceptor flight, even though a CAP flight seemed to be on station. Another time the CAP flight on station correctly intercepted the intruder and no new flight was spawned and tasked for intercept. Do you notice some similar behavior of the CAPs on station at any chance?

Usually a flight RTB when they have no more task. You could use a script to check if the group has no more task and is airboren, something like this: local _unitname = 'InsertNameOfUnitHere' local _unit = Unit.geByName(_unitname) local _group = Unit.getGroup(Unit.geByName(_unitname)) local _groupcontrl = Group.getController(_group) if _unit:inAir() == true and Controller.hasTask(_groupcontrl) == false then --Enter function you want to do here# end Don´t know if it works, but that`s where I would start trying...

And how is that with resupplying a CV in rough seas? I have been on the North Atlantic in gale winds lasting over 5 days (container and bulker vessels only and I can confirm it`s NOT fun ;) ), I assume the fleets will need to be resupplied by ship-to-ship transfer more often? At least that would be the point where I assume the Master of an supply vessel to shit his pants, if he has to keep steady parallel course with a CV in rough seas, while transferring fuel and supplies...