Is it worth mapping for Vanilla anymore?

printz said:

Because those who choose PrBoom (instead of other ports, IF there's a choice) may do it because they're "purists".

... but you forget that SvStrife is not 'pure', i.e. there is almost no original Strife code in there. Much of its features are implemented by observing and trying to replicate them.

If you want pureness for Strife you are currently out of luck. Overall though, ZDoom is still closer to the real deal because all the crucial stuff has been reverse engineered from the original EXE.

Graf Zahl said:

... but you forget that SvStrife is not 'pure', i.e. there is almost no original Strife code in there. Much of its features are implemented by observing and trying to replicate them.

If you want pureness for Strife you are currently out of luck. Overall though, ZDoom is still closer to the real deal because all the crucial stuff has been reverse engineered from the original EXE.

Speaking of that.. how close is it? Can you play through strife without any problems currently?

As for Vanilla mapping, I see no problem going that route so long as you are willing to go limit removing.

Any map that is being made for vanilla should either go all the way, or not at all. Hitting any of the limitations is in my opinion a deal breaker, including the save game limitation.

I find that PrBoom-plus with -complevel 2 suffices just fine if I want the game behaving like Doom 2.

Mike.Reiner said:

Speaking of that.. how close is it? Can you play through strife without any problems currently?

Yes, I just did so over the last couple of weeks.

No one ever messes with palettes. I want to see more messing with palettes. Palette changes can completely rebreath an atmosphere when combined with creative new texturing. It'll make Vanilla appear fresh.

I find the constraints starting to get to me so my minimum for mapping now is Boom compatible maps.

Mike.Reiner said:
As for Vanilla mapping, I see no problem going that route so long as you are willing to go limit removing.

You mean in the "as long as I" sense, as surely others might not mind, else we wouldn't be seeing new vanilla levels.

Any map that is being made for vanilla should either go all the way, or not at all. Hitting any of the limitations is in my opinion a deal breaker, including the save game limitation.

Not really, as "made for vanilla" generally means it runs with the DOS executable. Keep in mind you can always note in the text file that it requires the Doom+ hack or even include the patch, which is a tiny file, in the ZIP, and note to source port users that this or that limit is exceeded or the limits are exceeded in general. Bigger save games in particular are supported by both Doom (through Doom+) and Chocolate Doom. You might want to point out Doom95 might or will have problems, but Microsoft's version doesn't even support DeHackEd, which is also "vanilla compatible".

myk said:

doesn't even support DeHackEd, which is also "vanilla compatible".

DeHackEd was never a vanilla feature. None of the vanilla Doom engine support DeHackEd, it's the other way around, dehacked that is coded to support the vanilla exes, and having to be updated whenever said exes were modified (which is why HeHackEd cannot be used with SotSR). The only things that support DeHackEd are source ports, starting with Boom, which introduced code just for the purpose of loading dehacked patches.

It's also a bit odd to consider DeHackEd a "vanilla feature" since by its very definition it's an alteration of the original exes.

But I didn't say "a vanilla feature" :p

Even then, you can call it an unofficial, additional feature of vanilla that isn't in the game out of the box, if you want.

Vanilla compatible means that if you download the package, you can use it with the original executable, semantics on whether that means the executable has a parameter for each thing in the package notwithstanding. DeHackEd is quite vanilla compatible, as it relies directly on the DOS executable, while many source ports add support for it, often in an incomplete but otherwise extended manner after the way Boom did (that may or may not be overcome in various ways through other means, such as with MAPINFO or the like).

If you analyze the term in context, as used in practically any case, vanilla is mainly a distinction between the executable out of the box with source ports, and any add-on is vanilla compatible when it works with that original executable.

In that case, just to play devil's advocate, are wads that require Doom-Plus vanilla-compatible? It modifies the original exe much like Dehacked does. Now *I'm* not even sure :P

I would say they can be called vanilla compatible, especially if the user is informed of the patch or it is provided in the ZIP of the WAD. The thing is, they clearly weren't vanilla compatible not too long ago, before entryway produced the patch. With that patch, the vanilla executable became capable of more things. It's just a term or way of saying things, so as long as it makes sense and is clear enough in the context, it works.

In these cases, nowadays you'd still also want to point out the WAD is "limit removing" on the text file, so source port users don't have issues, or someone not using Doom might ignore the patch, read "this is vanilla compatible" and run it on Chocolate Doom, for adverse effects.

It's an interesting argument. (and this post is probably a bit disorganized, I'm in a bit of a hurry and I got a head ache.)

