[Danukem]

I'm not sure how the best way to phrase this is, but the way that EDuke32 currently responds to an invalid quote number in a gametext command, seems bad.

Here's a loop that I use, which is in a display event:

whilevarn temp 0
	{
		gametextz NEWFONTSTART 320 y B 0 fontpal orientation 0 0 xdim ydim 16384
		sub y 7
		sub B 1
		sub temp 1
	}

I accidentally set B to an undefined quote number. Apparently, this caused it to abort the current iteration of the loop, but not break out of the loop (it didn't reach the "sub temp 1" line). This made my computer lock up and the log file to be filled with 71KB of this line:

Line 9385, gametextz: invalid quote 573

I see this as part of a larger issue I have noticed. While previously, invalid values would allow code execution to continue, currently in many contexts invalid values cause code execution to stop in very destructive ways. For example, I've had actors stop working because they were asked to play an invalid sound number, and code execution in the actor stopped completely, with all lines in the actor's code after that point doing nothing. Little things like invalid sound numbers and quote numbers happen from time to time, they shouldn't cause code execution to stop.

[TerminX]

The change to the VM to error out when a command fails is actually beneficial to you. It takes what used to be undefined behavior and makes the result consistent. Here's the problem with continuing after encountering an error: since the command didn't complete, nothing will have been output into any variables the command may have been supposed to return data into, making any accesses of such variables by further commands invalid. A really simple example would be if a command was supposed to return a sprite number, but didn't actually modify the value of the variable it was supposed to return it into due to erroring out. Any code afterward accessing the returned value as if it was the sprite number it was supposed to be would then be operating on whatever sprite happened to be at the index referred to by whatever the last value of the variable was. It's much better to just abort the whole execution so that you notice something has gone wrong and can fix your code, instead of silently continuing while all manners of unintended fuckery occur.

That infinite loop there is definitely a bug though.

[Danukem]

TerminX, on 05 January 2020 - 02:06 PM, said:

It's much better to just abort the whole execution so that you notice something has gone wrong and can fix your code, instead of silently continuing while all manners of unintended fuckery occur.

I understand the theory behind it, but there's going to be an error in the log either way. It's my responsibility to check for log errors and fix them, even if I don't notice something going wrong immediately.

With a project in development, this isn't too much of a worry since it will certainly cause me to fix things immediately. But there are surely various released projects out there over the years that have an occasional bad quote number or other minor error but still used to function without major issues. Now those are going to be completely broken.

EDIT: Also, I still have to look at the log to figure out what the heck is going on. When I had an actor stop working because of a bad value, I had no idea what was going on until I looked in the log and saw the bad sound number error. So, if you are going to use the "stop everything" approach, it would actually be much better from my point of view just to have EDuke32 quit entirely with an error message. Stopping code execution in the middle of an actor, state or event can cause very, very strange things to happen which have no obvious bearing on the actual error.

[Danukem]

Here's another example where I think the current error handling is needlessly troublesome.

Quote

Line 1366, ifvare: Gv_GetArrayOrStruct(): invalid index 30 for "visited"

In this case, I use the game array visited[] in EVENT_ENTERLEVEL. I had defined more levels than the array could accommodate (the original number was adequate but more levels keep getting added). When it gets to the error of trying to check data on an array index that is out of bounds, the game continues but the event stops running from that point forward. This does cause problems, but they are essentially random (i.e. they have nothing discernable to do with the actual error). That's true in general -- when you stop code execution in the middle of a state, event or actor because of an error, but just let the game keep running, the results are essentially random, and usually very confusing. As we've seen, these can even lead to the game locking up. The only way to know what is going on is to look at the log and see that there was an error at the root of it.

That being the case, I think it makes more sense to either: 1) Don't abort code execution at all and just keep the game running, or 2) Make the game quit completely and put the error message in a dialog box. If the reason for stopping code execution is that it makes the error more obvious, then why not just go with option 2? What could be more obvious than the game quitting with an error message? I actually favor option 1, though, and the reason is as explained in my post above: it's what used to happen, and there are surely projects out there with minor errors (like bad quote numbers) where the undefined behavior didn't cause any problems.

The error is in the log either way, and ultimately the coder needs to check the log. If someone has code that causes undefined behavior, that's on them.

[Sangman]

Perhaps there should be syntax for letting CON scripts opt-in to a more strict execution mode, similar to doctype in HTML https://www.w3school...tag_doctype.asp, or a feature toggle

CON that doesn't set it should just handle errors the way they used to before whereas in strict execution mode it could crash the game or whatever.