Page MenuHomeFeedback Tracker

Debug console not reporting error on LOCAL EXEC
Closed, ResolvedPublic


Entering a script with an error into the debug console will generate an error when LOCAL EXEC is pressed. But if LOCAL EXEC is pressed again, no error is generated. I expect LOCAL EXEC to generate an error each time I request the script's execution.


Not A Bug
Operating System
Windows 7
Steps To Reproduce

Enter the following script into the debug console of a mission and press LOCAL EXEC. Note the misspelling of "systemchat".

[] spawn
    while { true } do
        sstemchat format ["Hello %1", diag_tickTime];
        sleep 1;

An error is generated.

Without making any changes, press LOCAL EXEC. No error is generated.

Additional Information

It is the software's job to report errors every time one occurs. It is the user's job to create errors so the software can report them.

Event Timeline

JB47394 created this task.Feb 18 2018, 4:53 PM

Hi, there are several issues with your example:

  1. If you have the pause menu opened, then time is not running, so the execution will pause on the sleep command. You need to use uiSleep instead.
  2. Because of the typo in the command the syntax is wrong as game understands "sstemchat" is a global variable and as the result the code doesn't compile and you get an error.

Try this code as an example (error is in the function name). You get an error every second.

[] spawn 
    while { true } do 
        ["[i] %1","123"] call bis_fnc_logFormatt;

        uisleep 1; 
Wulf closed this task as Resolved.Feb 19 2018, 4:00 PM
Wulf claimed this task.
Wulf changed Resolution from Open to Not A Bug.

You've misunderstood the report

Here's a simpler example:

sstemchat "Hello";


Result: error reported


Result: no error reported

The debug console correctly refuses to run the incorrect code, but it only reports an error the first time I press LOCAL EXEC.

I assume this was introduced when you guys stopped generating a flood of errors on the lines below the code box that were being evaluated all the time (which was much appreciated, by the way). So you're spotting that there was no change to the code and don't report any more errors on it. Pressing LOCAL EXEC is a statement that the user definitely wants that code evaluated. It's an explicit request as opposed to an implicit one.

You are right. You need to change the content of the exec field to make the LOCAL EXEC recompile the code. But is it a real problem? Do you really need to get informed that there is still compilation error if you didn't modify the content of the exec field and just spam the button?

The use case is not spamming the button. It is one of pressing the button at one time, doing other things, then coming back and pressing it again. If the user knows that the code is in error then he's not going to press the LOCAL EXEC button. But he did press it, so he was either confused, in doubt or simply forgot the state of the code. Regardless, if a user presses a button that says that it does something, it should simply do it. If the button can't perform the function that it advertises, then it should be disabled.

Note that I do not recommend greying out the LOCAL EXEC button simply because the code hasn't changed since an error was detected. I may want a reminder of what the error was without checking the RPT file. There may be other reasons as well.