Add Target Debug run with addon config

[Dystopian]

Fixes #712.
Addon config has a greater priority than mission one.
Also function description fixed.

• If merged, fix Target-Debugging wiki page

[jonpas]

What about the new array syntax: enableDebugConsole[] = {"SteamID1", "SteamID2", ...}?

Honestly I'd like an option to just have it the same as the vanilla debug console, so we don't have to write things twice all the time.

[Dystopian]

Target Debugging is only available, when the Debug Console is available

So Debug console checks steam IDs if they exists. Why do you need to define different ways for both consoles? If you insist I can implement it.

[jonpas]

Oh right, never mind! :P

[commy2]

Should be:

getMissionConfigValue ["EnableTargetDebug", getNumber (configFile >> "EnableTargetDebug")] isEqualTo 1

imo. There is no reason for an addon to overwrite the mission if the mission sets the value explicitly.

[commy2]

same

[commy2]

Addon config has a greater priority than mission one.

Why? Nowhere else is that the case.

[Dystopian]

Target Debug is server admin/developer tool disabled by default. Security questions are solved with vanilla enableDebugConsole. There are no any reasons to disable it in mission config. Addon priority is for those times when you play some mission where you need to debug something right now (multiplayer missions are difficult to debug, so sometimes you have to debug in playtime) but for some reason the author disabled it (by chance or purposely) (like BI disabled enableDebugConsole in its coop missions).

[Dorbedo]

I personally don't agree with this.
If the missiondesigner has disabled the feature on purpose, his decision should be respected and not be overwritten by an addon.
If the missiondesigner didn't use the value, the Addon specified value should be used instead.
Just like commys suggestion.

[Dystopian]

What purpose can it be? As server admin and addon tester/developer I can't agree.

You should understand that Target Debug is not user feature like ACE Cargo e.g., which can be disabled in favor of some mission features. This is an admin feature and mission designer is not that man who finally decides.

[commy2]

It should work the same way as vanilla does described here: #712
I don't know which way that is.

[Dorbedo]

BIS-Wiki Vanilla order

1. Mission param is checked. If is not defined then...
2. description.ext param enableDebugConsole is checked. If is not defined then...
3. Eden attribute option is checked. If not defined then...
4. Global/mod param enableDebugConsole is checked.

[commy2]

So mission config beats addon config. Just like everything else. It's a good rule to go by. It seems to me like this PR does it the opposite way though.

[kymckay]

I sort of don't see the point in an addon being able to enable the debug console if the mission can just override it anyway 🤔 (More of a comment on the vanilla behaviour than anything else)

[commy2]

I guess it's more convenient to be able to change the default behavior by addon.
I'd say that almost all missions that "disable" the debug console, actually just didn't bother adding the entry. And if it's disabled explicitly by the mission, then that should overrule the addon.

[PabstMirror]

Yeah, I'd say if either one explicitly disables, then it should be disabled

private _cfg = configFile >> "EnableTargetDebug";
private _blocked = ((isNumber _cfg) && {(getNumber _cfg) isEqualTo 0}) || {(getMissionConfigValue ["EnableTargetDebug", -999]) isEqualTo 0};
if ((!_blocked) && {1 isEqualTo ([getMissionConfigValue ["EnableTargetDebug", 0], getNumber _cfg] select isNumber _cfg)}) then {
    ...

[Dystopian]

So nobody answered my question about mission maker purpose to disable Target Debug. I gave 2 arguments for addon priority and nobody said anything against.

About enableDebugConsole analogue: as I saw in dev version src a week ago after T124835, it looks like mission value WILL NOT beat addon value. I don't know if it's changed in release version - we'll see in 1.74.

[Dorbedo]

I think there is no good reason for overruling the missionmakers decision. If you have the permission of the missioncreator, you could modify the missionfile very easily. If not, you should respect the decision.

I don't see a reason to make the behavior different from the vanilla behavior. This makes things much more complicated.
Until the vanilla behavior is not changed, CBA should stick with mission priority over addon.

I must add, that we are talking about a very few cases. I think, there will almost never be someone allowing the debug console, but disallowing the target debugging.

[Dystopian]

We have this in vanilla 1.76:

_chk = getMissionConfigValue ["enableDebugConsole", 0]; 
if !(_chk isEqualTo 0) exitWith {_chk};
...
_cfg = configFile >> "enableDebugConsole"; 
if (!isNull _cfg) exitWith {_cfg call _fnc_getConfigValue};

Mission value has priority only if > 0.

[commy2]

BIS_fnc_isDebugConsoleAllowed is a mess now.

[Dystopian]

updates on this?