LUA scripts: workflow ... how to?

Quick question to you LUA script pros: how do you develop your scripts, what, hrm, "workflow" do you have? Or more precisely, how do you do such "simple" things like syntax checking?

How to test ... that one is as obvious as it is laborous, I guess .... change it and test it within DCS. But before that? I bet, one wants to write as much code as possible before the next test cycle. But then, how do you deal with syntax errors? Syntax highlighting of Notepad++ is surely a big help, but that can't detect all errors. So, does one really have to go into DCS just to discover the first error, correct it in Notepad++, go back to DCS, ... rinse & repeat?

I write them in notepad++ and throw them into DCS.

As long as it has errors, I continue to fix them.

You can hardly do any differently with an interpreted language that is run inside a no debuggable environment.

I'd love another solution for this as it does waste A LOT of time going in and out of DCS. I can see at least two solutions for this: compiling the code outside of DCS but then you have to solve the problem with functions specific to DCS:World (syntax checking might work though!). The other solution is to reload scripts from the harddrive in a running mission without stopping the mission.

Syntax validation is already given by some coloring, in the end, but it's an interpreted language, you can't compile it.

It would be already quite handy to pack up the lua files inside the miz and launch them via a commandline, or either 'refreshing' a loaded mission form MP (I test them in MP so I leave the Mission Editor open and alt+tab). Unless I have to speed up things then I need single player instances.

Most of my wasted time is: return to editor, re-open the .lua file, save mission, relaunch it.

Edit script. Switch to DCS, update the trigger that includes the script, save and run the mission. Once the mission is loaded run through the mission or sequence and see if it blows up. Exit the mission back to the mission editor. Start over again.

The steps don't sound so bad but it takes a surprising amount of time. Since not all errors cause a fatal error.

I'm not sure if this can be done but if there was a way to just quickly refresh/restart the game to execute from the very beginning again, that would cut down on the times for the mission to start and exit.

Plan what you want to do ahead of time. Depending on the script try and have a small test mission used only for "does this work" tests. For smaller missions the simulator loads quicker, especially if the units within the mission don't really change much. If loading time is seriously annoying, disable un-needed DCS modules in the module manager, this skips the starforce check but makes those units unavailable for control, but can shave time off of the DCS splash screen between the mission editor and the actual loading screen. When in doubt add env.info() statements. env.info() statements do become a little annoying the larger the script is or the more looped items become. If you are working with sizable tables it can be helpful to write the table to a lua file for future reference.

Syntax issues ain't so bad as the sim will let you know it failed to compile and where. I still have plenty of syntax errors, although occasionally I code a bunch of stuff and get no syntax errors. Honestly the annoy ones are the logical errors where the script just stops because it is a syntax error, but it isn't a compile error. Those you just gotta find where the problem is via env.info() statements.

You can use Lua-demo to check syntax or operation of a piece of script. Obviously it won't recognize DCS functions but it's still pretty useful thing.

http://www.lua.org/cgi-bin/demo

LUA scripts may be compiled. The result is not necessarily a compact binary, but it is not any longer readable in a text editor. The new created file has the extension LUAC. DCS does accept LUAC files without any problem. Back to the syntax check. Every compiler run is preceded by a syntax check. The compiler stops and shows the bug location and its reason. Unfortunately, the scope of variables cannot be checked in LUA by nature. If a function or variable is located anywhere in another script, LUA automatically assumes an external object. The missing possibility to declear objects can be a pain. Another advantage is the LUA library for C developers . If you plan to create a DLL for your mod, you need to include the LUA library (64 bit version!) to implement the interface for LUA scripts.

The compiler is part of the free LUA SDK. It contains the SciTE IDE and the necessary binaries. Compiler runs can be initiated with a simple mouse click. Check the following links:

http://www.scintilla.org

http://www.lua.org

Unfortunately there is a conflict of interest between coding, which is fun, and debugging, which is annoying :) The larger blocks of code you write without debugging, the harder debugging becomes. If I have a good idea what I want to do I can write it down in one session (one evening = about 4 hours). Then I run the code through a test. If I have a lucky day it works right away (which is awesome). But of course there might also be errors that take days to isolate and fix. If I am exploring new concepts I run the code a lot more often. Generally I think I spend about 50% time coding and 50% time testing.

Syntax errors are cough quite easily. Writing in Notepad++ already greatly reduces mistakes in the first place. Then after each major code block I copy it and past it over in a do script waypoint command in the ME. This will trigger a DCS syntax check right away, without having to launch the mission. This is great to catch all those missing commas and brackets. The meat comes with finding logic errors. I create a lot of minimalistic test missions to check specific aspects of the code. A logic error mostly manifests with the script stopping. What I then do is drop trigger.action.outText("sometext", 1) lines in to the code. That way you can see, how far the code works until the script hangs up. You can then narrow it down to the exact line that stops the script and hopefully recognize the mistake.

As already mentioned, http://www.lua.org/cgi-bin/demo is a great place to quickly test code bits (with DCS specific reference removed/adjusted of course).

I keep a text file along with a mission file. Using Notepad++ I will develop the LUA scripts in the text file and paste the code into the ME on a Do Script action.

As I'm working through the script issues (with a lot of help from the folks here) I'll keep the old code and copy and paste it lower in the text file and modify that, rinse & repeat, back and forth, until it works. I'll attach the text file from my latest mission.

