free action bug in r1278

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • d_m
    Angband Devteam member
    • Aug 2008
    • 1517

    free action bug in r1278

    So, I just lost a pretty promising dwarf priest to ghouls on Level 40. I was copying save files around so I have an (old) backup, but what's interesting is that the character was wearing the cloak of thorongil:

    Code:
    h) The Cloak of Thorongil [1,+10]
         Provides resistance to acid, fear.
         Cannot be harmed by acid, electricity, fire, cold.
         Prevents paralysis.
         Grants the ability to see invisible things.
    Anyway, somehow I got paralyzed by the ghouls/ghasts despite having free action. I can post a dump if necessary, although it doesn't actually show the paralysis happening (it took awhile for me to die). Thoughts?
    linux->xterm->screen->pmacs
  • zaimoni
    Knight
    • Apr 2007
    • 590

    #2
    Originally posted by d_m
    So, I just lost a pretty promising dwarf priest to ghouls on Level 40. I was copying save files around so I have an (old) backup, but what's interesting is that the character was wearing the cloak of thorongil:

    Code:
    h) The Cloak of Thorongil [1,+10]
         Provides resistance to acid, fear.
         Cannot be harmed by acid, electricity, fire, cold.
         Prevents paralysis.
         Grants the ability to see invisible things.
    Anyway, somehow I got paralyzed by the ghouls/ghasts despite having free action. I can post a dump if necessary, although it doesn't actually show the paralysis happening (it took awhile for me to die). Thoughts?
    I don't immediately see the bug just by grep'ing the source (melee1.c is formally correct, and I see only one call to calc_bonuses that actually touches the player state and it's what I would expect).

    The stock
    Code:
    make clean -f Makefile.win MINGW=yes
    isn't working on Vista, so I'd consider manually deleting all of the *.o files and rebuilding if you're on Windows. (Problem is that Makefile.win is feeding UNIX relative paths to Win32 del which auto-fails; copy autofails as well. rm and cp are installed on my system; disabling the Win32 utility swapin makes Makefile.win work properly.)

    Takkaria: I do have a patch, but I don't know what the proper strategy is. (I don't think it's just commenting out the no-UNIX-utility bypass code.)
    Zaiband: end the "I shouldn't have survived that" experience. V3.0.6 fork on Hg.
    Zaiband 3.0.10 ETA Mar. 7 2011 (Yes, schedule slipped. Latest testing indicates not enough assert() calls to allow release.)
    Z.C++: pre-alpha C/C++ compiler system (usable preprocessor). Also on Hg. Z.C++ 0.0.10 ETA December 31 2011

    Comment

    • takkaria
      Veteran
      • Apr 2007
      • 1951

      #3
      Originally posted by zaimoni
      I don't immediately see the bug just by grep'ing the source (melee1.c is formally correct, and I see only one call to calc_bonuses that actually touches the player state and it's what I would expect).

      The stock
      Code:
      make clean -f Makefile.win MINGW=yes
      isn't working on Vista, so I'd consider manually deleting all of the *.o files and rebuilding if you're on Windows. (Problem is that Makefile.win is feeding UNIX relative paths to Win32 del which auto-fails; copy autofails as well. rm and cp are installed on my system; disabling the Win32 utility swapin makes Makefile.win work properly.)

      Takkaria: I do have a patch, but I don't know what the proper strategy is. (I don't think it's just commenting out the no-UNIX-utility bypass code.)
      I guess if we're relying on GNU make, some straightforward string substitution in variables to replace '/' with '\' might be the best strategy. I don't remember though, since I've not looked at the mingw makefile for a while.
      takkaria whispers something about options. -more-

      Comment

      • d_m
        Angband Devteam member
        • Aug 2008
        • 1517

        #4
        Originally posted by zaimoni
        The stock
        Code:
        make clean -f Makefile.win MINGW=yes
        isn't working on Vista, so I'd consider manually deleting all of the *.o files and rebuilding if you're on Windows. (Problem is that Makefile.win is feeding UNIX relative paths to Win32 del which auto-fails; copy autofails as well. rm and cp are installed on my system; disabling the Win32 utility swapin makes Makefile.win work properly.)
        I'm running Linux, but I've definitely run into situations where "make clean" didn't seem to work fully, and I ended up doing a fresh checkout. Do you think I am seeing an echo of an earlier bug?
        linux->xterm->screen->pmacs

        Comment

        • d_m
          Angband Devteam member
          • Aug 2008
          • 1517

          #5
          I restored from the earlier save and kept playing, I just saw this again.

          This time, I managed to background Angband and kill it, so I have a panic save. Of course, restoring the save kills the character, but I thought this might be more useful.

          Anyway, for me it seems like free action doesn't really work right now.

          Save file is attached. I'm wearing a Ring of Free Action so it's pretty obviously a bug.
          Attached Files
          linux->xterm->screen->pmacs

          Comment

          • d_m
            Angband Devteam member
            • Aug 2008
            • 1517

            #6
            As an experiment, I wrote some code to get my character out of the paralysis cycle. The following patch unparalyzed me as soon as the spectator gazed at me:

            Code:
            Index: monster/melee1.c
            ===================================================================
            --- monster/melee1.c    (revision 1278)
            +++ monster/melee1.c    (working copy)
            @@ -942,6 +942,8 @@
                                                    /* Increase "paralyzed" */
                                                    if (p_ptr->state.free_act)
                                                    {
            +                                               if (p_ptr->timed[TMD_PARALYZED])
            +                                                       clear_timed(TMD_PARALYZED, TRUE);
                                                            msg_print("You are unaffected!");
                                                            obvious = TRUE;
                                                    }
            So clearly, state.free_act was TRUE, but the paralysis timer was also incremented for some reason. Something like this (that periodically resets the paralysis timer for someone with free_act set) would fix the problem, but clearly it'd be more correct to figure out how it's getting set in the first place.
            linux->xterm->screen->pmacs

            Comment

            • zaimoni
              Knight
              • Apr 2007
              • 590

              #7
              Originally posted by d_m
              I restored from the earlier save and kept playing, I just saw this again.

              This time, I managed to background Angband and kill it, so I have a panic save. Of course, restoring the save kills the character, but I thought this might be more useful.
              Mr. M 5 doesn't die when the panic save is loaded on my system (local build with MingW32 4.2.1). The paralyzed display goes away on the first attack (bite).

              Of course, with only 9 hp an escape would be sorely needed.
              Zaiband: end the "I shouldn't have survived that" experience. V3.0.6 fork on Hg.
              Zaiband 3.0.10 ETA Mar. 7 2011 (Yes, schedule slipped. Latest testing indicates not enough assert() calls to allow release.)
              Z.C++: pre-alpha C/C++ compiler system (usable preprocessor). Also on Hg. Z.C++ 0.0.10 ETA December 31 2011

              Comment

              • zaimoni
                Knight
                • Apr 2007
                • 590

                #8
                Originally posted by takkaria
                I guess if we're relying on GNU make, some straightforward string substitution in variables to replace '/' with '\' might be the best strategy. I don't remember though, since I've not looked at the mingw makefile for a while.
                While I'm fairly sure that would be needed, I'm unclear whether that would work on my system. Neither del nor copy are executable at all from within bash, which is what GNU make uses as a command shell on my system.
                Zaiband: end the "I shouldn't have survived that" experience. V3.0.6 fork on Hg.
                Zaiband 3.0.10 ETA Mar. 7 2011 (Yes, schedule slipped. Latest testing indicates not enough assert() calls to allow release.)
                Z.C++: pre-alpha C/C++ compiler system (usable preprocessor). Also on Hg. Z.C++ 0.0.10 ETA December 31 2011

                Comment

                Working...
                😀
                😂
                🥰
                😘
                🤢
                😎
                😞
                😡
                👍
                👎