Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Roofi

Can a wad really be considered as vanilla if it uses a dehacked?

Recommended Posts

3 hours ago, magicsofa said:

No, it doesn't. D4V is said to be "vanilla-compatible" but it does indeed modify the exe.

D4V is vanilla-compatible because Dehacked IS compatible with the executable. That's my whole point.

The fact that it changes the engine doesn't have any relevance to me, because in the end that's just another arbirtrary rule of what vanilla can or not be. You are trying to separate resource from engine while it's all raw data (and in this case the code is just swapped around), but at the same time you are saying that changing the exe is not vanilla while an external patch magically is. And that without considering that the result is absolute the same.

 

The point is, vanilla-compatible have a simple meaning. Beyond that you are basically moving the semantics to anything you want it to be.

Edited by Noiser

Share this post


Link to post
31 minutes ago, magicsofa said:

Think of it this way: imagine Doom is a car. The .exe file is the engine. It's like the "brain" of the car. You can have doors, seats, wheels, and so on but in order to actually drive the car you need the engine. It "does the work." The other stuff - doors, paint, windows, etc - is the resource file, in our case called a .WAD file meaning "Where's All the Data." It doesn't do any work. It just sits there waiting for the engine to operate on it. Okay, maybe you can connect the steering wheel to the tires and move them around without an engine, but you get my point. The engine does stuff while the rest of it is essentially static.


Now imagine you replace all the cloth upholstery with black leather because you think you're really freaking cool. At this point you haven't changed the behavior of the car. The engine still runs the same. On the other hand, if you add nitrous to the car, now you have actually changed the engine itself. It can drive faster than before.

This is a perfect analogy, because in all cases, the car has been altered and is no longer in its vanilla state. Changing the upholstery or the engine still means it's no longer the "vanilla" car, as-sold by the manufacturer :)

 

EDIT: I think I'm going to make a video breaking down all the different ways in which the word "vanilla" is used in the Doom community, I think it would do a lot of good to newcomers in particular. Terms like "vanilla compatibility" and "vanilla gameplay" and such really could use some in-depth explaining - There are some levels that use ZDoom features but still insist on "vanilla gameplay" and there are "vanilla compatible" wads and mods that absolutely do not feature "vanilla gameplay" and any change whatsoever technically meas you're not playing "vanilla" Doom even in the "vanilla EXE" because something has been changed. It's not exactly straightforward.

 

I mean, I'm not surprised people are getting into semantical arguments - there's so many layers to be broken down and different potential interpretations.

Share this post


Link to post

I think the problem is that we have some overlap between "vanilla format" and "vanilla gameplay" here...

 

If you want to carelord the everliving hell out of this discussion then anything that isn't made by id themselves is also not vanilla, but merely "vanilla compatible" provided it works within the constraints of, say, choco doom... Which would mean that HR2 is about as vanilla as Sunder, or KDIZD...

 

I find discussions like this fruitless in the end, because at the bottom line a lot of what's "vanilla" depends on the angle you're taking, or subjective interpretation of what the term "vanilla" actually means, or how far down the rabbit hole of technicalities you're willing to go...

 

Nobody would argue that some of the earliest SMW kaizo ROM-hacks are "vanilla" (even though kaizo loosely translates to "rearranged", if memory serves), but they use vanilla assets and mechanics exclusively...

Share this post


Link to post

One could argue that "vanilla" ought to be limited to stuff that only requires the original game -- without any third-party utility such as DEHACKED to change the game's behavior -- but the community consensus for decades has been that DEHACKED changes do not remove the vanilla status.

 

In a debate between descriptivism and prescriptivism, descriptivism usually wins.

Share this post


Link to post
1 hour ago, magicsofa said:

It can't change the angles of the mancubus fireballs. It can't make revenant fireballs always home.

I don't have a dog in this race otherwise, but for anyone reading this who fancies doing vanilla -- uh, ish -- modding, you can make revenant fireballs always home with a specific frame timing setup due to a quirk in the math. Can also give player missiles smoke trails via same method.

Share this post


Link to post
2 hours ago, Gez said:

One could argue that "vanilla" ought to be limited to stuff that only requires the original game -- without any third-party utility such as DEHACKED to change the game's behavior 

Let me show why I don't like this way of thinking:

If you are using third-parties as a parameter, then maps cannot be vanilla as you need an editor to build them (or a tool like Slade to edit the resources). So to keep the narrative you have to stretch the rules by saying that game behavior is the turning point - which seems completely arbitrary to me. I prefer to use the occam's razor in this case: Vanilla-compatible simply means compatible with vanilla.

