** Feature Suggesting Guidelines **

[Cutmanmike]

1) Make sure the feature you're suggesting isn't already in ZDoom.

You can usually check by browsing the Wiki and looking for whatever you're after. If it's not there, it's a good idea to have a quick scan through the SVN Changelog (Use Ctrl+F to search using keywords that apply to the feature you want. For example if you wanted to know if ZDoom supported custom damage types, use a word like "damage" or "damagetype" in the search box) to see if it hasn't been recently added (meaning it will be in the next ZDoom version).

2. Give an example where your suggestion would be useful.

Unless it is really obvious how your suggestion could be handy, please include an example where you could use it.

A suggestion such as "Players able to be viewed as skyboxes" with no description or example on why one would want to make a player a skybox, would be a bad example of a feature request. Unless you can come up with a good example why authors would use the feature you're requesting it probably won't get added. Things such as "Because it would look cool!" etc are not really acceptable.

3. Don't request huge requests.

By huge requests I mean complex things like 3D Floor support, GL Renderer, Better Netcode. Major changes which require alot of work should be upto the developers, and will probably end up with [Later] or [No] tags (For the examples above you should try using another ZDoom based port such as GZdoom or Skulltag).

4. Don't re-suggest things you have suggested in the past.

If your suggestion gets No'd within good reason, don't post the same suggestion again. By all means try to work out and debate around the refusal in the Closed Feature Requests forum, even if it means bumping an old topic. More importantly don't get angry/upset and begin flaming if your feature wasn't added!

Closed request reason reference:

[No] - The request was not accepted. Read the thread to find out the reason.
[Added]/[Done] - The request was added and will be in the next version of ZDoom (or the SVN version)
[Already In]/[Not Needed] - What you requested is already in ZDoom and/or there is another way to do what you requested.
[Later] - Will be reconsidered at a later date (Maybe).
[WFDS] - Wait for DoomScript (A fabled ZDoom scripting language Randy has been planning for some time). In other words, wait until the engine is more capable.

Edit: Because we have one for bugs, and Mr.Tee isn't here to save us! Tell me if I missed something or made something up

[TheDarkArchon]

I would group [not needed] in with [already in] rather than [no]

[Cutmanmike]

S'pose so

[Vaecrius]

Don't mind if I suggest the top three reasons why feature suggestions, especially DECORATE suggestions, are rejected? There's considerable overlap with Cutman's guidelines, but are a bit more specific and (hopefully) more from the POV of someone looking at a suggestion than thinking one up.

1. Cost/Benefit analysis

The simplest of the three. Basically, you have W, the amount of work needed to properly implement your feature, and A, the amount of awesomeness that Randy or Graf could expect to see from use of this feature, in terms of both inherent functionality and likelihood of being used by others. If A does not significantly, objectively exceed W, then you're probably out of luck, even if the effect you want is currently impossible.

Note that if it's impossible to "properly" implement your suggestion, then it's going to be a flat-out no.


2. Passing the buck on to Randy and Graf

Really a subset of "cost/benefit analysis" but big and frequent enough to merit its own section. There are certain suggestions that are understood as basically the poster being too lazy to come up with an already possible solution and instead just want ZDoom to have a simple flag or function that does what they want.

Things that might raise warning flags that your suggestion will be refused on this basis:

