Stonehouse

That is good to know. Wonder if the AI does as well.

Some editors like pycharm and LDT have lua plugins that allow you to check syntax.

Possibly the endurance is still to be tweaked for the final version of the Spitfire. Looking at the lua, the av fuel consumption in the Spitty is 0.302 kg/s so for 247 kgs of fuel I believe it's too high. Not sure if this number is only for the AI or just a mission planning number for the editor. I understood Spitfire IXs had about an hour and a half on internal fuel at cruising speeds of about 400 kph for a range of around 600-700 kms. The lua actually quotes 1015km for max range for the Spitfire for the ai which sounds about right for when drop tanks are used or perhaps the ferry range. So based on about 90 mins endurance on internal tanks I would have thought this would mean an average fuel consumption of about 0.04-0.06 kg/s instead. No expert for sure so probably someone will correct me and there is likely much more to the calculation or this number in the lua doesn't have any real effect and it is one of the engine numbers instead that dictates range. The 247 kgs of fuel is correct based on http://www.streamline-ops.com/en/info/fuel_weight_conversion_tables/ and a factor of 0.72 to convert from litres to kg for avgas and what I have seen for Spitfire IXe fuel capacities and so maybe it's just that the consumption numbers are too high at the moment. I know if I build a mission where an AI takes off from the coast in England and tries to reach the beach head area they turn back when they get about 3/4 of the way there which I believe happens because they think they don't have the range. I don't that this was the case in r/l but again I could easily be wrong about that too.

Late to the conversation, had internet problems on top of a few other real life issues. The idea of starting the planes as uncontrolled essentially static objects was actually done by another old GCI script by RagnarDa. As people have pointed out it did have some nice things about it as it meant that destroying the aircraft on the ground had an immediate in game effect. For what the new MOOSE functionality is doing you'd have to despawn aircraft on shutdown after landing and then respawn them as uncontrolled. Is there much difference between a static object and an uncontrolled aircraft from a performance point of view? Might also simplify logistics for you FC when you get to it.

Unfortunately it looks like the new model textures that DOL worked so hard to give us have a problem in DCS 2.1 - I see the B29 as a pinkish orange aircraft. Hope you see this DOL and can figure out what needs to change to make it ok. Cheers, Stonehouse

This one might help you out https://forums.eagle.ru/showthread.php?t=178895

Ok for your mission a few minor things. * Don't put time more 5 on the flakmgr trigger, best for it to run immediately after the mission actually starts. Note that a mission start trigger will actually fire before the mission begins. If you want to control when a flak zone becomes active then add conditions to the relevant trigger for the flak zone. * use lower case do's and end's *flak zones were 2368m or something like that. Note that this limits the height that a tgt will be engaged at. Set the zones at around 8000m to correctly represent Flak 36/37 88mm. The main problem seems to be that even though you had a do script for MIST it was not being loaded. I found these errors in my log: These indicate to me that MIST didn't get loaded. I believe the problem is the filename used for your copy of mist. You used MIST.4.3.47.lua as the filename I believe the DO SCRIPTFILE is having trouble understanding this because of the extra "."s. My copy of MIST 4.3.47 is named MIST_4_3_47.lua and when I used this everything worked fine as far as I can tell.

Apologies Mustang but getting the "Invalid or Deleted File." error for the link you just posted. Anyone else with the same problem?

Can't see the images of the units. <edit> FlightControl, could you please replace the embedded imageshack pics with just attached ones? I don't have either an imageshack login nor do I use facebook and therefore cannot see the pics you've added to your post. I'm pretty sure I can guess what is in them but would like to be sure. I believe while that's probably not the average these days I do know that I'm definitely not the only person in that position who uses these forums so it would likely help more than just me. Thank you.

Yes we certainly are although the group is not as large as IL2 days. We've been active for about 17-18 years running now. I've been XO since about 2010 ish. Agree, it is sad to see the local community shrink over the years. I do occasionally see posts in these forums from ex members, it is always a good moment to see that they haven't lost their love of combat flight sims even if they do their flying elsewhere these days. Cheers, Stonehouse

Perhaps post up the mission and someone can try to help you look at it?

Interesting thing, took T}-{or's 18plane3element mission, moved the raid back to around Cherbourg and did nothing else than add 3 planes to each group for a total of 72 aircraft. Ran the mission and very unexpectedly I got 4 combat box formations rather than what I thought I would get. It took a little while for the formations to close right up but in the end you got a very nice 72 plane raid and a lot of bombs. By the way don't use time advance at too high a rate (ie more than x2 or x3) as the alpha doesn't cope very well (or didn't on my machine anyway) and you get problems.

RE GCICAP - Most likely culprit is the airfields & zone names. There were issues when NTTR came out as well. For simple CAPs you might be better off with MOOSE. The only thing really missing from MOOSE these days is GCI guided intercepts and packaging things into one dropped in module ie MOOSE requires some reasonably simple scripting. I will try to find time to look at the GCICAP issue but my schedule is quite tight these days.

