Welcome to the ZDoom Forums!

Thanks, I missed that when I went through the example wad.

A missing #library statement is a user error. A library without this will inevitably have problems with string references.
And that's exactly what's missing in the linked code.

Strange, this may be the reason some of my mods' string-related features have been breaking in Zandronum 2.0 (I would like to note that they do not break in Zan 3.0 or the latest versions of ZDoom/GZDoom, so it may be an unrelated bug causing that)

Edit: Looking at the bug report, adding a #library definition fixes it, which is exactly what fixed those issues for me in Zan 2.0, so maybe it's the same bug. In that case, I don't think this is present in current versions of ZDoom.

http://zandronum.com/tracker/view.php?id=1307
http://zandronum.com/tracker/file_download.php?file_id=953&type=bug

[quote="Ijon Tichy"]
This is a weird bug. When StrParam doesn't come into play, ACS libraries have their own string table, and things work fine. However, when StrParam is used and a map with ACS is opened, ACS libraries suddenly decide that using their own string table makes too much sense, and instead, they use the string table that the BEHAVIOR lump is using. This fails miserably. Every single string in the library changes values, and this ends up leading to a crash with libraries such as stralloc.h (to be attached).

1. Load Zandronum with strparambroken.pk3.
2. "map map01"
3. Hit the switches on the metal textures. The strings for these are provided by BEHAVIOR, and StrParam works as expected. (Should print "StrParam BEHAVIOR" and "Static BEHAVIOR")
4. Hit the switches on the stone textures. The strings for theses are provided by LOADACS... or would be if it didn't break. They print the exact same things the metal switches do (instead of "StrParam LOADACS" and "Static LOADACS").
[/quote]