Mission Debugging Tools/commands?

[SierraFox]

I've been wanting to make a sandbox style mission for quite some time, a whole bunch of Ground targets for CAS, AI flights for CAP that you can just jump in to and mess around with what ever you like. there's going to be quite a few scripts involves, most likely respawn ones to keep the action going. However something that i feel like is going to cause me grief is going to be making for each group's scripts work as intended.

 

Is there anyway to test these scripts without having to jump in a plane and shooting them down? ie: some kind of tool/cheat/command that allows you to kill certain units for the purpose of testing missions and scripts?

[theOden]

add a mission command (F10 Other) and let that one do Unit.Destroy().

Otherwise pumping lots of env.info() into dcs.log textfile is a good way to track weird behaviour ingame.

(I think I've read more log than played ingame the last weeks)

[FlightControl]

Try a lua framework. These help to put trace of variables etc, which can be conditionally switched on and off... Like this one: http://flightcontrol-master.github.io/MOOSE/Documentation/Base.html

 

Hopefully this helps.

[Pikey]

Welcome to the club! (no smiley's i'm serious, you've found the time consuming and interesting part of DCS mission making)

 

So with this you have to test something thats way down the line, right? Certainly it's the truth when you get an hour int a misison with the chaps and up pops the dreaded white bos on teh server and the desync starts...

 

So....tips.

 

Start the mission with the framework and major triggers that define it's body. Test all of those critical things first. Use F10 triggers to push them faster if you need. So if its entering a trigger zone, dying or whatnot, setup a trigger to kill them on demand. I "think" deactivate works for most of that, you can use an explosion for some things too. Most things you can do with an activate or deactivate group. Do you know how to set that up in the menu? Probably if you got this far then you can tell you just need to check for a flag continuously or switched. When it changes, the thing happens...ie when you hit the menu.

 

If you are using scripting, here's a tip to make it faster. put the script on your desktop and call it using

assert(loadfile("C:\\Users\\USERNAME\\Desktop\\sometest.lua"))()

You can then hit shift-R and reload the mission and you don't need to do the "dance" of loading a different file, saving, putting the old file back and saving to force the update/changes of your LUA files.

 

Do mini tests of triggers outside of the mission in isolation when you aren't comfortable with their results yet. Just make a few units.

 

Do the 'adding loads of units and colour' at the end when the logic is defined. There's nothing worse than setting out cool placements and you stalled on a scripty type thing after all that work.

 

 

 

add a mission command (F10 Other) and let that one do Unit.Destroy().

Otherwise pumping lots of env.info() into dcs.log textfile is a good way to track weird behaviour ingame.

(I think I've read more log than played ingame the last weeks)