If your default map format is something other than UDMF: Why?

[Clippy]

1 minute ago, boris said:

 

That's not DB1, that's DB2.

 

Well I'm not surprised I don't know what I'm talkin about

[Wavy]

I want to further elaborate my stance on this topic

 

The main reason I don't use UDMF is because most of the features don't really intrigue me. Slopes, fog, scripting and all that jazz is cool, but most of my maps/ideas don't really need that. Most of the features that I want to add towards my map can be done in Boom. Yeah it's far more limited than UDMF, but that doesn't make it overall worse.

 

I like stuff like deep water, bridges and room-over-room architecture, but I can do these in Boom and although it may not be the easiest things to set up and work, it functions exactly how I want it to and it's compatible with most ports.

 

I don't hate UDMF at all, it just isn't for me.

 

That's my take.

[Doomkid]

2 hours ago, Clippy said:

Well I'm not surprised I don't know what I'm talkin about

lol, it’s ok Clippy. If you ever do feel like moving up to GZDB I can try and offer some assistance. But, Considering you’re on DB2 (which I never used), switching to DBX might actually be kinda easy for you. Apparently it’s much the same, just with easier functionality (being able to draw lines going through eachother and having the editor automatically separate everything into working sectors, for example)

 

Anything DB2 and up is still miles ahead of WadAuthor and DB1, at least :p DBX might save you time for future maps tho. Just something to keep in mind, that’s all!

[Sectorslayer]

When I started mapping again last year I accidentally created my first map with UDMF. Wow, I thought! I did not remember all those settings and special editor things from old DEU days. Later I learned that I can choose formats and what all these ports are about. I tried "Knee Deep in ZDoom". It's a tech demo, I know. But this was so far from the Doom I knew, I was shocked. Now I play even without freelook and it's great.

 

Although in the beginning I was fantasizing about glass windows and outdoor lightning I decided to stick with vanilla Doom format. In the end it recreates that Doom feeling very well. Modern ports have hardware rendering and dynamic lightning now. That's wonderful! I don't need a special format to have that. Limit removing shall be my limit for now and this works without UDMF. Probably also because of the fact that I create maps with SLADE. Doom format and SLADEs capabilities are a good match. Its already an almost infinite creative space...

 

[Clippy]

1 hour ago, Doomkid said:

lol, it’s ok Clippy. If you ever do feel like moving up to GZDB I can try and offer some assistance. But, Considering you’re on DB2 (which I never used), switching to DBX might actually be kinda easy for you. Apparently it’s much the same, just with easier functionality (being able to draw lines going through eachother and having the editor automatically separate everything into working sectors, for example)

 

Anything DB2 and up is still miles ahead of WadAuthor and DB1, at least :p DBX might save you time for future maps tho. Just something to keep in mind, that’s all!

 

Thank you when I have enough time and patience to mess around I'll give er a try again

[LexiMax]

4 hours ago, Mordeth said:

Yeah, no. And perhaps this is where the confusion by some posters is coming from? 

 

I am well aware that Eternity supports UDMF, but most people in this thread are talking about the GZDoom namespace of UDMF, even if they don't specifically say so.

 

I actually don't know if you can make a UDMF map that runs on both GZ and Eternity, but even if you could, that wouldn't change the compatibility calculus for me by much.  To me, UDMF only really makes sense if you set out to make a map with the specific intent of only being playable on GZ or Eternity.

[BrassKnight]

For me, I map on Boom format (used to map in Doom 2 format) because I find it to be the middle ground between the Doom 2 and UDMF format, it's simple to use since it's essentially the vannila format extended but it can be advanced too with stuff like voodoo dolls. UDMF has a lot of cool stuff in it but I don't need them or they seem too complicated for me to learn, I was just overwhelmed and couldn't map at all.

[Terraformer9x]

I go with Doom 2 or Boom usually mostly because of demo compatibility,

 

but...

 

Spoiler