Just confirming that I have run a simple test mission this evening with a 16 ship B17 formation and used the latest Mist and the flak script from user files - flakv3.4 and it works fine for me. Only issues I found is that the B17s make avoidance manoeuvers and break formation when the flak is close enough to damage them and that if I used a single flak regiment (addtgt with 6 batteries ie 24 guns in 6 groups of 4 as per the readme in the script) and high skill that the 16 B17s were very quickly decimated flying at 4000m. Admittedly 13000 ft is a bit low for a raid into Germany but they did fly at that sort of height for raids into coastal France attacking harbours and rail heads I believe. I'm not sure if that apparent increase in lethality is because of the change from strength to volume in the trigger.explosion action or just something else patched in since I released v3.4. If I get time I will have a look at it and maybe tweak the accuracy and damage and also make a couple of easy changes I have had in the pipeline for a while now that improves the performance of the script a little. So I'm not sure what the issue was for you mrsteel, but I don't believe it is the flak script or mist at fault. Cheers, Stonehouse

Pretty sure the entry in user files contains the latest published version. The version of mist used in the example mission though will be out of date as you mention. Usually Mist is backwards compatible so it sounds odd that you have had issues. I have not had any other reports of what you experience under 1.5.6 or the NTTR map prior to last weeks patch so possibly it's a DCSW 2.1 bug/scripting engine change. I was planning to try to build a test Normandy mission this evening so will investigate and see what happens. As far as controlling when the flak fires simply enhance the trigger condition to meet the situation you are after. ie The standard trigger condition is one or more enemy a/c in a named zone. So just add additional evaluations to the condition to meet your requirement. eg you might have the standard enemy aircraft in zone and time more 600 so for the first 10 mins of the mission the flak would not fire or some other combination. One I have often used is to add a ground unit or structure to represent the battery fire control and target director and make it so if it gets killed the flak stops firing. So the condition becomes enemy aircraft in zone and director unit is alive.

Until the actual flak units for the WW2 pack are patched in you could try this to simulate it https://www.digitalcombatsimulator.com/en/files/683612/

