SLADE icon indicating copy to clipboard operation
SLADE copied to clipboard

Crashing when browsing textures in map editor

Open inventor200 opened this issue 3 years ago • 6 comments

SLADE Version: 3.2.0 Operating System: Ubuntu 22.04

Issue Details: So far this has only happened in visual mode, but I added a bunch of textures to my project (which is currently being edited from a directory). I'm scrolling through a list of them to edit the front texture of a wall, and once I cross the gray textures, the whole program just exits spontaneously. I can't find an error log in Slade's directory.

I'm not sure how to narrow this down any further, so if you have tests for me to run, I'll write back to you here.

inventor200 avatar May 03 '22 08:05 inventor200

UPDATE: I've made a backup of my project so that I can access the exact state my map was in when the crash happened.

However, I opened up Ultimate DoomBuilder 2 on a windows VM and pushed through a lot of lag to make a few edits to the primary copy of the map. In DoomBuilder, I have discovered that there were some invalid textures, so I went back into Slade and cleaned those up. This didn't fix the issue, though, and the crash happened again.

I ran Slade in a terminal to see if anything would be logged there, but all I got after the crash was Segmentation fault (core dumped), which might as well be the C/C++ version of a shrug. So while this does not narrow it down much, I hope it's at least something. Nothing else was logged to the terminal during the recreation.

inventor200 avatar May 03 '22 08:05 inventor200

UPDATE: I have invited you as a collaborator for the mapping project on GitHub, so you can download the contents for testing, if need be.

inventor200 avatar May 03 '22 09:05 inventor200

This is happening because you have two textures that use eachother as patches (N_GRBR05 and N_GRBR13) which is causing an infinite loop. Does running it in gzdoom show an error in the console or anything? I'm wondering how it deals with these textures.

sirjuddington avatar May 03 '22 11:05 sirjuddington

...huh! Well, GZDoom doesn't bat an eye. No warnings or errors or anything in the console. This is probably what I get for amassing a bunch of textures packs together and trying to condense them in a single TEXTURES entry.

EDIT: Trying this on Ultimate Doom Builder and it's resolving two separate textures without any issue. Not sure how it decides to break the loop tho.

EDIT 2: I wonder if I have textures and patches that share names, and GZDoom and UDB are strictly checking for patch names and never using textures as patches.

inventor200 avatar May 03 '22 13:05 inventor200

I think I figured it out. There are patches by those names, but the TEXTURES entry defines a texture by the same name. The textures directory, however, does not contain this; those textures are only assembled with patches.

So GZDoom and UDB are probably restricting their scopes to only accept patches, and don't look for other textures by the same name.

Basically, if a texture needs a patch by some name, it will only accept patches (probably from the patches directory). If a texture has that name, it will not be used as a patch and will be skipped.

inventor200 avatar May 03 '22 13:05 inventor200

Possible workaround: replace instances of Texture "N_******" with Texture "NT******" to specify the name as a texture.

UPDATE: Moved the project over to the Linux computer after doing the texture name replacements. Crash bug has disappeared; workaround seems to have worked!

inventor200 avatar May 03 '22 13:05 inventor200