Edited by Noiser

Share this post


Link to post

For me If it doesn't crash vanilla doom, it's vanilla compatible, no matter how many dehacked tricks you use

Share this post


Link to post
38 minutes ago, Noiser said:

Let me show why I don't like this way of thinking:


You are responding to a statement that Gez did not make. Your quote cuts off an important part of the post: "but the community consensus for decades has been that DEHACKED changes do not remove the vanilla status."

I was merely trying to explain why these somewhat confusing layers exist. I didn't mean to say that I think vanilla should always refer to "no mods of any kind." I agree with the community standard. It would be more cumbersome to have to explain every single time that my mod is "compatible with the original exe barring the excepted changes available through dehacked patching." Most of the time it's easier to just say vanilla compatible... and most of the time, people are using a port that will conveniently apply these patches on the fly. But, when someone wants a more exact explanation and thus a deeper dive into the slightly messy world of dehacked modding, it's important to be really precise about the differences between doom.exe, hacked .exe, and source ports. Again, most users won't really care about the nuts and bolts here, and most of the time they won't have much reason to. However, especially for people who want to create vanilla mods, it can be helpful to know some of this stuff in order to avoid headaches in the future.
 

 

1 hour ago, holaareola said:

I don't have a dog in this race otherwise, but for anyone reading this who fancies doing vanilla -- uh, ish -- modding, you can make revenant fireballs always home with a specific frame timing setup due to a quirk in the math. Can also give player missiles smoke trails via same method.


Heh, I figured someone would catch this... more specifically, dehacked can't make revenant projectiles home that were spawned on the wrong gametic. 

Share this post


Link to post
Quote

Can a wad really be considered as vanilla if it uses a dehacked?

Yes, as long as it can be played on the original game engine.. even if the original game engine has been hacked to do it..

Since Dehacked was around before any source engines, right? 

There wouldn't have been anything known as "limit removing" yet, anyway.

Share this post


Link to post
15 hours ago, magicsofa said:

It would be more cumbersome to have to explain every single time that my mod is "compatible with the original exe barring the excepted changes available through dehacked patching. Most of the time it's easier to just say vanilla compatible... and most of the time, people are using a port that will conveniently apply these patches on the fly. But, when someone wants a more exact explanation and thus a deeper dive into the slightly messy world of dehacked modding, it's important to be really precise about the differences between doom.exe, hacked .exe, and source ports.

I'm being as clear and precise as possible: Dehacked is vanilla-compatible.

Edited by Noiser

Share this post


Link to post
3 hours ago, Nine Inch Heels said:

If you want to carelord the everliving hell out of this discussion then anything that isn't made by id themselves is also not vanilla, but merely "vanilla compatible" provided it works within the constraints of, say, choco doom... Which would mean that HR2 is about as vanilla as Sunder, or KDIZD...

 

I find discussions like this fruitless in the end, because at the bottom line a lot of what's "vanilla" depends on the angle you're taking, or subjective interpretation of what the term "vanilla" actually means, or how far down the rabbit hole of technicalities you're willing to go...

 

I agree, these nit-picky arguments are so old and tired. Let's just play the damned game however we feel like. The only time I care even a little bit about the word vanilla is when a map is described as "vanilla format" and it's an impressive achievement in mapping engineering, but I'm going to play it with GzDoom anyway so it doesn't really matter. If you only play stuff made for Doom2.exe, God bless you. In fact, I have a map set due for release in 3075 that I started during the great vanilla wave of the early '10s, and for some reason I committed myself to vanilla format and I will finish what I set out to do if it fucking kills me.

 

So there's your "Megalyth is a goddamn moron" post for the day.

Share this post


Link to post
8 hours ago, Noiser said:

If you are using third-parties as a parameter, then maps cannot be vanilla as you need an editor to build them (or a tool like Slade to edit the resources). So to keep the narrative you have to stretch the rules by saying that game behavior is the turning point - which seems completely arbitrary to me. I prefer to use the occam's razor in this case: Vanilla-compatible simply means compatible with vanilla.

Let's be more explicit, then: you don't need third party tools to play. The way the content is created doesn't matter, it's the way to play the content that does.

 

An example of why this can be relevant is that using DEHACKED restricts your engine choice to A. engines that explicitly support DEHACKED (i.e.: source ports) and B. engines that are explicitly supported by DEHACKED. So your vanilla-compatible wad ends up not being compatible with Doom95 for example. It's also not going to work with "ROM hacks" of otherwise straight console ports like the Xbox360 version. (It is pretty cool that the Unity port got DEHACKED support, otherwise it'd be another example.)

 

