Split from "Detecting automap?"

[Xtyfe]

The suggestion forum is not getting any smaller, I think this is a reasonable idea.

It has been stated before that one of the functions of the suggestions forum is to provide a library of possible suggestions for the devs to peruse should they feel like working on some new features. Getting smaller is not necessarily a good thing in that case.

I guess my frustrations about things not currently being developed from there were too subtle

[Zippy]

So how do you reconcile the existence of all these features which have nothing to do with Doom with "it will always be a Doom engine"? These features have, as far as I can tell, been added to extend the capabilities of the modder in bringing his or her creative vision into the engine, not to further emulate the Doom engine's original behavior. The current feature set can be used to turn a mod into something virtually unrecognizable as a Doom game. What is your threshold at which point a feature makes ZDoom not Doom anymore?

It's not Chocolate Doom. And the point isn't specifically and only to emulate vanilla. The point is that it's a Doom engine. The fundamental underpinnings of the engine are strongly based in Doom. And that's important because the Doom engine was created years and years ago with the express purpose of serving a specific kind of game. Those fundamentals are built into the very thought and design of the engine.

"Emulation" and "Expansion" are different things. Things need not be rejected just because they aren't "Doomy". But they do have to mesh with the history and design of the engine. And the purpose that the developers see for the engine. And the design principles that the developers hold.

Also, there is no "threshold" of a feature making ZDoom "not Doom". Don't fall into that trap. Things are rarely so digital.

Bad how?

In the ways several others have already pointed out. Mainly that it's not robust. If it breaks the simulation in some circumstances, that is an immediate red flag. And the reasoning, "some other existent features can break the simulation already," isn't a valid justification.

[Blzut3]

As has been basically said the matter of accepting or rejecting a feature isn't so much about if a feature would make sense in Doom's gameplay, but rather if the feature makes sense in the design of the engine. While ZDoom isn't perfect there are some things you can pretty much expect with ZDoom (by no means a comprehensive list):

• Your mod will work on any platform supported by ZDoom.
• Your mod will work on future versions of ZDoom [if you bother to let us know when it breaks].
  • Debug mode will work so that developers can examine issues.
  • Future features should either enhance your mod or not affect it. (This is why we want to avoid being able to detect renderers for example.)
  • A sub-category of future versions are forks
• Your mod will work in multiplayer provided some simple precautions are taken.
  • Your mod will work on different net code models even if not optimally.
• You can record a demo of your mod which can at least be used as an intermediate step for video encoding
• For players: No mod will alter the state of your computer.

Now anyone who has delt with ZDoom for an extended period of time would know that some features break these rules. The problem is the rule I highlighted, if we make a mistake it's more or less permanent (unless it's particularly bad and there's just no way to support it). ZDoom isn't perfect of course and getcvar is an excellent of something that probably should have been implemented in a different way.

So now with that said what is wrong with detecting the automap in ACS from an engine design standpoint. Simple, the presence of the automap is not tied to the game state and ACS is designed to alter the game state. The previously mentioned net synchronization issue is one example of a problem that is caused by allowing this.

Besides the network there are some advantages of having things like the automap not locked to the game state. I could, for example, implement multi-head support into ZDoom and have the second screen operate exclusively as an auto map. What does your automap detecting function do in this case? If you use it to cover the automap you have been circumvented. Ignoring abuse, what if you use it to draw useful information over the automap how does the engine know? Now you have things floating over the game view since your code was unaware (as it should be) of this feature.

As someone suggested this could be solved by adding more specific features like hinting that the hudmessage should not be drawn over the automap. This way the engine can do what it needs to work as expected. There's nothing really wrong with drawing stuff based on if the automap is up or not. SBarInfo allows it since SBarInfo is a read-only script. (If anyone wants to know what SBarInfo would do in the multi-head configuration, probably a case of if(automapBarIsDefined) drawAutomapBarOnSecondScreen else drawNothing.)

Also, when we reject a feature because of abuse potential it's not exacly because it can be abused, but rather because realistically speaking the largest use case for the feature is abuse.

[Nash]

Well, Blzut3 said pretty much everything that needs to be said. I think the picture is clear now, technically at least.