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.
Description
Details
- Severity
- Minor
- Resolution
- Not A Bug
- Reproducibility
- Always
- Operating System
- Windows 7
- Category
- Scripting
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.
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
Hi, there are several issues with your example:
- 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.
- 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; }; };
You've misunderstood the report
Here's a simpler example:
sstemchat "Hello";
press LOCAL EXEC
Result: error reported
press LOCAL EXEC
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.