Slade - exploded PK3: ACS compile causes Slade to crash

[smeghammer]

So - I've been experimenting with building a mapset as a PK3 rather than a WAD file. Definitely like the proper namespacing - soothes the programmer in me...

 

Anyway, I think I have come across a bug(?) in Slade.

 

My workflow is:

 - edit the actual .wad files in the /Maps/ sub-folder in Eureka or UDB (unzipped filestructure)

 - edit resources in relevant sub-folders in Slade3 (unzipped filestructure)

 - compress using Windows built-in zip option

 - change extension of resulting .zip file to .pk3

 -> play

 

I started adding scripts in the /acs/ subfolder. I looked at an existing .pk3 file and saw that the /acs/ subfolder also contained compiled .o files.

 

OK so the problem:

Slade allows editing of ACS in an uncompressed project /acs/ folder and also offers the compile option. So I thought using this should compile to .o files.

 

However, when I do this, Slade crashes completely with this:

 

 

The crash dump in full:

 

Spoiler

 

Version: 3.1.11
No current action

Operating System: Windows 10 (build 19042), 64-bit edition
Graphics Vendor: OpenGL not initialised
Graphics Hardware: OpenGL not initialised
OpenGL Version: OpenGL not initialised

Stack Trace:
0: (H:\Dev\SLADE\Build\src\Archive\ArchiveEntry.cpp:457) ArchiveEntry::importFile
1: (H:\Dev\SLADE\Build\src\MainEditor\EntryOperations.cpp:1353) EntryOperations::compileACS
2: (H:\Dev\SLADE\Build\src\MainEditor\UI\EntryPanel\TextEntryPanel.cpp:358) TextEntryPanel::handleEntryPanelAction
3: (H:\Dev\SLADE\Build\src\MainEditor\UI\EntryPanel\EntryPanel.h:72) EntryPanel::handleAction
4: (H:\Dev\SLADE\Build\src\General\SAction.cpp:529) SActionHandler::doAction
5: (H:\Dev\SLADE\Build\src\UI\SToolBar\SToolBarButton.cpp:398) SToolBarButton::onMouseEvent
6: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\common\appbase.cpp:658) wxAppConsoleBase::HandleEvent
7: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\common\appbase.cpp:669) wxAppConsoleBase::CallEventHandler
8: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\common\event.cpp:1416) wxEvtHandler::ProcessEventIfMatchesId
9: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\common\event.cpp:1887) wxEvtHandler::SearchDynamicEventTable
10: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\include\wx\event.h:3912) wxEvtHandler::TryBeforeAndHere
11: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\common\event.cpp:1518) wxEvtHandler::ProcessEvent
12: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\common\event.cpp:1646) wxEvtHandler::SafelyProcessEvent
13: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\msw\window.cpp:5871) wxWindow::HandleMouseEvent
14: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\msw\window.cpp:3158) wxWindow::MSWHandleMessage
15: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\msw\window.cpp:3873) wxWindow::MSWWindowProc
16: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\msw\window.cpp:2940) wxWndProc
17: [unknown location] AddClipboardFormatListener
18: [unknown location] GetClassLongW
19: [unknown location] DispatchMessageW
20: [unknown location] IsDialogMessageW
21: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\msw\window.cpp:2689) wxWindow::MSWProcessMessage
22: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\msw\evtloop.cpp:145) wxGUIEventLoop::PreProcessMessage
23: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\msw\evtloop.cpp:163) wxGUIEventLoop::ProcessMessage
24: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\msw\evtloop.cpp:230) wxGUIEventLoop::Dispatch
25: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\common\evtloopcmn.cpp:242) wxEventLoopManual::ProcessEvents
26: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\common\evtloopcmn.cpp:283) wxEventLoopManual::DoRun
27: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\common\evtloopcmn.cpp:90) wxEventLoopBase::Run
28: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\common\appbase.cpp:380) wxAppConsoleBase::MainLoop
29: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\common\init.cpp:507) wxEntryReal
30: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\msw\main.cpp:184) wxEntry
31: (H:\Dev\vcpkg\buildtrees\wxwidgets\src\v3.1.3-91ca46db88\src\msw\main.cpp:305) wxEntry
32: (H:\Dev\SLADE\Build\src\Application\SLADEWxApp.cpp:477) WinMain
33: (d:\agent\_work\6\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288) __scrt_common_main_seh
34: [unknown location] BaseThreadInitThunk
35: [unknown location] RtlGetAppContainerNamedObjectPath
36: [unknown location] RtlGetAppContainerNamedObjectPath

