ZDoom

The self == stateowner check is now [git=944ae2bc09497f52ad6e81354b4f74bc6ece67d5]restricted to action functions[/git], so it won't crash Damage functions. The other problem has been [git=efc9ed2fe9685a448af32065935eb33228c011c3]fixed[/git] too.

[quote="Major Cooke"]Using A_SetUserVar, that works from weapons to player.[/quote]
I don't see why that shouldn't work as described, since it works on self, just like every other function called from a weapon state. Don't consider A_SetUserVar and operator= as equivalent, since they're not. The former is resolved at compile time, and the latter is resolved at runtime.

[quote="Vaecrius"][code]actor zimpball:doomimpball replaces doomimpball{
var int user_blah;
damage(1+user_blah)
states{
spawn:
TNT1 A 0 nodelay{
user_blah=100;
}goto super::spawn
}
}[/code][/quote]
Looking at the code generated for the spawn state here, I think it should be safe to omit the self==stateowner check for any actors that aren't inventory items, since those are the only ones that could possibly be called with them different.

actor D : rocket
{
	Damage (bool(A_JumpIf(true, "crashes")))
}

This isn't the only place where damage expressions are problematic with this anyways:
[code]actor D : rocket
{
Damage (bool(A_JumpIf(true, "crashes")))
}[/code]
The actor D will crash the game when it explodes.

[quote="Vaecrius"]Was this supposed to [url=http://forum.zdoom.org/viewtopic.php?f=3&t=21885&p=941581&hilit=vm+self+pointer#p941581]break projectiles that use uservars in their damage definition[/url]? If so, why, given they don't involve weapons or custominventory?[/quote]
This FxClassMember change is generating bad code for damage expressions, because those don't have a callingstate parameter, but it generates code to try to compare against it anyway.

[quote="Vaecrius"][examples here][/quote]
I think I already know what's happening.
This doesn't actually trigger because of your decorate code, I think it triggers when the damage is calculated (which is done within the VM) and since there is no stateowner pointer passed to the damage vmfunction call the error is triggered.
To test this you could just put the damage on a missile and make it explode, see if the error shows.

That should work, so please report a new bug.

actor zimpball:doomimpball replaces doomimpball{
	var int user_blah;
	damage(user_blah+1)
	states{
	spawn:
		TNT1 A 0 nodelay A_SetUserVar(user_blah,100)
		goto super::spawn
	}
}

actor zimpball:doomimpball replaces doomimpball{
	var int user_blah;
	damage(1+user_blah)
	states{
	spawn:
		TNT1 A 0 nodelay{
			user_blah=100;
		}goto super::spawn
	}
}

What would be proper?

Both this[code]actor zimpball:doomimpball replaces doomimpball{
var int user_blah;
damage(user_blah+1)
states{
spawn:
TNT1 A 0 nodelay A_SetUserVar(user_blah,100)
goto super::spawn
}
}[/code]and this[code]actor zimpball:doomimpball replaces doomimpball{
var int user_blah;
damage(1+user_blah)
states{
spawn:
TNT1 A 0 nodelay{
user_blah=100;
}goto super::spawn
}
}[/code]trigger the error and abort.

In that case, probably because their calling info is not set up properly.

From all the complaints so far, it seems that only that particular function aborts.

Was this supposed to [url=http://forum.zdoom.org/viewtopic.php?f=3&t=21885&p=941581&hilit=vm+self+pointer#p941581]break projectiles that use uservars in their damage definition[/url]? If so, why, given they don't involve weapons or custominventory?

So, curious, [url=https://github.com/rheit/zdoom/pull/801/files]by abort[/url], does that mean it shuts down the game (go to console) or does it just reject doing that specific thing from happening?

It still was a bad, shortsighted decision then.

[quote="Graf Zahl"]Yeah, well, thank you for abusing something that was never meant to work that way...
The entire thing is broken, everybody knows it and yet people depend on the broken behavior, making a fix impossible. :( Ever since this got reported the first time the one issue that prevented us from addressing it is modders' insistence on abusing every single glitch they find.[/quote]

I didn't see it as abuse since randi made it possible. >.>;

Updated the PR: I simplified the check and fixed the problem I mentioned previously.

if (self != stateowner)
{
    if (variable_address outside of range for AActor)
    {
        throw an error;
    }
}

FYI, I committed the rest of this PR but left out the self check for now.

And what a check really should do is something along:

[code]
if (self != stateowner)
{
if (variable_address outside of range for AActor)
{
throw an error;
}
}
[/code]

But can it be done in a less costly manner? Your attempt of a fix adds a lot of code for each variable access which may actually cause performance issues because this can happen so often.


I hope that for the real scripting language a better solution can be found.

[quote="Major Cooke"]I utilize A_SetUserVar for weapons setting user variables on the player directly in D4D.[/quote]


Yeah, well, thank you for abusing something that was never meant to work that way...
The entire thing is broken, everybody knows it and yet people depend on the broken behavior, making a fix impossible. :( Ever since this got reported the first time the one issue that prevented us from addressing it is modders' insistence on abusing every single glitch they find.

Using A_SetUserVar, that works from weapons to player.