Stonehouse

Hi matador, That's a 1.2.16 mission but the mist version you are using is the one Grimes built for 1.5beta - so I am not sure if it is compatible. Maybe ask over in the mist thread if what you are doing is going to work or perhaps first go to Grimes Github site and grab Mist 3.7.51 or whatever was the latest prior to 1.5 beta being released. Give it a try and see if that sorts it out. Cheers, Stonehouse

Ok thanks Grimes. Will try and get my brain around it.

Does that mean I need to insert the entry to the table differently too? Just thinking if the table is going to be missing indexes I am guessing #table + 1 won't work anymore? I guess that is also why when I deleted an entry like I first tried landing events wouldn't add an entry anymore? Is that where I would use table.insert? If the old entry looked like: landedaircraftsING[#landedaircraftsING + 1] = {groupname = actuallandinggroupname, unit = landingunit, unitname = Unit.getName(landingunit)} would the table.insert version look like table.insert(landedaircraftsING, {groupname = actuallandinggroupname, unit = landingunit, unitname = Unit.getName(landingunit)}) <edit> or table.insert(landedaircraftsING.groupname, actuallandinggroupname) table.insert(landedaircraftsING.unit, landingunit) table.insert(landedaircraftsING.unitname, Unit.getName(landingUnit)) thinking about it feel this is correct? Thanks Stonehouse

Ok I've run into a problem that I can't get around because I don't understand enough about arrays as tables. I will keep on looking but thought I would ask here in case someone can short circuit things for me. So in simplified terms On a LAND event in an event handler I put an entry in a table containing details of the unit that landed via table[#table + 1] = {blah blah} In another function I am reading through the table and if the unit's absolute value of velocity is < 1 I am despawning it. So For i = 1,#table do figure out absolute value of velocity if absvel < 1 Unit:destroy() end end Thing is over time this table will get bigger and bigger each time a unit lands. However if I do a table = nil or a table.remove(table, i) right after the destroy or even later in the function doing the despawns no further entries are written to the table by the LAND event. I assume that the pointers to the elements in the table are getting screwed up by the removal of the entry and so the next time a LAND happens and #table is evaluated it has problems. Obviously I don't want the table to continue growing but I can't see how to remove the entry without breaking things. Any advice or tips please? Thanks, Stonehouse

It's probably just a wiki update - of course assuming I'm not misunderstanding things - but the event table seems to have changed structure in 1.5. I'm debugging an issue around auto despawn of landed aircraft in GCICAP and am finding that the event table now looks like the below for a LAND event: initiator according to the wiki seemed to have been the unit id whereas now it is a table of ids. Does this mean in future if two events of the same type happen at the same exact time there will be two entries in the initiator table as well as possibly two entries in the place table? or will there always be two entries in the events table? Also the initiator id value doesn't seem to be a unit id??? Pretty much I'm storing the event.initiator value in a table ie landingtable.unit = event.initiator and then later on trying to do a landingtable.unit:getVelocity() - which used to work but now am obviously finding that landingtable.unit contains a table not a unit id so the getVelocity just bombs. Any clues would be very welcome <edit> Ok really confused now. Trying to test event table coding using the BIRTH event as that's quicker than LAND. So have the following code: Getting an error now that string.format(airspawnunit) is failing because it is getting a table. Has Unit.getByName always returned a table? What does getVelocity() require? Unit or the unit id? Thanks, Stonehouse PS @moderators please move this over to the Mission builders corner if it is becoming something unrelated to 1.5 beta ie If it's due to me misunderstanding which is seeming to be more likely. PPS ok it is me, finally seem to understand that Unit is a collection of attributes (class finally clicks with me) and ID is just one of the attributes. So I am guessing that the id listed in the event table is actually a reference to another table internal to DCS that holds all the units. Mods please DO shift this over to the Mission Builders corner if you think it will help anyone else or delete it as you see fit. Apologies for wasting space here.

Thanks Grimes. I have another question around events - which is probably just a wiki update but will start a new thread.

I did do a search but found nothing but these may have been mentioned in one of the 1.5 related youtubes that I haven't really caught up with yet so if that is the case apologies. Pretty much was looking for more info on the only designated and priority designated ROEs and whether they are fully implemented yet? Mainly interested in the second one if it works as I hope it does. Looking through a _G dump I only see the standard ROEs and their internal values. I can see the new restrict AB options etc however so does this mean the new ROEs are still WIP at this time? Thanks, Stonehouse

It is fixed in 1.5

lol don't know about considerate, more selfish really as if I miss things by being deliberately slack then it only comes around again :music_whistling: More helping you guys helps myself.:D

Sorry, news is still that it's getting there. Testing continues around some issues trying to sort them out before I pass it on to others. Hoping to avoid other people getting headaches and stress from using it.

Just an fyi that this one is solved or at least semi solved with Grimes's help. Basically it seems that the ["parking"] should be left off or must be a unique reference for aircraft spawning via a script if you don't want planes parked on piano keys on the runway.

No problem, sent you a PM with a download link as well as description of how I have been running the test. As stated in the PM if you need anything else let me know. Cheers, Stonehouse

Ran it today on a vanilla 1.5 beta setup, just Mist and GCICAP scripts. Sent groups of intruder aircraft over the red border in sufficient numbers to make sure a GCI group was spawned. First two groups that spawned included one with the piano keys spawn. You can see these planes highlighted on map view in the attached. DCS.log also attached. I closed the mission down shortly after taking the screenshots. Let me know if you want anything else Grimes. Cheers, Stonehouse dcs.txt

