Editor Preview Mode Question

[iceman77 19]

Is there anyway to determine if the currently loaded mission is being previewed through the editor? For example I want to run debug code, only if the currently loaded mission is being previewed through the editor. Looking for a more dynamic way to integrate debugging into my SP Scenario framework. Please don't tell me to comment out the debugging code when I no longer need it :).

Thanks,

Iceman77

[Sandy* 10]

I usually do my debugging stuff by having something like debugMode = 1; in init.sqf and then just writing all the debug script with if (debugMode == 1) then { };.

It's not automatic, but all you need to do to disable it is change one number.

[Tajin 349]

How about simply checking the profileName?

That way you can at least make sure the debugmode only shows up for you.

If you also need a simple way of disabling the debugmode for yourself, you can use all sorts of things for that.

Even something as trivial as checking if you have a watch equipped. ^^

if !("ItemWatch" in assignedItems player) exitWith {};

Edited November 13, 2014 by Tajin

[IndeedPete 1038]

I tend to use a debug variable loading up on init:

IP_TESTMODE = true;

It's fine for single missions and I just set it to false on release. For my campaign I use a config based approach so I don't have to change the debug settings for every mission. Having sort of a "misc" class for values I want to store in a config but not worthy of having their own classes.

Campaign Config:

class MainValues
{
basicRate = 0.1;
buddyCostRate = 0.25;
glassGoggles[] = {"G_Tactical_Clear", "G_Tactical_Black"};
startDate[] = {2037, 6, 1, 8, 0};
startDebts = 1;  
       startMoney = 0;
startUniform = "U_C_Commoner1_1";
[b][color="#FF0000"]testmode = 1;[/color][/b]
};

And then in every mission's init (first line actually):

IP_TESTMODE = if ((getNumber(missionConfigFile >> "MainValues" >> "testmode")) == 1) then {true} else {false};

This way I only have to set testmode to 0 on release. Works well but I wouldn't mind a better / prettier solution. Only improvement I could think of would be to create a function initialising the IP_TESTMODE var and set it in CfgFunctions to run as preInit. That way I could remove the first line in every init.

[Tajin 349]

The perfect solution in my eyes, would be an addon that displays the debug-info and allows you to turn it off. It should also feature a userconfig file in which you can enter an array of keys.

Any mission that is set up for it (and has a matching key) would then automatically send debug-info to that addon.

... actually, I think that wouldn't be so hard to do.

[Sandy* 10]

How about simply checking the profileName?

That way you can at least make sure the debugmode only shows up for you.

If you also need a simple way of disabling the debugmode for yourself, you can use all sorts of things for that.

Even something as trivial as checking if you have a watch equipped. ^^

if !("ItemWatch" in assignedItems player) exitWith {};

Since he's building a scenario framework, I think it's probably important that some random item's presence doesn't suddenly enable a debug mode. Checking for profile name or player ID doesn't sound that convenient either, who wouldn't want to test their mission without it or even just play the mission normally.

Wouldn't all of this be just unnecessary work and effort compared to changing a single variable's boolean value in the source files?

[Tajin 349]

Depends. He specifically asked for a way that doesn't require code-changes.

The trick with the watch is simply the easiest trigger I could think of. ;)

Un-equip the watch and you won't get any debug-messages. You won't have any problems with that, as long as your mission doesn't require the watch for something special.

Of course it's always possible to handle such things in a more complex/advanced way (as stated in my last post).

Good rule of thumb: Always make your own debug-function so you can easily extend, change, disable or remove it later on, without much hassle.

[Sandy* 10]

Un-equip the watch and you won't get any debug-messages. You won't have any problems with that, as long as your mission doesn't require the watch for something special.

But this kind of implementation would actually limit things by forcing the debug mode on or off for scripts that run on mission initialization, depending whether you script the watch to be equipped or not on startup. At that point, you would be editing an entire line of script to enable or disable it, which was my point about the simplicity and easiness of a single boolean value. But each to their own. :)

[Larrow 2828]

For main editor only, will not work from MP editor as MP actually saves and plays your mission it is not a true preview.

_debug = false;
if( {["RscDisplayArcadeMap", _x] call bis_fnc_instring}count (uinamespace getvariable "gui_classes") > 0 ) then {
_debug = true;
};

or

not relying on a BIS funtion

_debug = false;
if( { _x in (uinamespace getvariable "gui_classes")}count ["RscDisplayArcadeMap_Layout_2", "RscDisplayArcadeMap_Layout_6"] > 0 ) then {
_debug = true;
};

Although they both rely, to different degrees, on the users using the vanilla editor layouts or at least one with a similar naming convention to them.

_________________

EDIT

Although they both rely, to different degrees, on the users using the vanilla editor layouts or at least one with a similar naming convention to them.

Fixed: Retrieves available editor layouts from config and checks against any of them being active.

_debug = false;
_layouts = [];
"_layouts pushBack (getText (_x >> 'name'))" configClasses (configfile >> "CfgEditorLayouts");
if ( {_x in (uiNamespace getVariable "gui_classes")}count _layouts > 0) then {
_debug = true;
};

OR

ICE_DEBUG = count ( "gettext (_x >> 'name') in (uinamespace getvariable 'gui_classes')" configClasses (configFile >> "CfgEditorLayouts")) > 0;

Edited November 13, 2014 by Larrow
slowly refining code

[iceman77 19]

Thanks all for the ideas. Atm I'm using a "debug" variable. Alternatively I also use a rank check (Colonel) too enabled debugging LOL. There's all sorts of nifty "hacks" regarding debugging. Anyhoot.. Larrow's hit the nail almost on the head. Though I figured there'd be a nifty command I could use similar to getClientState, but for SP =(. Something was telling me it'd all lead to a cfg entry =). Thanks guys!! Thankyou Larrow!

[IndeedPete 1038]

If you're designing a framework for other creators I'd recommend offering both Larrow's approach (maybe as default) and a config / variable way as optional. It's true, I mostly use debugging in the editor but since my last bigger project was the M.E.R.C.S. campaign I had to do some specific testing within a campaign environment. (Passed variables from earlier missions, dynamic mission sequence / campaign flow etc.) I've actually developed sort of a three stage test protocol. First I develop and test a campaign mission in the editor, then implement it into the campaign environment and do another test with debugging enabled. And finally, I (usually on another profile) test the mission without debug stuff, still in a campaign environment.

[iceman77 19]

Ahh that's neat. Sounds very similar to how I make scenarios. I make scenarios in "modules' if you will. I make 2 folders. The main mission folder and the test mission folder. I work mainly in the test mission folder / editor, break down all planned features, and turn the bigger one's into modular functions. I get each one working independently one by one in the test mission, then "push" the module to the main mission when it's ready.

On another note I always wanted to do a campaign. I make some pretty fantastic, but smaller SP scenarios, which I've never ever shared with anyone. My fortay in Sp scenarios is small, to the point, but I try to be extremely detailed with the (mission related) environment, plot and also animations. One thing I don't do too much unfortunately is voice overs. For me it's hard to find believeable actors :p. And it stinks to have a well thought out mission, dampered by poor voice overs LOL.