Stonehouse

Question (sorry I am at work) Lilkiki made a fire mod which is essentially an invisible static object which when destroyed emits smoke and fire. If one of these was spawned on the runways etc and not destroyed would it block traffic without being obviously visible ie (deactivated airfield) alternatively if they were placed and destroyed so are burning and smoking (destroyed airfield) would that shut down the base too? Mod here http://forums.eagle.ru/showthread.php?t=138241

Don't know if this helps you? Have a look at the script in this thread http://forums.eagle.ru/showthread.php?t=120195

As far as I can tell the getPayload function seems to work fine now. Cheers, Stonehouse

Hi Grimes, Initial quick tests are looking good. The aircraft spawn in much quicker than with 3.6.43 and right away you can see different stores (eg drop tanks) are appearing on planes as well. So I think it looks ok now but will do some more tests this evening and post up an all clear or not tomorrow morning. Thanks, Stonehouse

Just an FYI that I'm getting reports from people that the latest version of Mist - I am assuming 3.6.43 - causes the flak script to stop working. I haven't had time to investigate and report back to Grimes what issues there are but in the meantime and until further notice please use Mist 3.5.37 if you wish to use the flak script in a mission. UPDATE: Further testing with 3.6.43 indicates that the flak script works fine with this version UPDATE2: There were some other bugs with 3.6.43 and these are now resolved with 3.6.44 and therefore 3.6.44 is now the recommended version for use with the flak script.

Sorry Grimes there still seems to be a problem with getPayload. With 3.6.43 I now see the aircraft spawn but they don't move they just sit there. I saw something similar when the template aircraft were set with 0 fuel so my guess is that calls to getPayload now return control back to the GCICAP script but are not returning the actual payload info. I've attached two copies of the same mission so you can see what I mean - it's my test bed mission for GCICAP. The only difference is that I've changed the version of Mist from 3.5.37 to 3.6.43 in the second one. The 3.5.37 one works fine but the other is as described above. <edit> getting reports from users that the flak script gets broken by the latest version as well. Not sure what function is involved and will have to do some digging and report back. <update> testing with 3.6.43 shows that the flak script is fine. User reports are due to timing - they were using 3.6.42 and that one did have issues when running the flak script. 3.6.43 is ok for the flak script and just the GCICAP script still has problems CAPGCI Mist 3537.miz CAPGCI Mist 3643.miz

Thank you! Will grab the new version and give it a go. I know exactly what you mean about common functions. I've got a common pension calc module at work that I am changing and the change is pretty simple but you wouldn't believe the resulting test scope. Sort of 1.5 day build and unit test = 20-30 days system and acceptance testing.

That's a very handy script xcom. As you say balance is really hard to achieve sometimes with a mix of AI and humans and this will really help. Thank you, I will have to d/l it and give it a shot when I get time.

temporary fix http://forums.eagle.ru/showpost.php?p=2354316&postcount=1

See http://forums.eagle.ru/showpost.php?p=2354316&postcount=1

Hi Grimes, Was working from home today and had a VPN outage so while waiting for it to get fixed I had a go at finding the problem with getPayload. I ended up with the following code which seems to work for me with GCICAP and flights are now spawning and taking off with different payloads as per the template aircraft. GCICAP calls the function using the unit name so I have not tested how this will work with passing the unit id instead but think it will be ok. Anyway hope it helps you somewhat. <edit> Just clarifying that the above was meant as me trying to be helpful and not anything else and I guess my point with the above work is that the getPayload function appears to have a bug in 3.6.42 and that passing it the unit name no longer works or at least no longer works as it did in 3.5.37. As far as I can tell the function does not return from being called. Honestly hope it is helpful to you Grimes. If you need me to test or supply more info very happy to.

While trying to gets things sorted out for the B29 crew I discovered that the FW-190 lua refers to a pilot_fw190.edm file for the crew member model used I *think* for the external pilot model for the plane. This file doesn't exist within my DCS World folder tree although the canopy model FW-190-fonar.EDM used during ejection does exist. I used to notice that when the pilot of the 190 bailed they turn into a modern day pilot - wonder if this is the cause and it is defaulting to a place holder model? <edit> Checked today while waiting for a network issue to get sorted. Currently the pilot changes to a modern pilot when bailing out. I copied and renamed the 109 pilot files and now get a WW2 pilot bailing. JSGME ready fix attached FW190 Pilot.zip

