** Bug Posting Guidelines **

[TheDarkArchon]

You made a bump of 360 days just to say that?

[Sir_Alien]

If someone knows how to reproduce a bug then that would be useful

If it's a bug that has happened to you, and you need to force it to happen again for the sake of reporting it, just do exactly the same thing you were doing when the bug occured the first time.

Otherwise, if you want to see a reported bug for your self for curiosity's sake, there is no one answer, since a lot of bugs are very specific. Read about any posted bugs and the bug report of what was happening in the game and try and replicate that situation for yourself.

[deathz0r]

You made a bump of 360 days just to say that?

Second golden forum rule: It's impossible to bump stickied threads.

[Rachael]

Should be updated:

6. Don't post bugs for anything older than 2.3.0, especially 1.22. These versions are old and won't be updated anymore. If you encounter a problem with these versions please verify first with a more recent version that the problem still exists.

Possible additions? (Everyone suggests this after a bug for an official version, even devs...)

9. Before posting your bug, please try to reproduce it in a pre-compiled SVN version. These versions often contain the latest fixes for bugs, and unlike official versions, are updated on a daily-to-weekly basis. If you cannot reproduce your bug in an SVN version, chances are it's already been reported and fixed, and your bug will be regarded as a duplicate.

10. Bugs which show ZDoom deviates from vanilla Doom/Heretic/Strife/Hexen will often be ignored and discarded. While reproduction of the original gameplay experience is important, it's also important to remember that ZDoom is a source port, not the vanilla game, and it will not replicate every minor detail of every game that you can play with it. Examples include permanent corpses in Strife, air control in Doom, artifacts in the software rendering (such as lighting and textures), remember this is not a complete list.

[Siggi]

I've changed the version number, I'll let the devs add the other two if they want to.

[Gez]

A few additional guidelines:

Addendum to 5: If the bug happens with the latest official version, check with a recent unofficial SVN build if it happens as well. No need to report a bug that's already been reported and fixed.


8: If you need to attach something to check the bug (such as a test mod, demo, save, etc.), then DO NOT use a non-permanent host like Rapidshare, MediaFire, or similar. If the file is small enough, zip it and attach it. Otherwise, host it on your own webspace or on the DRD Team files service.

[Xaser]

Agreed on #8, as long as "DRD Team Files service" is a link to the right place, so newcomers can find it easily (or at least have no excuse for missing it ).

[Graf Zahl]

I added a new guideline (See point 5.)

I'll make it very clear again: I will completely ignore any bug report sent by PM from now on! I will not respond to them nor will I keep them in my inbox. I will delete them without taking any action on them.

There's still some people who apparently think it's ok nagging the developers to fix their problem spots and believe that a PM is a better tool for that. This is really annoying because it clutters my inbox with stuff that should be in the public forum. So if the only way I can make people learn this is the hard way, so be it!

[Enjay]

Can I make a suggestion about this (and other) announcement threads? IMO, it would be better if this thread was pruned to a single post. ie, it had the rules post and all subsequent discussion was either deleted after it was finished with or discussion posts moved to a different thread for record purposes, or an entirely separate rules discussion thread.

Why? Because I have visited a number of forums where there is an announcement thread about rules or whatever and when you see that it has dozens, if not hundreds, of posts in it, there is an automatic reaction of "I can't be bothered reading all that". Equally, I have visited forums where their announcements are a single-post thread. Such threads are far less daunting to open and read.

Now, I know that the important stuff in this thread has been consolidated into the first post and that is all a newcomer has to read, but the newcomer doesn't know that and it is off putting to see that the thread has a large number of posts. If a newbie sees an announcement thread and it clearly only has one post in it, I think it will be more likely to get read.

[Gez]

It's easy enough to split this thread in two, for anybody having access to moderator options.

[Xaser]

I'm all for the split, but I don't want to see the discussion deleted. A subsequent sticky could be handy in such a case.

[Enjay]

I agree, deleting it would not be the best. IMO, a single-post guidelines thread that was locked, so only mods/admins could alter it, with a separate rules discussion thread would be good.

[Siggi]

It seems I can't change the thread type in the Development forums. Which means I can't guarantee this thread would still be stickied if I split it.

My guess is Graf or Randy would have to do it.

[Gez]

6. Don't post bug reports for any version older than 2.3.1 (such as 2.3.0, 2.0.99x, 1.22) These versions are old and won't be updated anymore. If you encounter a problem with these versions please verify first with a more recent version that the problem still exists. If the bug happens with the latest official version, check with a recent unofficial SVN build if it happens as well. No need to report a bug that's already been reported and fixed.

I think that "recent unofficial SVN build" should be a link to here because there are still people who cannot find this place.

[Siggi]

Now that I can do.