#define "string" broken in libraries

[GooberMan]

Using version zdoom-2.8pre-526-g004cf57

Took a while to work out what it was exactly. But it seems that if a script from a library (in my case a script launched from a library ENTER script) tries to read a user cvar when a map has a BEHAVIOR lump it fails and returns 0. Maps without BEHAVIOR read the cvar correctly.

I don't have a simpler example right now, but this is a packaged version of Z-Kart with just the relevant maps for the bug in it. Load up the kart testing ground from the new game menu. Third person camera works fine, and the readout shows MaxCameraDistance working just fine. Load up the return to hell cup and you'll see the third person camera working wrong and the MaxCameraDistance readout showing 0.

EDIT: As Edward points out below, the problem is nothing to do with cvars.

[edward850]

Well hang on, I'm sure I have played DoomRPG with maps that have scripts before, and that has copious amounts of User CVar checks. Something doesn't seem right about this.

[GooberMan]

Yeah, it's only my script that's compiled in the kartphysics library. Does Doom RPG do user cvar checks from library scripts launched from a library ENTER script?

[edward850]

I'll have to check. I'll run through some test tomorrow and see what I come up with.

[edward850]

This isn't a bug with usercvars, but rather one with the ACSVM itself, it seems. Your defined string constants are being destroyed when loaded on top of another script, which means all getcvar is seeing is a NULL string. If you use "cl_camdist" manually instead of CVAR_CAMERADISTANCE, everything works as expected. Can't really say why this is happening, though.

[GooberMan]

Alright, updated the topic to match this new information.

[Blzut3]

Off hand, I'm thinking this is going to be "Switch to DH-acc" where you have a real preprocessor.

[randi]

Fixed.