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

[Roofi]

Hi all, I'm making this thread because I see quite a few projects that claim to be vanilla but make significant changes by modifying monsters or weapons for example via dehacked. I'm not here to discuss the quality of these wads which are undoubtedly very good.

 

If I stick to the definition of vanilla in general: "a basic version of something, without any special features or customisations"
On the other hand, although very old, the practice of dehacked implies a patch of the original executable.

 

I know that the question today is not really relevant because even the vanilla adepts have understood that Doom is now played almost exclusively on ports that support dehacked, but in the strict sense of the term I tend to consider dehacked as a way to free oneself from limits without explicitly considering the project as "limit-removing".

 

I think that for a wad to be vanilla, it must accommodate the limits of the executable. New textures are ok for instance , because you don't have to modify the  original exe. In the same way, a dehacked can be optional, if its only purpose is to change the names of the maps on the automap for example.

 

What do you think? Perhaps my definition of wad vanilla is too elitist.

 

[Jacek Bourne]

I personally think of a wad as vanilla if it can be run using vanilla ports or dosbox. If the dehacked features work in dosbox or something like chocolate doom then I’d consider it vanilla. A good example of this is many of Doomkid’s projects.

 

Regarding gameplay however, I will only regard something as vanilla if it doesn’t modify any of doom’s monsters or add any new ones. A good example of this is Stardate 20x6.

[Noiser]

On 12/1/2021 at 9:13 AM, Roofi said:

(...) but in the strict sense of the term I tend to consider dehacked as a way to free oneself from limits without explicitly considering the project as "limit-removing".

That's the thing: You are not freeing yourself from limits by using dehacked on vanilla format, you are working with them as strictly as possible - that's why you cannot add anything, just use what is already on the game. Action-pointers cannot be changed, not even extra letters can be added on words: you have to work following the rules of the original code. 

The way how I see it, Dehacked is vanilla-compatible because the patch is compatible with the Doom 2 executable (or Doom 1). You cannot use BEX on a vanilla exe for example, because it will not work. Now if you go as far to ignore that, then new maps or resources (sprites, textures, music) cannot be vanilla as well because these are also patches that modifies the internal data of the game. Which is a weird way of thinking imo, after all that's what mods do - they modify something on the game.

That said, if you think of "vanilla" as playing "without gameplay changes" (definiton used by those from the gameplay mod scene) - then sure, I can see how Dehacked cannot be vanilla. At the end, these terms are not 100% objective and we use it more as a matter of organization than anything else, so there's that 8D

Edited December 7, 2021 by Noiser

[Egg Boy]

Can a wad really be considered vanilla if it uses custom textures?

[uber]

for what it's worth, i personally consider "vanilla" wads to be a subset of vanilla-compatible wads. the former are basically just levelsets that might have cosmetic changes via custom textures or sprite replacements, but otherwise keep all gameplay mechanics intact as they were in the iwads, say memento mori, d(2)twid, etc. then vanilla-compatible is the whole set of wads that can run in the original executables or chocolate doom without the need of modern sourceport features, but might introduce major changes in the way the game plays, with custom monsters or weapons like in strain or rowdy rudy, and also old total conversions like batman doom.

but then again, that's a mostly arbitrary and admittedly kinda blurry distinction i made for myself. btsx, for instance, plays just like doom 2 but has so many new textures and even some unnoticeable dehacked patches (if i'm not mistaken) that it'd be strange to put it in the same category as, say, fava beans, even though it makes sense from a "featureset" point of view. and also, almost all levelpacks change the automap names using dehacked - would that mean that technically none of them are truly vanilla? 

[BGreener]

4 hours ago, Roofi said:

What do you think? Perhaps my definition of wad vanilla is too elitist.

 

 

I suppose it depends on the context. You can have a gorgeous GZDoom map making use of a lot of features while still balanced around the intention of playing it traditionally all vanilla-like, even straight down to bearing infinitely tall actors in mind. Down to the most technical level, anything that uses a .deh patch or anything that's outside of the original games I guess I wouldn't consider "vanilla"?

 

