Joyride

Thanks guys, I'll see if I can debug. AI on the road and getting "stuck" has always been a thorn in the side of this miz in particular.

Good to know. Wiki would have been my friend if I'd have looked that up..doh. :-) Glad you enjoyed it.

That should be enough, though I haven't run it lately to test for new bugs created by version updates. Just...not...enough...time...! :-)

Bravo, Ranger!

Classydjo, I haven't had time to run it through in 1.2.7,, but let me know if you had any problems. Haven't heard of anything.

Ranger, this (below) updates it once every tenth of a second and follows a target. As number3 pointed out, you'd need to add a LOS check to avoid terrain potentially getting in the way. Haven't had time to get there yet, but would be pretty easy to roll incorporate using MIST. function SparkleLase(OriginGroupName, TargetGroupName, LCode) local OriginGroup, TargetGroup = Group.getByName(OriginGroupName), Group.getByName(TargetGroupName) local OriginUnits, TargetUnits = OriginGroup:getUnits(), TargetGroup:getUnits() local spots = {} local TargetVec3 = TargetUnits[1]:getPoint() local TargetAdjVec3 = {x = TargetVec3.x, y = TargetVec3.y + 2, z = TargetVec3.z} local status, result = pcall(function () spots['Sparkle'] = Spot.createInfraRed(OriginUnits[1], {x = 0, y = 2, z = 0}, TargetAdjVec3) spots['Laser'] = Spot.createLaser(OriginUnits[1], {x = 0, y = 2, z = 0}, TargetAdjVec3, LCode) return spots end) if not status then env.error('ERROR: ' .. assert(result), false) else if result.Sparkle then local Sparkle = result.Sparkle function KillSparkle() Spot.destroy(Sparkle) end function UpdateSparkleLase() KillSparkle() KillLase() SparkleLase(OriginGroupName, TargetGroupName, LCode) end timer.scheduleFunction(UpdateSparkleLase, nil, timer.getTime() + 0.1) end if result.Laser then local Laser = result.Laser function KillLase() Spot.destroy(Laser) end end end end

This is an awesome idea MBot...will be following with much interest.

No continuous trigger, you can use a switched condition. So, if Client #13 pushes F10 that turned flag #683 true, message is sent, and same trigger turns flag #683 false. All set to repeat again if everything is switched condition.

I went down the same road trying to tie the F10 keypress to an "event" so that an "initiator" could be ID'ed, but not aware of any way to do this. If someone else has figured it out this would be handy, indeed.

Using the ME you can add F10 menu items specific to that group (client) and then have a unique flag for each group/client when they press the F10 command. For example, you add an F10 menu item "Request Sit Rep" to each and every client, using the "Radio Item Add for Group". If 10 clients, you'd have 10 lines of triggers, with 10 unique flags. When one of those flags turns true, there is a second trigger line which sends a "Group Msg" to that group (client) only. A bit cumbersome if you have numerous F10 messages and many clients, but if only a "sit rep" type situation this works very quickly easily. Where I use scripts for this is when I get into F10 submenus, which the ME GUI can't do.

FWIW, I have had infrequent, but persistent ~5 second freezes with every version of DCS dating back to the first A-10 beta. SSD and 24 GB ram here (I use this machine for heavy CAD work). I gave up trying to sort that one years ago, but it only happens maybe once every 2 hours of flying time - your's sounds way more frequent. So, while you definitely need an upgrade, no guarantees everything will be fixed. It did happen recently about 1.2mi out on a gun run on a T-72 tho...not fun knowing you are hurling towards death with a frozen screen.

Ran this mission for a bit today. A few thoughts: - I believe there is too much unnecessary AI action built in that may be causing stability and performance issues. For example, over 30 SA-10s in a tight area seems unnecessary. The miz spawns AI helos and unprotected aircraft which fly directly into and become fodder for the SA-10s, which can have a dozen missiles in the air at any time (serious hits on performance and opening the mission up to crashes, for only some "eye candy"). - while missions can often have 2,000+ units and be stable, MOVING groups create a much higher drain on sim resources, as well as missiles in the air tracking, AI aircraft, anything with waypoints! etc. I could just look into the mission editor and see you would have potential issues with this mission without even running it. Given the reality of DCS, economic mission design and tough decisions about "eye candy" vs. "mission essential" units and AI actions is a must, in my opinion. - suggesting to potential mission downloaders that they should consider modifying their sim settings to be able to fly this .miz may significantly reduce the number who do download it! :-) Instead, I'd focus on giving the mission a diet and making it more playable (lean and mean!). Sounds like you are already working towards that...

