WAD2UDMF or better?

[Enjay]

I know this has been discussed several times, but most of the discussions are old-ish.

What is the current thinking on then best way to convert a map from ZDoomHexen to UDMF? The methods I have tried all require significant post-conversion cleanup.

a) WAD2UDMF. (which I believe is no longer maintained)
works, mostly, but after conversion:

1) There are lots of unattached vertices (which can quickly be cleaned up with GZDB's F4 error checker).
2) Line type 121 isn't handled very well. Line tags tranfer across (good) but lines used for other purposes (e.g. sound zone boundaries) lose their arguments.
3) Something I just discovered and which I have not seen mentioned anywhere else: dynamic lights can get messed up. I *think* what happens is if an argument is >128, then the converted light has the argument set to argvalue - 256 but if the value is <128, then the value is transferred across correctly. So, every dynamic light needs to be checked and edited too. (Around 128 is my guess - I'm not sure exactly where the condition changes)

examples with original values (from DeePsea) pasted in:




[edit]
Egad! The same thing happens with other thing arguments. I had a key set to lower a sector with tag 209 but after conversion it was set to lower sector -47. And an ambient sound thing set to play sound 195 was set to play -61! WAD2UDMF is basically useless for my purposes it would seem!
[/edit]

4) Any sector with a tag seems to automatically get "Actors move instantly with moving floors" property.



b) Converting by using F2 in GZDB or copy/pasting from Hexen to UDMF in GZDB.
Again, most of the work is done, and done successfully but:

1) Line type 121 is also not handled well. Amny lines with this special just lose the special making it a pain to go back and find where they all should be. (My workaround is to change them all before conversion to an unusused type that gets converted correctly, then go back and find all the converted lines and set their args/tags/properties appropriately.

2) Activations are messed up - particularly player walks over lines lose their activation types and have to be found and fixed.


All of the above can mean quite a long time (potentially a couple of hours on a big map) going back and simply fixing conversion errors before making any other actual progress on the map. Because many of the problems are not technically errors (i.e. they don't flag up as errors in an error checker) there is alway the worry that by searching for them manually, I may have missed some problems.

I have converted literally hundreds of maps from Doom format to ZDoomHexen format using zwadconv and only very, very occasionally had to fix up anything post-conversion. I understand that the Hexen to UDMF conversion is more complicated but it would be really nice if there was some way to approach the reliability of conversion that I am used to from zwadconv.

Line type 121 is my biggest problem. I have a bunch of maps that I want to convert and, on checking, I use line type 121 a lot - every map has many instances of this line type. So, not having a good conversion method may be a barrier to me progressing.

So... any advice?

[Graf Zahl]

I know this has been discussed several times, but most of the discussions are old-ish.

What is the current thinking on then best way to convert a map from ZDoomHexen to UDMF? The methods I have tried all require significant post-conversion cleanup.

a) WAD2UDMF. (which I believe is no longer maintained)
works, mostly, but after conversion:

1) There are lots of unattached vertices (which can quickly be cleaned up with GZDB's F4 error checker).
2) Line type 121 isn't handled very well. Line tags tranfer across (good) but lines used for other purposes (e.g. sound zone boundaries) lose their arguments.
3) Something I just discovered and which I have not seen mentioned anywhere else: dynamic lights can get messed up. I *think* what happens is if an argument is >128, then the converted light has the argument set to argvalue - 256 but if the value is <128, then the value is transferred across correctly. So, every dynamic light needs to be checked and edited too. (Around 128 is my guess - I'm not sure exactly where the condition changes)

examples with original values (from DeePsea) pasted in:




[edit]
Egad! The same thing happens with other thing arguments. I had a key set to lower a sector with tag 209 but after conversion it was set to lower sector -47. And an ambient sound thing set to play sound 195 was set to play -61! WAD2UDMF is basically useless for my purposes it would seem!
[/edit]

4) Any sector with a tag seems to automatically get "Actors move instantly with moving floors" property.

Some people really cannot read specifications, otherwise they wouldn't make such idiotic mistakes. With so much broken-ness I doubt this tool ever was usable.
BTW, issue 4 should only be done for Doom format maps, which require this behavior, but not for Hexen format maps.

[Enjay]

Yes, what WAD2UDMF produces is a right mess. There is far too much post conversion clean-up to be done and some of the errors are hard to find unless you know that they are likely to happen and you go searching for them.

Fortunately, doing conversions through GZDB actually seems to be working reasonably well. It still always needs a bit of post-conversion checking, so it's not quite as hassle-free as ZWADCONV was but it's nothing like as bad as WAD2UDMF.

If for some reason anyone is interested, this is the method that I use (just some notes I typed for myself to make sure that I always do everything required). This exact method may not suit everyone, but it works for me.

Load map in Hexen format
Search and replace line type 121 with line type 201*

Press F2 and open Doom2 UDMF Project

Save the map with a new name

Copy/paste the scripts from the text file to the F10 script editor (compile)**

Search for line type 201
If arg 0 is >0 it was a normal 121 with just a line id so just give it a tag (same as type 201 arg0) and set type to 0
If arg 0 is =0 look at arg1 (it could be a sound boundary (1) or a wrapping mid tex etc) set flags accordingly

Search for and check activation types for doors (usually 12) and lifts (usually 62) in case they need to be monster activated

Search for teleport types (usually 70 and 71) to see if they need to be set to monster activates