Hi Grimes, Managed to find half an hour while waiting for dinner to cook which wasn't expected. Put a debug line directly before the call to mist.getPayload and one directly after. The one before turned up in the log but not the one after so it seems it is calling the mist function but not returning. Do I need to change the syntax for my call to mist.getPayload when using the new version? My call is like the below and hasn't changed for months since using late activation aircraft as templates was implemented. The value of interceptorside will be blue or red and give you a string like "__GCI__blue1" and on the template aircraft this is the unit name. This works fine with 3.5.37. Thanks, Stonehouse

Ok thanks. Work is pretty crazy at present so it'll probably be a few days before I get any real time to investigate but will let you know how it goes. Hoping it is my end of things but basically just changing versions of Mist initiated the problem and reverting to 3.5.27 made the problem go away so logically it seems that Mist 3.6.42 is somehow the cause. Thanks, Stonehouse

Hi Grimes, I'm finding that the current release version of CAPGCI is having problems with 3.6.42 and the symptom is that CAP and GCI aircraft are not spawning. I've not had time to analyse and debug things to find the root cause yet (my hunch is getPayload but it is just a hunch) but wanted to ask if you had the expectation that your changes in 3.6.42 were backward compatible or that we definitely needed to make changes to/review our scripts to ensure they comply with Mist going forward? Thanks, Stonehouse

Please note I have discovered that there is an issue with this script and the latest version of Mist. Basically CAPs and GCIs do not spawn with 3.6.42. Please continue to use Mist 3.5.37 until I've had a chance to figure out what is happening. Thanks, Stonehouse <edit> there appears to be a problem with the Mist function getPayload in version 3.6.42 in that passing it a unit name no longer returns the required information to the GCICAP script - as all GCI and CAP aircraft use this function to pick up payload info from template aircraft this breaks the GCICAP script. Grimes has said that it was intended to be backward compatible so I'm hoping he'll have time to look into it soon and allow people to avoid having to keep old versions of Mist just for GCICAP. Thanks

Ok went back to my mission in progress and removed the flight for the seemingly umpteenth time, saved it, added them back and this time it worked so no script clash but perhaps the sequence of steps I used is the cause?? Anyway problem solved even if not explained.

Ok just tried it with the same mods but no scripts and it worked fine. So......script clashing??? bugger

I'm building a new mission and have a 4 ship of P51s which are tasked with an armed recon mission but begin the mission as uncontrolled and then have a triggered action to start. Then have a mission trigger to actually make the action happen - all very normal way of having a group of apparently static aircraft start up and take off. Only thing is I am noticing that only the first aircraft in the group will start it's engines while the others get a pilot and turn on their lights but won't start. This means the flight never leaves. No mods are on except More Visibility and the B29. Mission is using latest version of Mist, flak, GCICAP, AWACs, bombing scripts which other than Mist's latest version I've all used previously without issue. I will try on just an absolutely vanilla mission when I get a sec to rule out mods and 3rd party scripts but just wondered if anyone else noticing this on the current patch level of DCS? Wondering if a bug has been introduced with the last patch. Thanks, Stonehouse

Wind direction will change the direction of take offs and landings - does that help you any?

Nice work Starway. One thing I noticed although it's no biggie. You have left the LandTexturesAutumn as a zip file rather than a folder which is the usual way with these sort of mods. Anyway easily solved either way by the user. Again nice work. Cheers, Stonehouse

Have a look through the CAP GCI script for examples of this kind of thing. Basically you can use an events and an event handler to check for aircraft that land or ones that crash (which is an actual logged event). There are a stack of different event codes for different things.

That Lancaster is a beautiful thing! I hope that it somehow ends up being allowed out into the wilds of DCS public life. Having an AI bomber to escort would make a huge difference to WW2 missions. Even static WW2 era aircraft would make a huge difference.

With the release of the Vietnam retexture of the standard map and being completely talentless in skinning I wondered if there was any chance of getting one or more of the very talented people here interested in a Hk-61 style skin for the 109K (yes I know only Es got sent to Japan for research but we have what we have) and a GM21 (Betty bomber) skin for the AN30? I was thinking these would serve for creating Burma style missions on the Vietnam retexture. Any interest? Cheers, Stonehouse

Did you realise you need to use summer for the mission to see the desert textures? Might be the reason you're not seeing the desert terrain if you have the wrong season. It definitely works with the current patch level - I was building a mission on it this morning.