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

Max # of linedefs in DB2

Recommended Posts

Sorry for the bump...

I've used the conversion tool, but when I try to load the level in DB2 I get...

Error of line 72892 while parsing UDMF data: Unknown keyword in assignment. Missing a previous terminator symbol?

Any help?

NT

Share this post


Link to post
NaturalTvventy said:

I've used the conversion tool, but when I try to load the level in DB2 I get...

Error of line 72892 while parsing UDMF data: Unknown keyword in assignment. Missing a previous terminator symbol?

Any help?


Maybe the converter crapped out? We'd have to have the converted map to tell whether there is a problem in the converter's output or whether there's a bug in DB2.

Share this post


Link to post

The tool wrote

renderstyle = translucent;
but it should be
renderstyle = "translucent";
Also, a lot of linedefs are missing their front side, because the tool did not write a "sidefront" field for many linedefs (do you have linedefs in your map without front sides?) The UDMF specs say that this field is required and as such Doom Builder chokes on it. I find this requirement odd though, because technically it should be possible to have a linedef without front side, regardless if the sourceport likes this or not.

I think it also inserted a stray "4" between the sidedefs structures and vertex structures, but that could also have been me pressing random keys while trying to fix your WAD during breakfast. But when I noticed the missing "sidefront" fields I gave up, so you're better off trying to convert this by hand.

Open your map in DB, with its original configuration. Go to Linedefs mode and select all linedefs, then switch to Things mode and select all Things also. Press CTRL+C to copy it to the clipboard. Now create a new map, with a UDMF configuration, and paste everything. Make sure you align your map correctly when pasting. Then good luck fixing things :P

Share this post


Link to post
CodeImp said:

The tool wrote

renderstyle = translucent;
but it should be
renderstyle = "translucent";
Also, a lot of linedefs are missing their front side, because the tool did not write a "sidefront" field for many linedefs (do you have linedefs in your map without front sides?) The UDMF specs say that this field is required and as such Doom Builder chokes on it. I find this requirement odd though, because technically it should be possible to have a linedef without front side, regardless if the sourceport likes this or not.



The requirement is there because a front side-less linedef is an error by definition. The Doom engine would crash on it. Any source port trying to deal with this has to hack around it and assign some arbitrary sidedef to such a line which is bad enough.

Share this post


Link to post
CodeImp said:

technically it should be possible to have a linedef without front side, regardless if the sourceport likes this or not.

Yes I agree, from a mapping perspective there is nothing wrong with a linedef without any sides, or only a back side.

But considering the DOOM code (and hence all source ports) was written assuming the front side is always present, and it would take a lot work to fix those pieces of code (for no real gain except a tiny bit of elegance), then the UDMF requirement makes sense.

Share this post


Link to post
Graf Zahl said:

The requirement is there because a front side-less linedef is an error by definition. The Doom engine would crash on it. Any source port trying to deal with this has to hack around it and assign some arbitrary sidedef to such a line which is bad enough.

I'm not saying a sourceport (nor vanilla Doom) should like this. I'm saying it should be allowed in the file format, because it is possible and consistent with the back side (it is even possible in the binary format). If the sourceport doesn't like it, it should just poop out an error saying linedefs without front sides are not allowed (and I think this is what happens).

I just checked and DB will still load the map, even when linedefs have no front side, it just shows a warning when loading the map, so that's fine. Still, this conversion tool is making some mistakes that need fixing for it to be useful.

Share this post


Link to post
CodeImp said:

Still, this conversion tool is making some mistakes that need fixing for it to be useful.


Thanks for your effort, takin' a look at this thing.

is there any hope for it being fixed in the near future? do we know who made it? Should I try holding out, or just bite the bullet and copy/paste my level into a new UDMF WAD?

NT

Share this post


Link to post
CodeImp said:

I'm not saying a sourceport (nor vanilla Doom) should like this. I'm saying it should be allowed in the file format, because it is possible and consistent with the back side (it is even possible in the binary format). If the sourceport doesn't like it, it should just poop out an error saying linedefs without front sides are not allowed (and I think this is what happens).

