Jump to content

Mission Testing Strategies


Zooker

Recommended Posts

I'm relatively new to mission building, but I've run into some problems with mission scripting crashing the game. For you more experienced mission designers, are there strategies that I can use to test various components of a mission to see what is causing the crash?

 

Anyone willing to describe their approach to missing design with an idea of minimizing testing time?

VF-111 Sundowners



[sIGPIC][/sIGPIC]

Carrier Group 1 - Battlegroup Delta

 

Beware the lessons of a fighter pilot who would rather fly a slide rule than kick your ass!

-Commander Ron "Mugs" McKeown, USN

Commander, U.S. Navy Fighter Weapons School

2 Victories, Vietnam

Link to comment
Share on other sites

Someone may correct me but I'm pretty sure the error code that gets thrown will identify the line in the code where your error occurs.

 

To get to the line just go to the .miz file and open it with 7zip and then open the "mission" file within that folder with a code editor like notepad++

 

Then you can scroll down to the appropriate line and make adjustments.

 

Typically if I've been uncertain of things then I'll trigger them to happen immediately on starting the mission (fly mission). If there's anything to fix then I'll go to the line of code and see what it was, then go back to the trigger item I put in and fix it. In theory you can just fix it in the "mission" file however if the mission is still open then you won't be able to save it (unless you change the file name.)

"ENO"

Type in anger and you will make the greatest post you will ever regret.

 

"Sweetest's" Military Aviation Art

Link to comment
Share on other sites

Yeah. but, be happy, OB doesn't crash yet. Effectively, if im watching the logs in Notepad++ it asks me to reload it as I tab back and im right there. There are lines in scripting you can put to debug it so you know where they got to, but I guess you are looking at crashes in the game and LUA doesn't CTD or only in the rarest of circumstances like one I posted for fixing recently, which is still because its a game engine issue.

 

If you are keen on debugging line by line, you can load a script dynamically by refering to one on your desktop then calling it continuously via a trigger. Most of the script devs have done this at some point or other to test whilst in game. There is also a LUA interpreter in Witchcraft a useful mod by FSF_Ian.

 

Let me know if this helps you.

___________________________________________________________________________

SIMPLE SCENERY SAVING * SIMPLE GROUP SAVING * SIMPLE STATIC SAVING *

Link to comment
Share on other sites

Generally speaking and in addition to the other comments - be methodical. If you are using scripts like GCICAP etc then don't add it all at once. Add each layer to the mission one at a time and be sure it all works before doing the next one. Keep saves to represent different stages under different mission names so that if it all goes pear shaped you have a point to easily retreat to and re-add the layer that is failing. Use the observer and game master to help you easily test triggers and script reactions. eg you can place test aircraft in an orbit at waypoints and use game master to order them about and help you test script and trigger actions. If it is a complex mission perhaps story board it before you start to give yourself an outline to work to. Often when I was working on GCICAPs development I would get a request for help from someone as to why it wasn't working in their mission. I usually ended up asking them to send me the mission file and in most of the cases when I opened it in the editor I would find this super complex mission which due to the number of objects and triggers etc would be essentially impossible to work with from my viewpoint. It was pretty obvious that the author had got all the way to the end of the mission build and only then tested whether the script worked. My approach was nearly always to delete everything out of the mission and leave only the GCICAP components and then test. Most of the time it was something trivial going wrong and the person would have seen it themselves if they put in the GCICAP layer first and tested it worked before adding anything else. This generally holds true for all the various scripts available other than the library type ones like Mist which are just added with a mission start trigger (which is better than a once time more trigger because it means it loads before anything else at all loads during the mission start up) and other scripts like GCICAP make use of them and therefore must be loaded first.

Link to comment
Share on other sites

Thanks! Sound advice to start. Mission building is turning out to be very time-consuming. Gives a new appreciation to the great missions that provided tot he community.

VF-111 Sundowners



[sIGPIC][/sIGPIC]

Carrier Group 1 - Battlegroup Delta

 

Beware the lessons of a fighter pilot who would rather fly a slide rule than kick your ass!

-Commander Ron "Mugs" McKeown, USN

Commander, U.S. Navy Fighter Weapons School

2 Victories, Vietnam

Link to comment
Share on other sites

Yeah. but, be happy, OB doesn't crash yet. Effectively, if im watching the logs in Notepad++ it asks me to reload it as I tab back and im right there. There are lines in scripting you can put to debug it so you know where they got to, but I guess you are looking at crashes in the game and LUA doesn't CTD or only in the rarest of circumstances like one I posted for fixing recently, which is still because its a game engine issue.

 

If you are keen on debugging line by line, you can load a script dynamically by refering to one on your desktop then calling it continuously via a trigger. Most of the script devs have done this at some point or other to test whilst in game. There is also a LUA interpreter in Witchcraft a useful mod by FSF_Ian.

 

Let me know if this helps you.

 

By watching the logs, is this something you're doing live while the mission is active? Or, are you reviewing them after the mission is closed?

VF-111 Sundowners



[sIGPIC][/sIGPIC]

