[zdbsp 1.19] compression troubles

[Mordeth]

See this thread on the ZDoom forums regarding zdbsp apparently not taking tags into account when deciding which sidedefs to compress. Is this something that needs to be fixed in zdbsp, or in EE's handling of compression or am I better off circumventing this in the map itself?

[andrewj]

You either can blame ZDBSP for not providing a way to disable this behavior. ZD = ZDoom, so expecting it to support other ports is a bit unrealistic.

Or you can ask Eternity developers to always unpack sidedefs. It is probably what a source port should do anyway.

Or you can use another node builder.

Or you can work around this issue in your map.

[Graf Zahl]

I took a closer look at ZDBSP. While it will remove unused sidedefs I could not find any place where it compresses them. I rather believe it's a problem with the editor whose compression feature never was tested on anything but ZDoom.

I agree with andrewj about one thing: Since it cannot be ruled out that maps are created with such overaggressive sidedef compression it may be a good idea to at least partially uncompress them on map load so that the problem cases get fixed.

I guess some compatibility needs to be retained, if you want to preserve some of those odd scrolling speed hacks.

[andrewj]

Graf Zahl said:

I rather believe it's a problem with the editor whose compression feature never was tested on anything but ZDoom.

Hmmm, is the map really large? Perhaps that is triggering sidedef packing in the editor.

[Mordeth]

andrewj said:

blame ZDBSP

Nobody "blames" anyone here. Not sure how you got that impression.

Editor used is DoomBuilder2. Problems happen after exceeding 65535 sidedefs pre-build and building with zdbsp 1.19. The symptoms are ACS actions that affect more sidedefs than the one targeted by tag, 3DMidTex vertical movement tags on different sidedefs that end up being "added" resulting in super turbo speeds and certain walls not registering frontal hitscans but only hitscans hitting at an angle. All but the latter can be 'solved' by using different offsets or using additional (unseen) upper or lower textures.

First I blamed blockmap troubles. It's easy to run into blockmap errors when working with portals and have run into this many times before, as putting portals anywhere near the border of your editors working area results into stuff like 1S lines not blocking but passing into the void, and other funniness.

After verifying that this is not the case, I suspected compression / sidedef packing was at fault. I'm already using compressed node format, for obvious reasons. The old utility 'dshrink' did not report a decrease when used on a build map, but did only when used on an unbuild map (which does not give a usable result btw, as dshrink needs to work on build maps). This, with additional comments from IRC, led me to believe zdbsp is compressing stuff and not doing it right.

There's no toggle option in DoomBuilder2 regarding this. Frankly I always surmised packing sidedefs could only be done after a build, not before.

[andrewj]

You cannot turn off sidedef packing on maps that large, because maps that large cannot even exist without sidedef packing (65535 is the absolute limit on sidedefs in the normal WAD format).

Does Eternity support UDMF yet? If not, or you cannot wait for it, then you only choice now is to work around the problem in the map itself.

[boris]

Mordeth said:

The symptoms are ACS actions that affect more sidedefs than the one targeted by tag

Sidedefs don't have a tag. The tag is assigned to the linedef. So if you have an ACS special that affects the sidedef of a tagged linedef, and this sidedef is compressed with a couple other ones, it might indeed result in unwanted behavior. At least if the port doesn't unpack sidedefs.

[boris]

Here's a WAD that reproduces the problem: http://88.198.197.45/boris/doom/compressed_sidedefs.wad

Tried it with PRBoom+, Eternity and (G)ZDoom. In PRBoom+ and Eternity both walls with the CEMENT9 texture scroll, even though only the right one has the scroll action (85). In (G)ZDoom it works as intended.
I guess that can be considered a bug in the compression algorythm in DB2/GZDB. The save way is to not compress sidedefs that belong to a line with an action (or at least certain actions).

[andrewj]

As a point of comparison: the sidedef packing in GLBSP ignores special lines -- i.e. a sidedef is never packed if the linedef has a non-zero special.

[boris]

The behavior has been fixed in revision 2615 of GZDoom Builder. See forum posts here.

[Mordeth]

boris said:

The behavior has been fixed in revision 2615 of GZDoom Builder. See forum posts here.

Boris, MaxED: thanks!

[Edit]: posted question about info panel / linedef mode in gzdoombuilder thread on the ZDoom forums, since I can't get that to work.

More importantly: the issue of walls not registering hitscans remains in Eternity, even after loading / saving a map in gzdoombuilder while under the 65K sidedef limit. In ZDoom this seems fine (apart from everything else EE being incompatible). Might be due to residual compression artifacts still present? Earlier version of the same map that never exceeded the 65K limit doesn't have this problem.