I just checked and DB will still load the map, even when linedefs have no front side, it just shows a warning when loading the map, so that's fine. Still, this conversion tool is making some mistakes that need fixing for it to be useful.

I don't see why an editor can't accept UDMF with a missing front side, but it's then the editor's responsibility to fix that, or make sure it gets fixed by the user, before saving that map for use by source ports, because as previously noted, we have no real way to deal with it port-side other than what amounts to a hack.

Share this post


Link to post
NaturalTvventy said:

is there any hope for it being fixed in the near future? do we know who made it? Should I try holding out, or just bite the bullet and copy/paste my level into a new UDMF WAD?

I emailed the author of the tool about these bugs and provided a link to this topic. If it gets fixed depends on him, I don't know. Didn't you make a conversion tool as well, Graf?

Share this post


Link to post
CodeImp said:

Didn't you make a conversion tool as well, Graf?



Nothing I could release, unfortunately. It's all mixed up in a larger project and hard to extract. I also haven't updated it in a long time.

Share this post


Link to post

That tool has a command line help option. Run it with 'zdoomconvert -h'.

Anyway, needs less EXEs and less iostream. That thing needs longer to start than to print its help...

Also, comes with source but no project files or other help to compile.

Share this post


Link to post
Graf Zahl said:

That tool has a command line help option. Run it with 'zdoomconvert -h'.

Anyway, needs less EXEs and less iostream. That thing needs longer to start than to print its help...

Also, comes with source but no project files or other help to compile.


I did this. . .

C:\Convert>zdoomconvert -w longshot.wad e4m2 hope.wad

and this happened . . .

WAD Type: PWAD
Conversion complete!

But hope.wad is not a valid WAD file. Did I mess this up, or is it not working properly either?

The only thing I'm not sure of is the 'e4m2' part. The help says this is the map lumpname from the wad file. That lump looks like the map, so I'm guessing that's what it wants?

Thx,

NT

Share this post


Link to post

Have you tried again with z34chris' updated tool? The bugs you had should be fixed now.

Share this post


Link to post

tried the new one...

wad2udmf -input longshot.wad output pleasework.wad

it did this...

wad2udmf version 0.3.3b
open input file and create output file
write lumps
numlmps 0
write header
close files


and then there was an empty file called pleasework.wad without any data in it.

still needs some work?

Share this post


Link to post

oops, Ill get that updated. I had a continue statement which prevented the program from running. I am testing this with the new release of zdoom and there seems to be more work to do with the polyobjects. So far, this program works with one of the previous releases of zdoom.

updated utility: http://www.atomicgamer.com/file.php?id=88645

Share this post


Link to post

Unless I am mistaken, it would seem that one would need to run a nodes builder for udmf maps as the 2.5 version of zdoom messes up the polyobjects in the demo wad after being converted to udmf. I tested this and got the same results by removing the nodes lump from the original binary file and ran the map in zdoom. Without nodes, it seems the whole map was rotating on itself.

Share this post


Link to post
z34chris said:

Unless I am mistaken, it would seem that one would need to run a nodes builder for udmf maps as the 2.5 version of zdoom messes up the polyobjects in the demo wad after being converted to udmf. I tested this and got the same results by removing the nodes lump from the original binary file and ran the map in zdoom. Without nodes, it seems the whole map was rotating on itself.


Yes, that's a known bug and already fixed. Unfortunately, someone does not consider this a good reason for a 2.5.1 release. :( Better get a recent SVN build off DRDTeam for testing.

Share this post


Link to post

Ill check the svn builds. The converter is possible, you just need a nodes builder as far as I know. UDMF uses the znodes lump that zdbsp can create for you.

Share this post


Link to post

Urgh, it's SUPER-OVER-DETAILPASSED! (>Stroke of mind<)
Deus Vult MAP04 is nothing related to this...

Share this post


Link to post
z34chris said:

Ill check the svn builds. The converter is possible, you just need a nodes builder as far as I know. UDMF uses the znodes lump that zdbsp can create for you.


I think I can handle me some nodebuilding. Were can I find the functional converter?

NT

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
×