The Official DoomTools Thread

[MTrop]

Not currently. Maybe an enhancement for the future?

[tewgytaylor]

On 11/26/2023 at 11:10 PM, MTrop said:

A small oversight I had when running your project from DoomTools was that the first argument after doommake run was going to be a specific port name to use when fetching the correct properties from doommake.properties. After that first argument, though, you can pass as many arguments to the executable as you want.

I see, that would explain it then. I still feel like a more obvious complevel switch would be a good idea for the future, even though admittedly it would just be a very small QOL feature

 

Edit: coming back to say having a way to run with whatever arguments I want is actually quite nice even if I don't personally enjoy using command line all too much, so while I still think adding to the gui wouldn't be a bad idea, this method also works wonders especially when testing in multiple ports

Edited November 29, 2023 by tewgytaylor

[Giomancer]

On 11/21/2023 at 8:06 PM, MTrop said:

I think there has to be an argument after "-i", which is the directory. Line 3 works because the "null" adds an argument after "-i", as expected. Your specified directory may not be included, after all.

Aha! What happened, as it turns out, is that I "got lucky"; I discovered that acc was just including the default files, which would have been great until I added global variables. The fixed snippet looks like this:

Spoiler

each (acsFile : acsList) {
    args = ["-i", includeDir, acsFile];
    if(booldebug) {
        debugACS = filenamenoext(acsFile) + ".debug";
        args->listadd("-d" + debugACS, 2); }
    execresult(exec(exePath, args, envvars(), exeWorkDir, logOStream, errOStream, null)); }

 

Thanks for explaining what was up!

Edited November 29, 2023 by Giomancer

[MTrop]

New Release: https://github.com/MTrop/DoomTools/releases/tag/2023.12.07-RELEASE

DoomMake
--------

### Changed for 0.24.0

* `Added` COPYWITHREPLACE function added to DoomMake.

 

[Warden]

Could you give an example of how to mod the Chaingun and work around hardcoded states? I've just been crashing nonstop trying to figure this out. With deh9000, the decorate looks like this: what is the DecoHack equivalent?

[MTrop]

I made a "super-chaingun" for a yet-unreleased mod that uses A_FireCGun. You'll have to make use of explicit state lines or state fill lines in order to set states on specific or from specific spots in the state table:

// ---------------------------------------------------------------------------
// Super Chaingun
// Faster chaingun.
// ---------------------------------------------------------------------------

weapon WP_CHAINGUN free states
state free S_DSNR1 to S_DSNR2 // unused
state free S_STALAG // unused

state free S_CHAINFLASH2 // not referenced in weapon. Must free explicitly.

// The chaingun is the worst to engineer, thanks to A_FireCGun.
// S_CHAIN1 is important for deciding the flash offset.

state fill S_CHAIN
{
	CHGG A 1 A_WeaponReady
	wait
}
state fill S_CHAIN1
{
	CHGG AB 3 A_FireCGun
	goto S_CHAIN3
}
state fill S_CHAINFLASH1
{
	CHGF A 4 Bright A_Light1
	goto S_LIGHTDONE
}
state fill S_CHAINFLASH2
{
	CHGF B 4 Bright A_Light1
	goto S_LIGHTDONE
}
state fill S_CHAIN3
{
	CHGG A 3 A_ReFire
	CHGG B 3 A_LoadShotgun2 // Spin down sound
	CHGG A 3
	CHGG B 4
	CHGG A 5
	CHGG B 7
	goto S_CHAIN
}

weapon WP_CHAINGUN "Super Chaingun"
{
	ammotype AM_CLIP
	clear states
	state ready S_CHAIN
	state fire S_CHAIN1
	state flash S_CHAINFLASH1
	states
	{
		select:
			CHGG A 1 A_Raise2
			loop
		deselect:
			CHGG A 1 A_Lower2
			loop
	}
}

You may not need to free those states beforehand - that was just because I needed some additional states for Vanilla.

 

Also, A_Raise2 and A_Lower2 are just #defined calls to A_Raise and A_Lower twice, respectively. They are not standard calls.

Edited December 11, 2023 by MTrop

[Warden]

That's perfect, thank you!

 

Edited December 11, 2023 by Warden

[MTrop]

New Release: https://github.com/MTrop/DoomTools/releases/tag/2023.12.26-RELEASE

DoomMake
--------

### Changed for 0.25.0

* `Changed` Added Doom Builder autosave ignores to Git and Mercurial ignore files.

 

[MTrop]

New Release: https://github.com/MTrop/DoomTools/releases/tag/2024.01.08-RELEASE

 

You will need to update your shell scripts by typing doomtools --update-shell to take advantage of the new memory usage parameters.

Changes
-------

- **2024-01-05** Added an uncaught exception modal.