I use a lot of test messages during the development. The attachment also has a Flag Display script in it that doesn't require LUA -- I'll run the Flag Display on a repeating message about every 10-20 seconds until they are all working.

WC

Then after each major code block I copy it and past it over in a do script waypoint command in the ME. This will trigger a DCS syntax check right away, without having to launch the mission.

Neato :thumbup:

Thanks for the tips!

The meat comes with finding logic errors.

When I develop in C++ or other languages I use unit testing religiously. For some reason I haven't been using that much in Lua but I don't see any reason why I shouldn't. That is otherwise a very good strategy to find logical errors almost as quickly as you'd find syntax errors.

I found this and it is great! It is based on a IDE called Eclipse. My scripting errors went down and I have a nice tasking system and can bookmark the code where I want to change things. The ERROR marking is a great feature as it marks any coding errors you do on lua basics. If you code some in .lua I recommend you to take a look at this.

http://www.eclipse.org/koneki/ldt/

LDT is about providing Lua developers with an IDE providing the user experience developers expect from any other tool dedicated to a static programming language. LDT is using Metalua, to analyze Lua source code and provide nice user assistance. LDT is an Open Source tool, licensed under the EPL.

Great find! Just tried it out and I am having some problems with the error detection (it marks the file I am working on as having syntax error even though it hasn't) and the run/debug command (it says it can't find the file I tried to debug). Anyone else having problems?

Start a small script with just "do" and "end" and start filling in between them. Also check your file encode should be changed to iso-85?? something. The top selection!

And debugging will only work with lua code. No DCS code

Preferences -General -Workspace -ISO-8859-1

Thanks! Will try it out.

No, it still marks non-errors, and refuses to debug. :(

I have not tried the debugger, it marks errors in the coding while you make them. Start small and learn how to use it. Also add new functions to the end of the code and mark them with bookmarks for easy moving to them. Works great.

Just tried the debugger on some simple "main" file and it works fine. It will of course just debug ORIGINAL LUA code and will fail if you call some DCS or MIST function.

If you use a debugger, you can emulate DCS World from outside the application and save a lot of time. I use lua for windows from lua.org and the scite editor / debugger.

When I create a new script, I start it with a few lines that launch a second script. The second script, called dcsWorld.lua has lots of definitions that emulate the DCS World environment. This really helps with debugging, saving time loading the sim over and over.

Each script starts with something like:

if not env then

package.path = package.path .. ";C:\\Users\\ <path to script save folder> \\?.lua"

require ("mission SOC")

require ("dcsWorld")

end

.... <your script code as normal>

When in DCS World, this does nothing as env will not be nil. If debugging outside DCS World, it loads two scripts.

The first, mission SOC.lua is the mission file, unzipped from the .miz and with a .lua extension added. Hence the mission editor output becomes available under a 'mission' table, almost as it does would be in DCS World where it is env.mission.

The second script loaded is one that emulates many of the DCS World tables. It doesn't do a very good job but it does enough to enable me to debug most things. One key thing it does is check for a mission table and make it available as env.mission. By doing so, the mission editor output is now available in the same way as it would be in DCS World.

Just a few ideas for you to play with :-)

dcsWorld.lua

When I create a new script, I start it with a few lines that launch a second script. The second script, called dcsWorld.lua has lots of definitions that emulate the DCS World environment. This really helps with debugging, saving time loading the sim over and over.

I've been wondering for a while now how difficult it would be to do exactly this. Your solution looks very elegant, thanks a lot for sharing! :thumbup:

Sorry for dumb question...but I'm trying to learn a bit more about these things...Puddlemonkey, could you explain a bit more about your code? I mean...in my c:\Users\Saved Games\DCS World\Script there are no lua script...so, how could the script load the SOC and dcsWorld lua file? For what I understand the code you wrote should help us to emulate DCS Wrld game about some objects and table...am I wrong?

Thanks for help and feedback

Check out my DCS Witchcraft project. It includes a browser-based Lua debug console that allows you to execute snippets of Lua code inside the scripting environment of a running mission.

It is very useful to take a look at table contents, read and set flag values or test out small pieces of code (e.g. to see if the code you just wrote to order a group of units around has the intended effect).

Disclaimer: I am not a mission builder. I used the following workflow to get unit positions exported to an outside process, but they should also apply elsewhere.

If you make sure that everything you want to develop is accessible through the global namespace, you can use the debug console to redefine functions while the mission is running.

Place your entire script in a snippet in the Lua console. When you have changed something, re-evaluate the snippet by pressing Ctrl+Enter.

If you use mist.scheduleFunction(), event handlers or similar, keep a reference to those so you can unregister them before running your new code and you don't end up with several copies being run.

An alternative would be to avoid re-executing the initialization code that sets up the event handlers and have the actual event handler function call a global function which you can just redefine when you need to.

Write separate Lua snippets to reset some of the functionality you are testing, e.g. to respawn certain groups in their original location and reset flag values so you can test a trigger again after it has been fired (this will probably not work with ONCE triggers, I have never used the trigger system myself much).

Thanks a lot for feedback Ian ;).

Downlaoded your code and script...hope to understand all the features and installation/use instructions.

I'll be back with more question in case of need...hope you don't mind.