Jump to content
The Dark Mod Forums

The game exits with success code even on error


Alberto Salvia Novella
 Share

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.

Link to comment
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.

Link to comment
Share on other sites

  • 1 month later...

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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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
  • Like 1
  • Thanks 1
Link to comment
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
Link to comment
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.

Link to comment
Share on other sites

I personally only ship technology that after testing it from all angles I don't find bugs in it myself, and even then I have to correct plenty of thing. My advantage is that I correct them as soon as possible, I don't continue buying furniture when my home is on fire.

Sure there are bugs that are undetectable at first, but missing assets don't belong into that category. It's like shipping a car without mirrors, and saying you didn't see it.

Cause if you haven't had time to do it right, what makes you think that you will have time to fix it?

I have already seen many brilliant ideas during my lifetime that failed just because the program was buggy. All the business that did that were out of the game on the fast track, and this project is not exception.

For instance the Dark Mod installer seems to fall into that type. Great idea, but my friends won't install it because the installer simply crashes on their Windows computer. Adding that the infrastructure is now down, it doesn't matter how great the game is. For them it simply doesn't work.

One think is making mistakes, but seeing them as such and prone to correction. On the other hand saying that shipping with half assed bugs is gud, I strongly think that's a joke. This isn't even difference of opinion, this is playing phony on me. Further refute from my side is waste.

  • Haha 1
Link to comment
Share on other sites

Alberto, I think we can introduce a cvar which would control warnings behavior. With possibilities:

  1. Print to console and do nothing else (like it does now).
  2. Print to console + show a few latest ones on top of the screen even with console closed (this already happens in debug builds, maybe there is even a cvar for it).
  3. Print to console + show last few, and produce a beep sound.
  4. Raise every warning to error. Errors throw exceptions, efficiently ending the current game session and going to main menu.

Given the amount of already released missions, I seriously doubt we would ever have anything except p.1 as default. But we could at least recommend more annoying warning policies to mappers when they are close to finishing their maps.

Link to comment
Share on other sites

4 hours ago, Alberto Salvia Novella said:

Sure there are bugs that are undetectable at first, but missing assets don't belong into that category. It's like shipping a car without mirrors, and saying you didn't see it.

That's a really poor analogy, since car mirrors are one of the core functionalities of a car. It's more like an FM being shipped with light gem being dark all the time.

4 hours ago, Alberto Salvia Novella said:

Cause if you haven't had time to do it right, what makes you think that you will have time to fix it?

You seem to be great at dogmatic theories from decades ago, but you're out of touch with modern practice. That's how development works these days, for quite some time now. Project scopes change all the time. Deadlines move, people have to abandon functionalities or settle for less. They leave half-working things in the background, move items to the backlog, so they can work on them when time / client allows. There are select people that prioritize bugfixes, but again, noone in their sane mind would waste time on implementing something that makes non-critical errors critical, just to push people to work harder.

And getting back to FMs and more personal projects, the practical side of things is, again, that the map can contain several thousands of entities. Missing even several of them (or missing textures, materials) is a low to medium priority fix. Might be a high priority if it's a plot item, but engine still will render a black box not sure whether it's frobabble. But technically, it still might be possible to finish the mission with a key loot model missing. If a texture or material def is missing, it will just turn black, so again, a high priority, not critical. Nothing worth crashing the game.

Link to comment
Share on other sites

Hard crashing the entire application for a missing asset is just stupid. If you do this on Windows (which most mappers and players are using), nobody will even see the error. They will just get the standard Windows "This application has caused an error and will be shut down" dialog and have no idea why unless they go hunting in log files. There is no benefit in this behaviour, you are literally hiding the problem if you do this. The only people who would conceivably want a console message followed by a hard crash are people running the game from the command line on Linux, which is a tiny minority of the userbase.

If you wanted to make a missing asset a hard error (in order to prevent mappers from inadvertently shipping a map with a missing asset), you could make it print a message in the internal console and then refuse to load the map, much like what currently happens if you try to compile a map which has a leak. This behaviour might be useful for mappers but would have no use whatsoever for end users (who are not responsible for the assets in a map), so it should at best be a configurable developer option, as stgatilov is suggesting.

  • Like 1
Link to comment
Share on other sites

4 hours ago, stgatilov said:

Given the amount of already released missions, I seriously doubt we would ever have anything except p.1 as default. But we could at least recommend more annoying warning policies to mappers when they are close to finishing their maps.

Yeah, it won't make sense at this point crashing the game for missing assets, as that could lead many campaigns as broken. It was just more like an ideal outlook.

Nevertheless probably there could be ways to make any error noticeable for sure, even if there's no crash.

3 hours ago, peter_spy said:

You seem to be great at dogmatic theories from decades ago, but you're out of touch with modern practice.

