Urgent APlayerPawn issues [Appveyor r3935 to r3936 versions]

[Lord Misfit]

[Bear with me, I'm still confused about this issue myself, so here goes my best attempt to explain this...]

https://github.com/coelckers/gzdoom/com ... f8847d7183
https://github.com/coelckers/gzdoom/com ... cade785131

I've been having a very interesting and confusing problem with what might be var corruption of sorts since a change in either of the above two commits related to the APlayerPawn scriptification process [where the code has been getting un-nativified for use in ZScript]. I can't be perfectly specific WHICH of the two commits above, since the first didn't have an SVN on Appveyor to run and test, only the latter commit did, and the commit before it did have the walls working, though the grunt sounds where defaulting to the original Doomguy's in that commit.

I'm not sure if this is specific only to WEAPON global vars or not, but in my mod Aetherius, since these versions, I've had an issue where if I had used one of the main weapon's alt-fire modes for shielding myself from attacks, I'm suddenly unable to use any kind of usuable linedef [switches/doors/etc] and my player character doesn't even make a GRUNT sound, so I effectively can't do anything and all progression in the level/game is effectively ground to a halt. This even persists if I save and reload or use "changemap", and only starting a completely new game or using "map" fixes it.

However the actual "use" key still does other mod-specific functions that aren't related to using doors/etc, so it's not that the key itself is fully refusing to work. After messing with it some, I noticed that one of the vars used by the altfire via a function in the weapon script would show "1078984704" as a value when I commented out the code that normally changed said var, instead of it being "0". I have to guess that's SOME kind a bitfield related to using things like walls/etc, because when I reallow the function to change the value, it stopped me from using walls/etc again.

I went and made a NEW var and renamed all instances of the old one except the original define to that one [but leaving the define of the original var intact], and tried out my weapon's alt-fire again, and happily found it seemed to fix my problem and I could use walls and it made proper grunting/use sounds as per normal, but when a friend tested this out, to confirm it, while he had said the wall-use issue indeed had been fixed, he noticed that after using the same weapon for a normal swing attack, the player's bobbing suddenly TURNED OFF COMPLETELY and never turned back on, and a followup playthrough from me had confirmed that the player's bobbing had indeed turned off after using the normal swing attack.

However, I also noticed that if I commented out the definition of what I had considered the original offending var, that my walls-not-being usable problem returned, as if the number of global weapon vars would determine what player "property" was somehow being changed [hence why I think there's a corruption/etc issue here]. If I readded that offending var definition, and then added yet another, I noticed both the wall-use problem and the lack of bobbing player after attacking that my friend reported vanished, but at this point I have no idea what OTHER property of the player's it might be corrupting, if any. Basically in the engine's current state, I'm worried about making new global vars for anything related to the player or weapons in fear of what it could end up corrupting/altering-under-the-hood. x.x

If you were able to keep up with me after all that, I'm glad you could, because I too am horribly confused about this and I don't think I could really have condensed explaining this all that much more than I did above. Also because of the nature of this issue, I can't really make a tiny sized "control" case for testing this issue outside of having you test Aetherius ITSELF to see the issue, and the mod is fairly large to begin with. The only thing I could get a concrete grasp on is that the issue started occuring in one of the two commits linked above and that besides the 3.7.1 and 3.7.2 official releases [which based on me and my friend's testing seemed to check out with none of the above issues occuring], all the SVNs since have had the issue.

Unfortunately due to a lot of the weird compiler issues in most of the 3.8-pre-1xx and 3.8-pre2xx versions before the "rollback" causing on-startup-crashes of the engine, I couldn't really run those versions to see if anything had changed or altered between what's effectively the 3.8-pre62 commit [the first DevBuild SVN on DRDTeam's site that has the issue] and the current 3.8-pre179 commit [the first one I guess since the "rollback" occured].

I'm not sure if anyone could give me advice on a way I could make a smaller "control" case to test with this kind of an issue though, but if I knew how, I certainly would, because I just know this will get noticed eventually by other modders at some point if it's not dealt with soon.

If you want to try to test this yourself w/ Aetherius, the mod is located @ https://github.com/LordMisfit/DV-DS-ComboPack . When you download the mod, go to the ZScript folder and open "dvds-weapclass.zc" and find "int FrameValue;" and "int FrameValue2;" and comment out either or both and then go into the game, and use the Sceptre's alt-fire [the spinning shield that blocks attacks] and/or the normal swing attack and check try moving to test the bobbing of the player and try using walls to see if you even hear the player's grunt sounds. (What you'll get depends on if you comment out one or both of the above vars, if you leave them both uncommented, the bobbing and using-walls will work, but again I don't know what other thing might be acting up under the hood).

Sorry I couldn't make this simpler than that at the moment. :\

[EDIT: I forgot to specify, but this is NOT appearantly JIT-complier specfic either. I tested with both JIT and non-JIT and I had the same issues]

[Matt]

I'm not sure if this is specific only to WEAPON global vars or not, but in my mod Aetherius, since these versions, I've had an issue where if I had used one of the main weapon's alt-fire modes for shielding myself from attacks, I'm suddenly unable to use any kind of usuable linedef [switches/doors/etc] and my player character doesn't even make a GRUNT sound, so I effectively can't do anything and all progression in the level/game is effectively ground to a halt. This even persists if I save and reload or use "changemap", and only starting a completely new game or using "map" fixes it.

I'm reading it as this:

1. Load Aetherius
2. Start game, use one of mod's weapons
3. Hit Altfire
4. Try to use a door

Expected: door open
Actual: nothing


Is this accurate?

If so, which weapon or weapons?

If not, what other steps are required to replicate the bug?

[Lord Misfit]

So far yes that is accurate, Matt. [if you comment out both of the "FrameValue" vars in dvds-weapclass.zc]

Just the Sceptre [Flora's main weapon on start up] seems to trigger this. The issue is activated specfically in the "A_SceptreTwirlFrameCheck" function in dvds-weapclass.zc, when it increments the frame counter for what frame the spinning sceptre in front of the player uses when using the alt-fire for the visual effect, basically.

At least for the original issue I saw. If you comment out just one of the vars I mentioned above instead of both, you should experience a different issue where the player's weapons don't bob when you use the weapon's main attack, but the wall-using issue also shouldn't show up. And if you don't comment either one, neither issue should show up, but as I said before, it might cause some other as-of-yet-unknown issue to occur with a player property somewhere.

[Matt]

See how much you can comment out and still replicate the original bug, and try to create a standalone zscript.txt that contains a weapon that does so.

(It's better that the modder do this with their own mod because someone else trying to do this would not know off the top of their heads the surrounding context of the code and it'll take a lot longer with a lot more shots in the dark)

[Matt]

In response to a PM, since this seems to have general relevance:

but the problem is how elaborate and interconnected a lot of background elements of the mod

as the author of Hideous Destructor I can definitely relate to that!

The problem is, this means the GZDoom dev folks aren't going to have a clue about how your stuff is organized without dedicating a lot of time to studying your mod that they won't have. If they tried to debug using Aetherius (or HD) as-is, they could easily spend dozens of man-hours looking at a part of the code that has nothing to do with what's actually causing the bug, in a situation where you (or I) would have known within the first 5 seconds that the problem would also be affected by this other piece of code in another file.

So it's not only a courtesy but a practical necessity that we, the modders, have to pull out the minimum part of our own mods that cause the bug to happen and put together a demonstration. See also the sticky note.


The times I won't do this are:

1. I'm pretty certain I know what's causing it and I'm just using HD as the most obvious example - and the example in question is one of the simpler parts of HD. (e.g. "Portals don't work in software, I noticed this with the back corridor in the HD range")

2. I haven't the slightest clue what the problem is and it's super obvious I lack the technical knowledge or sufficient feedback from GZDoom (e.g., ability to understand crashlogs) to even begin to figure it out. ("HD crashes to desktop on startup with GZ commit no. 12345 but works fine in commit no. 12344, crash log attached")

3. A demo already exists. ("Cameratextures on HUD broke again, here's a link to _mental_'s test pk3")

Any suggestions you can give me for how to approach this? Should I try to use the original weapon as a basis to condense, or do you honestly think I should try to recreate it from scratch?

What I normally do in a situation like this is:

1. find out exactly which actors cause the bug (is it all the HD weapons, or even the vanilla weapons while running HD)?
2. create backups of your work (copy another folder, commit to git, etc.)
3. see if disabling ACS helps
4. keep commenting-out and breaking things, running the mod and checking for the bug and nothing else each time until the bug no longer appears
5. find the one line of code that can stop the bug if you comment it out
6. create a new weapon from scratch with only that one thing
7. see if that new weapon can be used to trigger the bug, if it does then post, if it does not then make a note that this is not the culprit and go back to step 3


Sometimes I'll shortcut around step 6 by inheriting from a stock Doom weapon (but only after checking to make sure that the bug isn't happening with the stock Doom weapon as well).

Only in the most extremely specific of cases would I try to take an existing HD weapon and pare it down until it works as a standalone, because otherwise it would be a lot more work for me to cut out all those elaborate background interconnections so that GZDoom would even start (and then figure out what I'd deleted by mistake such that I could no longer replicate the bug), than for me to take the offending code and shoehorn it into something like this:

Code: Select all

class testwep:weapon{
    states{
    select:
        TNT1 A 0 A_Raise();
        wait;
    deselect:
        TNT1 A 0 A_Lower();
        wait;
    ready:
        TNT1 A 1 A_WeaponReady();
        wait;
    fire:
    altfire:
        TNT1 A 1;
        TNT1 A 0 A_Refire();
        goto ready;
    }
} 

[Lord Misfit]

https://github.com/LordMisfit/TempRepo1 - So I did what I could in trimming the fat here, and I was able to get it to do what I recall it doing. Though I learned something else interesting related to the issue when one of the vars in question are commented out instead of none or both, where it would prevent your weapons from bobbing after doing certain attacks. I found the offending function and while I was testing it, I changed a few things to get rid of ACS warnings, and found it was outright randomizing the value, but instead of JUST having issues with bobbing, when I held down the attack key to alter the value, I'd randomly ATTACH TO THE CEILING and then back to the floor instantly, among other things. You'll be able to see this for yourself in the repo above.

Whatever this issue is doing, it's affecting different player-related bitfields, I guess based on the total number of global vars defined in the "BaseWeapon" actor, but I noticed the bitfield that affects the bobbing and attaching to the ceiling is DIFFERENT from the bitfield that can prevent you from using walls/grunting on the walls, so I assume each new var or removed var causes one of the vars still defined in the actor to read/affect a different player-bitfield of some kind altogether. Unfortunately, I have no idea WHICH bitfields they are in accuracy, just that they're two[possibly more] different bitfields.

Doing some tweaking on the functions, I found the value readout by the offending var in the main-attack's function reads out as "1072693248" when the values aren't being changed, while the var from the function for the alt-fire prints out as "1078984704" when it's not being changed [I did this w/ Console.Printf commands you'll be able to see/use during the testing]. As long as the values above aren't changed, nothing acts wrong with the player while either one or both of those "FrameValue" vars are commented out near the beginning of the "BaseActor" in "testweaponattempt.zc".

I also just discovered, that if you notice the order the vars AFTER the "FrameValue" vars are placed in: if you move their orders around, the vars altered by doing this are no longer adversely effected by these issues [but whatever vars are in their "position"s probably ARE though]. o.o STRINGs also count as part of the "order" too [INTs obviously do too, and I'm guessing DOUBLEs do as well if any where in the code], moving them just below the FrameValue vars will also mess with which vars below them are affected by all of this too. CONSTs do not seem to affect it though.

I still don't have any clue what possible bitfield/properties might be getting altered if both of those vars are left accessible to the actor though, but I hope what I've gotten together can be of some use.

Matt, I used your code example above for the weapon, but I ported it to DECORATE [like how it was in Aetherius actually] because I was having self pointer issues using the custom functions in the ZScript code and had to do it this way to load GZDoom. I used the fist sprites for visuals on the weapon itself too.

I hope this helps, though I'm still confused to the actual cause of this issue, at least I seemed to be able to replicate it in a much smaller test repo for you guys. :V

[Lord Misfit]

Just made an update to the repo above. I decided to make Console.Printf displays for ALL the global vars used by the BaseWeapon class, and I noticed MULTIPLE vars are giving off non-0 values [bitfield looking values, a couple were even negative], but since global vars are appearantly supposed to default to 0, this is obviously some kind of issue where these bitfields[player/etc related] are bleeding their values into weapon global vars. x.x

[_mental_]

Could you please add the following line to A_GetSceptreDamage() and A_SceptreTwirlFrameCheck() ?

Code: Select all

Console.Printf("class: %s", getclassname());

I guess you will be surprised when you will see the output.

Also, if you try to convert testweapon.dec to ZScript in a straightforward way, you will get another hint

Code: Select all

Call to member function ... with incompatible self pointer.

The problem here is the engine allows such errors to happen silently. I believe this should be fixed somehow.

[Graf Zahl]

This is a great example why ZScript and DECORATE should not be mixed. The error detecting capabilities of DECORATE are unfortunately somewhat limited so if some bad ZScript is used from there, some safeguards will become ineffective.

[_mental_]

Does it help if functions from Actor class only will be allowed? The idea is to add a check to ParseAction() similar to CheckFunctionCompatiblity().

[Graf Zahl]

Oh. I assumed DECORATE would take the same path. Yes, it would make a lot of sense to do the same check there.
I wonder how many mods that will cause to error out...

[_mental_]

I was thinking about the same. Also, I'm not sure that it's the right place to put a check. Probably, CheckFunctionCompatiblity() should be called for this case too while it does not at the moment.

[Lord Misfit]

Could you please add the following line to A_GetSceptreDamage() and A_SceptreTwirlFrameCheck() ?

Code: Select all

Console.Printf("class: %s", getclassname());

I guess you will be surprised when you will see the output.

Okay forgive me if I'm not getting it right at the moment as I'm half-asleep, but am I supposed to have expected the class printout to be that of the WEAPON or the PLAYERCLASS?

Also, if you try to convert testweapon.dec to ZScript in a straightforward way, you will get another hint

Code: Select all

Call to member function ... with incompatible self pointer.

The problem here is the engine allows such errors to happen silently. I believe this should be fixed somehow.

So is the take-away [besides "get your stuff converted to ZScript"] supposed to be "don't use global vars in weapons anymore", else it should give you that self-pointer error? Sorry, I'm temporarily awake at the moment and was checking stuff before I went back to sleep, so I might not be processing this on all cylinders right now. o.o

[ketmar]

heh. basically, when you're calling methods for player's weapon, they are called with player actor as `self`, not with weapon actor. this is just how the engine does it internally. so you end up unintentionally modifying internal player class state. of course, it causes all kinds of havoc all around.

[Graf Zahl]

This is sadly a relic from a time long before DECORATE that cannot be undone anymore. There simply was way too much content being made that depended on this oddity because this is what made it possible to call actor functions from weapon states.