Last Log Messages:

This is version 1.56 (Dec 27 2018)
This software is not supported by Raven Software or Activision
ZDoom changes and language extensions by Randy Heit
Further changes by Brad Carney
Even more changes by James Bentler
Some additions by Michael "Necromage" Weber
Error reporting improvements and limit expansion by Ty Halderman
Include paths added by Pascal vd Heiden
Error: File 'C:\Users\smegh\AppData\Roaming\SLADE3\temp\myscripts.acs' couldn't be removed (error 2: The system cannot find the file specified.)

 

 

However, if I first compress the project files/folders to a ZIP -> .pk3 file,  open that in Slade and then compile, there are no issues...

 

I haven't tried this exact workflow on Ubuntu yet - I'll update when I do.

 

Any thoughts on this?

 

 

  

Edited January 4, 2021 by smeghammer

[Kappes Buur]

Not sure if this will fit the bill, but it is worth a look

https://forum.zdoom.org/viewtopic.php?f=37&t=25083&p=480622

[smeghammer]

12 minutes ago, Kappes Buur said:

Not sure if this will fit the bill, but it is worth a look

https://forum.zdoom.org/viewtopic.php?f=37&t=25083&p=480622

 

Mmm! Yes that looks interesting! Thanks. I'll have a proper dig into that lot. It would definitely be useful to be able to compile the ACS without having to convert to .pk3 first.

[smeghammer]

OK I have a simple workaround for this.  I created a batch file, pointing at my acc.exe, with a repeated % argument and pointing at the include files:

 

C:\Games\Doom\ACC\acc.exe -i C:\Games\Doom\ACC %1 %1

(or you could put acc.exe in the PATH)

 

This batch file is in the same directory as my acs source.

 

The key is a dummy file, with NO extension, that has the same name as the acs source file. Turns out that ACC assumes the .acs and .o extensions for the two arguments if they are not specified:

 

 

I can drop the dummy file onto the batch file and the compiled .o file is created and I can then drop the entire project folder (here, /src/*) onto GZDoom and the script will work.

 

 

** DON'T drop the .acs file or you will end up with a .acs file that is compiled, and lose the acs source code!! **

 

 

 

 

Edited January 4, 2021 by smeghammer

[Nevander]

Not sure if this helps but when I compile ACS with SLADE, I prefer doing it with an empty template PK3 with nothing else in it except the ACS folder. I copy my source and compile. Once compiled, I copy those files to my real PK3/WAD. I guess I don't trust SLADE to do it right when all my other project files are there too.

Edited January 5, 2021 by Nevander

[smeghammer]

16 hours ago, Nevander said:

Not sure if this helps but when I compile ACS with SLADE, I prefer doing it with an empty template PK3 with nothing else in it except the ACS folder. I copy my source and compile. Once compiled, I copy those files to my real PK3/WAD. I guess I don't trust SLADE to do it right when all my other project files are there too.

 

Yeah that's a good idea. I was certainly uncomfortable with mucking about with the compressed PK3 - My gut feeling is that once the PK3 is made, it should be read-only. I was quite please when I figured out the workaround with the dummy file and acc.exe on the exploded directory structure, and if things do fuck up, I can restore from my github repo..