Can you really say a Dehacked edited exe is vanilla Doom? Like Batman doom for instance. It's using the vanilla engine. But it doesn't use the vanilla characteristics.

But at the same time I think the original definition is still solid. "Vanilla compatible" means that it is compatible with the Dos exe. Doom95 is a source port like ever other really. It just so happens that it was shipped with several copies of the games.

While Doom+ isn't a port of any kind, I think it still would be counter intuitive to refer to it as "vanilla" or wads that require it at minimum as "Vanilla compatible" since that would most likely confuse more than anything. Like, "-This so called Vanilla compatible wad crashes with VPO errors in Chocolate Doom/Doom.exe"

Doom+ should be referred to as limit removing. Even if it still have some inherent limits (like I had to experience with HereticP, the blockmap limit) Though, if the person making the wad hasn't made sure that it's working with it in testing. Then it's not entirely unreasonable to think that it might not fully work with it. At least if the maps are large.

I don't think sending the DoomP executable with your package is a good idea though. If people want to use DoomP. They should do like everyone else that want to us a specific exe.

This might have already been answered, but does Doom+ work with Dehacked?

kristus said:

This might have already been answered, but does Doom+ work with Dehacked?

I don't see why not. AFAIK all it contains is some changes to the machine code that shouldn't affect Dehacked in any way.

kristus said:

does Doom+ work with Dehacked?

Yes.

myk said:

Not really, as "made for vanilla" generally means it runs with the DOS executable. Keep in mind you can always note in the text file that it requires the Doom+ hack or even include the patch, which is a tiny file, in the ZIP, and note to source port users that this or that limit is exceeded or the limits are exceeded in general. Bigger save games in particular are supported by both Doom (through Doom+) and Chocolate Doom. You might want to point out Doom95 might or will have problems, but Microsoft's version doesn't even support DeHackEd, which is also "vanilla compatible".

I don't see what relevance Doom+ and Chocolate Doom have with this. They are modified executables and are not the original engine.

"vanilla compatible" is a term used differently for some of us I suppose. Others are perfectly content if that means they can play in vanilla and don't care about saving. I find it odd that there is a save game limitation that is lesser than what the engine itself is capable of doing.

That said I do appreciate Doom+ quite a bit, I have an AV.EXE that is actually Doom+ with your av.deh patch applied, just so I can run around map20 for kicks and not get VPO'd in dosbox :P.

I'd like to have an fdoom+ for Plutonia 2. Speaking pf Plutonia 2, why does that crash in chocolate doom on the first demo and vanilla does not?

Graf Zahl said:
I don't see why not. AFAIK all it contains is some changes to the machine code that shouldn't affect Dehacked in any way.

Indeed, DeHackEd, the longtics demos hack (called "v1.91") and Doom+ are all compatible with each other.

kristus said:
Can you really say a Dehacked edited exe is vanilla Doom? Like Batman doom for instance. It's using the vanilla engine. But it doesn't use the vanilla characteristics.

It's just a word that means "unmodified," in the most strict sense vanilla is using the game out of the box as such, as even adding a PWAD is "not vanilla" (with the game even having a warning that says "this is a modified version of DOOM, we don't offer support" when -file is used) but can also by extension refer to the executables, especially when referring to whether something is "vanilla compatible."

For example, someone might say, "you could do that with DECORATE, which gives you many options, or use DeHackEd which might be enough for what you have in mind and would let people run your add-on with vanilla". In that sense, DeHackEd is vanilla.

While Doom+ isn't a port of any kind, I think it still would be counter intuitive to refer to it as "vanilla" or wads that require it at minimum as "Vanilla compatible" since that would most likely confuse more than anything. Like, "-This so called Vanilla compatible wad crashes with VPO errors in Chocolate Doom/Doom.exe"

Yeah, that's what I was referring to above, especially since the patch is newer than many PWADs. Not pointing out that a PWAD relies on a patch would cause issues just as much as not saying any PWAD which exceeds the limits of the original executable is limit removing or requires something. That can be said of DeHackEd, as well; if you don't point out in the text file that either the DeHackEd utility or a port is required to apply the patch, any users that aren't too knowledgeable won't know what to do.