If we take a look at the Bethesda RPGs, there's a couple of recent examples to show why this third-party tool notion can be important. Both Fallout 3 and Skyrim SE recently got exe updates. They didn't actually change much, if anything, in the code: in Fallout 3's case, they did remove the GFWL requirement, but otherwise all they did was to recompile the exe with VS 2019 so it'd integrate better on the Microsoft store. Now those games' modding communities tend to rely on third-party tools a lot, notably on script extenders, which are kind of like DEHACKED in that they're extremely dependent on knowing the exact layout of the exe, with precise addresses of each function. So whenever there's an exe update, everything that relies on these tools breaks, until the tool is updated.

Share this post


Link to post
51 minutes ago, Gez said:

So your vanilla-compatible wad ends up not being compatible with Doom95 for example.

It's not as if Doom95 couldn't be supported by Dehacked, the frame table is intact and should be just as hackable. The catch is nobody cares about Doom95. :P

Share this post


Link to post

There's a special subset of vanilla Doom maps without the use/support of dehacked, for those source ports that simply do not support it or do not support a particular version. Doom95 is the simplest example of an official source port that can play PWADs, but does not implement any sort of DEH support, or Doom for MacOS etc.

 

Most advanced source ports probably went through a phase where no DEH support was available, too.

Share this post


Link to post

My view is that what these days means vanilla for Doom includes Chocolate Doom as it is basically just direct port of the original game with very minimal quality of life features like built in support for dehacked patches. People are way more likely test their maps for vanilla compatibility by using Chocolate Doom than they are to use original 1.9 exe in DOSBox. 

 

Chocolate Doom is also in many ways closer to original DOS version's limitations than both Doom95 or recent official Unity port. It also could be argued that because of official Unity port of Doom exists, it can be seen as direct update to original 1.9 vanilla exe making Unity port by definition also vanilla with it's all raised limits and new features. Unity port also has built in support for dehacked and is updated official version of Doom making dehacked officially vanilla Doom feature.

 

There is also long history of old wads using dehacked to mod the original DOS Doom games, so I would say that also for historical reasons, dehacked is vanilla. Dehacked also does not really add anything to the vanilla DOS executable. It only allows to edit values that already exist and because of that limitation, I would argue that the modified exe is still vanilla, nothing was added and nothing was removed.

Share this post


Link to post
14 hours ago, Doomkid said:

EDIT: I think I'm going to make a video breaking down all the different ways in which the word "vanilla" is used in the Doom community, I think it would do a lot of good to newcomers in particular. Terms like "vanilla compatibility" and "vanilla gameplay" and such really could use some in-depth explaining - There are some levels that use ZDoom features but still insist on "vanilla gameplay" and there are "vanilla compatible" wads and mods that absolutely do not feature "vanilla gameplay" and any change whatsoever technically meas you're not playing "vanilla" Doom even in the "vanilla EXE" because something has been changed. It's not exactly straightforward.

 

I think it's a limit of the language we use, when a wad is called vanilla it refers to it's vanilla compatibility, but in most modding scenes vanilla just refers to the state of the game without mods.  If we go by that definition the meme "Can a wad be considered vanilla?" is a genuine question, because the definition of vanilla varies.  This is why zdoom maps like hanging gardens could be argued to be as vanilla as D4V.  Multiple people use different terms that all shorten to vanilla and it would be nice if we could all use terms that shorten better.

Share this post


Link to post
11 hours ago, Megalyth said:

I agree, these nit-picky arguments are so old and tired.


Except nobody in this thread is care-lording over what vanilla means. I haven't seen a single post saying that vanilla shouldn't include dehacked mods. Some of us have explained why "vanilla mod" is a contradiction that only makes sense in this context. That isn't really an argument. I wasn't talking about what should or shouldn't be in terms of the doom lexicon, and nobody else was either, as far as I can tell. I wasn't offering an opinion, other than "despite the confusing aspects of it, our terminology is totally fine." If you want to make up your own story about what happens when a dehacked patch is applied, then you will be wrong. If you want to say that vanilla  should always mean no dehacked, then it is you who are nitpicking. My answer, and everyone else's answer to the OP is yes.

Share this post


Link to post

@magicsofa

It's not any argument in particular, just the broader argument (or discussion I suppose), not even limited to this thread, or Doom for that matter.

 

It makes sense to limit things like demos and speed runs to a particular format for the sake of fairness, but for casual play it's just not worth worrying about.