Carrier Group 1 - Battlegroup Delta

 

Beware the lessons of a fighter pilot who would rather fly a slide rule than kick your ass!

-Commander Ron "Mugs" McKeown, USN

Commander, U.S. Navy Fighter Weapons School

2 Victories, Vietnam

Link to comment
Share on other sites

If you watch some of the MOOSE configuration videos he uses a "live log" of some sort that will show a live view of your mission as it plays. I can't recall the name of the program off the top of my head-

 

But in doing what I was talking about- just go to "dcs.log" in your "saved game" folder and review it afterwards if you're getting errors.

"ENO"

Type in anger and you will make the greatest post you will ever regret.

 

"Sweetest's" Military Aviation Art

Link to comment
Share on other sites

By watching the logs, is this something you're doing live while the mission is active? Or, are you reviewing them after the mission is closed?

 

Either. If you are logging stuff via env.info() or similar functions then you can keep track of stuff in the DCS.log. Depending on what I am testing I may just pause the game, alt-tab and look at the current log to see if it is printing what I am expecting. Other times checking the log after exiting the mission is all that is needed. Occasionally I will use trigger.action.outText() to show something directly on screen for a "real time" output if it makes sense to. I did that with my iads script to show rough stats on what the systems are doing and when the script tells it to change a specific behavior.

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

Generally speaking and in addition to the other comments - be methodical. If you are using scripts like GCICAP etc then don't add it all at once. Add each layer to the mission one at a time and be sure it all works before doing the next one. Keep saves to represent different stages under different mission names so that if it all goes pear shaped you have a point to easily retreat to and re-add the layer that is failing. Use the observer and game master to help you easily test triggers and script reactions. eg you can place test aircraft in an orbit at waypoints and use game master to order them about and help you test script and trigger actions. If it is a complex mission perhaps story board it before you start to give yourself an outline to work to. Often when I was working on GCICAPs development I would get a request for help from someone as to why it wasn't working in their mission. I usually ended up asking them to send me the mission file and in most of the cases when I opened it in the editor I would find this super complex mission which due to the number of objects and triggers etc would be essentially impossible to work with from my viewpoint. It was pretty obvious that the author had got all the way to the end of the mission build and only then tested whether the script worked. My approach was nearly always to delete everything out of the mission and leave only the GCICAP components and then test. Most of the time it was something trivial going wrong and the person would have seen it themselves if they put in the GCICAP layer first and tested it worked before adding anything else. This generally holds true for all the various scripts available other than the library type ones like Mist which are just added with a mission start trigger (which is better than a once time more trigger because it means it loads before anything else at all loads during the mission start up) and other scripts like GCICAP make use of them and therefore must be loaded first.

 

I'll echo this. While I tend not to delve in to the depths of MIST or MOOSE, I do tend to adopt a methodical approach to testing. First, does my flight go where it's supposed to go? If there's air combat, does it happen in the general area where I want it to? Do enemy units appear where I want them to? Do they do what they're supposed to do? Etc.

 

I tend to start simple, e.g. with unit spawn and basic waypoints, then once that's all working I then build on it with any necessary waypoint triggers, playing voice over files etc.

 

Very important to test at each stage so if you come across a problem you know that everything up to that point worked as desired - far better than trying to debug 50 different things all at once.

 

And yes, mission creation - even simple missions - is incredibly time consuming if you want the results to be professional. It's definitely all worth it though when people tell you they enjoyed playing your mission.

System Spec: Cooler Master Cosmos C700P Black Edition case. | AMD 5950X CPU | MSI RTX-3090 GPU | 32GB HyperX Predator PC4000 RAM | | TM Warthog stick & throttle | TrackIR 5 | Samsung 980 Pro NVMe 4 SSD 1TB (boot) | Samsung 870 QVO SSD 4TB (games) | Windows 10 Pro 64-bit.

 

Personal wish list: DCS: Su-27SM & DCS: Avro Vulcan.

Link to comment
Share on other sites

I'll echo this. While I tend not to delve in to the depths of MIST or MOOSE, I do tend to adopt a methodical approach to testing. First, does my flight go where it's supposed to go? If there's air combat, does it happen in the general area where I want it to? Do enemy units appear where I want them to? Do they do what they're supposed to do? Etc.

 

I tend to start simple, e.g. with unit spawn and basic waypoints, then once that's all working I then build on it with any necessary waypoint triggers, playing voice over files etc.

 

Very important to test at each stage so if you come across a problem you know that everything up to that point worked as desired - far better than trying to debug 50 different things all at once.

 

And yes, mission creation - even simple missions - is incredibly time consuming if you want the results to be professional. It's definitely all worth it though when people tell you they enjoyed playing your mission.

 

I create test missions to have existing test scripts and test missions available for regression testing per release or conducting major changes in the framework.

It is a lot of work, but it has helped me a lot and has avoided me wasting time cleaning up the damage after an unwanted publish.

These test missions provide a valuable source to guarantee functional stability and also provide a trainer and teaching platform for users of the framework.

 

FC

[TABLE][sIGPIC][/sIGPIC]|

[/TABLE]

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...