Thanks, Grimes. Processing on a 0.1 sec delay definitely helps. Not perfect, but usable for now.

Has anyone been able to generate a continuous beam onto a moving target? I am assuming that Spot.setPoint function would update the laser spot, but couldn't get it to work. I did a workaround (see below) to end and restart the laser every second, to keep the beam updating onto the moving target, but it's jumpy and difficult to lock as SPI from the A-10 TGP. -- function to generate IR and laser from Origin Group Lead to Target Group Lead function SparkleLase(OriginGroupName, TargetGroupName, LCode) local OriginGroup, TargetGroup = Group.getByName(OriginGroupName), Group.getByName(TargetGroupName) local OriginUnits, TargetUnits = OriginGroup:getUnits(), TargetGroup:getUnits() local spots = {} local TargetVec3 = TargetUnits[1]:getPoint() local TargetAdjVec3 = {x = TargetVec3.x, y = TargetVec3.y + 2, z = TargetVec3.z} local status, result = pcall(function () spots['Sparkle'] = Spot.createInfraRed(OriginUnits[1], {x = 0, y = 2, z = 0}, TargetAdjVec3) spots['Laser'] = Spot.createLaser(OriginUnits[1], {x = 0, y = 2, z = 0}, TargetAdjVec3, LCode) return spots end) if not status then env.error('ERROR: ' .. assert(result), false) else if result.Sparkle then local Sparkle = result.Sparkle function KillSparkle() Spot.destroy(Sparkle) end function UpdateSparkleLase() KillSparkle() KillLase() SparkleLase(OriginGroupName, TargetGroupName, LCode) end timer.scheduleFunction(UpdateSparkleLase, nil, timer.getTime() + 1) end if result.Laser then local Laser = result.Laser function KillLase() Spot.destroy(Laser) end end end end

Can you share the file? Would love to see what's different if that works. So it's not the script you used above...? trigger.action.radioTransmission("BeaconNear.wav", PilotVec3, 1, true, 61000, 1000)

Also, I noticed it only worked if loading the audio file via a "dummy" trigger vs. just dropping the .wav or .ogg into the .miz file manually.

You are talking about "looping" right? ie: loop boolean = true? Didn't try that, but let me know if you can get a single transmission to work more than 3 times (being triggered each time, not looping).

Good news is, I figured out why you can't get it to work. You must use a NINE digit radio freq, such as 124000000. Just like they are in the UHF, VHF_AM, and VHF_FM "settings.lua" files. Bad news is, using trigger.action.radioTransmission, you will only hear audio the first 3 times you use it in a mission. After that, no sound. I've tried numerous combinations of how it's triggered, time between etc, but every .miz has the same "three-times-and-done" issue. If anyone is able to get more than 3 radio messages to work, let me know. (edit: not "looping" but repetitive single transmissions, like radio calls)

To add to that, I am starting to break the big missions like these up into defined "phases", so that if you do have a restart there is a triggered mechanism to destroy all units in phases that had been completed up to that point. Just requires some organization and thinking in your triggers.

Finally got around to messing with this. With a little help from BAntDit, here's a simple working example (in spoiler) for generating an IR pointer and laser: Note that I raised the beam 2m off ground at the generating object and at the target point. If you use defaults, the beam is on the ground.

Is it that the last script overwrites any variables that are not made "local"?

While a global theater seems like a cool idea, not sure how that would have any sensible application or need from a mission design/scenario. Just give me a big theater, ala Persian Gulf, big enough to require air refueling for certain sorties.

Easy solution - save as either .wav GSM 6.10 format (much smaller file size than standard .wav) or use .ogg and simply reduce the sample rate. 11,000 Hz works pretty well, you can even go down to 8,000 Hz. File size will drop dramatically, though you may also notice loss of quality. For radio calls for instance, the quality loss may actually make it sound more realistic.

Works perfect, thanks galevsky06.

Curious if anyone has been able to nest an addCommand within a submenu. I can't figure out what needs to be used for "path" to get the addCommand menu item into the desired submenu. Any luck?