Share this post


Link to post

Here's my 2 cents... as long as said Dehacked mod replaces only the map names and the text that occurs between maps (e.g. before MAP07) AND the WAD contains nothing else but the maps and textures, sure.

 

And .bex doesn't count.

Share this post


Link to post

I think the most interesting thing about the thread is that no one has addressed why from a utilitarian standpoint why we use the term vanilla.  Words mean things because we need terms to describe the world, that's why language exists in the first place.  From a utilitarian lens of analysis dehacked is clearly vanilla because vanilla in a modding context only refers to the advanced engine necessary to run it.  There are glitches in other source ports that vanilla doesn't have that can prevent a wad from being played in those ports properly,  Doom Legacy didn't support voodoo dolls as used in Scythe 1, Zdaemon had a few involving the way Pickups are handled.  From a utilitarian perspective the goal of a mod being "Vanilla" is that it works in a native dos computer with a fresh install of Doom 1.9.  The only definition of vanilla compatible that disallows for dehacked is one that could also be used to disallow any lumps that were replaced by the wad.    

Share this post


Link to post
5 minutes ago, Astronomical said:

From a utilitarian perspective the goal of a mod being "Vanilla" is that it works in a native dos computer with a fresh install of Doom 1.9.


But that isn't what the community perspective has settled on. According to our local dialect, D4V is a "vanilla mod." We have usurped the literal meaning of the word. Go over to an Oblivion forum and talk about vanilla mods - people will be like, what the hell are you talking about? It only makes sense in the context of Doom.

Share this post


Link to post
3 hours ago, magicsofa said:

My answer, and everyone else's answer to the OP is yes.

Actually, your answer to me was "No, it's not". Sorry, but I don't agree with your view that vanilla-compatible is just a convention. I see Dehacked as literally compatible, because the program works on the original executable. BEX is not vanilla-compat, DEHXTRA is not vanilla-compat, the original format is. Again, vanilla refers to the target of the mod - as you won't need to apply the patch on a modified executable. If you want to be REAAALLY nitpicky, I can give you that the extra weapons that comes with the mod are D4V-compat (lol), but the main patch is vanilla.

(Just to make clear my POV about this)

Share this post


Link to post

-If it runs on Chocolate, it's vanilla.

-If it uses Boom format, it's chocolate.

-If it requires Eternity, it's chicken.

-If it requires GzDoom, it's turkey.

-If it requires GzDoom but uses no GzDoom features, it's vanilla/chocolate and the author is a a turkey.

Share this post


Link to post

Part of being a member of a community is accepting its lingo. While you can always challenge the dogma of any association you're part of, you need a compelling reason to do so if you expect anybody to care. I don't see one here, past argument for its own sake. It's more practical to accept the way thousands of people use the term "vanilla" than to demand they all change because they're "wrong".

Share this post


Link to post
1 hour ago, Noiser said:

Actually, your answer to me was "No, it's not". Sorry, but I don't agree with your view that vanilla-compatible is just a convention. I see Dehacked as literally compatible, because the program works on the original executable.

When you're determined enough, you can make a lot of things that run on the original executable.

 

It's long been accepted by the community that DEHACKED is still vanilla-compatible. But I doubt it'd be accepted that limit-removing, custom DECORATE actors, and use of the Doom-in-Hexen map format would be similarly accepted as being vanilla-compatible, despite these things being literally compatible thanks to ACE.

Share this post


Link to post
1 hour ago, magicsofa said:

But that isn't what the community perspective has settled on. According to our local dialect, D4V is a "vanilla mod." We have usurped the literal meaning of the word. Go over to an Oblivion forum and talk about vanilla mods - people will be like, what the hell are you talking about? It only makes sense in the context of Doom.

That is because Vanilla in this context is a shortening of the phrase "Vanilla compatible" and because of this D4V is vanilla because it is vanilla compatible.  Vanilla in the Oblivion community means the base game from a fresh install.

Share this post


Link to post
8 hours ago, Edward850 said:

It's not as if Doom95 couldn't be supported by Dehacked, the frame table is intact and should be just as hackable. The catch is nobody cares about Doom95. :P

Not only that but it could even trivially allow pointers in any frame, since Windows executables don't have a relocation table like DOS ones do. Though, if the DeHackEd author would've had access to Watcom documentation back in the day, he probably could have figured out the relocation table format like we did much later and allowed that under DOS as well.

 

When you get down to it, 1997 is the arbitrary cut-off point of development on things that applied to the DOS exe which determines what is or is not accepted as "vanilla" in some cases.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×