Split from "Detecting automap?"

[Gez]

From my perspective, it is not the purview of the developer to ignore the content creation tier and make design decisions for the end-users.

They're making design decisions for themselves, thank you very much. If such a design decision includes "not risking the total destruction of netcode stability by adding hare-brained features that'll only be actually useful in weirdo experimental mods", then it is a decision that maybe you should respect.

If you are not happy with that decision, there are at least three forks of ZDoom out there that have been created with the express intent of adding some features that were denied by Graf and/or Randy.

It should be the modder's job to utilize the tools available to them

Yes, and that is exactly what they should do: use the tools available to them. Instead of clamoring for moar stuff all the times. I don't think the inability to disable the automap will really be the one single reason why you won't get a Cacoward this year.

[Trance]

They're making design decisions for themselves, thank you very much. If such a design decision includes "not risking the total destruction of netcode stability by adding hare-brained features that'll only be actually useful in weirdo experimental mods", then it is a decision that maybe you should respect.

I can only go back to my previously stated point that such features that risk destruction of netcode stability already exist, and have been used to positive effect by modders. It's an awfully dismissive generalization to paint, say, GetScreenWidth/Height() with the same broad brush, even though they pose the same risk to netcode stability if misused.

Consider this discussion in a general way, however, so it doesn't get sidetracked into talking about this one specific feature discussion. The main issue is the feature acceptance policy.

If you are not happy with that decision, there are at least three forks of ZDoom out there that have been created with the express intent of adding some features that were denied by Graf and/or Randy.

What I'd like is concrete justification for those features being denied in the first place. I'd like to know why it's considered valid justification to deny a feature in order to protect players from incompetent modders.

Yes, and that is exactly what they should do: use the tools available to them. Instead of clamoring for moar stuff all the times. I don't think the inability to disable the automap will really be the one single reason why you won't get a Cacoward this year.

I think it might. Any absence of a needed feature might be enough to lose someone a Cacoward. You never know for sure until you actually see the feature in action, nor can you predict any potential use of a feature by a clever modder.

[Gez]

I can only go back to my previously stated point that such features that risk destruction of netcode stability already exist, and have been used to positive effect by modders.

There is always potential for abuse in everything. The existence of a feature with abuse potential isn't a reason to accept another with a greater abuse potential.

What I'd like is concrete justification for those features being denied in the first place.

"I don't feel like working on that" should be enough justification for 100% of all denied suggestions. Devs aren't your personal slaves.

I think it might. Any absence of a needed feature might be enough to lose someone a Cacoward.

If a single feature is really that essential, then either the mod is far too gimmicky to stand a chance; or it should never have been made on a Doom engine to begin with.

[Kate]

"I don't feel like working on that" should be enough justification for 100% of all denied suggestions. Devs aren't your personal slaves.

He never said that wasn't a valid answer, but that is rarely ever the actual answer that is given.

[Trance]

There is always potential for abuse in everything. The existence of a feature with abuse potential isn't a reason to accept another with a greater abuse potential.

That wasn't my point. My point was, why is abuse potential sufficient justification to ignore creative potential and discard the feature suggestion?

"I don't feel like working on that" should be enough justification for 100% of all denied suggestions. Devs aren't your personal slaves.

I never even attempted to imply that. But if that's the real reason for denying a suggestion, then it should be an easy enough job for some other programmer to code it, and all the devs would need to do is merge it in. Hell, if that's the only reason for denying those features, they only need to say "Do the work yourself". But they'd have to have a different reason for then denying those features if they do actually get realized in code form, ready to be merged in.

If a single feature is really that essential, then either the mod is far too gimmicky to stand a chance; or it should never have been made on a Doom engine to begin with.

What a thing to say. I have far too many ways to go with this sentence to pick a single counterargument.

[TheDarkArchon]

There is always potential for abuse in everything. The existence of a feature with abuse potential isn't a reason to accept another with a greater abuse potential.

That wasn't my point. My point was, why is abuse potential sufficient justification to ignore creative potential and discard the feature suggestion?

