Stonehouse

I'm guessing that all it needs it the appropriate dds file/s in the zip file of textures for the Spit modified but I don't how to do it. Once we had the modified items you could use JSGME to have the cleaner hood or not as per the recent prop mod to help FPS. On the dirty glass being authentic - again I could be wrong - but in the RAF or RAF like air forces I believe the erks were assigned specifically to one or two pilots and if they left the canopy dirty and it wasn't a very quick turn around refuel and rearm (meaning not enough time) they'd get a bollocking. Similarly if the hood didn't slide perfectly easily.

Is there a kind graphics artist out there that can clean up the sliding hood perspex please? I could be very wrong but I was under the impression from my reading of historical accounts that particularly the ground team for an aircraft/pilot in the RAF made a solid attempt to keep the glass as clean and clear as possible before every flight as during wartime specks and dirt on the canopy could = someone getting shot down because a distant contact was obscured or even ignored because it was thought just dirt. I find it makes it even harder than usual to keep track of contacts at a distance because of the dirt. I'd fix it myself if I knew how. Thanks, Stonehouse

Perhaps it is possible to just do the same trick as for the terrain mods? Have a folder name the same as the zip file and just have the modded dds files in there and they will be loaded in preference to those in the zip file? <edit> yes it does seem to work doing a quick test and also this allows easy use of JSGME

Ok I tried adding that exact code set to a mission on a once trigger on time +10 as a do script. It didn't crash even though I had a single blue Mi8 (only unit) in the mission. Give it a go and see what you get so as to compare. If you don't get a crash either then it seems that perhaps the groups table is not getting populated properly when running in the auto ground script. Possibly the #groups is getting corrupted and is therefore the loop trying to address a non existent table entry and then the getUnits() is being passed crap and crashes as a result. Changing to a pairs loop would stop that from happening. <edit> just tried again quickly before I go and work on the house. Added a couple more Mi8s to the group for 3 helos and a group of 3 A10Cs. Still no crash on that code set for me <edit2> sorry brain dead. you set the groups table just prior to the loop so my earlier comment about #groups makes no sense.

Not sure. Can you make a copy of it, edit it and make your only change be updating to Mist 4.3.74 and then try to run the edited mission and see what happens? It may be Mist related and not DCS after all.

Perhaps the tables need to be traversed using pairs rather than for i=1,#whatever? Particularly as units get destroyed.

OK considering it used to work without crashing and that the GCICAP script has not been updated the logical implication is that DCS changes are connected to the problem. So as I said people should create a thread over in the release bug area to ask if it can be investigated to confirm it is a bug and if so rectify it. However please be sure to have no mods loaded when generating the logs of the crash and the mission itself as having any mods on will obscure the matter. ie raise questions as to whether it is the mod or DCS possibly being the root cause. Obviously attach the mission and logs to your post in the bug sub forum. Think Big Newy has a link to guidelines for bug reporting in his sig.

hmmm I'd be really interested in that. I'm the XO for the virtual RAAF No457 Squadron which was set up back in 1999 for flying IL2 and has been transitioning to DCS World for quite a while (the Cliffs of Dover debacle moved us to DCS mostly but most of our members are pure WW2 only so the journey has been a long one relieved occasionally by CUP and Team Fusion patches. Only about a quarter of us like modern era jets). Our CO and resident graphics artist is No457_Squog if you wanted to get in touch with him (via PM) and collaborate in the work of creating 457 squadron skins. S!

Passing thought - you could possibly pick and choose buildings from the map that are in an older style or wood or prefab metal workshops etc and instead of deleting edms replace them with another one to generally give the map an older feel by copying the old style building edm to the filename of the building you want to "remove". If you did it all through JSGME you'd be able to easily switch back and forth. Might not get 1940s but you probably could achieve early/mid cold war era.

Thanks Zubetto for the great work. Would have said so earlier but you just can't sidestep Christmas for DCS ;D lol I'll be adding it to our group's training map so hopefully will be able to report back about how well it works when we first fly it in our initial 2017 flying night in a few weeks.

Just the usual mist github site https://github.com/mrSkortch/MissionScriptingTools/releases/tag/4.3.74 Though looking at it properly now it was sept 2016 so you should have seen it already but it happens sometimes that people don't keep up to date. Know it's caught me once or twice.

OK if the crash is consistent and repeatable with a simple pure GCICAP only set up probably start a possible bug thread in https://forums.eagle.ru/forumdisplay.php?f=487 and attach your logs and the mission and the details. I did see that there was a recent hotfix to mist so just be sure that you are using the latest one before you post. Pikey/ gromit190 if you can do the same thing with the autonomous ground script and/or CTLD in his thread that would probably help ED see that it isn't just a GCICAP issue.

Not really script errors per se. Seems similar to the errors recently seen in the autonomous ground force script by gromit190 https://forums.eagle.ru/showpost.php?p=2997393&postcount=23 I can't decipher what you are showing - which is basically a dump listing - all I can say really is that I think DCS is trying to write to a location in memory that is locked/unaddressable and so fails. I would suggest making a copy of your mission and take out everything but the GCICAP set up so it is just the bare bones and then test if you still get a crash at the same point. If you do it is probably worth opening a post in the bugs thread as it may well be a DCS bug or something has changed in the last few patches to render GCICAP unworkable in it's current version. Putting in a bug thread with the logs and mission attached may get other more knowledgeable people involved. If you don't crash then it implies that some of the other objects or triggers or scripts etc etc are causing the problem so you could then add them back a few at a time noting what you add each time and after each addition run the mission. If it crashes then something in the last added set is the culprit. If you wanted to then you could remove the last set of things and add them one at a time noting each until you get the crash bug. This would imply that possibly the last thing you added was the cause or perhaps the last thing added creates a fatal combination. In any case this would be more info for your bug report and help the ED guys locate and fix the issue. I guess you could also PM lukrop to see if he is able to assist you.

