How do I extract my maps without their texture data?

Some of you might have seen me post some screenshots of some maps I began work on some time ago. Part of the reason this project was brought to a halt, was that while editing my .wad file with XWE, I inadvertently deleted some texture (flat?) information which caused all sorts of horrible problems.

In the end, I had two version of my .wad - one which Doombuilder could open, but would crash Zdoom (and other ports), the other would load fine in Zdoom, but crash Doombuilder the moment it attempted to load the texture data.

Other interesting problems it created included causing certain textures not to tile correctly, and to animate all textures like Bfall backwards.

So, I realised the easiest solution would be to extract just the barebone map data, re-import the custom textures I was using, and start over.

Surely there is an easy way to do this? Exporting the maps in Doombuilder, extracts not just the map data, but all my damaged texture information as well. I don't want this, obviously.

Is there some option in Doombuilder I'm missing?
XWE just crashes if I click on the map entry. :(

Also - is anyone else using a Logitech G9? Doombuilder doesn't seem to like it at all the moment I swap into 3d mode, and I was wondering if anyone else had issues with it.

I'm not knowledgeable with xwe, but maybe try copying the map sectors in doombuilder and pasting in a new blank doombuilder map (probably obvious and you already tried). And probably good to only open a copy of a wad in xwe, not the actual wad because there's no undo as far as I know; it just permanently changes it.
Also apparently people have had problems/crashes on vista if you use that, so that's one land mine you might look out for (something about having to disable some process for the fix but I don't remember exactly, google or search this forum probably).
You should take just about anyone else's advice over mine, but one guess would be to make a new blank map with the same texture pack or whatever then import that into xwe and try to copy the files from that over to replace the messed up wad's files. That's a random guess, so probably don't do that..

Actually I still have macabre v3 or something and its not messed up as far as I know if that's what you are referring to so could sendspace it (zdoom map I think). Boom maps are less engine-restrictive and you can do some nice stuff with dummy player 1's on scrolling floors.

I would use deutex. Example command line:

deutex -levels -xtract broken.wad

I can't quite think of any sort of cataclysmic situation involving textures would cause something like ZDoom to crash. Are you saying that you corrupted/deleted the TEXTURE1/PNAMES lumps? That's the only thing I can think of that would remotely cause problems. Maybe you can upload the wad in question and have someone take a look at it.

When dealing with textures, TEXTURE1 is the main lump that stores the most specific information regarding textures. It references multiple patches from the PNAMES lump and assembles those patches into "textures". The map's SIDEDEF lump references texture names found in the TEXTURE1 lump. That's how everything links together. If you have a problem or inconsistency in any of those lumps, then things can go badly (but not too badly as to make zdoom crash). I'm curious as to what's causing the crashes...

Extracting a map without "texture data" is impossible though. In order for a map to be valid, it needs a SIDEDEFS lump, which contains texture information for all sidedefs. Perhaps this is what you deleted? If that is the case though, I'm afraid your map is not repairable by any means I'm aware of... (Edit: short of copy-pasting the sectors and re-establishing all textures used)

Insane_Gazebo said:

So, I realised the easiest solution would be to extract just the barebone map data, re-import the custom textures I was using, and start over.

Surely there is an easy way to do this?\

Actually, that's what I would have recommended to you. IMO, it's generally easier to just start over with the textures than trying to sift through all that information trying to find what's wrong. Texture issues ususally don't crash Zdoom, so it sounds more like some type of I/O error that screwed up all your data. I'm sure you're aware that you can't have a map open in XWE and another editor at the same time, because they will get confused reading the data like that and write it in such a way that it will not be usable. That's the only thing I can think of that would cause this related to XWE. If you've been keeping backups of your maps, your best bet is just to go back to the most recent one's that aren't corrupt.

Well, this is embarrassing. I could have sworn I'd tried copying and pasting my maps from one file to another, and hence, had discarded the idea.
Trying it again, revealed that it worked fine. The error is now gone, and all but one texture is now displaying correctly.

As to the source of the error, I'm almost certain that EarthQuake's first guess is entirely correct - that I accidentally deleted something in the TEXTURE1/PNAMES lumps. I think I had created some superfluous entries, and had been attempted to clean them up when I touched something I shouldn't have.

The only problem is SKINLOW refusing to tile vertically. If I were to create a wall 104 units high (the height of SKINLOW), it displays fine. Any subsequent tiles in a vertical fashion, though, have the border of the texture pushed downwards by roughly 30 or so pixels.
Given that I've never touched the texture, how could this have happened?
(If it's unclear what I mean, I can always post a screenshot.)

The Doom renderer only tiles textures with a height of 128 properly. Even some more modern ports don't tile textures properly that don't have a height that's a power of 2. ZDoom, for example, doesn't.

So, if you need to retain compatibility, you should never try to vertically tile such a texture. There is no guaranteed behavior. Even in ZDoom you can't rely on it because GZDoom tiles everything properly thanks to the internal workings of 3D graphics hardware.