Doom+ should be referred to as limit removing. Even if it still have some inherent limits (like I had to experience with HereticP, the blockmap limit) Though, if the person making the wad hasn't made sure that it's working with it in testing. Then it's not entirely unreasonable to think that it might not fully work with it. At least if the maps are large.

It's always good to know what the WAD has been tested with, and it is wise to note what type of limit removing we are referring to, as Doom+, Boom, PrBoom and ZDoom all have different limit raising or removing capabilities. Noting an add-on works on the weakest and anything more powerful should be enough. Just saying "limit removing" may not be enough in many cases.

I don't think sending the DoomP executable with your package is a good idea though.

I agree including the executable is dumb and the package entryway offers certainly wouldn't do because it includes the executable and, even if you just include the patch in src.zip, it makes the user apply each limit increase separately through a GUI, but if one wants to include it, one can offer a little patch with a small and simple patcher utility, as the one found here; the Doom+ patch with the patcher is just 3KB, zipped.

Mike.Reiner said:
I don't see what relevance Doom+ and Chocolate Doom have with this. They are modified executables and are not the original engine.

The note on Chocolate was because it allows higher save game sizes, and Doom+, which also does that, is relevant because any PWAD packaged with the Doom+ hack is vanilla compatible, because the contents of said package can be used directly with that original executable. Even if the patch is not included, but mentioned or known, the patched executable is still the DOS executable, as opposed to a compiled port. As an analogy, if you edit your DOOM II IWAD to add perkristian's enhanced sounds or something like that, it's still the (now modified) id IWAD, as opposed to something else, like Freedoom's IWAD, both of which can be used to play DOOM II add-ons.

In any case, PWADs made for the DOS executable where you can't save have been available since 1994. You can call them buggy, and might want to run them on something else if you rely on saves, but they are certainly playable with the DOS executable. For example, AV was made specifically with Doom in mind, because some of the level designers wanted it to be suitable for COMPET-N runners, yet they didn't care that the levels exceeded the saves limit... especially considering the speed runner orientation, as demos and saves don't mix (short of TAS).

"vanilla compatible" is a term used differently for some of us I suppose.

We all share the use of terms. If you misinterpret the usage of a term by someone else, you can get confused in regard what another is saying. See above for more details on how the term is used and where it comes from. The context, how it relates to the rest of what is said and when and where it is said, is very important in telling what a term means during a usage.

Speaking pf Plutonia 2, why does that crash in chocolate doom on the first demo and vanilla does not?

Try upgrading to the latest revision build of Chocolate Doom, if you haven't, as that bug was reported and, I believe, fixed.

Heh, I could use bsdiff to create a patch that'd turn doom.exe into gzdoom.exe. Would that be vanilla? :p

No, but it would be vanilla compatible :p

(Not that it would have any use in being that.)

Well I'll always map for vanilla.

I agree with kristus, the only true "Vanilla" is an unmodified DOOM.EXE. Once you start talking about the Doom+ patch, it's still modified and is capable of different things. Distributing the patch is not useful for everyone, I can't run Doom+ natively on Linux for example.

I'd call Doom+ "limit-removing", though it's entirely possible to make maps in the Vanilla spec (ie: Doom.cfg in Doom Builder) which require a limit-removing port.

Ironically, this would probably be the best choice if you were making say a massive classic-styled level and wanted to ensure a large audience. That way it work work with Doom+, Boom, ZDoom, and all the other random other ports like Legacy/Doomsday/DelphiDoom/etc.

Personally I consider vanilla being a (restricted) set of features, which each advanced port simply expands on. How "classic" a particular wad is doesn't necessarily depend on the port but which provided features it uses. For example you could create maps that, functionally, fall into vanilla specs just as well for ZDoom, Eternity or EDGE as you could for vanilla itself. What makes Boom "different" from the more advanced ports is that the Boom features are widely available in a number of different ports and almost everyone playing Doom has a highly Boom-compatible port installed. Thus if you're going to do a map that uses an extended set of features, but doesn't necessarily need any port-specific advanced features, Boom is a good choice.