The script is using coalition.addGroup if that is any help to you. I can pm you a link to the latest beta if that is of any assistance as well. It seems to happen pretty much every 2nd or so time I test run my unit testing mission. Usually the GCI fighters launching to pick up an intruder the CAPs can't cover. lol just promise not to laugh at my lua coding skills or lack thereof <edit> run it again to check something else and at time accel got the same thing within a short time - as you can see about 8mins in from mission start. You can see that the other plane in the group has just taken off and some others are about to but the remaining aircraft in the highlighted group is sitting on the piano keys again. Again the airfield uses HAS although as said before that could be unconnected and a red herring. I am using the more vis mod and Ajax's awac's script so will try again tomorrow (near midnight for me) with both turned off and plain vanilla DCS 1.5 beta to ensure there is no sneaky issue being caused by either an leave only DCS, Mist and the GCICAP script as possible source of problem.

During testing of the GCICAP script I have noticed that 2nd wave GCI and CAP fighters which spawn in "ramp" mode at an airbase occasionally ends up with most of the aircraft correctly in their parking spots and they taxi out fine but one plane will spawn on the runway piano keys always seemingly pointing at the taxiway. By the time I see it and check it in F2 view it has engine running and lights on but never moves even though the rest of the group taxies out and takes off from the opposite end of the runway. Happens to both red and blue factions and seems to happen on airfields using HAS for parking spots although that is conjecture on my part and not a confirmed observation. The script uses parking bays 1-4 and I am assuming DCS will move the plane elsewhere if the bay is already occupied at time of spawning and perhaps might have a bug at present?? Perhaps it no longer is correct to nominate parking bays for script spawned aircraft? I remember seeing another post about parking bay issues but searching Bugs and Problems didn't find it for me. I don't recall seeing a post of the same issue as I have experienced so thought it best to mention it. It is repeatable and I see it quite a bit. If already reported or my error please close/delete post. Cheers, Stonehouse <edit> Thanks Sithspawn or whoever moved this post, sorry I wasn't sure where to put it as it didn't seem a true mission editor issue as such or a game performance issue so stuck it in general questions for want of a better place

Ok thanks. I'm updating the manual for GCICAP and waypoint speeds are now a mission designer parameter so wanted to make them aware that script parameters are in knots and whether it was iAS or true.

I've checked through the M-E manual and done some searches here in this sub forum but can't find any info so far. Does anyone know if the speed entered in the M-E for a waypoint is true ground speed or iAS? I am assuming because it doesn't say that it is true ground speed? Thanks, Stonehouse

Another update for you. I hope that all the major issues have been resolved. The insubordinate CAP flights now use a racetrack orbit and so far seem to be behaving. The GCI messages work fine for players in the cockpit but still spam people in Gamemaster and observer slots. Plus quite a few new features and old things reworked a bit. Not sure if the recent hotfix for mist changes anything but will check during testing. Which is were it is up to now. I have something I hope is a suitable release version and going through the testing process to try to ensure no issues or at least no major ones. Manual has been redrafted and is parked while testing is going on in case there needs to be revisions and final proof reading to try ensure it makes sense and also is clear in it's instruction on how to do things..........So new version should be out soon unless the tests show up problems. Cheers, Stonehouse

I believe (from what I've seen) that the waypoint where you declare the orbit and the next waypoint forms the long axis of the racetrack and you can't define the width. Generally it seems to work pretty well so far for me though.

Thanks Grimes, much appreciated

Trying to think outside the square with the issue with CAP flights not following waypoints properly and was thinking to try setting them up to have a spawn waypoint and then a orbit waypoint in their cap zone. So I have been in the M-E trying to set up orbit waypoints but so far don't seem to be able to get anything else other than a circle in the drop down list. Even for a KC135 which I could have sworn had the ability to fly a racetrack orbit in DCS. Is there a trick I am missing to make it accessible? Seems to be the same in 1.2.16 and 1.5 beta

Ok attaching my dumps of the CAP aircraft groups data used to spawn them using addGroup. If Grimes and some other people who are up on spawning units via add Group can check them over and offer feedback on where there might be issues it would be really helpful. Generally barring the difference expected due to aircraft name, altitude etc they look as I expected to see but then again I'm still learning this stuff so more experienced people's comments are very valuable. Thanks, Stoney CAP-blue #1.lua CAP-blue #2.lua CAP-red #1.lua CAP-red #2.lua

Ok thanks Pikey & Snafu for the feedback on the wayward groups. I am going to use the debug utilities to dump the table being used by the coalition.addGroup to a file and that should prove it once and for all. I will post up the file when I've had time to generate it and hope some people like yourselves and Grimes and other lua fluent people can look it over for possible problems. If nothing comes out of it then I'll switch to cleaning it all up ready to publish it. I have a few more things for the near future but I might leave those until after 1.5 leaves beta. lol I mean I would actually like to fly the P40 when it comes out rather than script/test/script :smilewink: Files here http://forums.eagle.ru/showthread.php?p=2518314#post2518314

I haven't been able to figure out why the CAP groups head off for the horizon yet but while working on it I have found that it seems the AI pilots hit the bar before flying. I've retrieved the waypoints being generated and via cut and paste put them into a dummy mission and checked that they are all within the CAP zone and watched a plane fly them perfectly. I have also double checked that the zone radius is being reported correctly and changed the waypoints from turning points to fly over points and this last has improved things but...they still end up flying to the border of the zone even though the waypoints are within 50% of the radius from the center of the zone. eg and Is it just that a 50km radius zone is too small for the Ai in a Mig15 and they can't turn fast enough to follow the route? But then why did the plane in the cut and paste mission fly the points exactly? Other than that they seem to stay roughly within the zone but it is weird that they are so sloppy. Any suggestions to get them to sober up?

Really impressive stuff Ian.