Detailing Project: Room by Room

[Guest DILDOMASTER666]

MP2E said:

Or, best of all, an Eternity Engine map pack. Linked portals and all sorts of portal effects would go great with higher detailed DooM maps. 8)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This would be great. But for this project Boom may be a good idea.

[ArmouredBlood]

MP2E said:

... However, UDMF itself is a specification of the Doom format that is supposed to be supported by any port that has support for it. Quasar(The writer of Eternity Engine, which is a BOOM based port) was one of the main writers of the specification. Meaning unless port writers all of a sudden have an interest of writing map formats for ports other than their own, this isn't even close to true.

So ... it's a format supported by any port that supports it? Way to tell what the format actually is. This is probably too technical but helps more than this barebones entry. So the jist I am getting is that UDMF is text based, and can thus support scripting WITHIN the map itself? No script lumps? And can also add parameters somewhat (messed around a little with it).

I'd say use UDMF(because it's new and needs more maps that support it!) or Boom format. Or, best of all, an Eternity Engine map pack. Linked portals and all sorts of portal effects would go great with higher detailed DooM maps. 8)

UDMF sounds better for this project from the 'you can read scripts within maps' standpoint (correct me if wrong here and above); eternity's portals sound great to work with, but mashing individual rooms together in eternity sounds a bit ugly if portals were used extensively. Probably better to have a project of maps from single sources for it.

[Guest DILDOMASTER666]

Incorrect. UDMF is as of now only supported by recent versions of ZDoom and does not facilitate in-map scripting of any kind without an external (relative to the TEXTMAP lump) BEHAVIOR entry or similar. Using UDMF has about the same effect as just saying this is a ZDoom project, with "the possibility of being supported by other ports in the future".

[MP2E]

ArmouredBlood said:

So ... it's a format supported by any port that supports it? Way to tell what the format actually is...

I was merely trying to say what it is NOT, which happens to be what was said before about ZDoom.

[ArmouredBlood]

Ok ... then why bother with UDMF now? From the little messing around I did it maps (maps, not runs) about the same as zdoom ~hexen, but with a new tab for more *stuff*. Meh, I'm not likely to get around to making for this soon anyway, when I do I'll just stick to boom >.<

EDIT: @MP2E; nevermind, I'd delete my posts if it didn't mess with thread continuity.

[MP2E]

ArmouredBlood said:

Ok ... then why bother with UDMF now? From the little messing around I did it maps (maps, not runs) about the same as zdoom ~hexen, but with a new tab for more *stuff*. Meh, I'm not likely to get around to making for this soon anyway, when I do I'll just stick to boom >.<

Well you're missing the point of UDMF, it's supposed to be a map format that will eventually reach the goal of being supported by most "advanced features" Doom sourceports. It's not supposed to have all the scripting of ZDoom, because if it did, then it wouldn't actually be Universal, would it? UDMF does have many more advanced features than boom, but nonetheless I think sticking with Boom wouldn't be a bad idea.

[ArmouredBlood]

MP2E said:

Well you're missing the point of UDMF, it's supposed to be a map format that will eventually reach the goal of being supported by most "advanced features" Doom sourceports. It's not supposed to have all the scripting of ZDoom, because if it did, then it wouldn't actually be Universal, would it?

All I'm getting out of this is that it will be supported by all ports. Is it really worth the effort of re-creating doom data so all ports can read it when you can just play it in the port? My main port is skulltag, and I have prboom for demos, and with those 2 I can play basically everything except random (G)zdoom stuff that takes advantage of newest builds that I then have to update those ports to.

[arrrgh]

I thought the point of UDMF was because it was a textformat instead of binary that whatever flags or variables you want can be added to linedefs and sectors directly because the format is flexible unlike binary formats?

[Guest DILDOMASTER666]

arrrgh said:

I thought the point of UDMF was because it was a textformat instead of binary that whatever flags or variables you want can be added to linedefs and sectors directly because the format is flexible unlike binary formats?

Tru fax.

[Antidote]

This topic is getting off topic. The format is no longer UDMF, rest easy. If you guys would like debate the facts and fallacies of UDMF, please make a new post. This project is going into works, please sign up or forever hold your peace.