The importance of simple examples in bug reports

Is there something that doesn't work right in the latest GZDoom? Post about it here.

Moderator: GZDoom Developers

Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.

If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.

Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!
User avatar
Rachael
Posts: 13527
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

The importance of simple examples in bug reports

Post by Rachael »

(cross-posted from this post - please go there to comment!)
I wrote:Today I want to touch on a topic that I don't think is stressed enough in this community: And it applies, in reality, to every project, not just Doom-related ones, and certainly not just GZDoom and its relatives regarding bug reports: Examples.

A lot of times, someone will post a bug report, which doesn't have a lot of info in it, and is pretty much the equivalent of "hurr hurr it duzint wurk!" These bugs are extremely difficult to solve, and the chances of it even being looked at are far less when you make it more difficult for it to be investigated.

While it is our goal to solve every bug we can, not leaving us with enough information about it is hugely problematic.

Another issue that seems to happen a lot is very complex mods are given as examples, requiring a huge download (and sometimes even a click-maze of advertisements to get through). This not only increases the amount of time required for us to acquire said mod in order to investigate it, but it greatly increases the difficulty of fixing the issue because of the amount of effort required to actually play the mod to get the issue to occur.

Two things really get in the way of fixing a mod: Startup time (with bigger mods) and time taken to reproduce the bug. The reason why this is such a huge issue is because we're not wholly unlike modders, ourselves - except our work requires us to restart GZDoom repeatedly because there is no way to make "live" changes to the running game. To make matters worse, sometimes we have to use debug builds, which are less than half the speed of the builds everyone else uses (that we distribute, both as releases and as devbuilds) - so complex mods are completely out of the question because it literally *is* unplayable for us, not to mention a nightmare to load. Repeatedly.

Here is an example of a GOOD bug report:
viewtopic.php?f=7&t=51976

The example is simple. It is nothing more than a square room that plainly shows the problem. There is no jumping through hoops to get it, it's simple to acquire, simple to run, and the problem shows immediately upon entering the map. This is ideal - and it should take you no more than a few minutes to construct. It doesn't have to be pretty - feel free to use the default textures. We won't judge your mapping skills on it. We'd really like to see more reports like these.

Here is an example of a BAD bug report:
1. Load up WolfenDoom: Blade of Agony with a recent GZDoom build.
2. Go to INTERMAP. Optionally, play through some of the missions until Marlene Dietrich appears.
3. Save your game.
4. Re-load your saved game.
5. The time of day and/or weather may change, or Marlene Dietrich and her audience will vanish.
There are a number of problems with this: First off, this is a huge mod, requiring a significant download in order to investigate. Secondly, it requires us to actually play missions - with an unknown length of time, which is *NOT* good when we have to restart the game over and over again, especially in a Debug build! The worst part is, it's difficult to know just by something random like a change in weather whether we solved the bug or not. I really do not want to see examples like these because they really hinder our ability to investigate them. (The original author was kind enough to whip up a more simplified example - thanks for that, and sorry to use your report as an example, but it is just one of many that are problematic)

Another problem with this is the instructions state "recent GZDoom build." If we aren't able to solve the bug immediately, then what happens is "recent" becomes highly ambiguous - to the point where we discard the bug report because we don't know what version to use. (In fact, it may have already been solved by then) Look in your GZDoom-username.ini file on the top line - it has the following:

Code: Select all

# This file was generated by GZDoom g2.4pre-693-g4a87a59 on Sat Mar 11 02:18:13 2017
Use that line to get the game's version number. If you don't know what part we want, just paste the whole line. It's okay! We know what to look for, there.

What it really comes down to is - we're not clairvoyant, and we need YOUR help in order to be able to help YOU! Keep it simple, make it so that we can restart the game over and over again right into the problem until it is solved. That will help HUGELY when we try and fix the bug.

If you do need to provide a big mod, however (and the problem is not feasible in a smaller one), giving console commands (such as player coordinates) or a savegame that warps right to the issue is helpful, also.

Thank you!

Return to “Bugs [GZDoom]”