Ciribob perhaps makes a local copy of mist in CTLD eg local _mist = mist and then all calls to mist are made using the local copy as this improves performance (local versus global is quicker) eg _mist.utils.tableShow

+1 to the sticky request. Really nice work!

Thanks Grimes.

Def there is a bug in getGroup, the script successfully passes a built in error/warning (ie something to help you spot where you haven't named a template correctly) a few lines before the template_group = mist.getGroupData(template_unit:getGroup():getName()) line is executed and therefore you know that a badly named template aircraft is not the reason for the error. Pretty sure it will get fixed relatively quickly as it is causing problems in paid DLC campaigns as mentioned in other threads.

Only guessing but I would assume a new version of the mission has been uploaded so you would download it and replace the version you are using?

Wasn't quite what I meant but still a good thing! This will allow players to have different traffic in different localities for instance. ie players go over the mountains and a trigger etc loads a different AT_ROUTES file. I assume you are rebuilding the tables holding routes and aircraft when a new AT_ROUTES is loaded. What I was thinking was more an additive thing where you might have say a civil AT routes file in your library and a military one and perhaps a helo one. Rather than have to build a new one that encompasses all of these it would be nice to be able to plug in each one as a DO SCRIPT and have each add entries to the table. lol probably asking for too much sorry but better still if you could do what you have already done and what I was meaning and control it all via a global variable that you set on the trigger action to say add the AT_ROUTES file to the tables or clear and replace. So have the default as perhaps replace but allow us to have assign a value to a global var on the trigger action prior to excuting the DO SCRIPT that tells your script to add to the tables instead of replacing. eg the trigger action becomes: DO SCRIPT( do addtotable = true ATR_ROUTExyz.lua end) There are probably a few different ways to pass the flag I guess. You know you could probably convert this to also handle ships etc and have a shipping traffic generator or ground vehicle generator as well.

Very nice ideas particularly the call back part which I had not seen previously and looks very powerful. Thank you. A couple of clarifications please though. It looks like the mission AirTraffic_Sochi_Test.miz is using AT_ROUTES_URSS_002.lua as a template for aircraft and routes? But the steps you list above seem to say that if we create a mission and place aircraft we want for air traffic as single units, set appropriate livery etc and place ATUF or ATUB in the TAIL# and give them a flight path from a base to another base and call the mission zATR something and then run it your script creates a new lua file in the user scripts folder call AT_ROUTES_something.lua? Do we need a mission start trigger in this template mission or does your call back function take care of that by recognising the zATR prefix and parsing the template mission to generate the AT_ROUTES_something.lua file? From that point on, you have airtraffic for a particular set of routes and aircraft defined and so to add that particular set up to a new mission you just add a mission start trigger that has the actions: DO SCRIPT FILE(AirTraffic.lua) DO SCRIPT FILE(AT_ROUTES_something.lua) DO SCRIPT FILE(zAirTraffic.cou) DO SCRIPT FILE(AirTraffic_ini.lua) Therefore once you are happy with an air traffic setup (the routes used and the planes you get spawned) you can reuse that same setup for multiple missions just by referring to the AT_ROUTES_something.lua file. Have I understood ok? Thanks, Stonehouse PS Passing thought.........would it possible to allow multiple AT_ROUTES files to be read? That way you could have layers of air traffic defined in separate AT_ROUTES and get a different feel to a mission by plugging in different mixes of AT_ROUTES from a library of air traffic setups? PPS - if I create a mission using this air traffic functionality and then say post it up on DCS user files does the end user need to have zzz0001_ATR_GameGUI.lua file in their user scripts folder to make the mission work?

Posts in the MIST thread about others having getGroup issues seem to indicate that the problem lies there.

Also seeing reports of getGroup problems https://forums.eagle.ru/showpost.php?p=2989286&postcount=892

FYI I have seen reports of problems with this script on another forum. Mission in question works prior to the last patch but doesn't afterwards - I think the person is using the beta but I am not sure (I've asked the question but haven't heard back). The issue seems to be getGroup is not working for the template aircraft. The error seen is that the getName in line 1513 fails. However I can see in lukrop's code that a Unit.getbyName works ok for the template aircraft in question so at present the theory is that getGroup is working differently for late activation units after the patch. If others are seeing the same issue then possibly a bug was introduced by the patch. template_group = mist.getGroupData(template_unit:getGroup():getName())

Thanks doom! Lots of interesting stuff in there.

Yeah meant mission editor sorry. Getting lazy in my dotage. If you want me to have a look that's fine just PM the link but as I told Hawkeye for his releases I'm going to be slow getting to it as I'm up to my neck in house renovations (as usual when I have more than a week of leave..........hmmm bad habit doing that to myself but I think the saying "happy wife happy life" applies)