Wads.ReadLump quirks

[JPL]

I'm making a mod with some non-trivial UI work and found myself wanting to be able to tune layout numbers live (ie without rebooting GZDoom). I remembered that ZScript can read lump data via Wads.ReadLump and wondered if it could read changes made to a file (in a directory-as-PK3, rather than from a PK3) at runtime. Sure enough it did. However, I discovered that ReadLump also has some quirks, and I'd like to know if they're intended behavior, a bug, or just something I'm not using properly.

Here's my EventHandler code that reads in the lump and sets variables from it:

Code: Select all

class LiveTuningHandler : EventHandler
{
	const ENABLE_LIVE_TUNE = 1; // set to 0 before release
	
	const LIVE_TUNE_FILE = "testlump.txt"; // this works
	// const LIVE_TUNE_FILE = "tuning.txt"; // this doesn't, WTF?!
	
	double liveValue0;
	double liveValue1;
	double liveValue2;
	double liveValue3;
	
	override void WorldTick()
	{
		if ( !ENABLE_LIVE_TUNE )
		   return;
		String lumpData = Wads.ReadLump(Wads.FindLump(LIVE_TUNE_FILE));
		// split lump data into lines (assume unix style line breaks)
		Array<String> lines;
		lumpData.Split(lines, "\n", TOK_KEEPEMPTY);
		// bail if we don't have enough lines to read from
		if ( lines.Size() < 9 )
		{
			Console.Printf("%i lines in %s, expected 9!", lines.Size(), LIVE_TUNE_FILE);
			return;
		}
		// hard-code line #s to read from; this is dev-only anyway
		liveValue0 = lines[2].ToDouble();
		liveValue1 = lines[4].ToDouble();
		liveValue2 = lines[6].ToDouble();
		liveValue3 = lines[8].ToDouble();
		Console.Printf("%f, %f, %f, %f", liveValue0, liveValue1, liveValue2, liveValue3);
	}
}

and here's the text lump it's reading from:

Code: Select all

// live tuning file - edit very carefully!
// liveValue0:
0.00008
// liveValue1:
314.777777
// liveValue2:
0451
// liveValue3:
1337

As noted in the comments, when LIVE_TUNE_FILE is set to a file called "testlump.txt", it successfully reads in all the lines, but when LIVE_TUNE_FILE is set to identical file called "tuning.txt", it only reads in a single whitespace character! That doesn't seem right.

I've noticed some other quirks with how data comes through the read operation, but none of them as reproducible as that.

Has anyone tried anything like this before, and/or encountered strange or broken behavior with Wads.ReadLump?

[_mental_]

Please post a runnable sample.

[JPL]

Please post a runnable sample.

The code posted above is all there is to it, save for the usual mapinfo line that adds the EventHandler. But here's a PK3 for convenience. (attached)

When you launch, you should see 4 floating point numbers logging to the screen. If you edit zscript.txt in the file and comment out the first declaration of LIVE_TUNE_FILE on line 8 and uncomment the line after it, you'll see an error message instead indicating that the file wasn't read from properly. That's the behavior that seems broken.

[_mental_]

ReadLump() works fine, you need to check value returned from FindLump() function. It will be -1 in the second case.
The thing is FindLump() expects a short name, i.e. up to 8 characters without extension. So tuning.txt is treated like tuning.t short name. That’s why it wasn’t found.
If you want to ask to change this behavior I will disappoint you. This was already requested and rejected.

[JPL]

ReadLump() works fine, you need to check value returned from FindLump() function. It will be -1 in the second case.
The thing is FindLump() expects a short name, i.e. up to 8 characters without extension. So tuning.txt is treated like tuning.t short name. That’s why it wasn’t found.
If you want to ask to change this behavior I will disappoint you. This was already requested and rejected.

LOL. That's terrible but thanks for letting me know! I'm guessing that's common in some native code but I hadn't yet encountered anything else in ZScript that works like that.