ResetInventory in ZMAPINFO makes weapon skip Select action

[eharper256]

See the title; when a level invokes ResetInventory, it presumably does not action this until after the very first tic of the start of the level.

Hence, if there is action that goes off on the zeroth tic of a weapons Select state, that seems to be ignored in a similar way to actors not executing their actions on their first line of Spawn unless they have NoDelay. A weapon Select state cannot be given NoDelay though, as this is reserved to Spawn.

I've noticed this because I have inventory items in my mod that track the current weapon being used, and which are given in the Select state and removed in the Deselect state. These items have +UNDROPPABLE, and are used to make sure various overlays work correctly. i.e.

Code: Select all • Expand view

   Select:
      TNT1 A 0 A_GiveInventory("AxeInHand",1)
      Goto Select2
   Select2:
      FAXE A 1 A_Raise
      Loop

There isn't any problem with these items being added normally (start any random map, and they're fine and in Inventory if checked with the PrintInv command) but specifically they seem to never seem to appear if added on the zeroth tick and ResetInventory happens. They are not being removed by the ResetInventory, as they are UNDROPPABLE, but they never seem to get there in the first place. The A_Raise also completes fine.

I've tried adding in an extra TNT1 A 1 before the line where they're given, however, and it suddenly goes back to its old behaviour; the item is there and the overlays behave as they should. So yeah, something funky happens in the first tic.

[Graf Zahl]

Please post a complete, runnable example.

[eharper256]

You can try it with the previous version of my Mod (0.94) https://mega.nz/file/8A0h1KrA#-7Jp-XDM4 ... lO3N2sQhP8 as I've already appended the noted workaround for 0.94A.

I was then using https://www.doomworld.com/forum/topic/1 ... vengeance/ on my test to isolate this issue, because it was relatively easy to test at the time since it had a ResetInventory on the level after the new episode for whatever reason so it was just start as Crusader, a quick killmonsters, grab any random other weapon lying around, noclip almost directly forwards to the exit, and then hit the exit switch and jump in. However, I see that a new version of that map-set is out so I'm not sure if that's still the case; and that's still probably too much aggro if you want to do it quickly Graf. Perhaps something like a Wadsmoosh and then just editing its ZMAPINFO to add a ResetInventory on E1M2 could work quicker?

Sorry I can't provide a more usable solution, I did my testing for this the rough and long winded way lol.

[Blue Shadow]

ResetInventory is irrelevant here, since the player's inventory is reset at the end of the map, rather than upon entering the new one. Also, the function that's called in the weapon's Select state is actullay executed, not ignored.

This is something I had experienced in the past, and during my investigation, I found that the Select state of the equipped weapon is entered rather early upon entering a map, before even things like "player entered" events. I know there's something that involves spawning a dummy player pawn as part of the process of moving the player from one map to another, so I assumed the player hasn't fully transferred to the new map, or something to that effect... I don't know.

Here's something simple to test this with: https://www.dropbox.com/s/sej4eipw1gvlj ... o.pk3?dl=1

Start a new game. Look at the HUD and you'll find you have an item. This item is given to you by the pistol upon being selected. If you check the console, you'll see a message telling you you got the item. Now, take away the item (from the console: take thing). Keep the pistol equipped and exit the map. Upon entering the new map, you'll notice the item isn't in your inventory, despite getting the you-received-the-item message (check the console).

For reference, this is the code of the pistol:

Code: Select all • Expand view

class PistolT : Pistol
{
    Default
    {
        Weapon.SlotNumber 2;
    }

    action void A_GiveThing ()
    {
        if (A_GiveInventory("Thing"))
        {
            Console.Printf("Success! "Thing" was given.");
        }
        else
        {
            Console.Printf(""Thing" could not be given.");
        }
    }

    States
    {
    Select:
        PISG A 0 A_GiveThing;
        PISG A 1 A_Raise;
        Wait;
    }
} 

[Graf Zahl]

The main problem here is that using the 'select' and 'deselect' states to find out if a weapon is the active one is not safe. These states are meant for raising and lowering the weapon, so whatever happens that interrupts or disturbs these animations will break the setup.

From DECORATE, I'm afraid, there is no safe method at all do do this - it'd require ZScript to have access to the actual weapon info.

[InsanityBringer]

hmm, I'm going to guess the dummy PlayerPawn thing is also responsible for the chainsaw sound oddity I noticed a while back.

[eharper256]

Hm; interesting that its actually a dummy player.

I of course have no idea of what happens in the deep code at this point, but I guess if [Select] is going off before a player is correctly loaded in that could indeed also explain why the state is not delivering the item to inventory as it should. Or perhaps, it is delivering it, but its being delivered to the dummy player, and then the new Reset player overwrites it.