Jump to content
Sign in to follow this  
roguetrooper

Command to prevent error-messages

Recommended Posts

It would be nice to have a command (to be put into description.ext or into a sqf/sqs or into a trigger) that prevents the error messages of -showscripterrors. This command should have a higher priority than -showscripterrors in the Arma-desktop-link.

You could add this command to your map when you are about to release it and you are sure everything works fine. So you could be 101% sure that your "customers" will not annoyed by that black error box although the map works perfectly but you forgot to remove/change a litte remnant of your 10000 lines of code that actually has no impact on the map's gameplay.

YES, I KNOW: You could just remove -showscripterrors from your Arma-link, but actually nobody who uses that parameter will remove it (since it's a precious tool - for mapmakers).

Edit: This command should also prevent the pop-up-error-dialogues that have to be confirmed by mouse-click. And maybe also the entries to the rpt-file.

Edited by RogueTrooper

Share this post


Link to post
Share on other sites

why not simply use two links to arma.exe with different params?

developer.lnk

play.lnk

Share this post


Link to post
Share on other sites

This doesn't seem like a good idea to me at all.

If you have some obscure bug somewhere in the code that breaks the mission in certain situations, good luck troubleshooting it if the mission just swallows the error and silently goes FUBAR. At least if an error message is thrown, the players will be able to report it so you can track it down. Without an error message, people will simply complain about the mission breaking somewhere and you will be none the wiser. This is probably more likely to drive away your "customers" than an error message.

Share this post


Link to post
Share on other sites

You may be right. But to enhance the practical value of those blackbox-messages, they should contain the file and line:

part of corrupted code
kind of error
file.sqf, line 34

The current scrap of message isn't THAT useful in certain situations.

Edited by RogueTrooper

Share this post


Link to post
Share on other sites
Then the script-error-message should at least contain the file name and the line, eg:

part of corrupted code
kind of error
file.sqf, line 34

It does sometimes! I know what you mean though. Don't worry though as a year from now we'll all be debugging in a Java IDE ;-)

Share this post


Link to post
Share on other sites

RogueTrooper, most of your problems will go away immediately if you finally STOP mixing up sqf and sqs like many people told you already x times.

If you stop using sqs constructs like goto and jump labels in sqf then you won't see such error messages anymore!

Xeno

Share this post


Link to post
Share on other sites
RogueTrooper, most of your problems will go away immediately if you finally STOP mixing up sqf and sqs like many people told you already x times.

If you stop using sqs constructs like goto and jump labels in sqf then you won't see such error messages anymore!

Xeno

Lol, I absolutely have no error messages from what you said. In almost all my sqF files I have goto and such without the faintest error message. I only have (until I fix it) error messages from REAL logical/typing mistakes, like setpos for an object that doesn't exist or a wrong amount of {[(

Share this post


Link to post
Share on other sites

And as it seems, a lot of runtime errors that you apparently can't figure out because it's pretty hard to debug spaghetti code. ;)

Share this post


Link to post
Share on other sites
Lol, I absolutely have no error messages from what you said. In almost all my sqF files I have goto and such without the faintest error message. I only have (until I fix it) error messages from REAL logical/typing mistakes, like setpos for an object that doesn't exist or a wrong amount of {[(

Just look at your last post in the editing forums... You post a sqs code snippet and write that's what's in your sqf file. Or look what you wrote here: "In almost all my sqF files I have goto"... there is no goto in sqf.

Anyways, that the sqf parser has some problems with missing {} or sometimes even silently does nothing when there is something wrong with preprocessor stuff in scripts is something which is known for years and is frustrating as it costs lots of time to find the issue, there is also an old CIT ticket about it (and at least one more experienced modder has left the game already because of that issue (and other issues)).

The sqf parser should get improved, if that's what this thread is about.

But, again, many of your own problems happen because you simply refuse to separate sqs from sqf. Either use sqs or use sqf.

Xeno

Share this post


Link to post
Share on other sites

Use squint in addition.

Share this post


Link to post
Share on other sites
Just look at your last post in the editing forums... You post a sqs code snippet and write that's what's in your sqf file. Or look what you wrote here: "In almost all my sqF files I have goto"... there is no goto in sqf.

Create a file.sqF with

_a = 0;
goto "jumpto";
hint "this message won't be shown";
_a = _a+1;
#jumpto
_a = _a+1;
~5.0
if (_a==1) then {hint format ["%1",_a]};
exit;

and execute it by [] exec "file.sqf"; in your init.sqs or in a trigger.

Why then is there NO hint "this message won't be shown" and no blackbox-error message? Why then is _a == 1 at the end of the file? Why then does this sqf (f like fox) executed with [] exec "file.sqf" work as expected and without any errors? I do not understand why people maintain this example would not work whereas it works without any error or problems. :confused:

Why then does this code work when "there is no goto in sqf" ? :confused:

Share this post


Link to post
Share on other sites

That explains a lot.

You're executing the file using "exec" instead of "execVM", which means it will be run as an SQS script, regardless of the file extension. (If I'm not mistaken.)

You are essentially still writing and running SQS scripts, but merely mislabeling them as SQF.

Share this post


Link to post
Share on other sites

Exec is for SQS code

http://community.bistudio.com/wiki/exec

ExecVM is for SQF code

http://community.bistudio.com/wiki/execVM

as MaddogX wrote, You don't use SQF syntax http://community.bistudio.com/wiki/sqf

but in fact still using obsolete SQS syntax http://community.bistudio.com/wiki/SQS_syntax

:rolleyes:FPDR

Share this post


Link to post
Share on other sites

*stares at avatar*

whoaw, you bought BI, what kind of a nice birthday present is that :eek:

Share this post


Link to post
Share on other sites

You're so gonna get infracted with that avatar ;-) Doesn't FADE get triggered by that sort of thing?

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×