[2.4.1] User variables in weapons have inconsistent owners.

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
User avatar
InsaneFury
Posts: 105
Joined: Mon Nov 23, 2009 6:51 am

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

Post by InsaneFury »

Bumping this one as I'm having a problem with my code which I believe is also related to the user_variable scope:

Code: Select all

actor TurnWeapon: PlasmaRifle
{
  var int user_angle; // Must also be declared in the player class for this to work!

  States
  {
  Ready:
    PLSG A 1 A_WeaponReady
    TNT1 A 0 A_Log("Angle:")
    TNT1 A 0 A_LogInt(angle)
    TNT1 A 0 A_Log("UserVar:")
    TNT1 A 40 A_LogInt(user_angle)
    TNT1 A 0 A_JumpIf(angle>user_angle,"Ready1")
    TNT1 A 0 A_JumpIf(angle<user_angle,"Ready2")
    SHT2 A 3
	Loop
  Ready1:
	TNT1 A 0 A_SetUserVar("user_angle",angle)
    PLSF A 20 Bright A_Print("READY1")
  Goto Ready
  Ready2:
	TNT1 A 0 A_SetUserVar("user_angle",angle)
    PLSF A 20 Bright A_Print("READY2")
  Goto Ready
  Select:
	TNT1 A 0 A_SetUserVar("user_angle",0)
  Select2:
    PLSG A 1 A_Raise
    Loop
  }
}
Basically what the code will ultimately be doing is have a weapon go into a different state based on the angle/previous angle of the player.

As-is now, the code always enters state Ready2. If however I edit the code with hard values (i.e. A_JumpIf(angle>10)), the code works as it should.
The problem here is probably related to the scope of the var int user_angle:
  • I placed var int user_angle; in the weapon actor.
  • I placed var int user_angle in the playerclass too (otherwise the code would generate warnings)
  • I'm setting the value of user_angle in the weapon's code, yet the next A_JumpIf statement seems to fail.
(I posted a question about A_Print here as I'd like to know which values the angle and user_angle variables are)

*edit*
DECORATE code updated. The uservar is reported as 65536, which I assume is the maximum 16-bit integer value. Or is this because something is casted improperly to the LogInt call?
User avatar
Major Cooke
Posts: 8212
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 10
Graphics Processor: nVidia with Vulkan support
Location: GZBoomer Town
Contact:

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

Post by Major Cooke »

I think that the code is still not behaving for weapons. I've never been able to get it right, or it's not been looked into thoroughly enough yet.
User avatar
NeuralStunner
 
 
Posts: 12328
Joined: Tue Jul 21, 2009 12:04 pm
Preferred Pronouns: No Preference
Operating System Version (Optional): Windows 11
Graphics Processor: nVidia with Vulkan support
Location: capital N, capital S, no space
Contact:

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

Post by NeuralStunner »

Yeah... This is one of the reasons I'm still using Arg[] in weapons (which affects the Player's Args, and I guess that isn't a big deal as I haven't heard of anyone assigning a special to a Player). You're limited to 5 numbers though...
User avatar
InsaneFury
Posts: 105
Joined: Mon Nov 23, 2009 6:51 am

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

Post by InsaneFury »

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?
Sir Cyril Fudgelot
Posts: 16
Joined: Wed Mar 24, 2010 11:34 pm
Location: Dead on the field of Caramel.

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

Post by Sir Cyril Fudgelot »

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.
User avatar
randi
Site Admin
Posts: 7749
Joined: Wed Jul 09, 2003 10:30 pm
Contact:

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

Post by randi »

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.
User avatar
NeuralStunner
 
 
Posts: 12328
Joined: Tue Jul 21, 2009 12:04 pm
Preferred Pronouns: No Preference
Operating System Version (Optional): Windows 11
Graphics Processor: nVidia with Vulkan support
Location: capital N, capital S, no space
Contact:

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

Post by NeuralStunner »

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?
pkmnfrk
Posts: 6
Joined: Mon Apr 26, 2010 9:52 am

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

Post by pkmnfrk »

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...
User avatar
MG_Man
Posts: 1401
Joined: Sat Jul 28, 2007 1:24 pm
Contact:

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

Post by MG_Man »

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.
Last edited by MG_Man on Tue Jul 10, 2012 10:48 am, edited 1 time in total.
User avatar
Xaser
 
 
Posts: 10774
Joined: Sun Jul 20, 2003 12:15 pm
Contact:

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

Post by Xaser »

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.
Guest

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

Post by Guest »

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.
User avatar
Major Cooke
Posts: 8212
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 10
Graphics Processor: nVidia with Vulkan support
Location: GZBoomer Town
Contact:

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

Post by Major Cooke »

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...
User avatar
Sami
Posts: 14
Joined: Sat Jan 19, 2013 2:56 pm
Location: Murcia, Spain

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

Post by Sami »

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.
ZzZombo
Posts: 317
Joined: Mon Jul 16, 2012 2:02 am

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

Post by ZzZombo »

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?
ZzZombo
Posts: 317
Joined: Mon Jul 16, 2012 2:02 am

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

Post by ZzZombo »

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?
Post Reply

Return to “Closed Bugs [GZDoom]”