MIssion Scripting Tools (Mist)- enhancing mission scripting Lua

Thanks, Grimes. Once I got the syntax right, had to then recall the bold Important Note in the MIST guide that you have to be in an vehicle/aircraft to see the message being displayed. :doh:

That is an unfortunate quirk of how the message system has to work. I've debated adding in an official "debug" setting within mist that would change the output to simply "outText" which would be capable of displaying the messages that either team can see.

Could MIssion Scripting Tools (Mist) help me?

I am making mission for UH-1H. I have a total of 20 objects, ground units and Trigger zones (for NDB navigation) that use trigger.action.radioTransmission. Each with its own audio file. This is small audio files (Morse code for NDB), converted to OGG. There is one problem! If I have only five transmission sources, units or trigger zones in any combination it is work perfect. As soon as I add any additional object with the function trigger.action.radioTransmission, previous five stop working and transmit audio file (loop mode). If I remove the sixth transmitting object, everything starts to work fine.

I have a question - how to increase the number of objects (trigger zones and units), which can use a trigger.action.radioTransmission? Currently works only five, and needs 20.

trigger.action.radioTransmission does not work at this time. At least I didn't get it to work.

http://forums.eagle.ru/showthread.php?t=105808

http://forums.eagle.ru/showthread.php?t=107139

My ticket with ED is open since May 8th IIRC, and hasn't been responded to yet.

So if you get it to work, I'll get you a beer ;)

trigger.action.radioTransmission does not work at this time. At least I didn't get it to work.

 

http://forums.eagle.ru/showthread.php?t=105808

http://forums.eagle.ru/showthread.php?t=107139

 

My ticket with ED is open since May 8th IIRC, and hasn't been responded to yet.

 

So if you get it to work, I'll get you a beer ;)

I have own NDB navigation (five NDB) and it work with UH-1H. But I dont know will it work in MP. So we could check!!! I will set up HOST (server) and we could try. What do you think?

NDB test mission. Online as a HOST I have Sound transmission and direction for A-10C and UH-1H !!!

For A-10C:

NDB TBL (Tbilisi) 310 MHz

NDB BTM (Batumi) 320 MHz

NDB GOR (Gori) 330 MHz

For UH-1H:

NDB KTS (Kutaisi) 1.6 MHz (1600 kHz)

NDB ABR (Ambrolauri) 1.65 MHz (1650 kHz)

Try this for multiplayer

Problem with radioTransmissions in Multiplayer is that clients won't hear a transmission that started after they joined.

So I changed your mission to make the transmissions start new every 6 seconds

Transmissions as triggers work just fine, the problem I mentioned affects the trigger.action.radioTransmission function in the lua environment

NDB test.miz

If you create a trigger in the mission editor and use radio transmission as an action, it works.

If you write a script and call trigger.action.radioTransmission from there, it doesn't

This is real navigation (NDB and VOR) for Georgia. Not too much :)

Q: How to increase the number of objects (trigger zones and units), which can use a trigger.action.radioTransmission? Currently works only five, and needs 20.

A: const unsigned int messageMaxCount = 5

I see mist 1.1. Where is version 2.0

There: http://forums.eagle.ru/showpost.php?p=1740382&postcount=132

Speeds been glued to Kerbal Space Program and has yet to update the first post. :/

There: http://forums.eagle.ru/showpost.php?p=1740382&postcount=132

Grimes can you front page Mist 2.0?

Grimes can you front page Mist 2.0?

Bugged Speed enough to change it. :)

Also starting to code some more stuff for an update. Will likely merge "SCT" into Mist among other things.

client update timeout

Hi Grimes (and others),

