Jump to content
The Dark Mod Forums
Alberto Salvia Novella

The game exits with success code even on error

Recommended Posts

How to reproduce:

1. Delete "tdm_fonts01.pk4"

2. Run the game in a terminal.

Result:

signal caught: Segmentation fault
About to exit with code 0

Also these errors are printed to stdout, where it should be stderr.

This is relevant because if the game crashes it cannot properly report that to a parent process. Such parent is needed, for example, for running the game with a single installation for all users on an Unix system.

Share this post


Link to post
Share on other sites

I don't mean that.

Command line programs can print its content using two different channels. One is stdout (&1), intended for regular messages, and the other is stderr (&2), for errors. If no channel is specified in the code, the program uses stdout by default:

  • echo "Message"
  • echo "Error" >&2

Also when those programs finish they return an integer value (named ${?}) which signals if it has finished properly or not for following commands. Success always has a value of 0, while any other value signals an error.

These are standard in every single application you see, and allows properly working between different software. For example, if The Dark Mod followed the standard, another application could check if it crashed and log the error:

    if [ ${?} -ne 0 ]; then
        echo "${function}: ${error}" >&2
        exit 1
    fi

I have written an application that allows all users in a system to run The Dark Mod with a single system wide folder. That application right now cannot tell when the program crashes. I'm planning to share the software in the case other people find it useful.

Share this post


Link to post
Share on other sites

Most of the errors about missing files do not terminate TDM. Missing assets usually allow to run the game, but corresponding objects look weird. There are only fatal errors which actually terminate stuff (where Windows users are dropped out of rendering engine and see a small blue window), and they happen rather rarely. Also, there are crashes, where application does not have reliable ways of doing anything.

In which cases do you suggest to return nonzero exit code?

I think right now you can see if anything bad happened by enabling qconsole.log via cvar and grepping it for ERROR: after TDM terminates. But note that perhaps you would see errors which don't stop users from playing the game normally.

  • Like 1

Share this post


Link to post
Share on other sites

The game also returns success even if crashes.

But anyway as rule of thumbs any error shall stop the process and crash the appliance for preventing further damage, and encourage people to fix it in situ before continuing further operation.

For example if there is a missing asset the user is better noticing it by a crash, so they can figure out why as soon as possible, than start gaming with damaged contents around.

The only exception of this is when that stop could cause a systemic collapse and there won't be a person able to fix it in a timely manner. For example, when the software is a system or server component.

lean-times-require-lean-thinking-16-728.

DFg1t_fXYAERm-I.jpg

lean-six-sigma-mistake-proofing-goleansi

Edited by Alberto Salvia Novella
  • Confused 1

Share this post


Link to post
Share on other sites
13 hours ago, Alberto Salvia Novella said:

For example if there is a missing asset the user is better noticing it by a crash, so they can figure out why as soon as possible, than start gaming with damaged contents around.

That's the dumbest thing I've heard in a long while. Literally nobody uses such rule.

  • Like 1

Share this post


Link to post
Share on other sites
12 minutes ago, peter_spy said:

That's the dumbest thing I've heard in a long while. Literally nobody uses such rule.

You should not be so bold about it. The idea of crashing if anything goes wrong is a very good idea in general, and I think a lot of programmers do so. I do so on my daily job most of the time. It is especially right because it is well-know that error-handling code is always the least-tested and the most-buggy. But I guess gamedev is somewhat different.

The particular example about missing assets is rather stupid, because assets for game engine is treated as input data. Crashing from a missing asset is like if interpreter would crash from any ill-formed source code. When a mapper develops his own mission, I guess he has missing assets most of the time, and he would be very unhappy if he could not play the game because of this.

Speaking about TDM, we have tons of console warnings on any FM right now. It surely could not happen if warnings were more annoying to everyone. I hope someone would clean them one day, but it is really a problem.

So the main problem right now is that obvious crashes somehow report zero exit code, right? I guess we can fix it.

  • Like 1

Share this post


Link to post
Share on other sites

Exactly, the key thing here is user type. End-user is neither a developer nor a content creator, they're not able to fix anything themselves. They should be able to enjoy a fan mission uninterrupted, to maximum possible extent, even with faulty or missing assets.

Content developers and content creators use the error message system, and even they can choose to what extent they ignore it. From the engine standpoint, assets (and by that I mean textures, materials, models and the like) are either rendered or not. So the biggest "penalty" engine-side is an error message + not rendering an asset, which is already implemented. Since a map can contain several hundred / thousand models with assigned textures and materials, it would be highly unpractical to punish a mapper with a crash. The engine is restrictive enough already, with things like not letting entities be placed in the void (which other engines I know permit).

  • Like 1

Share this post


Link to post
Share on other sites

I'm with peter_spy on this and I assume John Carmack/id software also agrees, why, because the Doom 3 game and engine is full of warnings and even missing asset errors that do not cause a crash! Is totally normal during development to mess around with assets, materials, models, fonts, etc that never end being used and so get broken definitions to stick around, like i said, Doom 3 came with many broken/missing .mrt and .def files but the game worked just fine. When you are developing, specially in a multi-user environment you don't want your game and tools to constantly crash because someone else failed to delete a material file!?

IMO crashes (asserts) and game-stop errors should be used for things that can potentially make harm to the user PC or cause serious visual problems in the game, all the rest should just be developer warnings that may or not be solved until shipping.

And if you really want to cause crashes for everything during development then, use assert, those only trigger on Debug mode not release mode so there's no danger of the final release mode game crashing because of something that should be a simple warning.   

Edited by HMart
  • Thanks 1

Share this post


Link to post
Share on other sites

When I said crashing I meant doing so before starting the mission, not while in it.

This creates quality by design, by forcing people to deliver only maps which have all the defects corrected beforehand.

In the Doom 3 context that won't make sense, cause it's a standalone product. A crash would mean crashing the entire game while playing, not as previous check before loading a map. Big difference.

Feature_Image_MDM_Best_Practices_Policy.

Edited by Alberto Salvia Novella

Share this post


Link to post
Share on other sites

That approach still doesn't make sense, regardless of development type. Whether we're talking about one-man projects, or team efforts, the final result is often full of flaws, minor concessions and bugs that are not show-stoppers. Noone in their sane mind would want to make them a no-go bugs for a project, especially if deadlines have to be met. This way people can assume an MVP and work on fixes or enhancements after a go-live.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...