** Bug Posting Guidelines **
-
- Posts: 7656
- Joined: Sat Aug 07, 2004 5:14 am
- Location: Some cold place
-
- Posts: 863
- Joined: Sun Aug 29, 2004 6:15 am
- Location: Sydney, Australia
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.doom2day wrote:If someone knows how to reproduce a bug then that would be useful
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.
-
- Posts: 353
- Joined: Tue Jul 15, 2003 4:09 pm
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Location: Land with them kangaroo
-
- Posts: 13741
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: ** Bug Posting Guidelines **
Should be updated:
Possible additions? (Everyone suggests this after a bug for an official version, even devs...)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.
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.
-
- Posts: 3288
- Joined: Sun Oct 03, 2004 8:57 am
- Preferred Pronouns: They/Them
- Location: South Africa
Re: ** Bug Posting Guidelines **
I've changed the version number, I'll let the devs add the other two if they want to.
-
-
- Posts: 17924
- Joined: Fri Jul 06, 2007 3:22 pm
Re: ** Bug Posting Guidelines **
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.
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.
-
-
- Posts: 10773
- Joined: Sun Jul 20, 2003 12:15 pm
Re: ** Bug Posting Guidelines **
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 ).
-
- Lead GZDoom+Raze Developer
- Posts: 49146
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ** Bug Posting Guidelines **
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!
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!
-
-
- Posts: 26540
- Joined: Tue Jul 15, 2003 4:58 pm
- Location: Scotland
Re: ** Bug Posting Guidelines **
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.
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.
-
-
- Posts: 17924
- Joined: Fri Jul 06, 2007 3:22 pm
Re: ** Bug Posting Guidelines **
It's easy enough to split this thread in two, for anybody having access to moderator options.
-
-
- Posts: 10773
- Joined: Sun Jul 20, 2003 12:15 pm
Re: ** Bug Posting Guidelines **
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.
-
-
- Posts: 26540
- Joined: Tue Jul 15, 2003 4:58 pm
- Location: Scotland
Re: ** Bug Posting Guidelines **
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.
-
- Posts: 3288
- Joined: Sun Oct 03, 2004 8:57 am
- Preferred Pronouns: They/Them
- Location: South Africa
Re: ** Bug Posting Guidelines **
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.
My guess is Graf or Randy would have to do it.
-
-
- Posts: 17924
- Joined: Fri Jul 06, 2007 3:22 pm
Re: ** Bug Posting Guidelines **
I think that "recent unofficial SVN build" should be a link to here because there are still people who cannot find this place.Mr. Tee wrote: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.
-
- Posts: 3288
- Joined: Sun Oct 03, 2004 8:57 am
- Preferred Pronouns: They/Them
- Location: South Africa
Re: ** Bug Posting Guidelines **
Now that I can do.