SLADE Discussion - Latest: v3.1.12 (26/May/2020)

[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 • Expand view

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:

[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.



Also this is a problem that may not be on Slade's end, but I guess asking doesn't hurt:
I use Realtek Audio as my sound driver, but a recent update screwed something up and the audio sounds awful unless I enable Multistreaming, which solves the quality audio issue and I believe it got better in certain areas. However, there are other programs that still sound low quality, including Raze, YamagiQuake and unfortunately the one I use the most, Slade3. I have 2 audio samples here that show how bad the audio dropped. The file "Audio Test.ogg" is how it should sound, and how it played before Realtek updated, and the file "Audio Test (recorded).ogg" is how it currently sounds when Slade3 plays it.

Audio Test.zip

Audio Test (recorded).zip

All audio files sound like this, except for MIDI.

So my question is: Is this something worth checking in, or is it something I should solve on my own?

[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 Kirisame]

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.