Debugging Tool Question

[Jedra]

I have been writing my own missions for a few months now and I am still learning the various techniques to improve performance in missions. Recently I have been trying to keep track of processes that are running withing a mission. Are there any debugging tools out there from Arma2 OA that help keep track of which scripts are running at any one time? I am thinking specifically about the following;

Scripts which are being called and running.
Scripts that have been execVM'd and are running
Script instances that are currently spawned
Global Variable tracking.
Local Variable tracking (within a script).

I know I can do things like diag_log to track entry and exit from scripts, but I wondered if there was anything out there that runs 'real time'.

Apologies if this is the wrong place to post this, but I couldn't really think of a better place.

[.kju [PvPscene]]

Basically not possible.

One could write a framework to support some of these to an extend.
However it would require people to adjust their code to make use of the monitoring.

BI would had to expose a lot more internal functionality to let the community write
anything meaningful I think.

You can use ArmaScriptTrace to generate a static calling tree.
It is useful, but by far not as in depth to the extended what you are hoping for.

[Jedra]

Ok, fair enough. I guess as my searches turned nothing up (not even a negative resonse) there was probably nothing out there but it was worth asking. I'll take a look at the script trace though it might help me understand a few more things.

Thanks for your reply.

[Moricky]

Take On Helicopters gonna introduce huge Functions Library (http://community.bistudio.com/wiki/Functions_Library) improvements, including tracking of what scripts were executed, from where and with which params.
It will also contain useful functions for declaring parameters, error reporting, halting or measuring expression's performance (http://twitter.com/#!/KarelMoricky/status/96130451747516416).
Having access to debug console (http://takeonthegame.com/social-media/?pid=57) will make your editing process easier too.

We expect to implement these features also to A3.

[Jedra]

That sounds like a very good thing indeed. Your debugging tool is already invaluable as a mod, but having some more support tools (like I have in my day job!) would make life so much easier.

[Sickboy]

Take On Helicopters gonna introduce huge Functions Library (http://community.bistudio.com/wiki/Functions_Library) improvements, including tracking of what scripts were executed, from where and with which params.
It will also contain useful functions for declaring parameters, error reporting, halting or measuring expression's performance (http://twitter.com/#!/KarelMoricky/status/96130451747516416).
Having access to debug console (http://takeonthegame.com/social-media/?pid=57) will make your editing process easier too.

We expect to implement these features also to A3.It reads as if such enhancements will only be available to the scripted functions library and thus are nothing more than some sugar coating scripting.
Is this correct or are we talking about stack-traces and parameter debugging built-in the script engine?

[sbsmac]

It reads as if such enhancements will only be available to the scripted functions library and thus are nothing more than some sugar coating scripting.

Agreed. I suspect it's more work than BIS are willing to implement but if the internal state of the ArmA scripting engine could be exposed via COM or some other interface then external tools (such as squint) would offer far more flexibility in debugging than the debug console.

[Jedra]

Looks like a full scale IDE with integrated live debug with breakpoints and data-query isn't about to happen then!

It takes me back to my COBOL days where outputting to STDOUT was the only way to debug a batch problem!

[.kju [PvPscene]]

Well you can

output stuff to the screen (sideChat, hint, cutText etc)
log to the rpt
measure execution time somewhat with diag_tickTime
use text editors or even IDEs now to help with the code itself
check for errors with squint


That said your overall request remains true.
To reduce development time and effective coding, the engine should expose this data.