** Feature Suggesting Guidelines **

[Cutmanmike]

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

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 Changelog (Use Ctrl+F to search using keywords that apply to the feature you want. For example if you wanted to know if GZDoom 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 GZDoom version). If you haven't found anything, ask about it in the Editing forum, just in case.

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 suggest huge changes.

By "huge," we mean things like "3D Models in Software Renderer", "Video rendering support", "In-game Internet Browser", or "Better Netcode." Major changes which require a lot of work should be up to the developers, and will probably end up with [Later] or [No] tags.

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 Suggestions 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!

5. Want to help clean things up? Please do so responsibly.

Once in a while, someone will have suggested a feature that is already in, or you might find an old thread suggests the same feature as another, newer thread. To help the devs clear out the list, please bump the thread and mention that the feature should be closed. Please don't use the Report Post button, as the devs do not often check the Reported Posts, and this also clogs up the Reported list for the moderators who are not necessarily devs.

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 GZDoom (or a development version)
[Already In]/[Not Needed] - What you requested is already in GZDoom and/or there is another way to do what you requested.
[Later] - Will be reconsidered at a later date (Maybe).
[DIY] - GZDoom already has what is necessary to handle the feature you are suggesting, and implementation is your job, not the developer's.

[TheDarkArchon]

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

[Cutmanmike]

S'pose so

[Matt]

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.

[Matt]

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.

[Matt]

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 [wiki]A_CustomBulletAttack[/wiki] and less like [wiki]A_PosAttack[/wiki], 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.

[Rachael]

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.

[wildweasel]

I was trying to remember if we had any stances on flagging/reporting bug/feature threads that have already been taken care of - I see a pile of reports in the Moderator CP right now that are all on Features threads that are either deprecated or already in. Since Global Moderators can't move anything into the Closed Features/Closed Bugs areas, and I'm unsure if Graf can access the reported posts, would it not be better for a user to simply bump the thread in question if it needs closing?

[Graf Zahl]

I haven't seen any reports. Bumping is definitely better because it also pushes the thread to the top.

[Nash]

Ah, my bad. I do vaguely recall instructions in the past that it's better to bump them; somehow it seems it didn't cross my mind just now. WW, can you send me a picture of the barrage of threads that I reported? It's 2 AM now and I'm really tired and I'd rather not go through the 20 pages again...

Sorry for the inconvenience. Just wanted to do my part to clean up the Feature Suggestions forum.

[Major Cooke]

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.

Well, I broke this one already by adding god2 and buddha2.

Albeit the only difference is they absorb everything.

-----

Unrelated note, perhaps WFDS should become WFZS?

[Rachael]

Well, I broke this one already by adding god2 and buddha2.

The difference is, you added something useful that wasn't in there before.

When I made that post, about 1 in 40-50 feature request threads were about restricting a player's ability to cheat from a modder's perspective, the "adding" part admittedly was probably just put in there to make it seem more solid and complete (and non-negotiable) but it was more in reference to adding codes that were already there for other reasons (i.e. duplicating iddqd).

Can you believe it's been 8 years since that post was made, though?