Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Shadow Hog

SLADE has issues with carets (^), turns them into backslashes

Recommended Posts

Exactly what it says on the tin. If a lump name has a caret (^) in it, it becomes a backslash (\). So, for example:

[00:31:02] <+JTE> ... KNUX^1 KNUX^2^8 KNUX^3^7 became KNUX\1 KNUX\2^8 KNUX\3^7
(That's technically incorrect; it becomes "KNUX\2\8", "KNUX\3\7", etc)

This is actually kind of annoying, because SRB2 character sprites have so many frames, they run through every ASCII character between "A" (0x41) and "f" (0x66), carets falling in that range (0x5E).

This change only happens when renaming a lump; SLADE can display lumps with carets in them correctly. However, if I were to rename "PLAY^1" to, say, "PLOY^1", I'll instead get "PLOY\1". Ctrl-Z to undo, and while "PLOY" becomes "PLAY" again, the end result will be "PLAY\1", which is still different from the original input lump name.

Tested on SLADE v3.1.0 beta 1.

Share this post


Link to post

It's a feature! This was actually needed to allow copy/pasting of entries between WADs and ZIPs without losing half of the sprite lump name. Entries with a \ have it changed to a ^ in a zip file, and inversely entries with a ^ have it changed to a \ in a wad file. This is default behavior because it's compatible with ZDoom.

Type "percent_encoding 1" in the console and it shouldn't happen anymore. Instead, what will be translated will be names with percent encoding in them (%##, where ## is the hexadecimal ASCII code of the character, e.g. "%5C" for "\").

Share this post


Link to post

One piece of advice: You'll never know what tools your data will be used with - so better do not make this stuff case sensitive. Lots of tools out there will happily 'fix' your 'broken' lump names without even asking.


Instead of having one sprite with 40+ frames, better split it into two sprites, just like Hexen did with actors having too many frames.


As this example shows, even using the backslash as a valid frame character already was a problem because it can't be used as a valid character in zips' filenames.

Share this post


Link to post

Wait, I mistakenly thought lumps are case insensitive in Doom? Damn.

I know textures (and maybe flats) are case insensitive, that's for sure.

Share this post


Link to post

They are case-insensitive in most Doom engines. SRB2, however, isn't most Doom engines.

Enforcing uppercaps in WAD files is already a togglable option in SLADE, though (wad_force_uppercase CVAR).

Share this post


Link to post

I would like to point out that SLADE assuming the ZDoom convention when dealing with ^ (and others?) characters is obviously only correct for mods targeting ZDoom (or a derivative thereof). Other ports handle this in different ways. Doomsday for example uses a percent-encoded form, allowing *any* character to be used in a lump name.

Share this post


Link to post

Doomsday is actually the reason why I added the percent_encoding CVAR in the first place.

Regardless of the method used, something is needed to deal with the fact that ZIPs cannot handle filenames containing \ (or /, by the way). If you write an entry named VILE\1.lmp in a ZIP file, upon opening it back, you'll find out that you now have a VILE directory which contains a file named 1.lmp.

Share this post


Link to post
DaniJ said:

I would like to point out that SLADE assuming the ZDoom convention when dealing with ^ (and others?) characters is obviously only correct for mods targeting ZDoom (or a derivative thereof). Other ports handle this in different ways. Doomsday for example uses a percent-encoded form, allowing *any* character to be used in a lump name.

How do the escapes fit in the 8 character limit?

Share this post


Link to post
Gez said:

Regardless of the method used, something is needed to deal with the fact that ZIPs cannot handle filenames containing \ (or /, by the way)

Obviously. Hence why Doomsday applies the convention: WAD lump directories are not encoded on disk but will be auto-encoded when indexed by the file system, ZIP file indexes are assumed to use a percent-encoded form to begin with.

I added the percent_encoding CVAR

I'm glad to hear it (I wasn't aware this CVAR existed; I tried SLADE years ago but dismissed it after finding it inconvenient because of stuff like this. I should try SLADE again...).

Share this post


Link to post
printz said:

How do the escapes fit in the 8 character limit?

They don't. The length limit only applies to WADs, not to ZIPs.

DaniJ said:

I'm glad to hear it (I wasn't aware this CVAR existed; I tried SLADE years ago but dismissed it after finding it inconvenient because of stuff like this. I should try SLADE again...).


I guess I forgot to mention it back then, but I did.

Share this post


Link to post
DaniJ said:

I would like to point out that SLADE assuming the ZDoom convention when dealing with ^ (and others?) characters is obviously only correct for mods targeting ZDoom (or a derivative thereof).


Obviously the setting should default to the most used engine, shouldn't it? And there's no doubt that this is ZDoom.

As for file name encoding, the backslash in sprite names is really the only character that requires special handling so why cook up a more elaborate scheme if it serves no purpose?

Share this post


Link to post

Graf Zahl said:
Obviously the setting should default to the most used engine, shouldn't it? And there's no doubt that this is ZDoom.

It should apply the corresponding behavior depending on what engine a WAD project is for, which can be asked for any new WAD edited or maybe also forced explicitly and in general by the user in the first use. Otherwise it just becomes a way to make it hard for people designing outside of ZDoom to use SLADE, or it pushes them to give up alternate engines of choice.

One of Boom's bigger flaws was that it didn't clearly distinguish Boom WADs, thus encouraging Boomisms, and then this continued through other engines like ZDoom with ZDoomisms.

Granted, we can only see this clearly now after years and it's unreasonable to assume the coders could have foreseen it as an issue, but should tools today commit more or less the same mistakes now that we know better?

As for file name encoding, the backslash in sprite names is really the only character that requires special handling so why cook up a more elaborate scheme if it serves no purpose?

If I'm not mistaken, it could wreck some things which rely on a sprite that gets renamed through SLADE.

Share this post


Link to post
myk said:

It should apply the corresponding behavior depending on what engine a WAD project is for.


Of course there should be a setting for the engine - but you still need a default. And for PK3 editing that default still would have to be ZDoom, due to higher popularity.

Asking for every WAD to be opened seems a bit like overkill, especially since there's no defined way to save engine info along with a WAD/Zip.

Share this post


Link to post

This is kind of a pointless tangent. I am not interested in debating which option is the most correct. Besides, in most cases, this will not be important, since I suppose the most popular modding target remains purely WAD format, without using extra characters beyond [\].

I suppose the percent_encoding option could be added as a checkbox on the configuration wizard, because it's rather obscure at the moment (otherwise this thread wouldn't exist in the first place).

Share this post


Link to post
Graf Zahl said:

As for file name encoding, the backslash in sprite names is really the only character that requires special handling so why cook up a more elaborate scheme if it serves no purpose?

It serves a purpose; it solves the issue in question and does so through the application of a resource naming standard everyone who uses the internet is likely already familiar with and uses on a daily basis.

Sorry if you think this is a sledgehammer cracking a walnut but Doomsday uses URIs throughout as a uniform way to reference all resources and the percent encoding standard applies everywhere.

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
Sign in to follow this  
×