help with a weird map

[bagheadspidey]

First, the map.

What's weird about it?

- If you try to edit (or even just save) the map in slade, it will totally break, even though it (mostly) works great in zdoom.
- If you face south and fire a rocket over the horizon, the game will freeze up for several seconds. Very weird.

Can anyone shed some light on what might be causing this weirdness? Also, can other editors besides Slade edit this map?

The map is created with all custom code (not a normal map editor), so there may be things I forgot to do or did wrong. I'm hoping a more experienced mapper can help me out a bit.

Also, before I forget, the wad has been run through zdbsp. The problems occur whether or not i run a nodebuilder on the map.

[Enjay]

No problem eding it in DeePsea. I can't get the rocket horizon problem in Zdoom r955 or GZdoom r101 either.

[bagheadspidey]

hmm, that's good. Thanks for looking into it, Enjay. Maybe I won't worry about that so much for now.

If anyone else wants to test this wad in more editors, I'd really appreciate the feedback... maybe it's just a bug with slade (I hope!).

[Zippy]

Seems fine with Doom Builder.

I've run into what may a different, but possibly related problem with SLADE (one of a few reasons I don't use it). Basically it saves the map wrong some how such that ZDoom, Doom Builder, etc. can no longer properly read the map properly and can't be used with those programs though SLADE itself can still read it.

[Enjay]

I noticed that the sidedefs are packed. Does SLADE still have a problem if you unpack them?

[bagheadspidey]

ok, stupid question but what exactly _is_ sidedef packing?

when my program creates sidedefs, it only creates one sidedef for each sector, as each side of the sectors are always the same. Then, each linedef in that sector references the same sidedef, rather than creating duplicate identical sidedefs for each linedef.

Is that sidedef packing? Is it bad? It kept my map size down a lot, but is it not supported in some engines / map editors?

I tried generating these maps with and without the technique i'm describing ("without" meaning no sidedef ever being referenced more than once), but it didn't seem to make any difference at all besides the size of the wad.

[Kappes Buur]

The Deepsea text file has this to say about sidedef packing:
1. Extended support for over 64k sidedefs for editing purposes only.
2. When saving a level with over 64k sidedefs, they are automatically packed.
3. Packing of SideDefs is now instantaneous thanks to an idea suggested by GLBSP.

I ran this file without any problem with Deepsea and Doombuilder.
In SLADE, v2.00 beta 1 according to the slade text file, it ran fine until I looked straight up.
At which point SLADE gave up and terminated the program. But then, it seems to do this for any file.

In a nutshell, no problem with foo2.wad

[Cutmanmike]

bagheadspidey, are you by any chance trying to make a new level editor?

[Wagi]

Baghead, "Sidedef Packing" is a technique that is used to lower the size of the sidedefs lump. In the linedefs lump, there is a variable that determines what sidedef number that particualar linedef uses. What sidedef packing does is find sidedefs with the same exact properties and then deletes them to save space.

For example, sidedef 28 has the same exact properties as sidedef 29. Sidedef packing deletes sidedef 29, and then finds any linedef referencing sidedef 29, and changes it to 28. This is supported in Vanilla Doom, but seeing how the stock maps don't use this, I doubt it was intentional.