ZDoom

by **Graf Zahl** » Fri Jan 29, 2016 7:15 pm

I concur with 'Can't fix'. With proper scripting this should be doable, but DECORATE is simply insufficient.

by **Major Cooke** » Fri Jan 29, 2016 7:10 pm

Alright I've done some digging. Basically, this sets user variables the same way custominventory items do. I don't think it can be worked around either. It's basically down to: can set, cannot read. So only use user variables on the player actor itself if the jump states are there.

And I don't think there's any way to fix it, really.

I know for a fact those self. and master. bits, those are clearly WFDS.

In general, I think this can be closed as [Can't fix].

See this for more info.

by **Nash** » Mon Aug 18, 2014 4:56 am

ZzZombo wrote:
Phineas Pillylock wrote:I suggest to use something like A_JumpIf(owner.someVariable>0) (owner is actor owns the inventory item), A_JumpIf(target.someVariable>0), A_JumpIf(tracer.someVariable>0), A_JumpIf(master.someVariable>0) (self-descriptive), and let A_JumpIf(self.someVariable>0) to be performed directly on the actor that defined the action pointer. A_JumpIf(someVariable>0) should look first for owner.someVariable if used from an inventory item and if it is not found then look for self.someVariable otherwise just behave the same as self.someVariable. someVariable maybe not only user variable but any Decorate expression that makes sense there, such as ceilingz or health. Hope I wrote it clear.
Ye, Randy, isn't this is exactly what allows to specify what object to reference to?

Wow it's been four years. :O

Whatever is going to be done to address this, I hope it cleanly avoids messing up existing mods because I heavily use user variables and I don't know, I just feel like what I've done is so finnicky and fragile that the slightest change on the executable side might break my mod horribly... :3

by **ZzZombo** » Mon Aug 18, 2014 1:52 am

Phineas Pillylock wrote:I suggest to use something like A_JumpIf(owner.someVariable>0) (owner is actor owns the inventory item), A_JumpIf(target.someVariable>0), A_JumpIf(tracer.someVariable>0), A_JumpIf(master.someVariable>0) (self-descriptive), and let A_JumpIf(self.someVariable>0) to be performed directly on the actor that defined the action pointer. A_JumpIf(someVariable>0) should look first for owner.someVariable if used from an inventory item and if it is not found then look for self.someVariable otherwise just behave the same as self.someVariable. someVariable maybe not only user variable but any Decorate expression that makes sense there, such as ceilingz or health. Hope I wrote it clear.

Ye, Randy, isn't this is exactly what allows to specify what object to reference to?

by **ZzZombo** » Tue Nov 05, 2013 10:03 am

Phineas Pillylock wrote:I suggest to use something like A_JumpIf(owner.someVariable>0) (owner is actor owns the inventory item), A_JumpIf(target.someVariable>0), A_JumpIf(tracer.someVariable>0), A_JumpIf(master.someVariable>0) (self-descriptive), and let A_JumpIf(self.someVariable>0) to be performed directly on the actor that defined the action pointer. A_JumpIf(someVariable>0) should look first for owner.someVariable if used from an inventory item and if it is not found then look for self.someVariable otherwise just behave the same as self.someVariable. someVariable maybe not only user variable but any Decorate expression that makes sense there, such as ceilingz or health. Hope I wrote it clear.

Why can't we get this?

by **Sami** » Sat Jan 19, 2013 3:25 pm

Hi. My name is Sami, and I decided introducing in the world of ACS and Decorate when Zdoom version 2.6.0 was out and so I begin to make a simple mod to try out the features of both languages, but I reached the problem that we all have, the use and access of user_vars in weapons. So googling i was took here and, after reading the replies in the topic, i contemplate the only way to make this to work, and i achieved it!

Before i explain what i did (which is not very difficult, but like the programmer i am i hate it) i will tell you the context of the problem: the playerclass i was doing, a rogue, has a stealth attack in the same weapon (Fire state) he usually uses so it needed a new "stealth state" (entered by the AltFire) in order to attack differently when the player controlling it wanted to. It was obvius that needed a "state" variable so i tried it with no result. Declaring the variable (its name is user_stealth) in the weapon and tried to use "A_SetUserVar" prints a warning error in game "no user_stealth var in the rogue actor". So, understanding the error i declared the variable in the playerclass actor and the error was gone, but when i tried to get variable's value the code didn't compile like yours. It's strange that you can set a variable but you can't get its value. The line that didn't work was this:

Code: Select all

A_JumpIf(user_stealth==1),"StealthFire")

Well, the solution is to access to variable's value via ACS. Its dirty but it's the only way. When you want to get variable's value, like this line:

Code: Select all

A_JumpIf((ACS_ExecuteWithResult(2)==1),"StealthFire")

You have to call the script (in this example, the script 2) that returns variable's value. The script 2 is like this:

Code: Select all

script 2 (void) {
    SetResultValue(GetUserVariable(0,"user_stealth"));
}

It gets the variable "user_stealth" of the TID 0 (the first parameter of GetUserVariable) which is the player. In this case is good to have the variable declared in the player actor, because i dont know how to get the TID of a weapon you have never picked up and i didn't have curiosity of how to get it. The dirty thing is that you need to put that script 2 in all map that may be needed or rather you will have that rogue trying to make a stealthy stab. I hope this helps a little.

And sorry for my english, i'm spanish.