If your concern for vanilla is that it's a requirement for making classic maps then there's something wrong: Simply using, say, Boom's generic actions to create a slow door that can't be used by monsters (which you don't have in vanilla) doesn't make the map any less classic. It's not the provided features, but how (if at all) you're using them. Thus I'd say there's really no point in sticking to vanilla except for lulz or srs bsnss, as Boom is already ubiquitous enough to be considered the modern standard.


Also, saying that vanilla mapping is somehow particularly worthwhile as it forces its limits on you is ridiculous; no one's stopping you from enforcing the same arbitrary limits on yourself when you're mapping for an advanced set of features. Vanilla is no requirement for that.

Jodwin said:

Simply using, say, Boom's generic actions to create a slow door that can't be used by monsters (which you don't have in vanilla) doesn't make the map any less classic.

What about SR/S1 doors, such as in E2M5? Those aren't monster-triggerable.

The tragic fall of vanilla mapping is, for me, the lack of conveyor belts. I won't use damage to trigger voodoo-scripts, because that's unsafe. So there's a milestone difference between vanilla and virtually any port with editing enhancements. Map scripting.

Jodwin said:
How "classic" a particular wad is doesn't necessarily depend on the port but which provided features it uses.

That's arbitrary and subjective, whereas sticking to a more or less concrete set of features (from the engine itself) isn't. And why imitate something when you can use it directly? Aside from other benefits, such as that actually testing with vanilla guarantees the WAD runs without even having to download a port and with practically any port.

Not to mention that Boom level sets just use Boom features here and there and aren't done so that "the levels use Boom features but everything is done so that it'll appear they are Doom levels" and even if that were the case in some particular instance, players wouldn't be able to play with actual Doom behavior (or "Doom compatibility".)

What makes Boom "different" from the more advanced ports is that the Boom features are widely available in a number of different ports

I'd say the "play consistency" factor counts just as much. After all, who doesn't have more than a few ports installed, after being in the community a while? Who won't get a port for a WAD people are saying is good? It's not like it costs money. The only ones I'd likely not use, if a WAD seems promising, are the ones that I know have technical issues on my system. Do you play many Boom compatible WADs just because they run on many ports?

and almost everyone playing Doom has a highly Boom-compatible port installed.

The ones that regularly visit sites like Doomworld, probably, otherwise it's hard to know what people that are more distant or casual use. The world has over six billion people, and any of those could be playing DOOM.

Thus if you're going to do a map that uses an extended set of features, but doesn't necessarily need any port-specific advanced features, Boom is a good choice.

Relatively, as the basic ZDoom format, especially if you don't abuse all the newest features, also works on a considerable amount of ports, including the two more popular online engines.

If your concern for vanilla is that it's a requirement for making classic maps then there's something wrong:

Regardless of different opinions and varieties of views, the link between the basic functionality and being "classic" is clear, and if you have a problem when people like to stick to vanilla, or some intermediate format (perhaps Boom) as a means of guaranteeing their "classic" feel and play, and whatever it may mean to them in particular, the joke's on you.

Also, saying that vanilla mapping is somehow particularly worthwhile as it forces its limits on you is ridiculous; no one's stopping you from enforcing the same arbitrary limits on yourself when you're mapping for an advanced set of features. Vanilla is no requirement for that.

Again, it's much easier to do it when the engine is helping you than otherwise and those arbitrary limits you're talking about have no point except a matter of style while using vanilla has concrete benefits.

Super Jamie said:
I agree with kristus, the only true "Vanilla" is an unmodified DOOM.EXE.

And who disagreed with that? As far as the engine is concerned, the only true vanilla is Doom, but anything that runs in conjunction with that executable is Doom compatible. Hence DeHackEd and the limit raising patch are Doom compatible.

Distributing the patch is not useful for everyone, I can't run Doom+ natively on Linux for example.

The insignificantly-sized patch doesn't mean you can't use a port instead and the DOS executable with the patch can be used in Linux under DOSBox.

it's entirely possible to make maps in the Vanilla spec (ie: Doom.cfg in Doom Builder) which require a limit-removing port.

Not really. Vanilla specs are best tested in vanilla, hacked or otherwise, and in addition to a port of two, as desired, or else another engine that really uses vanilla specs may choke on it, have visual glitches or bugs. Ports change more than just making additions or raising limits, and can alter physics slightly (making some things not work) or make optimizations that allow possibilities that would break in Doom.