I really, really hope that someday in the future, we get poly object support in something like MBF21.

 

[printz]

Eureka's UDMF support is currently under construction. I'm working on making it official. 

[NiGHTMARE]

2 hours ago, AlexMax said:

 

I am well aware that Eternity supports UDMF, but most people in this thread are talking about the GZDoom namespace of UDMF, even if they don't specifically say so.

 

I actually don't know if you can make a UDMF map that runs on both GZ and Eternity, but even if you could, that wouldn't change the compatibility calculus for me by much.  To me, UDMF only really makes sense if you set out to make a map with the specific intent of only being playable on GZ or Eternity.

 

Don't forget (K8)Vavoom!

 

From what I can find on-line, ZDoom has its own unique UDMF extensions while Vavoom and Eternity don't, so as long as you avoid those it seems you could in theory make a UDMF map works in all three points.

 

4 hours ago, Doomkid said:

Anything DB2 and up is still miles ahead of WadAuthor and DB1, at least :p DBX might save you time for future maps tho. Just something to keep in mind, that’s all!

 

I'm still using DeePSea, which is even older than DB1! (For what it's worth I also still use Paintshop Pro v7.04 and Winamp ;))

 

[Gez]

17 minutes ago, NiGHTMARE said:

while Vavoom and Eternity don't,

They actually do; they're just a bit more obscure.

 

https://repo.or.cz/k8vavoom.git/blob/HEAD:/specs/udmf_k8vavoom.txt

https://eternity.youfailit.net/wiki/UDMF

 

EDGE also supports UDMF, but I didn't find a spec document for it.

Edited June 21, 2021 by Gez

[Biz!]

I choose BOOM because it's "chill", other than that it would also be Doom format because "it's chill."

[Horus]

15 hours ago, leodoom85 said:

 

Different topic from what's talking here and that mindset is kinda wrong. I suggest to not compare to others and treat any videos like a hobby, even if it's not viewed a lot.

I know, I was just responding to jerrysheppy’s argument that whilst yes, YouTube theoretically reaches a larger audience, in practice it doesn’t change a whole lot unless you put a lot of effort into post-production. I don’t actually care about my view count for either videos or demos.

[jerrysheppy]

True, although any given random Doom wad release doesn't 'reach a large audience' in the grand scheme of things either, but that doesn't immediately disqualify the argument that vanilla format is better for reaching as large an audience as possible.

 

Having a video on YouTube and being able to just toss someone the link can only make it more accessible a prospect to share your videos with others, which is mostly what I meant, not becoming an ~*~influencer~*~ or whatnot. ;)

 

The use case of demos for sharing your gameplay (as opposed to competition, etc.) still seems to be sending it to one or a very small group of people who you know are interested in playing demos back.  Which it's good at if that's all you want!  A YT video, you can link or embed in passing in a Doomworld thread and anyone who wants to can watch it for essentially a zero effort investment.

[roadworx]

2 hours ago, NiGHTMARE said:

I'm still using DeePSea, which is even older than DB1! (For what it's worth I also still use Paintshop Pro v7.04 and Winamp ;))

but...why?

[jerrysheppy]

4 minutes ago, roadworx said:

but...why?

 

'Why are you using these 20 year old programs?' they said, in the thread where many folks were ardently defending the merits of vanilla Doom gameplay.

 

Spoiler