That's kind of what I have been saying. You would probably want to record any hit event on the aircraft you are interested in (ie the 109s) - Pikey's example gives you this sort of thing. But then you need to look at them in the order they happen in as soon as possible after the event happens and after each evaluate if the P51 was the initiator and if the target is 0% health (ie dead 109) and then if that is true send your message. To complicate matters I think that a pilot kill doesn't equate to the unit health being 0% but perhaps you could ignore that as in real life a plane with a dead pilot will fly on for a little while depending on a few factors and possibly the P51 pilot won't be sure that he's made a kill. However if he sees the plane on fire or blow up or the pilot bail out then he'd send the message that he has made a kill. It sounds like a simple thing but it is actually quite complex. From a script point of view the most straight forward would be for each hit event on the aircraft of interest, check the initiator. If the initiator is one of the P51s, check if the 109 is dead. If it is then issue the message. You may need to record the fact that you have sent a message about that 109 so that you can check for that being done and not send another. For instance if the P51 shot a burst of 30 rounds at the 109 and the 15th round destroyed it but more rounds of the same burst still hit the 109 you would not want to issue messages for rounds that hit after the 15th. <edit> maybe if the mission you are building is fairly simple then you can approach the problem from a different direction and apply a degree of abstraction to avoid building a complex script. Assuming you can manage where and when the engagement takes place, perhaps you could use two mission triggers - the first checks for a P51 shooting AND a 109 being hit. The second is only done if the first is true, this checks to see whether a 109 is dead. If it is then issue the message. You would want the second condition to be evaluated either switched or continuously (you'd need to experiment to figure out which) but the condition could only be allowed to be true once or else you would generate the message more than once for that 109. I think this could approximate what you want to have happen as long as you've managed the situation in the mission, it may take quite a bit of tweaking to get it doing what you want most of the time. I'd suggest trying to prototype it with a single P51 and a single 109 and if you get it working then expand it to cover the groups of planes.

Just an fyi, when I wrote the flak script I tested in the editor trying to pick an explosion strength for the trigger.action.explosion. I did this using the EXPLOSION trigger action (as I assumed it was the same as the script version) and varied the strength from 1 upwards. I definitely noted that there was a damage radius that increased with strength. Checking today as I was posting this I see that the labels for the EXPLOSION trigger action (as I recall anyway) seem to have changed over the last year or so and now where I recall seeing STRENGTH the label has become VOLUME. Maybe under the covers this was always the case and the label has been updated to better represent what happens? Ditto for the EXPLODE UNIT action. Are you able to provide any info or find out Sith as to what actually happens for these actions? Is it the same uniform explosive force but the volume it fills is configurable? or something else? I've been working on a new version on and off for a long time based on world.searchobjects rather than the MIST units in zone and without actually thinking about why, I did find that the explosions seemed to act differently in test missions and I did end up increasing what I thought of as the strength value. No eta for this by the way as it's very much more off than on. Is there any info you can provide as to whether the in game graphic will eventually scale based on the volume rather than the current 1.5 situation where I believe (but am happy to be corrected) the same explosion graphic is used for all strengths/volumes? Thanks, Stonehouse

Hi Veteran66, Sorry been very flu ridden last couple of days and still am pretty miserable. So you have sorted it out to your satisfaction? or are you asking if the UNIT SHOOT + UNIT DEAD method is ok? If the latter then it will probably work most of the time but there is nothing there that guarantees that the P51 didn't shoot at something else at the same time as flak blew the 109 to pieces. All it checks is that the P51 fired and that the 109 is dead. It doesn't check to see how the 109 died and whether it was the P51 that killed it. Anyway hope it works for you. PS make sure you use a ONCE type trigger or else once the 109 is dead you get the message every time the P51 fires.

Yeah but according to your post and as Pikey says the complication is that you want to only send a message/sound file when the target aircraft is destroyed by a particular set of attackers and no other ie any one of the P51s destroys one of the 109s. Pikey's example is essentially the script version of the mission trigger thing I'd already mentioned. You need to expand it slightly using some of the other things passed back in the event table entry by S_EVENT_HIT: http://wiki.hoggit.us/view/DCS_event_hit Event = { id = 2, time = Time, initiator = Unit, weapon = Weapon target = Object } So you'd be checking on each and every hit event whether the initiator was one of your P51s and whether the target was one of your 109s. This could be pretty expensive code to run if a lot of things are firing at a given moment as it applies to all hit events even no lethal ones. eg a ground machine gun fires at a truck 100 rounds and 20 hit so that is 20 hit events, at the same time a 109 attacks another plane and hits it 15 times so 15 hit events, likewise at the same time one of your P51s fires at one of the 109s we are interested in and scores 10 hits but doesn't kill it. Still 10 more hit events. I believe that from an event handling point of view all the hit events are the same and it is only when you look at the details you can differentiate between them. You might be able to make it less expensive by somehow linking it to S_EVENT_DEAD and S_EVENT_PILOT_DEAD (from memory if the pilot is killed the aircraft is not dead until it hits the ground so you need to check both although it has been awhile so I could be wrong) so that when something is destroyed you then check the hit events to see what killed it and issue your message accordingly. Tricky thing there is the hit event is likely fractionally before the dead event. A better way might be to hand off each hit event's details and every pilot death event's details to a scheduled function that runs every two or three secs and it checks the hit event to see if the initiator is one of the P51s and the target is one of the 109s. If it is you can then check to see if the 109 has a health of 0 or a corresponding pilot death for it and if has issue the message. You'd probably have to add the details of each event to a table and pass that table to scheduled function. Once the scheduled function had processed a table entry you'd need to remove it so it doesn't get looked at again and also to avoid the table getting too large and making things get slow accordingly. Anyway some flavour of this sort of thing might do what you want. @Pikey - does MOOSE already have that sort of thing built in? I'm behind on my reading and down with the flu as well today so my brain is complete mush. In fact the way I feel today I wouldn't be surprised if someone posts that my suggestion is complete rubbish and offers a much simpler approach. <edit> told you my brain was mush, just realised Pikey's example limits it to the unit in question so it isn't for each hit event after all so the performance issue may not be a problem. You would still need to check the initiator is one of your P51s and the health of the 109 = 0 before issuing the message. I think you still need to also check for a pilot kill too.

ah ok, I see what you mean now. Have to think about it a bit, you may be right in thinking you need a script after all now that you have described the full problem.

Ok so it isn't just a P51 getting damaged then. You want it to be shot down and this to trigger a radio call? Still think you can do it with a mission trigger. Except instead of checking for unit damaged you would check for any one of the P51 units being destroyed and if that condition is satisfied trigger a radio call or a sound file. If you want an actual audio message rather than a text message you will need to record a message in ogg format if I remember correctly. Probably would use a ONCE trigger in conjunction with a UNIT DEAD condition (you would need to check each of the P51 units using a compound OR condition) and an action of SOUND TO GROUP or something similar or RADIO TRANSMISSION. Sorry I just noticed the mod in your signature. You already know all about recording stuff. The above suggestion should still work.

You could do that in the mission editor triggers without having to do a script I'm pretty sure. <edit> looking at the editor you'd probably use the unit damaged condition and if you wanted to cover the whole group you would just add several unit damaged with OR operators and have the action be set either increment flag1 or give it the value you want it to be when the P51s get damaged. I did something similar in this old mission https://www.digitalcombatsimulator.com/en/files/348122/ where the 109s call for help when they get damaged and it triggers a scramble from a nearby friendly airfield.

Nice find. Also noticed the default year month and day are in there too and that the editor now allows you to set dates in years like 1944 etc. <edit> ok doesn't seem to work for me - either season or default dates changing.

Agree with Pikey. MOOSE is your best bet these days. You would have to clone the current GCI script and then rewrite big chunks of it to end up with a analogue for CAS missions. Mainly in the detection side of things as the current script is completely geared to air contacts. lukrop hasn't been back to do anything with GCICAP for something like a year now nor has he responded to any of the questions people ask from time to time so I believe he's wandered off to other things. If I ever came back to it I would be trying to work with Flightcontrol and convert the whole thing to a group of MOOSE modules/classes.