SNAFU

Just had an half an hour yesterday and modified the ROE of the CAP and the intercepttask. I tested the version briefly, seemed to work, but had no time for extensive testing. For the b4 version check 1st post.

That sounds really weird. Never experienced this. I have no idea what might be the cause of this, did you check the log.file?

Rivvern, I hope I have time on the weekend to take look at the mission. What HiJack said is correct, the CAP waypoints are randomly created inside the triggerzone and turning points in which the fighter use their Radar to search for targets. If the fighter detects a target he actually should not engage, due to the ROE still in RETURN FIRE only as long as no hostile A/C is in their territory. But that is theoretically the case and I have to check the ROE settings. From the picture there is nothing you did wrong. I would only use a smaller size of trigger zones for the airfield markers, since they might be confusing, but that`s all I notice at the first look. And you might want to switch off the debugging messages by setting debuggingmessages = false I actually also wanted to check the ROE of the CAPs so, if they remain in Return Fire mode as long as their own airspace is not violated. I also observed some really aggressive behavior by the CAPs in some cases, but could not really reproduce it. There is still a lot of work left on the script, like some points I always wanted to do is: -include AWACS -include seaborne radar -smart intercept profiles -only shadowing of intruders if they are of civil type -disengaging of interceptors if SAM is engaged on target -... Currently I have not enough time at hands to continue, but I try to check the ROE settings of the CAPs.

The string "A-" is just a variable string. You can also replace "A-" by "AnotherRandomAICreated or whatever you like". The semicolon is a leftover, shouldn´t do anything so you can delete it. It just separates statements in LUA as far as I know.

What do you mean? You can check if the error is also logged without the RandomAirtraffic script?

Ok, that appears to be part of a MIST function, which lists all new groups into a table, if they are not already in the table. The error seems to appear when a client takes control or leaves the control of a plane and seems to be related to the group name. I guess the MIST function is regularly called to check for new events or groups with the mist.schedule, maybe Grimes knows? It could be rather a general MIST issue, maybe you try an older version of MIST or another? Sometimes I find in several versions of scripts in the compressed *.miz file, which I actually long deleted in the mission editor, but they somehow stuck in the compressed file. Then I have to delete them manually in the *.miz.

Ok, the modification with adding the debugging messages didn´t work I guess... I have issues with the debugging function in another script too, have to look.... The reference to line 4254 is leading to the MIST script. Maybe you can see what function in MIST is called up in this lines and find out who this could be related to a group spawn and despawning as client?

Just for correct understanding... After an hour DCS logs into the log 00033.291 INFO SCRIPTING: mist.scheduleFunction, error in scheduled function: [string "C:\Users\Jack\AppData\Local\Temp\DCS\/~mis00..."]:4254: Parameter #1 (unit name string) missed At the same time you get the scripting error message in game on the screen, therefore you know it is line 2561 or 2682? Where is the function NewSpawntimer coming from? From my understanding mist.scheduleFunction (function, arguments of function, starting time, intervall, cycles) is not correctly described in the MIST manual, as far as I remember. Maybe you switch 900 with time.getTime() + 3600, but only a wild gues. In my next testing version I would include a kind of scripted debugging message as you see in (t8) to find out in which area of the script it stops. This is a further development version of the t7 and not tested. I don´t know when I find the time to test this one at home... :cry: MIST3_2_RandAirtraffic_t8.lua

You can test this version (t7) here attached, there I just quickly replaced the mist.scheduleFunction with the inbuilt time-schedule to exclude issues with MIST. Note I am in office and had not chance to test the modification... ;) MIST3_2_RandAirtraffic_t7.lua

Ah, right in the old scripts I used the mist.scheduleFunction... Do you use the script together with the GCI-CAP script? I assume some issues, when groups are deleted by both scripts, because the basically use the same function to clear up landed aircrafts cluttering the airfields, but so far that is just a wild guess. I will take a look and see if I have an idea, posting or Pming the mission might help.

What do you mean "wrong script"? Line 4254, looks like a MIST problem, I usually don´t use mist.scheduleFunction?

A little late now I guess, but I will check by, when online. Airstarts are possible, you have to fiddle a little bit around with the lines of the local CAPdata table (around line 2681 look for ["type"] = "TakeOffParking", ["action"] = "From Parking Area", and change it into ["type"] = "Turning Point", ["action"] = "Turning Point", This should give the CAP flights an airstart over the airfield. If you want them to spawn in the CAP zone in the air, delete point [1] and rename point[2] into point[1] in the CAPdata table. To create certain intercept profiles it takes a little more effort.You have to modify the local interceptask in line 1476. Every point reflects a waypoint. So you see it is at the moment just a simple "direct pursuit from the actual point of the flight to 2/3 or so of the way between the target and then look again". Nothing sophisticated and lives by the repeated generation of the task. With a some time and math invested this points in the table could reflect better interceptprofiles. RagnarDa implemented some better interceptprofiles in his GCI script as far as I know, maybe it is possible to get a direction from that script. You can deactivate one side completly by commenting the timer for the side in line 3771 like f.e. this example which deactivates the intercept checks for the "red" side --timer.scheduleFunction(interceptmain, 'red', timer.getTime() + 5) timer.scheduleFunction(interceptmain, 'blue', timer.getTime() + 5) Or as HiJack said, but I don´t know, if that doesn´t cause some hickups on the way... Concerning the disabling one side, check if above works with taking out the time for the function. You can disable the debugging messages by setting in line 29: debuggingmessages = false To change the payloads you need to know the payloads you want. Therefore you create a payload for the plane in the ME, safe the file. Now you decompress the *.miz file and open the mission file. In this file you look for the payload and replace the one in the script. Just search for "payload" in the lua file and you find an entry for every plane type. Hope that helps. BTW: I uploaded a slightly changes version of the lua file in the first post. I actually didn´t change anything important, just deactivated the debugging message and put it all in a do-end block to limit the locals. But I had no time to put more work into this, since I am working on a complete dynamic mission template, which also contains some simple ground war logic, like fighting for triggerzones, holding and supplying them, but I guess first the dynamic added units should be getting more stable in DCS.

If you exchange line 1452 with line 1518 you the sorting as follows: Georgia settled in the numbers between US and RUS: randomAirplane = math.random(1,18) -- random for airplanettype; US AC 1-8, Georgia AC 9, Russian AC 10-18 randomHeli = math.random(1,18) -- US AC 1-10, Georgian AC 10-12, Russian AC 13-18 randomFighter = math.random(1,36) --NATO AC 1-16, Georgian 17, Russian AC 18-36 Then you can split the types by editing the numbers in the math.random(). But I didn´t declare the most varaibles as locals since it caused some issues, therefore using the script twice in a mission might cause problems. I didn´t check this in depth, but forexample the "groupcounter" is global and therefore used by both scripts currently. This would need some overhaul to be sure, so feedback always welcome... ;)

I have the list from the Mission Log Sorftware by AriesWings. You can place an AI flight in the ME and set it takeoff, then you open the MIZ file and chech the Mission-file with Notepad and look for the ID in the unit-table behind "TAKE OFF PARKING", that is how you can easily get the ID of the airfield, if you don´t know the name, but I don´t know an easy way to get the correct name of airbase. When you have the ID you could try by replacing <enter ID number here> with the ID: local airfield = Airbase.getByID(<enter ID number here>) local airfieldname = Airbase.getName(airfield) trigger.action.outText(airfieldname, 60000000) But that is purely experimental, since these functions are not documented anywhere in this way. Airbase.getByName() is existing and Unit.getName(Unitself) is exisit, but I don´t know if this is transferable on "Airbase" type. @HiJack: That is possible... I actually wanted to rewrite the script that all airports on the map are used and the type and color the plane spawns depend on the owner coalition of the airfield. But I do not see myself doing this in the near future. I have a general idea how to do this and the functions are availabe, but I have to work on a squad campaign before I get back to this. But this was my first bigger script - actually quite simple - only getting the specifics for the plane-tables was an effort. With a little scripting knowledge the table can be taken and used quite easily for a script as described above. As said... only the time is missing...

As long as the CAP triggerzones are not overlapping and there is no violation of the airspace, the CAPs should remain in their CAP triggerzones and not engage anything... in theory, was in my testing, when I sperated the CAP zones from enemy CAP zones far enough. But the ROE could be implemented and the spawned with ROE Return fire (have to check if that is not already the case). When the EWR detects an intruder the idle CAP gets the task to actively engage defined group and the ROE should be OPEN FIRE. I should be easy to change, if that is not already the case. Somewher in line 2728 task must be the ROE action: { ["tasks"] = { [1] = { ["enabled"] = true, ["auto"] = false, ["id"] = "EngageTargetsInZone", ["number"] = 1, ["params"] = { ["targetTypes"] = { [1] = "Air", }, -- end of ["targetTypes"] ["x"] = actualCAPzoneposx, ["priority"] = 1, ["y"] = actualCAPzoneposz, ["zoneRadius"] = actualCAPzone.radius, }, -- end of ["params"] }, -- end of [1] [2] = { ["enabled"] = true, ["auto"] = false, ["id"] = "WrappedAction", ["number"] = 2, ["params"] = { ["action"] = { ["id"] = "Option", ["params"] = { ["value"] = 4, ["name"] = 1, }, -- end of ["params"] }, -- end of ["action"] }, -- end of ["params"] }, -- end of [2] [3] = { ["number"] = 3, ["auto"] = false, ["id"] = "WrappedAction", ["enabled"] = true, ["params"] = { ["action"] = { ["id"] = "Option", ["params"] = { ["value"] = 2, ["name"] = 3, }, -- end of ["params"] }, -- end of ["action"] }, -- end of ["params"] }, -- end of [3] [4] = { ["number"] = 4, ["auto"] = false, ["id"] = "WrappedAction", ["enabled"] = true, ["params"] = { ["action"] = { ["id"] = "Option", ["params"] = { ["value"] = 1, ["name"] = 4, }, -- end of ["params"] }, -- end of ["action"] }, -- end of ["params"] }, -- end of [4] [5] = { ["number"] = 5, ["auto"] = false, ["id"] = "WrappedAction", ["enabled"] = true, ["params"] = { ["action"] = { ["id"] = "Option", ["params"] = { ["value"] = true, ["name"] = 6, }, -- end of ["params"] }, -- end of ["action"] }, -- end of ["params"] }, -- end of [5] [6] = { ["number"] = 6, ["auto"] = false, ["id"] = "WrappedAction", ["enabled"] = true, ["params"] = { ["action"] = { ["id"] = "Option", ["params"] = { ["value"] = 264241152, ["name"] = 10, }, -- end of ["params"] }, -- end of ["action"] }, -- end of ["params"] }, -- end of [6] [7] = { ["number"] = 7, ["auto"] = false, ["id"] = "WrappedAction", ["enabled"] = true, ["params"] = { ["action"] = { ["id"] = "Option", ["params"] = { ["variantIndex"] = 2, ["name"] = 5, ["formationIndex"] = 1, ["value"] = 65538, }, -- end of ["params"] }, -- end of ["action"] }, -- end of ["params"] }, -- end of [7] }, -- end of ["tasks"] }, -- end of ["params"] Or in the task of waypoint 3 and following beginning line 2829: I will check and implement this in a new a version, when I find the time... :) PS: You could try to change these task by looking for IDs and values of these... My theory is that: [3] = { ["enabled"] = true, ["auto"] = false, ["id"] = "WrappedAction", ["number"] = 3, ["params"] = { ["action"] = { ["id"] = "Option", ["params"] = { ["value"] = 4, ["name"] = 1, }, -- end of ["params"] }, -- end of ["action"] }, -- end of ["params"] }, -- end of [3] ["value"] = 4, ["name"] = 1, means ROE Return Fire, but I have to check.

Eno,Good you sorted it out, please report errors or hangs in the script. I hope I get the chance to rewrite the script and make it more effective and a little smarter... only time is the issue... HiJack, I assume you are not you referring to this script (CAP/GCI script)... The Random Airtraffic is simply ambiente, and the planes do not engage actively in combat. I think they are more like drones, don´t know if they even evade incoming fire...

Hmmh, did you crosscheck with the example mission? It doesn´t matter if you declare the strings with ' or with " in the *.lua file, afaik LUA uses both to declare strings. The name in the ME should be without the ' or ". Or you can load up your mission and I take a look, when I find the time.

Sorry, it seems I didn´t update the description in the 1st post, and the description in the *.lua file might be misleading. 'AF1' is meant as a place holder for the name you enter in line 12 to 14. The triggerzone named the same as the airfield, the triggerzone represents and the same as in the script line 12, 13 and 14. So you basically look the the airfields, you want the AI to use for takeoff and landing, enter the name in the script line 12-14 and place a triggerzone with the same name above the airfield.

Besides the usual problems of HI and AI close together, I didn´t have an issues with spawning, while testing.

Thanks for the info, HighwayEd :thumbup: I had chance to check your mission. It should work when you rename the triggerzones over the airfields and give them the same name they have script, in this case "Batumi", "Kobuleti" and "Kutaisi". This is the only and esiest way I found to get the Airfield ID right, which is need to let the AI spawn on the right airfields. You could also use the table posted above, but I thought editing the airfield name in the script and in the ME is easier.

Currently the dynamically adding of objects is problematic, as I understood. In my DCS World installation I feel that crashing planes cause the most of my DCS software issues. So everything enhancing the frequency of planes hitting the ground - and that is what the script is doing. So I would recommend for every missions, which is designed for larger client numbers and longer runtimes - as it is necessary for public servers - to keep it simple and not use any script at all or anything on the map, which is not strictly necessary. But who likes to play in a DCS VOID? So please report back your experience, when you find some time for testing the script in bigger missions. I didn´t test it with Grimes`IADS script yet, but I see no reason they should interfere. My script just makes a table of all units of a certain type and checks every aircraft, if it is detected by these units. If the IADS script switches of the EWR radars it might be interesting to find out, if the script function still detects the intruders. The scripting function "...TargetIsDetected(...)" does only seem to work for ground units. I didn´t get any useful results trying to use AWACS as EWR system, that`s why I used the patriot SR and HAWK SR for the blue side. But if you add the unit-type string of any unit, which has a radar, which can detect aircraft, to the line if possibleEWRunittype == "55G6 EWR" or possibleEWRunittype == "1L13 EWR" or possibleEWRunittype == "unit-type string" it should also add every unit of this type on the map to the EWR system. You just need to find out the exact name of the Sa-10 radar. You can do this by placing such a unit on a map and extract the *.miz file and take a look into the mission file and look for the string in the unit table ...["type"] = 'something'. Tack Tack ;)

Ick bün Hamburjer un wat geiht dik dat an? :P

From this article: http://de.euronews.com/2014/02/05/frankreich-spanischer-frachter-luno-havariert-und-verliert-kraftstoff/

hmmh it worked fine, when I tested yesterday evening. Please try the example miz file and cross check, that`s what I would say. Remember that the other script is also active in the example file. If you have time, you can sent me your mission and I take a look, but that won´t be before someday next week.

That should be easy... Modify the if block in line 2553 and add groupcounter < [choose your maximumg number, here 10] behind the 2 if-checks as condition as following: if (LogisticOrHeliOrFighter == 1 or LogisticOrHeliOrFighter == 3) and groupcounter < 10 --your maximum number then coalition.addGroup(_country, Group.Category.AIRPLANE, _airplanedata) elseif (LogisticOrHeliOrFighter == 2) and groupcounter < 10--your maximum number then coalition.addGroup(_country, Group.Category.HELICOPTER, _airplanedata) end And you have to modify line 2743 and add groupcounter = groupcounter -1: shutdowngroup:destroy() groupcounter = groupcounter - 1 Note that I didn´t test this modification... anything might happen, that`s the fun with scripting... ;)