(Just teasing! I just think it's funny!)

 

[roadworx]

1 minute ago, jerrysheppy said:

 

'Why are you using these 20 year old programs?' they said, in the thread where many folks were ardently defending the merits of vanilla Doom gameplay.

 

(Just teasing! I just think it's funny!)

lol, touché

[LexiMax]

3 hours ago, NiGHTMARE said:

Don't forget (K8)Vavoom!

 

I didn't forget about it.  The post I was quoting quoted me mentioning that specific port.

 

*sighs*

 

This is why I feel like this thread is honestly kind of silly.  UDMF is a way of serializing map data and has absolutely nothing to do with the gorillian features that a given port might add.  The advantage of UDMF is that it might give you more convenient access (or access at all) to certain features compared to the binary Doom and Hexen map formats.  The disadvantage is that the UDMF format isn't supported by most ports, and the ports that do support it sometimes support features in incompatible ways making the fact they support UDMF essentially an implementation detail and no promise of compatibility.

 

And that's about it.  But somehow, the thread gets onto tangents that talk about the features that a port might expose through UDMF, usually GZDoom.  It's a little frustrating when we can't even agree on what we're discussing.

Edited June 21, 2021 by AlexMax : Got rid of a distracting analogy

[Gez]

The basic specs for UDMF -- that is to say, not port-specific namespaces -- are basically at the MBF level, just with more granularity for skill-level thing placement (ITYTD is separated from HNTR, UV is separated from NM).

 

But it does allow floating point coordinate values for vertices and things, and also it allows to go past the Doom or Hexen format limits for the number of vertices, sidedefs, linedefs, and sectors. So it can still be useful if you want to make a gigamap.

 

The core point of UDMF is that every port that implements new feature can do that easily by adding new properties. Incompatible implementations can be mitigated to some extent thanks to the namespace system.

[Ashurion Neonix]

Vanilla (limit removing)

I enjoy working under vanilla limitations mainly for port compatibility since my preferred port is crispy doom.

I choose to make them for limit removing ports as I find working around static limits to be unfun.

I also like to stick with the textures from the IWADs or modified versions of them as I also like a classic look.

[jerrysheppy]

Anyway, reading this thread (which has been a very pleasant surprise, insofar as it's exploded like with people sharing their own experiences and having civil back and forth debates, with only the one notable exception that I'm aware of) I mostly understand the sort of responses about wanting to map in vanilla for specific reasons, like enjoying the problem-solving/masochism aspects of it, or one's laptop being older than Methuselah and barfing on GZDoom, things like that. I anticipated some of those responses but it's still super nice to read people actually describing their own experiences and perspectives.

 

I'm still, without (of course) saying that anyone is bad and should feel bad, somewhat head-scratchy about the folks who want these more advanced features, but not those advanced features, and who use it as an argument for not taking up GZDoom/UDMF—because part of the whole point is that GZDoom doesn't hold a plasma gun to your head and tell you that you need to start putting 3D floors everywhere.  I just played DavidM's lovely Ascent of Titan level set (yes, I'm half a year late, but I was taking a break from Doom for much of that half-year) and one of the things that struck me was just how much of a vanilla-compatible flavor was in 90% of the architecture and detailing.  It felt like David set out to make a very vanilla-feeling mapset, but when he needed the occasional freedom to, say, place rooms over rooms, it was right there waiting for him.  

 

Finally, I've noticed that there are two opposing arguments that, basically, agree that accommodating a broad spectrum is a good thing, but disagree on where exactly they see that accommodation.  Some say that mapping for as vanilla a format as possible means your map has the highest possible audience of users/players, which is certainly not wrong in a sense.  Others (me) make the argument that adopting UDMF as a default standard offers the highest possible inclusivity in what you might call "mapfeel" for a given source port; that is, you can make and play an E1 clone flawlessly in GZdoom/UDMF, and you can also play just about any older map, but you can't make and play Technicolor Antichrist Box in doom2.exe. 

 

It occurs to me that there is a crude analogy with human ABO blood types, where you have, among other things, a universal recipient type (AB) and a universal donor type (O).  If you don't know what blood type a transfusion recipient has or will have, you can safely give them type O blood, all else being equal; this is analogous to putting out a vanilla-limits map knowing that as many people as possible will be able to play it.  If a blood bank could have an endless supply of any blood type they wanted, they'd pick type O (O negative, to be precise). But, if you could choose a blood type for any given recipients to be, you'd pick AB-positive for the greatest amount of flexibility in accommodating whatever blood types the bank might have on hand.  In real life we don't have the ability to pick what blood type we want ourselves or a patient to be, more's the pity, but in Doom we generally do (the exceptions being things like folks who aren't privileged to be able to upgrade their computer to run GZDoom, which I realize is sadly still a thing but which we can hope will become less so). 