We have been working on a dynamic MP mission for the Huey (http://forums.eagle.ru/showthread.php?t=108056&page=10) that uses mist extensively. It works fine in SP, but in MP it is plagued by apparently randomly occurring "connection interrupted" events, i.e. it kicks out one or several clients, while other clients can keep playing (DCS does not crash or anything). We have been struggling with this for a week now. Given your extensive experience with DCS and mist, can you give us any hints what might be happening. The log states "client update timeout" (or something similar, I am away from my computer now).

Hello,

Thoughts about Mist v3.0:

Grimes spoke about Auto-scaling threat here. I have the same need, and it could be cool to have kind of getClientNumber(CoalitionId) into the API.

EDIT> not a so good idea, most of the time you want what kind of unit it is, so you will have to loop on the humans list.

We should have a kind of mist.DBs.humansByName or mist.DBs.humansById but in Real Time DBs

Use mist.DBs.humansByName or Id and something like this:

for groupName, groupData in pairs(mist.DBs.humansByName) do

if Group.getByName(groupName) then

--this group exists so therfore we can use it

end

end

also there is a function built into the scripting engine:

coalition.getPlayers() pretty much does the same sort of thing.

Hello!

Just a curiosity post: has mist.goRoute() been broken after the latest patches? My mission now crashes to desktop when that function is called. I might be doing it wrong, but it worked in 1.2.4.

http://pastebin.com/79MxZncb

Here's a link to the script, it's the same script I posted before. Line 232 - that if/else block deals with a Huey touching down in a rescue zone, and a verification team is spawned then waypoints from the team to the asset being picked up are generated and goRoute is called. Mission crashes to desktop there, occasionally if it doesn't outright crash the units that are spawned just stand there.

Here's the error log:

# -------------- 20130730-052557 --------------

# C0000005 ACCESS_VIOLATION at 548B9CE6 00:00000000
00000000 00000000 0000:00000000 
548B9CE6 00C2F1F0 0000:00000000  ?getPathParam@wcRoute@@QEBANNNAEBVVec2d@osg@@@Z()+D6
548C11F0 00C2F260 0000:00000000  ?CreateGroupPath@wcRoute@@UEAA_NMN_N00@Z()+2F20
5490BA8F 00C2F2C0 0000:00000000  ?nextStep@woMovingVehicle@@QEAAXN@Z()+3F
548F8682 00C2F2F0 0000:00000000  ?nextTime@woCar@@QEAAXAEAN@Z()+92
548E6961 00C2F320 0000:00000000  ?setFollowingCurrentState@wcColumn@@QEAAPEAVLandGroupState@@XZ()+111
5DAB8561 00C2F3B0 0000:00000000 
5DAB8A1B 00C2F400 0000:00000000 
B0C05819 00C2F490 0000:00000000 
B0C0826D 00C2F4F0 0000:00000000 
B0C1E104 00C2F520 0000:00000000 
B0C1DFDB 00C2F550 0000:00000000 
B0CB28E8 00C2F5C0 0000:00000000 
B0CB3E9E 00C2FBC0 0000:00000000 
B0CB6ADB 00C2FC70 0000:00000000 
70C01832 00C2FCA0 0000:00000000  BaseThreadInitThunk()+1A
712CD609 00C2FCF0 0000:00000000  RtlUserThreadStart()+21

Thanks for any help you can provide!

mist.goRoute() itself isn't explicitly bugged as I have not been able to replicate the crash and every single mist movement function works so far. What is likely causing the crash are the circumstances of giving the order to move.

Can you isolate the usage of that function into a standalone mission so I can get a better idea of what is going on?

Here's a test mission that incorporates the SpawnVerifyTeam.lua. When it doesn't crash to desktop, the team spawns but does not move. They moved fine in v1.2.4, and stopped moving in v1.2.5.

The mission is very simple, there is a unit named "downed pilot" on the runway and he is sitting in a zone called "RescueBegins". Once the player's helicopter, unit/group "Chevy 1-1", moves within zone "RescueBegins", the SpawnVerifyTeam.lua script is called. The script monitors Chevy 1-1 until it touches down and stops moving at which point it spawns a new group called "VerificationGroup", takes the position of this new group and the position of "downed pilot" and generates waypoints from the new group's spawn to the pilot and runs mist.goRoute(verifyGroup, ingress) with verifyGroup being the new group variable and ingress being the waypoint table.

I'd say on my computer it crashes once out of every five times it's run, with the other four times currently resulting in no movement from verifyGroup.

So start the mission and literally just takeoff and land on the grass right in front of you, and the VerifyGroup will spawn but just stand there whereas in the previous version of DCS they would properly navigate from their spawn position to the downed pilot's position.

If this is still too general a mission, I'll try and cut it down even more but it would lose some of the functionality that is built into how the script is supposed to run.

test.miz

Here's the code that sometimes crashes. As you can see, I spawn verifyGroup, generate waypoints for their ingress to the assetUnit, output that they are on the ground and heading to the asset as well as play an audio file stating the same thing (doesn't work in test mission but does in full mission).

if rescueUnitVelocity.x < 1 and rescueUnitVelocity.y < 1 and rescueUnitVelocity.z < 1 then
   verifyGroup	= spawnVerifyGroup(assetUnit, rescueUnit)
	
   ingress		= generateWaypoints(assetUnit, rescueUnit, 'ingress')
   trigger.action.outText("This is Delta squad. We have boots on the ground and we're pushing towards the asset.", 40)
   trigger.action.outSound('StartPushToAsset.ogg')
			
   mist.goRoute(verifyGroup, ingress)
end