It's not something I've thought about, and it's still something I'm thinking about.

[Astronomical]

48 minutes ago, Egg Boy said:

Can a wad really be considered vanilla if it uses custom textures?

Can a wad be considered vanilla if it replaces any lumps in the wad?

[boris]

The term "limit-removing" generally refers to the removal of certain static limits of the original executable, like the maximum number of visplanes. There's even a DoomWiki article about it: https://doomwiki.org/wiki/Limit_removing

[Nevander]

2 hours ago, Egg Boy said:

Can a wad really be considered vanilla if it uses custom textures?

 

1 hour ago, Astronomical said:

Can a wad be considered vanilla if it replaces any lumps in the wad?

Can a wad be considered vanilla if it wasn't made with DoomEd on the id Software computers?

[BaileyTW]

As far as I am concerned, vanilla means it runs with the doom, doom 2, or final doom exicutable and through something emulating msdos. Otherwise you would have to ask the question if any map that has a style of gameplay too far from that of the original games can be considered vanilla (Can Plutonia 2's map 29, Ticket to Eternity really be considered vanilla gameplay?). I will simply not ask that question and instead let the limits of the doom engine define this.

[Matthias]

[Astronomical]

42 minutes ago, Nevander said:

Can a wad be considered vanilla if it wasn't made with DoomEd on the id Software computers?

Can a wad be considered vanilla?

[Misty]

I think "vanilla" these days has broad spectrum, yet confined by limitations and things you must put in consideration. It's only natural for people to improve and evolve old things. That's how dehacked was created to expand what's already established. 

[magicsofa]

4 hours ago, Noiser said:

The way how I see it, Dehacked is vanilla-compatible because the patch is compatible with the Doom 2 executable (or Doom 1)

No it isn't. The original way to use dehacked mods involved creating a new .exe with the relevant modifications "hacked" into it (hence the name). Of course, these modifications only mess around with static values such as thing properties and frame numbers, and don't change the code itself, so it's not like the behavior of the engine was actually being changed. Still, it's a different executable.

(EDIT: to be more specific, only ports are able to apply dehacked patches "on the fly")

Like others have quipped, by the same logic you could argue that new maps don't count as "vanilla" because they are also changing the data of the original maps.

In a general sense, yes, "pure vanilla" would refer to the original game with no modifications. Since the original executable did support loading PWADs, you could still say that falls under vanilla Doom. Also, wasn't partial sprite replacement intended to be supported but failed due to an oversight?

Anyway, I think most people are just referring to the vanilla engine. Since dehacked mods only change the values of things, not the behavior, I think it should still count as vanilla, the same way replacing maps, textures, and sprites does.

[DJVCardMaster]

Vanilla is often considered for everything that could run on doom2.exe, if you can load dehacked patchs on your doom2.exe (Guess you can since it has been done since the mid 90's). Then, it is. Limit-removing goes beyond Vanilla in the sense that every map does not count the static limits of doom2.exe, you know, visplanes, drawsegs or things that could make it crash or break on a normal playthrough. There are quite a few sub-categories in Vanilla, as the visplane limits are higher on "Vanilla-ports" like Doom 96. 
Everything that runs on doom2.exe also runs in Chocolate Doom, but CD can also remove said limits.
There are several interesting things in DeHacked that may run in the original .exe, those for me are considered Vanilla. Like this one:
 

 
This may be one of the most advanced things you can find in terms of Vanilla DeHacked.

[Xaser]

Well, the de facto answer is if it works in Chocolate Doom, it's vanilla. :P

 

Maybe the best "academic" answer I've heard is that "vanilla" basically means "anything you could do using the tools that existed before Doom's source code release", hence why DEHACKED is considered vanilla while Doom+ is not. The line is arbitrary, but there it is.

[Bauul]

In most games, "vanilla" tends to mean "unmodded".  However, for Doom it has the more specific definition of (as others have pointed out) "compatible with the original .exe".  

 

In that case, Dehacked is considered "vanilla" in the sense that it's compatible with the original .exe.  Dehacked patches could in a sense be described as "vanilla mods".  That's an oxymoron for some games, but makes sense in the context of Doom specifically.

 

The problems start coming in when people unfamiliar with the accepted Doom lingo start applying it differently, so you get people talking about (for example) "vanilla GZDoom maps", which doesn't make sense in the context of Doom specifically.

[RetroAkaMe]

Kinda. If you'd run it in DosBox, no DeHackEd exe in any place, it won't use the DeHackEd resources. Vanilla Doom does NOT have Dehacked pre-installed.

But I'd say it's vanilla since you don't need any limit-removing source port.

[Noiser]

43 minutes ago, magicsofa said:

No it isn't. The original way to use dehacked mods involved creating a new .exe with the relevant modifications "hacked" into it (hence the name).

Read my post again.

The fact that you are modifying the exe doesn't change the fact that it's a patch.

Also it's a bit weird that you though I was unaware of how it works.

Edited December 1, 2021 by Noiser

[Redneckerz]

Considering DeHacked and particularly DoomHack only replaces what is already there, it is still vanilla. It technically isn't adding anything. DoomHack should be considered a proto-source port of some sorts, that involved implementing new mechanics before the source was available.

 

6 hours ago, Roofi said:

I think that for a wad to be vanilla, it must accommodate the limits of the executable. New textures are ok for instance , because you don't have to modify the  original exe. In the same way, a dehacked can be optional, if its only purpose is to change the names of the maps on the automap for example.

DeHacked constitutes more than just changing map names. DeHacked can be used for new gameplay mechanics: See the crazy things seen in Doom.

 

Linguica's DeHacked Douchebaggery gives a good overview of absolutely crazy things possible with DeHacked:

Quote

• Static cannon (Chocolate Doom/PrBoom Plus) (an overflow hack)
• Teleport.deh: (Enemies teleport instantly right next to you. MAY HARDLOCK DOSBOX OR SYSTEM. NON-MEMORY SAFE.)
• Comehere.deh: (Enemies teleport straight into to you, and as its a modifed archvile, get killed as a result, resulting in a anime style flight and gliding over the floor effect. MAY HARDLOCK DOSBOX OR SYSTEM. NON-MEMORY SAFE.)
• Boomerang.deh: (An archvile flame on top of a revenant missile makes it act like a boomerang)
• Flames.deh: (A flame field in a plus formation which hurts you if you get too close)
• Spwnspot.deh: (A spawn cube has a set spawn target. But what if the spawn target followed you? You get homing spawn cubes)
• Ohmygod.deh: (A spawn cube that also sends a ton of fire balls in multiple spots, essentially creating some sort of firework effect.)
• NPC.deh: (''I accidentally realized that putting the SpawnFly code pointer in an enemy's attack state will forcibly set the reactiontime to -1, and so the monster will never attack you again, unless attacked first, which resets reactiontime to 0 and lets a single attack happen in return. You can also set the monster's reaction time in Dehacked to -1 so that it will never attack first. This effectively makes a "NPC" which walks around, doesn't attack you, and will do a tit-for-tat retaliation if hit, but not with the cheesy edited pain state like I've seen.'')
• IDK.deh: (A Icon of Sin whose spawn cubes are plasma burts in a set pattern, leading to a Touhou bullet-hell like effect.)
• Archhelp.deh: (''Give the archvile flame a negative speed, let it wake up and walk several steps with 0-length frames, then you have a spot somewhere pseudorandomly in front of the player to screw around with. One could use this concept to make, say, damaging area denial spots pop up in front of the player randomly.''. In this case, after an archvile is finished with his attack, it summons a Cyberdemon which briefly ''pops'' in, shoots, and then disappears instantly.)
• Summoner.deh: (''Why not turn the archvile into a bona fide summoner? (I used the revenant fireball for the spawn pointer but I think any projectile type would work?)''

 

14 minutes ago, Astronomical said:

Can a wad be considered vanilla?

Very philosophical. I like! :)

 

 

[magicsofa]

21 minutes ago, Noiser said:

The fact that you are modifying the exe doesn't change the fact that it's a patch.

 

Yes, a patch that can never be employed using just the original executable.

[Noiser]

On 12/1/2021 at 4:59 PM, magicsofa said:

Yes, a patch that can never be employed using just the original executable.

Sure, but what is your point?

(EDIT: not trying to argue, I'm genuinely curious)

Edited February 27, 2022 by Noiser

[magicsofa]

Just that dehacked patches are modifications to the original game data, and therefore not "strictly" vanilla. So I can see why OP would question what category such mods are supposed to fit into. The only mods that are actually supported by doom.exe "out of the box" are pwads that replace maps and textures only. Sprite replacements also work but only if you either replace all the sprites, or include the unchanged iwad sprites along with your pwad which would make it illegal to distribute.

The confusion really comes from the fact that we use the term "vanilla" to refer to the source code, and colloquially agree that changing static values (but not the rest of the code) still counts as "running in the vanilla engine." But, technically, you are still changing the code. All of those thing properties and such are hard-coded into tables within the executable. You can't tell doom.exe to read the values from a different file instead - which is why in the old days, without the aid of a source port, you had to create a new hacked .exe in order to play mods that used dehacked. The dehacked program was literally modifying the source code for you in order to change those values. As others have pointed out, the "true" meaning of vanilla is no modification. So, no dehacked, no custom maps, no nothing. We've just shortened the phrase "vanilla engine" because in most cases it's obvious that yes, you are modifying some part of the game, and so it's not really necessary to specify that part of it. And since dehacked only changes static values, it doesn't really affect the actual logic of the executable. If a part of the code says, add number X to number Y, dehacked can only change the values of X and Y, not the fact that they are being added together.

On the other hand, when referring to the unmodified game, we generally just say "the IWADs" or "original Doom" or something like that. Definitely confusing for new members, but it just stems from the need to differentiate between mods that require a more extensively modified version of the engine, such as ones that support ACS scripting, and mods that only require deHacking at most.

[Murdoch]

But is anything, ever, truly vanilla? Like... what is vanilla, anyway? Is even doom2.exe really vanilla? Are we all, in our own way, vanilla?

 

The above is a very stupid way of saying, why does it matter? Vanilla = can run on original Doom executable without source port. That's all that is meant to intend. So yes, your definition is bordering elitist.

[Doomkid]

Modifying the game’s maps alters the experience of playing the game just as much as, if not more than modifying the weapon behaviour. From a gameplay perspective, anything but iwad maps or behaviour ceases to be “truly vanilla”.

 

From a compatibility perspective, if no source ports are required, you are playing a vanilla wad. (Patching the EXE is irrelevant as a PWAD - patch wad - is literally doing the same thing, just to the IWAD and on-the-fly rather than being manually patched beforehand).

 

So there you have it: If you’ve modified a map OR a weapon/monster, it ceases to truly be “vanilla Doom”. However, if the wad or mod works perfectly without any source port, it is - by definition - vanilla compatible (functions with the baseline Doom or Doom2 EXEs).

[Liberation]

Quote

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

 

Yes I believe it can. When we say vanilla compat we tend to imply that it would run with doom2.exe or whatever.

 

But dehacked patches can't be loaded by doom2.exe!! Well yes that is true, but if we used DeHackEd v3.0 etc etc to create a new .exe like years gone past then that would work, we just skip that phase for numerous reasons these days. 

[Doomkid]

I’ve seen dozens of people say over the years that using a .deh patch is “less vanilla” than using a patch.wad (and in way more combative language than we see here, lol).

 

I always wanted to ask why patching over the iwad on-the-fly using the -file command is “less patchey” than patching over the EXE manually. If vanilla Doom could read .deh files using the -file command, would that magically grant them “true vanilla” status even though it changes nothing other than “when” the patching happens?

 

Also this is my exact reaction whenever people say .deh files aren’t REAL vanilla:

 

 

[Noiser]

1 hour ago, magicsofa said:

You can't tell doom.exe to read the values from a different file instead - which is why in the old days, without the aid of a source port, you had to create a new hacked .exe in order to play mods that used dehacked. The dehacked program was literally modifying the source code for you in order to change those values. As others have pointed out, the "true" meaning of vanilla is no modification. So, no dehacked, no custom maps, no nothing. 

But that doesn't contradict anything I said. I really cannot see what you are trying to debate.
"Vanilla mod" refers to the target, not the end result (which will obviously change, otherwise would not be called a mod).

 

And vanilla-compatible means exactly that: being compatible with the unmodified exe. Doesn't matter if you are changing the executable or making it read from another file... that's totally irrelevant.

Edited December 1, 2021 by Noiser

[Capellan]

A WAD using dehacked may literally just be replacing map names.  Is that still vanilla?  It yes, when does a dehacked patch become not vanilla?

 

I think that "runs with Chocolate-Doom" is a good modern day definition of "vanilla".

[magicsofa]

1 minute ago, Noiser said:

Vanilla-compatible means exactly that: It's compatible with the unmodified exe.

 

No, it doesn't. D4V is said to be "vanilla-compatible" but it does indeed modify the exe. You cannot play D4V using the original doom.exe. It was not possible in 1994, it s not possible now, and it will never be possible in the future. Even if all I did was change the last character of ENDOOM, I would have changed the exe. Superficially, for sure, but a change is a change. Dehacked changes the exe. A PWAD does not change the exe. It's only a "patch wad" because it overrides what was previously read from the IWAD or "internal wad." It cannot change any of the data in doom.exe.

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 where it gets a little muddy. The doomcar has this quirk where the horn is actually in the engine. If you want to change the horn, which arguably doesn't change how the car drives, you still have to get inside the engine. It's not conveniently located among the other "static" elements of the car. It's embedded in such a way that there's just no method for you to modify it without opening up the engine itself. This is where those static values that dehacked changes are found. If iD software wanted to build their game in a cleaner way (or more "modular") then they would have put the state tables, thing properties, code pointers, and other static data into the IWAD. But, they didn't, which is why we say they are "hard coded" into the engine. The programming that is responsible for rendering walls and floors onto the screen is lumped together in the same file with the table that says how much health an imp has. There is no way to "unmarry" those two things. If you remove the thing table, the .exe will not run. It's as if removing the car's horn would stop it from starting up. In programming this is considered bad practice, and I hope the car analogy shows why: The horn should be totally separate from the engine, as should the doors, upholstery, and anything else that doesn't have a good reason for being directly connected to the engine.

Dehacked only allows us to mess with the oddly placed horn, and to go even further, it is still restricted to exactly 1 horn at exactly the same location as before. Otherwise, car doesn't go.

I'm not trying to say that dehacked mods shouldn't count as "vanilla compatible." They are. And to nitpick even further: the OP asked "can a wad be considered vanilla if it uses dehacked" but a WAD cannot use dehacked when using the original executable. Only source ports have the added ability to read dehacked files from inside the PWAD. In order to work with doom.exe, your .deh file has to be separate. You can put it in the .wad and it will do absolutely nothing because doom.exe will just ignore it. Also, you could load the .wad without applying the .deh patch and you will get a half-baked version of the mod, lacking all of the modifications to thing properties or state logic. All this means is that "vanilla mod" is a short way of saying "vanilla engine with modifications to the static data such as maps, textures, sprites, thing properties, and state tables." By itself, without that context, the phrase "vanilla mod" is a direct contradiction. Vanilla means not modified, but mod means yes modified. This paradox can only be solved by understanding that the only "vanilla" part of "vanilla-compatible mod" is the engine's behavior. They use the original renderer, the original line actions, the original attack functions. The only things that can be modified in a vanilla mod are data points like how much health something has, or which animation states lead to which animation states. The fact that some of that data is buried within the executable is just an oddity and example of iD software not making their product as modular as they could have. Furthermore, dehacked can't even modify some of those static values. It can't change the angles of the mancubus fireballs. It can't make revenant fireballs always home. It can't modify the number of tracers fired by the shotgun, or the ssg, or the bfg blast. But that's just a result of how far Greg Lewis went with his hacking. The more important distinction is that none of the actual code can be changed other than the numbers found within it.