Better quality is what increases speed, enabling Agile and Lean methodologies. The sooner you figure out mistake proofed ways of working the faster you can move to new features and ship, instead of constantly firefighting past issues and rely on in dept testing.

For instance my latest software is DevOps software, which I use for packaging apps using continuous integration. I'm considering releasing daily, or even hourly.

More time creating, less maintaining. Be smart lazy, not dumb lazy. Mistake proof today, release quality now, relax tomorrow.

Link to comment
Share on other sites

 

2 hours ago, OrbWeaver said:

If you wanted to make a missing asset a hard error (in order to prevent mappers from inadvertently shipping a map with a missing asset), you could make it print a message in the internal console and then refuse to load the map, much like what currently happens if you try to compile a map which has a leak. This behaviour might be useful for mappers but would have no use whatsoever for end users (who are not responsible for the assets in a map), so it should at best be a configurable developer option, as stgatilov is suggesting.

I'd even go as far as to say that even mappers aren't responsible for most assets in the map. Many TDM missions use stock assets, with a just few customizations here and there. As you know, there are numerous errors appearing in the console just when you're using stock assets, and these are mostly harmless, e.g. engine is looking for some old paths/dependencies, throws an error, then finds new paths (eg. to textures). Obviously, making the engine crash because of that would be ridiculous.

2 hours ago, Alberto Salvia Novella said:

More time creating, less maintaining. Blah, blah, blah...

Yeah, you're high on corporate slogans, but what you've written so far shows you have no idea how collaborative projects work in practice, because you keep ignoring the context like scope, functionality, or user type.

Edited by peter_spy
Link to comment
Share on other sites

Yeah, you keep nailing it ?

xwOhVggtUaxQmCFS9B9qYMfUvWBIYd3Bf5qN0hJt

I have been involved in collaborative projects for the latest twelve years, coordinating the Ubuntu Papercuts project for three. The Ubuntu origami look and feel was inspired in one of my designs.

Keep spinning for jackpot ?

Edited by Alberto Salvia Novella
Link to comment
Share on other sites

You people keep missing each other's points, I think. Context matters :) Alberto, while I agree with your practices in principle, even "universal" concepts don't apply universally to every problem. I would recommend trying to find a recording of John Romero talking about id Software's history and how they approached game design. He specifically mentions why missing assets are not treated as hard errors, and - surprise - it was specifically to enable fast iteration and getting products shipped :)

Like I said, context matters. Missions and assets are not quite the same thing as writing code.

  • Like 3
Link to comment
Share on other sites

15 minutes ago, Alberto Salvia Novella said:

I have been involved in collaborative projects for the latest twelve years, coordinating the Ubuntu Papercuts project for three. The Ubuntu origami look and feel was inspired in one of my designs.

...And yet you've been playing some fast and loose with terms like DevOps, saying you have "a DevOps software" :D Which is nonsense, showing that you don't necessarily grasp what DevOps really means.

Same for acting like a big-time slogan-driven programmer in the age of Agile, where something completely different (and almost exactly opposite) constitutes the foundation of day-to-day development. And I'm saying that as a newbie in IT, actually. So it doesn't take that long to get that :) 

Link to comment
Share on other sites

Alberto, could you please comment if my suggestion would help for your goal?

I'm afraid that some sort of compromise is the best we could get here.

 

P.S. When I start hearing trendy words like Agile, DevOps, etc., I usually instinctively block myself from whatever follows...

  • Like 1
Link to comment
Share on other sites

maps being compiled would not see a missing asset,(except for maybe a info_player_start) as the dmap only compiles the world brushes into walls, floors, ceilings, and adds stuff for assets if they are there and ignores them if they are not. unless a model origin is in the void, but that is just detecting that an inside part is in the void, if that asset isn't loaded then it isn't there.

 

this is the wrong type of program for some thing like agile or devops methods,

 

Edited by stumpy
Link to comment
Share on other sites

Yeah, there is a lot of noise and unnecessary corporate speak behind stuff like Agile or DevOps, but when you trim out the fat, it boils down to a few useful and relatively simple things.

TDM might benefit from it, but obviously this isn't a pro / business-oriented project. People simply do what they can, when they can. Thus spamming pseudo-motivational programming memes is not going to help with anything.

Link to comment
Share on other sites

I guess that printing to the console and to the top of the screen would be the ideal, as long as there aren't an abundance of missing assets. Otherwise it would need a still obvious, but not as invasive, way to notice the error.

Perhaps a frog could croak every time there's some warning, not joking ?  That way it would be clear without affecting the game-play.

Or just having an easy way to show the console in game...

Edited by Alberto Salvia Novella
  • Like 1
Link to comment
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.

 Share

×
×
  • Create New...