- **2023-12-31** Increased maximum memory allocation for shell scripts to 4 GB.

WTEXport
--------

### Changed for 1.5.3

* `Fixed` [GUI] Added message for requiring an output WAD file.

 

[Sikreci]

I've got a weird issue with the Linux (bash) version of DoomTools, I finally invested some effort into investigating the issue and made some discoveries. doomtools --gui works once, and only once, per boot. It launches with no issues, everything works, but if I exit the program it will never run again until I reboot, logging out/in again won't work either. Every subsequent attempt, the log file looks like this:

[2024-02-02 17:54:03.426] (DoomToolsSettingsManager) INFO: Loaded settings from /home/sikreci/DoomTools/settings.properties

Only the one line. The java process seems to be exiting successfully, so it's not a matter of the JVM just sitting around in the background being useless either.

 

Curiously, every other tool besides doomtools that has a gui switch runs just fine over and over again as many times as I want. decohack --gui, wadtexscan --gui, wadmerge --gui, etc., they all open up in a little GUI window just fine, but not doomtools itself.

 

Using OpenJDK 17 on Fedora 38. Any ideas?

Edited February 2 by Sikreci

[MTrop]

The only thing I can think of is that DoomTools GUI opens a local port, 54666, (bound to localhost, so it sits behind the firewall) in order to detect if it is still open so that it can only have one instance of itself running.

 

What happens when you try to doomtools --gui at the shell again? If you get:

DoomTools is already running.

...then that port might be held open by some other process or something in your OS. Terminating DoomTools (and the JVM) should close that port, but if it doesn't, I'm not sure what could be going on.

 

EDIT: The code in question is this, in DoomToolsGUIMain.java:

/**
 * @return true if already running, false if not.
 */
public static boolean isAlreadyRunning()
{
	try {
		instanceSocket = new ServerSocket(INSTANCE_SOCKET_PORT, 50, InetAddress.getByName(null));
		return false;
	} catch (IOException e) {
		return true;
	}
}

So, this means Java will try to open port 54666 (INSTANCE_SOCKET_PORT) with some arbitrary connection backlog bound to localhost (InetAddress.getByName(null)), so that it doesn't try to open the port through the firewall. If it succeeds, DoomTools GUI is not running. If an exception happens (because the port is already open), it thinks DoomTools is already running. I picked an arbitrary port to test for. If anything else on your system opens this port, it will create a false positive.

 

As far as I know, this is the most robust way to detect a single instance of a Java program running across all platforms, but I could be wrong about that. Maybe exclusive file locks could be better? Are those guaranteed to be relinquished on termination?

Edited February 3 by MTrop
Add Java code and explanation.

[Sikreci]

So the socket is definitely getting opened and closed properly as expected. It doesn't think it's already running, in fact it seems to successfully start the program to some extent since it manages to output that one line to the log, but then it just silently fails somewhere along the line.

I borrowed my wife's work computer using PopOS and everything works as expected there, so I'm pretty sure whatever it is is not your fault. There must be something screwy with my system configuration or the OpenJDK builds in the repos I'm using, don't know which.

 

On a possibly related note, how is the standalone JAR release meant to be used? I thought about trying to use that instead of the bash version for testing but trying to run it with java -jar only ever returns "no main manifest attribute, in doomtools-2024.01.08.211409815.jar".

[MTrop]

The JAR contains no manifest because there's several mains in the package:

net.mtrop.doom.tools.DecoHackMain
net.mtrop.doom.tools.DMXConvertMain
net.mtrop.doom.tools.DoomFetchMain
net.mtrop.doom.tools.DoomImageConvertMain
net.mtrop.doom.tools.DoomMakeMain
net.mtrop.doom.tools.DoomToolsMain
net.mtrop.doom.tools.WadMergeMain
net.mtrop.doom.tools.WadScriptMain
net.mtrop.doom.tools.WADTexMain
net.mtrop.doom.tools.WSwAnTablesMain
net.mtrop.doom.tools.WTExportMain
net.mtrop.doom.tools.WTexScanMain
net.mtrop.doom.tools.gui.DoomToolsGUIMain

Each of those correspond to an application, and the shell scripts each point to one of those for execution.

 

They're intended to be command-line apps, but maybe DoomToolsGUIMain should be the default? Hmm...

[Sikreci]

Ah I see. I'm just trying to figure out if there's some way I can get some more output from the JVM or something so I can track this down, but this is really no longer related to DoomTools but rather troubleshooting some kind of OpenJDK configuration issue on my end.

[MTrop]

New Release: https://github.com/MTrop/DoomTools/releases/tag/2024.02.14-RELEASE

Changes
-------