Run F4 error checker
transfer heights (209) lower colour numbers and WATERMAP flag as unknown textures

Optional
Search for type 209 and evaluate if any could/should be swapped out for 3D floors

Search for any sectors with type 195 (hide textured floor) and replace with the flag version

Try to find any projectile activated lines (no search function available). If enemy shots are meant
to activate them (e.g. breakable windows) then they need to have the "Monster Activates" flag.


REMEMBER! If you are moving geometry in GZDB, it will separate split sectors unless "Merge Dragged Vertices Only" is selected.

*I use line type 201 because I don't think that I have ever used it (so it won't clash with anything). The arguments from type 121 transfer across to 201 and are preseved during the conversion.

**Only necessary because DeePSea doesn't store the ACS source in the WAD by default so mine are all in separate ACS files on my HD.


If anyone can think of anything obvious that I need to add to my checklist, then please post it. However, the above has been giving me pretty good conversions with minimal post-conversion cleanup required.

[Caligari87]

I know this has been mentioned before, but it would be nice if dumpmap could be used for this. GZDoom obviously has a working internal representation of the map, so perhaps an extra argument such as "dumpmap udmf" could be added (to not override the legacy CCMD behavior).

[Graf Zahl]

No, the engine does not have a working saveable representation of the map anymore. Some things like slope creators or polyobjects, and a few other things get translated into internal representations that are very different from what the mapper sees. The irony here is that a Hexen format to UDMF converter should be a simple and straightforward thing - far simpler than ZWADCONV, in fact.
All the gotchas are laid out in the UDMF spec. Someone just needs to write it.

[Pedro vc]

I converted more than a dozen of my old Hexen Format maps to UDMF simply pressing F2 on GzDoom Builder and changing the map format. It never resulted in any issues

[Enjay]

You must have been lucky with what line types were used in the maps. Having now converted around 70 maps (I've kind of lost count), I'd say around 50 of them needed reworking (albeit slightly) simply because of them containing line type 121.

Other than that, however, my method out outlined above catches most things and a simple map can be converted (with a fair degree of certainty that everything is working) in about 20 minutes. It can of course be quicker (much) or slower, depending on map complexity and exactly what is in the map.

A few things that I have added to my method is to check for line types 156 (Line_SetPortal) and 215 (Teleport_Line). These have mostly converted OK but both can set line id's and both types have caused a problem at least once. It's always easy to fix. It's just that you need to catch the error - so a quick serch for the line types helps.

Another one that I have added to my searches is line type 208 (TranslucentLine). This also sets line ids (in Hexen mode) and it can mess up slightly. If the line just sets an ID (i.e. arg 0 is non 0 but the map doesn't really do anything with the ID) then the conversion keeps the value in the field but GZDoom seems to do nothing with it. So, it's just ignored and doesn't obviously cause an issue (worth clearing out though). If the ID is meant to be used, then it needs to be set properly as a line tag by hand.

Also, a not very common construct (I have found it in 3 maps) is to use a line type 208 in Hexen mode, give it a line ID (via arg0) and then elsewhere in the map give other lines a type 121 with the same ID. This means that the translucency properties set on the first line gets copied to all the other lines with the same ID. However, this no longer works after conversion - even if all the ex-line 121s are given a suitable line tag after converting. They will just appear fully opaque in game.

The search is quick enough though. An F3 search for type 208 can be scrolled through and any where arg0 is non-zero can be investigated further - easy to spot in the result. However, this often means a second search (for line type 121 in Hexen mode or simply for line tags if the UDMF conversion has already been done) to find any lines with IDs/tags that match the one set on the line 208. Like I said, it's not common practice but worth checking for.


As an aside, for what it's worth, the numeric values that ZDoom accepts on a lower side to give colour to an underwater area created with a line type 209 (or the WATERMAP alias) are not recognised by GZDB, so they always flag as an unknown texture during the F4 error check. If it's a complicated map with lots of fake floors, that can throw up a lot of errors.

I also look inside scripts for instructions to align, rotate and pan floors/ceilings just so that I can set them manually in UDMF. An entirely optional thing that I just think is so cool to be able to do after a couple of decades of not really being able to do much with flats directly in the editor.

I also always check the two (what I call) "ear modes" (sound propagation and sound environment modes - both have ears on their button). Two very useful tools that are great fun to play with and make setting up various sound/environment zones soooo easy.



It also seems that me picking line type 201 for a temporary holding value for line type 121s was a good choice. So far, in all the maps I have only found one single instance in one single map of line type 201 actually being used for something. Moreover, because it was set up properly, it looked very different to the converted line type 121s (i.e. it had a full set of parameters) so it stood out in my search result as something to be treated differently.


Some people might wonder why I am doing all this. Nothing to get excited about. I've always liked messing around with other people's maps to help me learn the engine and/or editing techniques. I'm currently trying to learn UDMF, GZDB and I still like poking around in maps so this kind of gives some purpose to my practice rather than just "doodling" in the editor. Converting a map, picking up the errors and maybe tweaking a few things just for the hell of it means that I have something to actually do rather than aimlessly fiddling with stuff. I always find something like that helps me learn software. I'd say that I'm now much more proficient with GZDB (and UDMF) than I was, although I'm sure that it still has a few really cool tricks and secrets up its sleeve for me to discover. I've discovered many so far (and been led to many as well via help posted on this forum).