ZDoom

Yeah I just did the latter [inventory items] since I have no idea when I'll really get into the drive to do a mass DECORATE-to-ZScript conversion process, or how long it'll take once I do. I haven't been mindlessly working on Aetherius in the last couple of months due to varying reasons [including a heatsink-replacement issue at the start of January], so yeah. :P

Still thanks for helping me to diagnose this problem so I can avoid doing it again. :V

[quote="Lord Misfit"]Okay, back and more awake now: so should I be trying to use things like Inventory Items as placeholders for vars in this case to get around this, or do I need to move the vars to the playerpawn and use them via invoker in the weapons' functions or something[/quote]
Once you've converted it to ZS, if a variable is properly something that's handled in the weapon, make it a variable in the weapon and use "invoker.<variablename>".

Until then, I'd use inventory items because custom playerpawn variables would require that the owner ("self" in the weapon state) be cast as that custom playerpawn class and that can't be done in DECORATE unless I've missed some new developments there.

It always works this way.

Okay, back and more awake now: so should I be trying to use things like Inventory Items as placeholders for vars in this case to get around this, or do I need to move the vars to the playerpawn and use them via invoker in the weapons' functions or something?

While I'm glad something seems to have been determined in what's going on here, I still need to figure out how to not have this happen in the meantime. >.>

Also it does make me wonder, why did this suddenly start messing with the player properties after Appveyor r3935 and not before it [or was it and I just somehow didn't notice]?

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.

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.

[quote="_mental_"]Could you please add the following line to [url=https://github.com/LordMisfit/TempRepo1/blob/c92d368679b264dac227853197b6221d0321635c/ZScript/testweaponattempt.zc#L198]A_GetSceptreDamage()[/url] and [url=https://github.com/LordMisfit/TempRepo1/blob/c92d368679b264dac227853197b6221d0321635c/ZScript/testweaponattempt.zc#L221]A_SceptreTwirlFrameCheck()[/url] ?[code]Console.Printf("class: %s", getclassname());[/code]
I guess you will be surprised when you will see the output.[/quote]

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?

[quote="_mental_"]Also, if you try to convert [url=https://github.com/LordMisfit/TempRepo1/blob/4f41d3b06c635abfe817847c2644cf77041b0dcb/DECORATE/testweapon.dec]testweapon.dec[/url] to ZScript in a straightforward way, you will get another hint[code]Call to member function ... with incompatible self pointer.[/code]
The problem here is the engine allows such errors to happen silently. I believe this should be fixed somehow.[/quote]

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

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

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... :twisted:

Does it help if functions from Actor class only will be allowed? The idea is to add a check to [url=https://github.com/coelckers/gzdoom/blob/fa53ae21e615e78b66c941ae7daa0d1ad278ca6f/src/scripting/decorate/thingdef_states.cpp#L579]ParseAction()[/url] similar to [url=https://github.com/coelckers/gzdoom/blob/fa53ae21e615e78b66c941ae7daa0d1ad278ca6f/src/scripting/backend/codegen.cpp#L7559]CheckFunctionCompatiblity()[/url].

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.

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

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

Could you please add the following line to [url=https://github.com/LordMisfit/TempRepo1/blob/c92d368679b264dac227853197b6221d0321635c/ZScript/testweaponattempt.zc#L198]A_GetSceptreDamage()[/url] and [url=https://github.com/LordMisfit/TempRepo1/blob/c92d368679b264dac227853197b6221d0321635c/ZScript/testweaponattempt.zc#L221]A_SceptreTwirlFrameCheck()[/url] ?[code]Console.Printf("class: %s", getclassname());[/code]
I guess you will be surprised when you will see the output.

Also, if you try to convert [url=https://github.com/LordMisfit/TempRepo1/blob/4f41d3b06c635abfe817847c2644cf77041b0dcb/DECORATE/testweapon.dec]testweapon.dec[/url] to ZScript in a straightforward way, you will get another hint[code]Call to member function ... with incompatible self pointer.[/code]
The problem here is the engine allows such errors to happen silently. I believe this should be fixed somehow.

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

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

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;
    }
} 

In response to a PM, since this seems to have general relevance:[quote="Lord Misfit"]but the problem is how elaborate and interconnected a lot of background elements of the mod[/quote]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. [url=https://forum.zdoom.org/viewtopic.php?f=2&t=56209]See also the sticky note.[/url]


The times I [i]won't[/i] 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 [i]slightest clue[/i] 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")


[quote]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?[/quote]
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 [b]and [i]nothing[/i] else[/b] 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 [i]more[/i] 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=php]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;
    }
} [/code]