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

Any utility that assists in the creation of mods, assets, etc, go here.
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.

Please read the full rules for more details.

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

Postby Plut0nio » Mon Jun 08, 2020 9:17 pm

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.
User avatar
Plut0nio
 
Joined: 09 Jun 2020
Discord: Plut0nio#5930
Twitch ID: Plut0nio
Github ID: Plut0nio
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: ATI/AMD with Vulkan Support

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

Postby sirjuddington » Wed Jul 08, 2020 9:31 pm

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).
User avatar
sirjuddington
 
Joined: 16 Jul 2003
Location: Australia
Discord: sirjuddington#7496
Github ID: sirjuddington

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

Postby NiGHTMARE » Thu Jul 09, 2020 4:56 am

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?
NiGHTMARE
.now.
 
Joined: 19 Jul 2003

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

Postby Enjay » Thu Jul 09, 2020 6:41 am

sirjuddington wrote: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. :thumb:
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

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

Postby Blue Shadow » Thu Jul 09, 2020 7:53 am

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

Code: Select allExpand 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:

User avatar
Blue Shadow
 
 
 
Joined: 14 Nov 2010
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: ATI/AMD (Modern GZDoom)

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

Postby Enjay » Thu Jul 09, 2020 8:59 am

Are you sure that you didn't select 7124513221146312704 other entries that you just forgot about? :lol:
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

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

Postby SweetTooth » Sun Jul 12, 2020 12:58 am

Any chance a dark windows theme will be added in the new beta?
User avatar
SweetTooth
 
Joined: 12 Jul 2020

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

Postby sirjuddington » Sun Jul 12, 2020 8:04 pm

NiGHTMARE wrote: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.

SweetTooth wrote: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.
User avatar
sirjuddington
 
Joined: 16 Jul 2003
Location: Australia
Discord: sirjuddington#7496
Github ID: sirjuddington

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

Postby NiGHTMARE » Mon Jul 13, 2020 5:37 am

sirjuddington wrote:
NiGHTMARE wrote: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.
NiGHTMARE
.now.
 
Joined: 19 Jul 2003

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

Postby Gothic » Tue Jul 14, 2020 4:58 pm

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?
You do not have the required permissions to view the files attached to this post.
User avatar
Gothic
To be fair, you have to have a very high IQ to understand ZScript.
 
Joined: 17 Jun 2011
Location: Where it all began...
Discord: #1462

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

Postby SanyaWaffles » Tue Jul 14, 2020 5:32 pm

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)
User avatar
SanyaWaffles
Navy Did Nothing Wrong
 
Joined: 25 Apr 2013
Location: Eastern Ohio
Discord: SanyaWaffles#5095
Twitch ID: sanyawaffles
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

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

Postby Marisa Kirisame » Fri Jul 24, 2020 1:45 am

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.
User avatar
Marisa Kirisame
ZScript Crimester
 
 
 
Joined: 08 Feb 2008
Location: Vigo, Galicia
Discord: 霧雨魔理沙#1666
Twitch ID: magusmarisa
Github ID: OrdinaryMagician
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

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

Postby Kappes Buur » Tue Aug 25, 2020 2:00 am

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:
Spoiler:

Slade 3.2.0 Beta 2
User avatar
Kappes Buur
 
 
 
Joined: 17 Jul 2003
Location: British Columbia, Canada

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

Postby wrkq » Tue Aug 25, 2020 12:52 pm

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.
wrkq
 
Joined: 02 Apr 2016

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

Postby Marisa Kirisame » Sat Aug 29, 2020 12:12 pm

SLADE gradually becoming slower over time is a known bug, and it seems to be quite hard to get it fixed.
User avatar
Marisa Kirisame
ZScript Crimester
 
 
 
Joined: 08 Feb 2008
Location: Vigo, Galicia
Discord: 霧雨魔理沙#1666
Twitch ID: magusmarisa
Github ID: OrdinaryMagician
Operating System: Other Linux 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

PreviousNext

Return to Editors / Asset Manipulation

Who is online

Users browsing this forum: No registered users and 0 guests