Druid_

It was a simple fix (lua trigger.setUserFlag is now trigger.action.setUserFlag). At least I hope so. New missions uploaded to first post. Let me know how you get on.

Ok, yep, there have been some changes to Lua script since this was written and probably also slmod (although Speed has made all versions compatible I believe). I will take a look and upgrade it to 1.2.2. Thanks for heads up

My pleasure guys. :) I look forward to playing your missions.

Trouble is your gtx680s don't run well in SLi in DCS. In fact my old 2 GPU ATI card only had 1 core actively running in DCS at any one instance, you might find that one of your 680s in SLi is almost idle in DCS. Nvidia or ATI just don't produce optimised drivers for DCS yet (still hoping!). The test I would like to see would be ATI7970 vs GTX 680 4gb.

@artdeeco. what you are seeing is the L-139 being locked up by the F-15, he gets a launch warning and dumps stores to avoid the incoming attack (standard procedure). Any others not locked by radar and/or fired on may press on their attack but when engaged will do likewise. Perfectly acceptable behaviour in my opinion. In fact if I was in a L-139 and a F-15 got airborne I would be dumping my stores and getting the hell out of there screaming 'help' to the su33s as I went! Changing ROE and reaction to threat WILL change the behaviour of your AI as mentioned. Also use Use Radar NEVER USE at start then changing to ON at a later WP will affect detection (no RWR sig in other aircraft). There are some quirks with the AI and they will never be perfect and occasionally you might find a bug. In the main though I have found it fun to find solutions and more often than not I am trying to get AI to be too damn stupid or my mission logic is just plain wrong.

Ok see attached .trk file (you can also open this in the ME as a mission file to see changes I made. 1 simple change btw). You have 2 A10a's airborne with 1 WP set approx 8 nm from the enemy target. At that WP you have a start enroute task-> search then engage in zone. In my test the A10s got to the WP at which the search then engage in zone logic will kick in, unfortunately you had no additional waypoints so the RTB logic also kicked in. They RTB'd without engaging. Reasons: 1) The A10s in the short time between the search then engage logic and RTB logic did not see the enemy. Not surprising really, I would have difficulty spotting anything from 8nm with the MK1 eyeball ( no targetting pod fitted! ) 2) Search then engage in zone when set as an enroute task will continue even though other waypoints are set afterwards. The problem was you had no waypoints and the nearest friendly base was behind so they turned 180 and therefore had no chance of detecting anything in the set zone. solution: I set one additional waypoint after the lat WP and towards the enemy. Sure enough as they got closer they detected the enemy and engaged. Both aircraft sustained damage and jettisoned stores as a result (standard procedure when engines are damaged), 1 RTB'd and the other continued to press on the attack with guns only. Hope that helps. known bug and reported. Put the wingman in a seperate group and set a 'follow'' action on the lead escort or AWACS. aggressive_enough_4_ya.trk

Can you attach a .trk of this please? Quite hard to reproduce otherwise.

Ok thanks, behaviour is incorrect. Reported to Devs. In the meantime a workaround is to put your 2 F-18s in different groups and set them both to escort the AWACS.

Can you attach your mission and I will take a look when I get some spare time. There is always the possibility that there's a bug that needs sorting.

Not s stupid question at all. Not possible either via script or in ME at the moment I'm afraid.

Damn need to update my drivers ... Loki whats the latest drivers you are using stutter free?

In theory they should work fine however to be on the safe side I would advise that once you have downloaded any mission which was made in an earlier version to open it in the mission editor and resave it. The main problem with older missions usually occur with slight changes in AI behaviour. Its usually down to the complexity and arrangement of the mission. I would say most missions will be fine.

Click on the airfield and make sure to set its coalition. Then make sure weapons are set to unlimited. EDIT: disregard, I see that you say that on e eternal view the weapons exist on the pylons it's just that you cannot load them on the MFD. Is this correct? I haven't had such a problem but will take a look at your mission when I get back to my pc this weekend.

What's particularly interesting in the video series is the redesign of the initial su-27 when it was realised it was no match for the F-15. Their solution was blatently obvious though .. take the best of the initial SU-27 and copy the F-15. E.g. Outer wing, speed brake, flaperons, cockpit canopy etc.

Thanks Kuky. There aren't many testers or players as a percentage of the total that use 3 screens or more so it has been low priority. Especially when you consider the iginuity of modders like yourself, PP etc who tinker and solve these screen problems.

yep it appears that the sounds starts at miz start regardless of condition. I saw this very recently and reported it but it looks the fix didn't make 1.2.2. Look for the fix in an autoupdate at some point.

Looping and client side issues have been fixed in the testers build. Hopefully the fixes will make the next patch. As for the lua problem and incorrect wiki, they have been reported and await fix.

Once a group is de-activated it cannot be activated again. This is a limitation of the miz editor. The best you can do to simulate is to note where it taxied into and shuts down then deactivate it and immediately activate a new unit in its place.

I don't think windows system restore keeps a log of all of the changes done to the various applications installed. So DCSW will remain unchanged. It's more for restoring system critical files. It will however keep track of all windows updates done I believe.

feature requested but I think it will be low priority given everything else that is being worked on at the moment. That said, ED have surprised me before with a feature suddenly appearing. It's all down to dev workload and feature simplicity I guess.

I reported this a while back & it's fixed in the testers version. Distance was increased massively & hopefully it will be fixed in the next version release.

I wonder if its anything to do with the fact that the sound file you refer to in your radio.transmission is not packaged in the miz file. Strictly speaking it should be. On your machine is the sound file used in your lua located in the same folder as the miz file? The radio modulation in the wikki is incorrect, you are right it is a boolean. Also try placing a unit (e.g. radiounit) where you would like the transmission to eminate from and use do local radio_vector = Unit.getByName('radiounit'):getPosition().p trigger.action.radioTransmission('this is hawg request picture.ogg', radio_vector, true, false, 251000, 300) end

Had a few problems when MP testing (possibly related to latest 1.2.1 ver), hopefully rectified. Need to MP test once more. Sorry its taking so long but with RL, family & testing 1.2.2 this miz has been relagated to low priority. I'm almost there though ...honest.

To test correctly you would have to run the script in DCS then reboot pc and run script again.

The trouble is that Local index = math.random(#possible_flags) Without seeding math.random with a random number first will always allocate the tasks in the same order. Maybe you forgot as I know we have been discussing this in the past. This is why my method used ME triggers to randomise and call the lua code. Trouble is, it's messy and uses up a bunch of triggers to do so