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

How many of you map in UDMF?

Recommended Posts

Hi to all...

Just out of general curiosity, how many of you are mapping in UDMF?
Or do you prefer Doom in Hexen format or just plain old vanilla?

I'm about to start a new map... the last one was made in Doom in Hexen and I was thinking of giving UDMF a try.

Any thoughts on the various formats plus pros and cons?

Share this post


Link to post

It is intriquing why UDMF hasn't replaced ZDoom in HeXen format, for ZDoom mapping.

Share this post


Link to post
Vermil said:

It is intriquing why UDMF hasn't replaced ZDoom in HeXen format, for ZDoom mapping.


Inertia. Most of us already are using ZDoom(DiH) format for advanced features, so I guess we just kinda keep doing what we are already doing.

I started a new, experimental map in UDMF and it's nice being able to accomplish a lot of stuff in the editor without having to resort to adding a bunch of ACS. I'll probably do all my future maps in this format.

Share this post


Link to post
printz said:

Dumb uneducated question: Why isn't UDMF XML?


XML is harder to parse, so implementing ports would have to import some XML parser lib from somewhere. Furthermore, XML also contains tons of syntactic features that are absolutely unneeded here. Finally, a UDMF map's TEXTMAP lump is long enough already; in XML its size would be multiplied by four or five easily.

Share this post


Link to post

UDMF mapping needs time to sink in really. It's easy enough to pick up if you know Hexen format and the additional freedom is useful. I've got a lot of Hexen format maps in progress, is why I've not changed to UDMF now that I'm familiar with it.

Share this post


Link to post
Gez said:

in XML its size would be multiplied by four or five easily.



Don't exaggerate. But twice as large would also be problematic.

The main reason is XML's complexity. I think it's one of the worst habits in software development to use XML as a universal tool to store data, even where a simpler approach might be better.

And even where some of it might be justified - there's still better formats out there (JSON, anyone?) XML is a horrendous bloated mess and half the implementations I have seen are either broken or have unacceptable limits.

Share this post


Link to post

Just plain vanilla, with DEU-based editor (Yadex). Well, it can manage Boom extensions too, but I don't need them.

Share this post


Link to post
Vermil said:

It is intriquing why UDMF hasn't replaced ZDoom in HeXen format, for ZDoom mapping.

The editor I use doesn't support it and I know a few people are in a similar situation. Not everyone uses DB2.

If I used an editor that supported UDMF, I would have switched right away. I don't see any significant difficulty in mapping in UDMF versus Hexen format (in fact, the two are very similar most of the time) and, obviously, UDMF offers a number of advantages over the other formats. That being said, I haven't come across anything important that I wanted to do that I couldn't make happen in Hexen format. Also, I have a number of existing projects in Hexen format where changing the maps to UDMF would confer no real advantage and so the swap-over process would be hassle for no benefit.

The bottom line for me, however, is that DB2 doesn't suit me as well as DeePsea does so that's the determining factor. There is nothing wrong with DB2, quite the reverse in fact; it's a very good editor. However, there are a number of DeePsea features that I use on a regular basis that aren't there in other editors, or which are done in a way that doesn't suit me.

Perhaps I will swap one day - when the attractions of UDMF are such that it offers some things that are important to me which cannot be done in Hexen format. Until then, however, I have no real reason to change.

Share this post


Link to post

I map in udmf but I haven't even produced any complete maps yet and I only just started to map since late last year.

Share this post


Link to post

Habit, more than anything. I used to map in Legacy format, before moving to ZDoom/Doom, and then ZDoom/Hexen formats. And that took years for me to do.

I've messed around with UDMF a bit though lately, and the extra freedom is very, very nice to have. I guess I'll eventually make the move over to UDMF once I'm comfortable with just how flexible it is.

Share this post


Link to post

I found that UDMF was useful for advanced features, but only after I'd made more than 60% of a mapset with ZDoom in Hexen format. Maybe next time.

Share this post


Link to post

I've been using good old Doom in Doom format for years now, and only starting to try and adjust to Doom in Hexen. Never touched UDMF before

Share this post


Link to post

The first map I ever released on these forums was done in UDMF format. It never saw much attention or reason to continue the project, so I started mapping in vanilla doom instead.

Share this post


Link to post

I looked up UDMF in the Doom wiki but I'm still not quite sure what it is. You've probably noticed a recurring pattern lately with my dumb questions becaue I'm so new to mapping.

Share this post


Link to post
GoatLord said:

I looked up UDMF in the Doom wiki but I'm still not quite sure what it is. You've probably noticed a recurring pattern lately with my dumb questions becaue I'm so new to mapping.


In short, it's a map format which offers an almost unreal amount of control to authors. It's also a lot less complicated than it seems. It's probably easier to get to grips with overall (from scratch) because it's so flexible. Yes, that does sound stupid, but trust me when I say that it makes sense.

Give it a try in DB2; once you get used to manually setting the triggers/parameters (what activates a line and how), you'll actually find it somewhat harder to map in the native Doom format, with its (comparatively) horrendous set of rigid linetypes.

Share this post


Link to post
BaronOfStuff said:

find it somewhat harder to map in the native Doom format, with its (comparatively) horrendous set of rigid linetypes.


The map format is independent of the modding features.

For instance Doom Legacy used the Doom map format and had Fraggle Script.

Share this post


Link to post
Vermil said:

The map format is independent of the modding features.

For instance Doom Legacy used the Doom map format and had Fraggle Script.


That might be true to some extent, but...

How do you do with Doom map format when you want to add a new thing flag or line flag? They're all already taken. So... you can't. So, you have to work around with a hack. Like Eternity's ExtraData. Sure, it is possible, but it is tedious and complicated.

With UDMF, there is no such limit at all. For example, even vertices can have additional information other than merely their coordinates. This has been used in ZDoom to allow vertex height slopes.

There is more. The flexibility offered by full parameterization (even just in the old Hexen format) allows to make combinations of line action, activation type, and speed that are simply impossible with vanilla Doom's line types, and even with Boom's generalized types.

Make no mistake, the format is a huge constraint on the modding features allowed. Want to have a special with a parameter higher than 255? In Hexen format it's impossible, or you have to make a clumsy workaround by calling an ACS script that will do it. With UDMF, there is no such restriction.

Share this post


Link to post

Although, yes, the Doom in Hexen format is limited (the "255" thing is annoying and the "dummy sectors" are odd), I use it. I used a converter before to convert to UDMF but a few parts of my level glitched, which made me resort to Hexen format.

I mean, I bet that was the converter's fault, but although I like the sound of more mapping freedom, I don't wanna take chances and risk an awesome level.

Share this post


Link to post
Graf Zahl said:

And even where some of it might be justified - there's still better formats out there (JSON, anyone?) XML is a horrendous bloated mess and half the implementations I have seen are either broken or have unacceptable limits.

Back when UDMF was being designed, I suggested to Quasar that JSON would make a good format. He (understandably) rejected this option because almost all JSON parsers are "whole-document" (DOM-style) parsers that read the entire file into memory. I started writing a pull-based parser that allowed JSON files to be read one step at a time, but I never finished it.

As it stands, my opinions on UDMF are... well, it's nice that some kind of standardised text-based level format exists. It's a shame that some deeper effort couldn't have been put into it: it seems like the main aim was just to reduce the implementation effort as much as possible. As one example, I wish the format could have been designed so as to remove the indexes from sectors, linedefs, things, etc. - if done properly then it would be possible to "diff" UDMF files stored in a version control system by using standard text diffing tools.

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
×