- **2024-02-13** Updated DoomStruct to `2.15.4`. [Changes here.](https://github.com/MTrop/DoomStruct/releases/tag/2.15.4-RELEASE)

DImgConv
--------

### Changed for 1.3.1

* `Fixed` Tall patches not being exported/converted correctly.

 

[plums]

51 minutes ago, MTrop said:

`Fixed` Tall patches not being exported/converted correctly.

Is there a way that you can make patches without adding posts at 128 pixels high? 200px-tall Heretic skies need to be made this way. If not, consider this a humble feature request.

 

Also I can't seem to update with the command-line at the moment.

 

Current version is: 2023.08.02.210425475
Contacting update site...
ERROR: Read error contacting update site: Connection reset

 

Edited February 15 by plums

[MTrop]

All releases 2023.11.14 and earlier need to update manually, as that fixes the updater (Github made a stricter change to their API).

 

Not sure what it does to Heretic skies. I'll have to take a closer look.

Edited February 15 by MTrop

[plums]

11 hours ago, MTrop said:

All releases 2023.11.14 and earlier need to update manually, as that fixes the updater (Github made a stricter change to their API).

Oh thanks. You should update the info on the main DoomTools website:

 

Quote

To update, from version 2021-09-21 and later, you can update DoomTools at the command prompt by typing

 

 

For Heretic skies I extracted a sky from Hexen with SLADE in png form and then ran

dimgconv SKY1.png -o SKY1.wad -p ../heretic.wad

and it gave me this, which looks like it's full of posts (filesize on the lump is huge) and displays extremely poorly in Chocolate Heretic. (Looks fine in GZDoom though :p)

SKY1.wad

Edited February 15 by plums

[MTrop]

New Release: https://github.com/MTrop/DoomTools/releases/tag/2024.02.20-RELEASE

Changes
-------

- **2024-02-19** Updated DoomStruct to `2.15.5`. [Changes here.](https://github.com/MTrop/DoomStruct/releases/tag/2.15.5-RELEASE)

DImgConv
--------

### Changed for 1.3.2

* `Changed` Patches are not split at the first 128 pixels anymore.

I decided that patches that are not rendered fullscreen don't get clipped at 128 in vanilla, so leaving out the clipping code will suffice since those that make vanilla texture patches know to clip them at 128, anyway.

 

The graphics not clipped at 128 still get displayed properly in all ports in fullscreen modes. The code before the tallpatch fix never clipped patches for vanilla, so I think we're still fine.

[MTrop]

New Release: https://github.com/MTrop/DoomTools/releases/tag/2024.02.27-RELEASE

DECOHack
--------

### Changed for 0.31.1

* `Fixed` The Soulsphere, Megasphere, Blur Sphere, and Invulnerability didn't have their `TRANSLUCENT` flag set. (Issue #112)

 

[MTrop]

New Release: https://github.com/MTrop/DoomTools/releases/tag/2024.03.13-RELEASE

EDIT: I should clarify that this fixes some issues with certain entry names in existing WADs.

Changes
-------

- **2024-03-12** Updated DoomStruct to `2.15.6`. [Changes here.](https://github.com/MTrop/DoomStruct/releases/tag/2.15.6-RELEASE)

 

Edited March 15 by MTrop

[MTrop]

New Release: https://github.com/MTrop/DoomTools/releases/tag/2024.05.20-RELEASE

 

The update to DoomStruct fixes some incongruities with Doom Sector reading/writing.

Changes
-------

- **2024-05-19** Updated DoomStruct to `2.15.8`. [Changes here.](https://github.com/MTrop/DoomStruct/releases/tag/2.15.8-RELEASE)

DECOHack
--------

### Changed for 0.31.2

* `Added` `TRANSLATION1` as a valid bit flag for Things.

DoomMake
--------

### Changed for 0.25.1

* `Fixed` [GUI-Studio] Fixed a potential NPE on the file watch service.
* `Fixed` [GUI-Studio] Fix WAD detection on opened files.
* `Fixed` [GUI-Studio] Studio will no longer try to open binary files as text.

 

[MTrop]

New Release: https://github.com/MTrop/DoomTools/releases/tag/2024.06.13-RELEASE

 

DECOHack
--------

### Changed for 0.32.0

* `Fixed` [GUI] Some autocomplete docs fixes/changes.
* `Added` Added more valid string mnemonics to Boom patches (notably, Woof/ZDoom obituaries).

DoomMake
--------

### Changed for 0.26.0

* `Added` DoomMake will check to see if it is already embedded in a project if `--embed` is used.
* `Added` Code in base projects for specifying a "library" IWAD file for CI builds.
* `Changed` New projects that convert assets and textures will build them into the project build directory, and merged from there.
* `Changed` Fixed documentation/comments in the created build scripts.

WadMerge
--------

### Changed for 1.11.0

* `Changed` MERGETEXTUREDIR now works on a "P" namespace if it exists in the target buffer.