PS: Soon i will post a WIP thread with all what i have done of my mod.

by **Major Cooke** » Sat Sep 01, 2012 1:18 pm

Xaser wrote:Yeah, the trouble is that there's an inconsistency. Action functions called in weapons have always affected the player (see A_GiveInventory and the like), so I would normally consider the bug to be that the player version is not being used every time. This, of course, leads to the "that's not so simple" issue that the variable has to be declared in the weapon for the code to realize that it's valid. So it's a catch-22 -- an incomplete implementation, sorta.

Last time I tried giving a user var to the player class itself and having the weapon do the modifying, it couldn't find it. I may be wrong, though, as it was a long time ago and the details were rather fuzzy...

by **Guest** » Thu Aug 30, 2012 7:44 am

I suggest to use something like A_JumpIf(owner.someVariable>0) (owner is actor owns the inventory item), A_JumpIf(target.someVariable>0), A_JumpIf(tracer.someVariable>0), A_JumpIf(master.someVariable>0) (self-descriptive), and let A_JumpIf(self.someVariable>0) to be performed directly on the actor that defined the action pointer. A_JumpIf(someVariable>0) should look first for owner.someVariable if used from an inventory item and if it is not found then look for self.someVariable otherwise just behave the same as self.someVariable. someVariable maybe not only user variable but any Decorate expression that makes sense there, such as ceilingz or health. Hope I wrote it clear.

by **Xaser** » Mon Jul 09, 2012 1:10 pm

Yeah, the trouble is that there's an inconsistency. Action functions called in weapons have always affected the player (see A_GiveInventory and the like), so I would normally consider the bug to be that the player version is not being used every time. This, of course, leads to the "that's not so simple" issue that the variable has to be declared in the weapon for the code to realize that it's valid. So it's a catch-22 -- an incomplete implementation, sorta.

by **MG_Man** » Sun Jul 08, 2012 11:22 pm

Sorry for 1.5+ year bump, but as of 2.6.0 this still doesn't seem to be resolved.

randi wrote:The problem is that weapon states other than the Spawn state are executed in the context of the player holding the weapon, not in the context of the weapon. Without a way to specify which object's members you want to access, it will always use the ones in the context of the object it was executed in.

Can't the A_SetUserVar and/or A_JumpIf functions be executed in the context of the player then, too?

I'm fine with the variables being always stored in the player. The problem is that all relevant functions related to variables don't seem to realize this when used in weapons, so the end result is that variables simply won't work for weapons. If they were made to check the variables of the player, even in all cases, then the problem would be solved.

by **pkmnfrk** » Sun Dec 05, 2010 2:29 am

I should like to point out that I ran into this bug too, as I reported here (before I realized this thread existed).

Moving the variable to the player class does not work, it simply fails silently. So, I think it's more than just a scoping issue...

by **NeuralStunner** » Tue Nov 09, 2010 8:05 pm

randy wrote:The problem is that weapon states other than the Spawn state are executed in the context of the player holding the weapon, not in the context of the weapon.

How is that different from CustomInventory, which seems to work great?

by **randi** » Tue Nov 09, 2010 7:03 pm

The problem is that weapon states other than the Spawn state are executed in the context of the player holding the weapon, not in the context of the weapon. Without a way to specify which object's members you want to access, it will always use the ones in the context of the object it was executed in.

by **Sir Cyril Fudgelot** » Mon Nov 08, 2010 12:11 am

I would like to bump this tentatively bump this thread again, seconding the above statement, hoping that it gets implemented either one way or the other. I would rejoice to see it reconciled, and my wad would continue forward.

by **InsaneFury** » Mon Aug 09, 2010 1:42 pm

randy wrote:I think you'll have to wait for scripting so you can unambiguously specify which object's members you want to access.

I myself ain't looking for unambiguously specifying which object's members to access, I'd just like to use a uservar in the weapon, regardless of whether it's defined in the weapon or related playerclass.

Can't this issue be addressed, by either:
1) keeping any uservars used in weapons, to be defined in the weapons.
2) keeping any uservars used in weapons, to be defined in the playerclass.
3) keeping any uservars defined in either weapon or player to both weapon and player.

As-is now, user variables don't work at all in weapons. Disregarding specifying the scope of the variable, could there at least be a workable feature?

ZDoom

[2.4.1] User variables in weapons have inconsistent owners.

Post a reply

Expand view Topic review: [2.4.1] User variables in weapons have inconsistent owners.

Re: [2.4.1] User variables in weapons have inconsistent owne

Re: [2.4.1] User variables in weapons have inconsistent owne

Re: [2.4.1] User variables in weapons have inconsistent owne

Re: [2.4.1] User variables in weapons have inconsistent owne

Re: [2.4.1] User variables in weapons have inconsistent owne

Re: [2.4.1] User variables in weapons have inconsistent owne

Re: [2.4.1] User variables in weapons have inconsistent owne

Re: [2.4.1] User variables in weapons have inconsistent owne

Re: [2.4.1] User variables in weapons have inconsistent owne

Re: [2.4.1] User variables in weapons have inconsistent owne

Re: [2.4.1] User variables in weapons have inconsistent owne

Re: [2.4.1] User variables in weapons have inconsistent owne

Re: [2.4.1] User variables in weapons have inconsistent owne

Re: [2.4.1] User variables in weapons have inconsistent owne

Re: [2.4.1] User variables in weapons have inconsistent owne