Because abuse potential can outweigh creative potential.

[Trance]

Because abuse potential can outweigh creative potential.

If a feature is abused in a mod and breaks the game, the players can discard the mod as crap. No permanent harm has been done. The abuse potential extends only as far as the WAD itself.

I don't see how this compares with the wasted potential of a mod unrealized because the feature was never added in the first place.

[Slasher]

@Trance: You do realize that even if you win this argument (which you won't because it's already going around in circles at this point), the feature still won't be implemented, right?

Just give it up. What Gez said is the ultimate truth about ZDoom. It's a Doom Engine source port and was not intended to be anything more. And what the devs say goes, purely on the basis that they control what is added to ZDoom and you don't, if for no better reason.

[Trance]

Just give it up. What Gez said is the ultimate truth about ZDoom. It's a Doom Engine source port and was not intended to be anything more. And what the devs say goes, purely on the basis that they control what is added to ZDoom and you don't, if for no better reason.

On the "it's a Doom port and nothing more" point, I call BS. Ten years of development since 1.22 invalidates that argument. There is so much in the feature department that was never in any Doom-engine game. ZDoom has become something greater over time, and continuing to insist otherwise is absurd. It won't STOP being Doom just because of a new feature. That feature won't suddenly invade your stock DOOM2.WAD playthrough. It will exist strictly within the confines of a custom WAD.

And regarding the second point, that's what I'm afraid the argument will eventually boil down to: "Too bad, shut up, it's my project and not yours, I'll do whatever I want, and you don't matter". Such a stance would be virtually a middle-finger to the modding community. I can understand refusing to add a feature due to lack of motivation, but if someone who DOES have the motivation adds the feature, they'd need a better reason than lack of motivation for refusing to merge that feature in.

Potential harm to the user's filesystem, sure. A broken, buggy implementation, sure. But beyond that, what?

If "your feature isn't getting in, just 'cause" is the justification, then it ISN'T one, and just.... I don't know what to say to that. I would hope there would be a better reason offered than that.

[Xtyfe]

After reading this topic, I can't help but notice the direction of the conversation, in circles.

Trance, I don't see you stepping up and coding this. I say nut up or shut up

[Zippy]

Just give it up. What Gez said is the ultimate truth about ZDoom. It's a Doom Engine source port and was not intended to be anything more. And what the devs say goes, purely on the basis that they control what is added to ZDoom and you don't, if for no better reason.

On the "it's a Doom port and nothing more" point, I call BS. Ten years of development since 1.22 invalidates that argument. There is so much in the feature department that was never in any Doom-engine game. ZDoom has become something greater over time, and continuing to insist otherwise is absurd. It won't STOP being Doom just because of a new feature. That feature won't suddenly invade your stock DOOM2.WAD playthrough. It will exist strictly within the confines of a custom WAD.

No. No. No, it is, in fact, a Doom engine. It will always be a Doom engine. There is so much of ZDoom that is steeped in Doom-ism that it will never pull away. It will never be a generic custom game engine. It can do a lot of things, yes, and many of them are far and away from Doom, but it is still a Doom engine, by design and intent.

DECORATE, the way actors are defined, reeks of the way Doom originally did it. And it's flexible... enough. But there are way better ways for it to be done if you wanted "a way to create entities in a pseudo-3D world." But we're going to stick with this frame/action function based setup because that's the way Doom did it, and sticking with that is a hell of a convenience since our goal is to make an advanced Doom engine. And that works for the kind of worlds a Doom engine is capable of supporting. A lot of the same ideas apply across the board.

Doom is intrinsic to the way the engine is designed, first and foremost, and as far as I am aware there are no plans to move away from that. It's not about restricting the tools to modders. It's about understanding what the damn tool is designed for to begin with.

Sometimes a poorly implemented or broken feature really is worse than not having the feature at all. The automap thing is a problem that would be nice to be solved, but a bad solution is a bad solution.

[Enjay]