I just tried moving mist.goRoute to before the outText and outSound lines and resulted in a crash to desktop with the following log:

# -------------- 20130731-044654 --------------
ÿ�
# C0000005 ACCESS_VIOLATION at 56A34A87 00:00000000
00000000 00000000 0000:00000000 
56A34A87 0063EBC0 0000:00000000 
6213F235 0063EC20 0000:00000000  ?CreateGroupPath@wcRoute@@UEAA_NMN_N00@Z()+F65
6213F4E0 0063ED40 0000:00000000  ?CreateGroupPath@wcRoute@@UEAA_NMN_N00@Z()+1210
6213E891 0063ED70 0000:00000000  ?CreateGroupPath@wcRoute@@UEAA_NMN_N00@Z()+5C1
6213781E 0063EE00 0000:00000000  ??0CustomFormations@@QEAA@AEBV0@@Z()+FCE
621586A5 0063EE50 0000:00000000  ??4TempFilesManager@CoreUtils@@QEAAAEAV01@AEBV01@@Z()+14C5
6216617A 0063EE80 0000:00000000  ?update@wcColumn@@AEAAXAEAN@Z()+2A
62166961 0063EEB0 0000:00000000  ?setFollowingCurrentState@wcColumn@@QEAAPEAVLandGroupState@@XZ()+111
6B208561 0063EF40 0000:00000000 
6B208A1B 0063EF90 0000:00000000 
27CA5819 0063F020 0000:00000000 
27CA826D 0063F080 0000:00000000 
27CBE104 0063F0B0 0000:00000000 
27CBDFDB 0063F0E0 0000:00000000 
27D528E8 0063F150 0000:00000000 
27D53E9E 0063F750 0000:00000000 
27D56ADB 0063F800 0000:00000000 
70C01832 0063F830 0000:00000000  BaseThreadInitThunk()+1A
712CD609 0063F880 0000:00000000  RtlUserThreadStart()+21

But the outText was still displayed, meaning the function mist.goRoute completed successfully and the outText was shown before the script/game crashed.

The functions spawnVerifyGroup and generateWaypoints are pretty small and pretty easy to read. spawnVerifyGroup calls a function that does some math to figure out waypoint coordinates, which side of the helicopter is closest to the downed pilot (so the rescue team spawns on that side of the helicopter) and also what heading the helicopter is facing so that the rescue team always spawns at 90 or 270 degrees relative to that heading, depending on which side is closer to the downed pilot. Otherwise it just creates a verifyGroupData table that contains the settings for the group prior to coalition.addGroup being called.

If I comment out goRoute, they spawn every time perfectly without any game hiccup (but obviously don't move), but if I uncomment goRoute the game hiccups for about a half a second when they spawn, they still don't move as they should, and occasionally the game crashes to desktop.

Been trying to narrow down exactly why for about two days now, which is why I asked if goRoute was known to be buggy. Definitely want to help figure out what is wonky, and I'm guessing it's something I'm doing wrong in either the waypoint generation or how I'm creating my verification team group, but like I said it used to work flawlessly in 1.2.4 so I don't know whether to wait until the next hot fix or if there's something obvious that I'm missing in my code.

I do a lot of programming, but this was my first attempt at LUA so I'm sure I missed something obvious somewhere along the line.

Manually moving the group via CA to the downed pilot results in the script continuing as normal and correctly using mist.goRoute() to return both groups to the helicopter on its own. So it is most likely contributed to spawning AI near the helicopter, assigning the goRoute() before the group is ready to receive it, or assigning a route within a certain distance of the helicopter.

Possibly setting the goRoute() to occur a few seconds after the group spawns might be one fix. Or maybe spawn em a little further out. You can also embed the route information into the group table you are spawning.

At least when it was first implemented the ability to change AI routes was finicky at times, even more so when commanded on a dynamically spawned group around the same time said group spawns. I wouldn't be shocked if 1.2.5 made it more finicky, but so far in my tests and running your attached mission I have been unable to reproduce the crash, let alone reliably.

I'll give those things a shot and see if I can make 'em start navigating on their own again.

Thanks for taking a look at it! I'll let you know if I figure it out.

Possibly setting the goRoute() to occur a few seconds after the group spawns might be one fix.

I did this and it fixed the problem. Just put a mist.scheduleFunction on the mist.goRoute function for five seconds after they spawn and now everything works perfectly fine again.

So whatever ED did in the latest patch must have increased the amount of time between when a group spawns and when it's ready for waypoint instructions, unless the waypoints are given to them in their initialization. Very interesting.

This doesn't impair my mission at all, so I'll just leave it this way.

As always, thanks again for your help!