• Can the ultimate effect of what you want be achieved using other means?
• Are these other means reasonable, i.e., would a reasonably alert modder be able to figure it out without resorting to some convoluted "hack"? (This unfortunately boils down to a judgement call that can't quite be quantified, and may be related to the original intent behind the introduction of any particular hard-coded feature)
• Even if the answers to both of the above are yes, can you save it by pointing out some old Doom-engine game that has this feature hard-coded and thus worthy of special treatment?
• Even if the feature is unique and cannot be achieved without a significant hack, would a hard-coded equivalent also be as convoluted as your hack?
• How applicable is this to other projects than the one that prompted you to make this suggestion?
• How applicable is this to other uses than the one that prompted you to make this suggestion?

3. Turning DECORATE into high-level QuakeC

That is what <strike>GODOT++</strike> DoomScript is for. DECORATE is really closer to a markup language like HTML than a Turing-complete language like C++ and the framework is quite unfit to accommodate things like AI or world physics or vectors or anything else that fundamentally changes how Doom works. Suggestions like this will most likely be rejected.

(someone please look over this explanation and correct if necessary, as I am not a programmer!)

[Graf Zahl]

Let's not forget one more:

Please verify whether the feature you want has already been implemented

Not all features are well known and get re-suggested quite frequently. It would save a lot of work if you could browse through the Wiki before making a suggestion.

[Vaecrius]

Isn't that exactly the same as Cutman's #1?

(Although it might be useful to split it into two things: make sure it's not something in the current release, and make sure it hasn't already been added in an SVN...)

[Graf Zahl]

It can't be stated often enough - and in as many different ways as possible,

You know, I really wish Randy would take the time to browse through the open suggestions and make a few comments himself so that everyone knows where the limits are.

[Vaecrius]

How about this:

Suggest a new feature as a last, not first, resort.

Take all reasonable steps to try to get what you want with what you have before asking for fundamental changes to how ZDoom works. Or non-fundamental changes, for that matter.

1. First, take what you want and break it down into how the Doom engine (more or less) sees things. Note the parts that do not seem to fit.
2. Search in the forums and in the wiki for those parts that do not seem to fit. If that doesn't work, try searching for the end effect that you want as well. If you still find nothing, continue on to the next step.
3. Take those parts that do not seem to fit and compare/contrast how the engine would see it vs. what the user would see.
4. Work out what alternative approaches could avoid the issues in (3) and still give, for the user, substantially the same effect.
5. If you still have processes that involve things you haven't seen in ZDoom, do another wiki/forum search looking for not your originally desired mechanism, but the alternative mechanisms that might work. If you find nothing, continue on to the next step.
6. Write up a few alternatives that, even if they don't give quite the effect you wanted, can in a pinch serve the same function.
7. Consider all the alternatives you've written. If all of them are unsatisfactory - whether because they largely fail to achieve what you want, or because you have 50 lines of convoluted code duplicated ten times for one tiny effect - continue on to the next step.
8. Devise a new feature for ZDoom that is based on existing functions and minimally changes any framework that needs to be changed. Whittle what you need down to its most basic properties for maximum applicability and flexibility: if your desired feature starts looking more like A_CustomBulletAttack and less like A_PosAttack, you know you're on the right track.
9. Come up with a few other situations where your desired feature might apply (and would not already be covered by some other function). If you can't think of a few very different examples that people are likely to want to use, go back to step 8.
10. Post your feature suggestion. Show, or at least briefly describe, your work.

[Eruanna]

This HAS to be said, and preferably edited into the first post:

Cheat Codes
They're not changing. You cannot add to them. You cannot subtract from them. You cannot disable a player's ability to cheat. You cannot add in ACS functions to easily detect player cheating. You cannot customize them. They are what they are, and that's what they'll always be. If you don't like it, this is not the forum you want to post in, because it will just be [No]'d, and you'll be flamed, etc, end of story. 'nuf said.

[Graf Zahl]

I wouldn't add this to the first post but it needs to be said here, too:

If you want to suggest a workaround for a requested feature please think first if your workaround meets the suggester's needs. I have seen it too many times that some people post stuff that completely ignores the original post's motivation or suggests some laborious things that would be more an annoyance than anything else to do repeatedly. Often these things come equipped with the word 'just' as if it was the most normal thing to do repeated cumbersome routines.

Such posts tend to create tension because the OP might feel ignored on purpose by that. Here's a good example of this kind of behavior which I really don't want to see anymore on the Feature Suggestions forum.