And regarding the second point, that's what I'm afraid the argument will eventually boil down to: "Too bad, shut up, it's my project and not yours, I'll do whatever I want, and you don't matter". Such a stance would be virtually a middle-finger to the modding community. I can understand refusing to add a feature due to lack of motivation, but if someone who DOES have the motivation adds the feature, they'd need a better reason than lack of motivation for refusing to merge that feature in.

Like it or not, when it comes down to it, the project (ZDoom) is the responsibility of the devs, especially Randi of course. It is his project and he can do whatever he wants with it. He doesn't need to justify the inclusion or non-inclusion of a feature to anyone if he doesn't want to. The devs usually do give a reason, but they don't need to.

Saying that the non-inclusion of a feature for the reason "it's mine and I'll do whatever I want" is a middle finger to the modding community?

A man goes into a pub in a small town and, for whatever reason, gets introduced to the clientele. There’s Farmer Jack, Barman Jim, Maurice “Dancer” and Sheepshagger John. After a few pints, the visitor’s curiosity gets the better of him and he asks John what’s with the nickname.

“See this pub?” asks John, "I built it, but they don’t call me Pubbuilder John? I’m the local doctor, I saved Barman Jim’s life once when he choked on a peanut, but they don’t call me Lifesaver John. Every year, I supply a huge Christmas tree for the village green, but the don’t call me Christmas Tree John.

“But you shag one lousy sheep…”

Randi (et al) provide over a decade of support and development for modders and yet they (potentially) refuse one lousy request...

[Slasher]

I would also like to clarify that I am one of those people who believe that ZDoom can be something more than just a Doom Engine port. However, I know that because the devs and other important people around here do not view it my way, it is going to remain a Doom Engine port as they see fit. And I accept and respect this, because it is the reality and no amount of whining or arguing in circles is going to change that.

So I'm still going to attempt to make the mods I want to make, (whenever I get around to that because it's been quite a while), but I will do so within the confines of the advanced Doom Engine port we have been given.

[Trance]

No. No. No, it is, in fact, a Doom engine. It will always be a Doom engine. There is so much of ZDoom that is steeped in Doom-ism that it will never pull away. It will never be a generic custom game engine. It can do a lot of things, yes, and many of them are far and away from Doom, but it is still a Doom engine, by design and intent.

DECORATE, the way actors are defined, reeks of the way Doom originally did it. And it's flexible... enough. But there are way better ways for it to be done if you wanted "a way to create entities in a pseudo-3D world." But we're going to stick with this frame/action function based setup because that's the way Doom did it, and sticking with that is a hell of a convenience since our goal is to make an advanced Doom engine. And that works for the kind of worlds a Doom engine is capable of supporting. A lot of the same ideas apply across the board.

Doom is intrinsic to the way the engine is designed, first and foremost, and as far as I am aware there are no plans to move away from that. It's not about restricting the tools to modders. It's about understanding what the damn tool is designed for to begin with.

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?

The automap thing is a problem that would be nice to be solved, but a bad solution is a bad solution.

Bad how?

(I really would rather not have this thread fixate on the automap thing; I'm trying to keep this about general feature acceptance, and the automap issue seemed to fit well.)

Randi (et al) provide over a decade of support and development for modders and yet they (potentially) refuse one lousy request...

I didn't mean to imply that one should incite a revolt over not getting a feature added. Of course I wouldn't ignore the work they've done. But I also don't think that refusing feature additions for no reason should be glossed over, either, regardless of who it is. It would be frustrating to anyone putting in a feature suggestion (or submission) getting "No'd" without reason.

[Blue Shadow]

I tend to believe that whatever features added weren't added for the sake to make ZDoom a whole different engine. Sure, modders have the freedom to use whatever freatures available to them to create whatever they want, but shouldn't expect a full support on the developers' behave to accomodate to features that go beyond the main purpose of the engine and what's made for. That's not their job.

ZDoom is a Doom-engine based port to mainly develop Doom-engine based games/mods, not to develop a side scroller or a space shooter, etc.