SLADE Discussion - Latest: v3.2.5 (19/Dec/2023)

[Plut0nio]

I can't get TiMidity++ to work with the newest SLADE (x64 version). I opened a GitHub issue with more info:

https://github.com/sirjuddington/SLADE/issues/1153

Thanks.

[sirjuddington]

3.2.0 Beta 2 is now up, with a new entry list that displays as a tree structure for archives that support directories (among other things).

[NiGHTMARE]

This may have been reported before (196 pages is a lot to look through!), but I've recently discovered the following:

If you remove (and presumably add) one or more patches from PNAMES without modifying the TEXTUREx lump(s) at the same time, when the changes are saved any textures which reference higher numbered lumps won't be updated and will now be using the wrong patches. If you have both a TEXTURE1 and TEXTURE2 lump and make changes to one but not the other, then the one you've modified will be fine but the other one won't.

I guess this could possibly be fixed by SLADE saving the TEXTUREx lumps whenever you save changes to the PNAMES lump, even if you haven't modified them?

[Enjay]

3.2.0 Beta 2 is now up, with a new entry list that displays as a tree structure for archives that support directories (among other things).

Looks good. The new tree structure seems to work well.

[Blue Shadow]

I'm getting a few "can't convert" warnings on start-up:

Code: Select all

Windows Version: 10.0
SLADE - It's a Doom Editor
Version 3.2.0 beta 2
32bit Windows Build
Written by Simon Judd, 2008-2020
Compiled with wxWidgets 3.1.3 and SFML 2.5.1
--------------------------------
Loading configuration
Loading resources
Looking for #include entry '/' / 'actions/main.cfg'
Looking for #include entry '/' / 'actions/aman.cfg'
Looking for #include entry '/' / 'actions/arch.cfg'
Looking for #include entry '/' / 'actions/pgfx.cfg'
Looking for #include entry '/actions/' / 'pgfx_brush.cfg'
Looking for #include entry '/' / 'actions/aelt.cfg'
Looking for #include entry '/' / 'actions/txed.cfg'
Looking for #include entry '/' / 'actions/anim.cfg'
Looking for #include entry '/' / 'actions/swch.cfg'
Looking for #include entry '/' / 'actions/ppal.cfg'
Looking for #include entry '/' / 'actions/data.cfg'
Looking for #include entry '/' / 'actions/ptxt.cfg'
Looking for #include entry '/' / 'actions/mapw.cfg'
Looking for #include entry '/actions/' / 'mapw_general.cfg'
Looking for #include entry '/actions/' / 'mapw_show.cfg'
Looking for #include entry '/actions/' / 'mapw_line.cfg'
Looking for #include entry '/actions/' / 'mapw_sector.cfg'
Looking for #include entry '/actions/' / 'mapw_script.cfg'
Looking for #include entry '/' / 'actions/scrm.cfg'
Loading icons
Warning: iCCP: known incorrect sRGB profile
Loading entry types
Loading text languages
Can't convert "F1" to a double (invalid)
Loading text style sets
Loading colour configuration
Loading base resource
Base resource loaded
Loading game configurations
SLADE Initialisation OK
Can't convert "-" to an integer (invalid)
Can't convert "\" to an integer (invalid)
Can't convert "[" to an integer (invalid)
Can't convert "[" to an integer (invalid)

---

And another thing: if multiple entries are selected, SLADE erroneously displays how many that are selected:

[imgur]https://i.imgur.com/tHiBftl[/imgur]

[Enjay]

Are you sure that you didn't select 7124513221146312704 other entries that you just forgot about?

[SweetTooth]

Any chance a dark windows theme will be added in the new beta?

[sirjuddington]

This may have been reported before (196 pages is a lot to look through!), but I've recently discovered the following:

If you remove (and presumably add) one or more patches from PNAMES without modifying the TEXTUREx lump(s) at the same time, when the changes are saved any textures which reference higher numbered lumps won't be updated and will now be using the wrong patches. If you have both a TEXTURE1 and TEXTURE2 lump and make changes to one but not the other, then the one you've modified will be fine but the other one won't.

I guess this could possibly be fixed by SLADE saving the TEXTUREx lumps whenever you save changes to the PNAMES lump, even if you haven't modified them?

Do you mean modifying PNAMES via the raw data editor instead of the texture editor? Modifying the raw PNAMES data isn't meant to update TEXTUREx along with it, really any PNAMES editing should be done via the texture editor so everything updates properly.

Any chance a dark windows theme will be added in the new beta?

Can't be done unfortunately, unless Windows adds a dark mode theme for general win32 apps (not a custom one like file explorer has), or I rewrite SLADE entirely using a different UI toolkit like Qt.

[NiGHTMARE]

This may have been reported before (196 pages is a lot to look through!), but I've recently discovered the following:

If you remove (and presumably add) one or more patches from PNAMES without modifying the TEXTUREx lump(s) at the same time, when the changes are saved any textures which reference higher numbered lumps won't be updated and will now be using the wrong patches. If you have both a TEXTURE1 and TEXTURE2 lump and make changes to one but not the other, then the one you've modified will be fine but the other one won't.

I guess this could possibly be fixed by SLADE saving the TEXTUREx lumps whenever you save changes to the PNAMES lump, even if you haven't modified them?

Do you mean modifying PNAMES via the raw data editor instead of the texture editor? Modifying the raw PNAMES data isn't meant to update TEXTUREx along with it, really any PNAMES editing should be done via the texture editor so everything updates properly.

No, this happens when done via the texture editor. Here's an example which can be be recreated via the following steps:

1) Copy TEXTURE, TEXTURE2, and PNAMES from doom.wad to a new wad
2) Edit the new wad's TEXTURE1 via the texture editor and remove the DOOR2_1 patch from BIGDOOR1. Save and close the texture editor.
3) Edit the new wad's PNAMES lump via the texture editor, and delete the DOOR2_1 patch. Save and close the texture editor.
4) Open either TEXTURE1 or TEXTURE2 in the texture editor, and look at pretty any texture to see that it now has the wrong patches!

I've confirmed this is still happening as of v3.2.0 beta 2.

[Gothic]

The latest beta version doesn't show metadata for audio files.

[SanyaWaffles]

According to some people I was talking to, apparently when converting graphics it adds another extension to it (so graphic.png becomes graphic.png.png)

[Marisa the Magician]

Is there any way to make SLADE ignore certain directories? The fonts folder in one of my mods frequently causes it to freeze or take really long to load/save or detect external changes.

[Kappes Buur]

I had left my computer running for several days and I noticed that Slade3 took more and more time to open a wad file, for example DOOM2.wad. Similar to what happened with early versions of Doombuilder2 where some timer was at fault. The latest 'record' was ca 45 secs.

Today I had enough of that and powered down and did a cold reboot. Now DOOM2.wad opens in ca 3 secs.

My specs:

---

[imgur]https://i.imgur.com/szsUKCc[/imgur]

Slade 3.2.0 Beta 2

[wrkq]

Did you keep SLADE open the whole time or were you closing and reopening the program in between?

If the former, try to leave SLADE open for a few days again and every few hours or so note down things the amount of Private Bytes and Handles it has opened to see if it has a leak.
It should clean out when you close it then and work fast again.

If you've been closing SLADE, it's something else on your PC causing some kind of resource hog/leak.
So, take a few snapshots of task manager and compare if some background process like your mouse driver, antivirus engine, or something like that is holding suspiciously high amount of resources after a few days.

[Marisa the Magician]

SLADE gradually becoming slower over time is a known bug, and it seems to be quite hard to get it fixed.