I'm just a layperson using what I believe is an accurate if basic account of blood-type considerations; please forgive me if I've gotten anything medically wrong!

 

Anyway, any analogy can only be stretched so far (I doubt we'll see people injecting them with the wrong types of blood to give themselves a "challenge"), but I thought it was an interesting way of looking at it.

[jerrysheppy]

41 minutes ago, AlexMax said:

 It's a little frustrating when we can't even agree on what we're discussing.

 

I feel like most people in this thread are in fact comfortably, if implicitly, agreed to use "UDMF" as a metonym for "GZDoom in UDMF format" and are doing so.  There are exceptions when vavoom or whatnot come up and a bit of clarification is needed, but those are just that, exceptions.  If we were to say "GZDoom", we might occasionally have to clarify that we don't primarily mean GZDoom in Hexen format.  

[esselfortium]

15 minutes ago, jerrysheppy said:

you can't make and play Technicolor Antichrist Box in doom2.exe. 

OK, new project time!(TM)

[Horus]

17 minutes ago, jerrysheppy said:

I'm still, without (of course) saying that anyone is bad and should feel bad, somewhat head-scratchy about the folks who want these more advanced features, but not those advanced features, and who use it as an argument for not taking up GZDoom/UDMF—because part of the whole point is that GZDoom doesn't hold a plasma gun to your head and tell you that you need to start putting 3D floors everywhere.

 I think what you’re missing is simply that different people’s minds are wired differently. Some people look at UDMF’s extensive feature list and can easily filter out what they don’t need and focus on what they do, others (like myself) get overwhelmed by all of the features and their mapping productivity and quality is hampered as a result. Neither group are right or wrong, it’s just different people work differently.

[ketmar]

so, basically, for wider adoption of UDMF, editors should simply implement "vanilla UDMF mode", removing all extended UDMF features from dialogs. then mappers won't be able to tell the difference. ;-)

[LexiMax]

Just now, ketmar said:

so, basically, for wider adoption of UDMF, editors should simply implement "vanilla UDMF mode", removing all extended UDMF features from dialogs. then mappers won't be able to tell the difference. ;-)

That would be doing a lot of work just to end up in a worse spot than you were beforehand.  The underlying map would still be unreadable by the kinds of ports that vanilla/limit-removing/BOOM/MBF authors want to target.

 

Seems like the kind of thing someone would only do out of spite.

[ketmar]

11 minutes ago, AlexMax said:

That would be doing a lot of work

not that much, i believe: the simplified interface is already there for non-UDMF editing. the extended one is prolly turned on by "this is UDMF map" flag, which can be factored to separate "enable extended interface" flag.

[jerrysheppy]

44 minutes ago, esselfortium said:

OK, new project time!(TM)

 

Hahaha.  Obviously I meant in its fully featured and 'fidelitous' form, but at the same time I would love to see what someone like you could come up with as a demake. :)

[LexiMax]

17 minutes ago, ketmar said:

not that much, i believe: the simplified interface is already there for non-UDMF editing. the extended one is prolly turned on by "this is UDMF map" flag, which can be factored to separate "enable extended interface" flag.

 

Again, just to make a map with an MBF featureset that can't be played in actual MBF ports?  That seems incredibly silly.

[ketmar]

20 minutes ago, AlexMax said:

Again, just to make a map with an MBF featureset that can't be played in actual MBF ports?  That seems incredibly silly.

nope, not that. make a map in UDMF format without being overwhelmed by features. the more people will map in UDMF, the more reasons to add UDMF support for sourceports that don't have it. and the first step in that direction could be made by editors, 'cause they already have all the necessary code.

 

then someday in the future editors could switch to UDMF by default, and only change namespaces.