Macro problem

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • shevek
    Rookie
    • May 2008
    • 16

    Macro problem

    So I'm playing a ranger, and I'm trying to get archery macro'd. I use the roguelike key set, so I inscribed my arrows with:

    @t5

    And then I macro'd

    t5*t

    And when I call the macro it returns "take off which item?" as if I had macro'd T.

    Any thoughts? What am I doing wrong?
  • will_asher
    DaJAngband Maintainer
    • Apr 2007
    • 1124

    #2
    Inscriptions do not change with the roguelike keyset, so you still have to inscribe your arrows with @f1 (or @f5). I think this is a bug that you still have to inscribe commands for the keypad keyset even when you're using the roguelike keyset.
    It strange to use the "t" command to fire an arrow inscribed with "@f1".
    Will_Asher
    aka LibraryAdventurer

    My old variant DaJAngband:
    http://sites.google.com/site/dajangbandwebsite/home (defunct and so old it's forked from Angband 3.1.0 -I think- but it's probably playable...)

    Comment

    • Elsairon
      Adept
      • Apr 2007
      • 117

      #3
      Note: Added to Angband Trac, Ticket 606.

      Comment

      • roustk
        Adept
        • Dec 2007
        • 167

        #4
        Originally posted by Elsairon
        Note: Added to Angband Trac, Ticket 606.

        http://angband.rogueforge.net/trac/ticket/606
        And you are fundamentally wrong.

        *Inscriptions* always assume the standard keyset.
        Macros use the selected keyset (roguelike or standard).

        The original poster's problem is that his 't5*t' macro is not finding his '@t5' arrows. That macro is processed as follows:
        * 't' is sent to keypress processor, which translates 't' to 'f'ire passing it through the roguelike keymap. 'f'ire then wants to know what ammo.
        * '5' in response to 'f' means "find the item with '@5' or '@f5'". Nothing is found with those inscriptions, so the game reports "Illegal object choice (tag)!".
        * 'f'ire then asks again "Fire which item?" and stops processing the macro (due to error).

        The inscription problem was reported long ago, and is surprisingly hard to fix in a robust manner. See ticket 437.

        Kevin

        Comment

        • Slick
          Scout
          • Oct 2007
          • 48

          #5
          I also use the roguelike keyset. [been playing since "Rogue"; no kidding.]

          I inscribe ammo with: {@1=g

          and I map F1 with: t1*t


          and everything works fine. Obviously you can use another number and also obviously, with this bug, you should not try to be fancy; use a number for ammo/firing which is not used with any other commands. That way you need not include the command "t" on the ammo inscription.

          Side note, when playing rangers, I also inscribe "good" ammo with @2=g and map F2 with t2*t. With this setup, I can shoot normal ammo at weak/avg monsters with F1 and I can shoot good ammo at tough monsters with F2.

          The "=g" just ensures that I'll auto-pickup the ammo if/when I shoot my last one.

          Comment

          • shevek
            Rookie
            • May 2008
            • 16

            #6
            Originally posted by roustk
            And you are fundamentally wrong.

            *Inscriptions* always assume the standard keyset.
            Macros use the selected keyset (roguelike or standard).

            The original poster's problem is that his 't5*t' macro is not finding his '@t5' arrows. That macro is processed as follows:
            * 't' is sent to keypress processor, which translates 't' to 'f'ire passing it through the roguelike keymap. 'f'ire then wants to know what ammo.
            * '5' in response to 'f' means "find the item with '@5' or '@f5'". Nothing is found with those inscriptions, so the game reports "Illegal object choice (tag)!".
            * 'f'ire then asks again "Fire which item?" and stops processing the macro (due to error).

            The inscription problem was reported long ago, and is surprisingly hard to fix in a robust manner. See ticket 437.

            Kevin
            Actually it looks to me like macros only call the standard keyset (hence the weird return reported in my original post). My macro was only fixed when I switched both t5 to f5 and the macro to "f5*t".

            Comment

            • roustk
              Adept
              • Dec 2007
              • 167

              #7
              Originally posted by shevek
              Actually it looks to me like macros only use standard keyset (hence the weird return reported in my original post). My macro was only fixed when I switched both t5 to f5 and the macro to "f5*t".
              Which version are you playing? I don't see this behavior in 3.0.9, 3.0.9b, or a recent nightly 3.1.0 (from about May 10). I can create a macro (=m4 <F1> t5*t <enter> for 3.0.9) and it works perfectly fine.

              Comment

              • shevek
                Rookie
                • May 2008
                • 16

                #8
                Originally posted by roustk
                Which version are you playing? I don't see this behavior in 3.0.9, 3.0.9b, or a recent nightly 3.1.0 (from about May 10). I can create a macro (=m4 <F1> t5*t <enter> for 3.0.9) and it works perfectly fine.
                Very odd. I'm playing the MacOS build of 3.0.9b. I've double checked and t5*t definitely returns "Take off which item?"

                Comment

                • roustk
                  Adept
                  • Dec 2007
                  • 167

                  #9
                  Originally posted by shevek
                  Actually it looks to me like macros only call the standard keyset (hence the weird return reported in my original post). My macro was only fixed when I switched both t5 to f5 and the macro to "f5*t".
                  I may have found it. Is it possible that you created a keymap, not a macro?

                  * Macros are fed through the keymap parser (e.g., request_command() in util.c), so 't5*t' fires '@f5' ammo in roguelike mode (and takes off @t5 equipmet in standard).
                  * Keymaps are fed directly to the main switch in process_command() in cmd0.c, so 't5*t' takes off '@t5' equipment in roguelike or standard mode.
                  * Inscriptions are interpreted using only the internal (standard) commands.


                  When you press a key, inkey_aux() checks whether it is a macro trigger. If so, it sends the macro string to inkey_ex() one character at a time. Otherwise, it sends the keypress to inkey_ex().

                  inkey_ex() and inkey() strip bad characters from their input and translate backquote as escape before sending it to request_command().

                  request_command() checks whether its input has a keymap. If so, it sends the keymap string to process_command() one character at a time. Otherwise, it sends its input to process_command(). Note that roguelike is a big keymap.

                  process_command() looks up its input in the big table of functions (in cmd_* structures in cmd0.c) and calls the appropriate command. For example:
                  Code:
                  /* Magic use */
                  static command_type cmd_magic[] =
                  {
                          { "Gain new spells or prayers", 'G', do_cmd_study },
                          { "Browse a book",              'b', do_cmd_browse },
                          { "Cast a spell",               'm', do_cmd_cast_or_pray },
                          { "Pray a prayer",              'p', do_cmd_cast_or_pray }
                  };

                  So, if you create a macro that connects <F1> to 't5*t' and then press <F1> in roguelike mode, the following occurs:
                  1) inkey_aux() translates <F1> into 't5*t'. It sends 't' to request_command() and leaves '5*t' in the queue.
                  2) request_command() looks up 't' in the roguelike side of the keymap table and finds an 'f'.
                  3) process_command() looks up 'f' and finds do_cmd_fire() in cmd_item_use[].
                  4) do_cmd_fire() uses get_item() to find your ammo. It gets one character from the queue ('5'), recognizes it as a number, and tries to find an inscription to match. First, it checks for something inscribed '@5'. Failing that, it looks for '@f5' (since 'f' was sent to process_command()).
                  5) Then do_cmd_fire() uses get_aim_dir() to find your target. It gets one character from the queue ('*'), recognizes it as a request for targeting mode, and calls target_set_interactive(). That makes a list of targets, asks about the first one, gets one character from the queue ('t'), recognizes it as a acceptance (like 5, 0, and .), and returns the target to do_cmd_fire().

                  On the other hand, if you create a keymap that connects control-Z with 't5*t' in roguelike mode, the following occurs.
                  1) inkey_aux() does nothing to control-Z.
                  2) request_command() looks up control-Z in the roguelike side of the keymap table and finds 't5*t'. It sends the 't' to process_command() and leaves '5*t' in the queue.
                  3) process_command() looks up 't' and finds do_cmd_takeoff().
                  4) do_cmd_takeoff() uses get_item() to find your item to take off. It gets one character from the queue ('5'), recognizes it as a number, and tries to find an inscription to match. First, it checks for something inscribed '@5' in your equipment. Failing that, it looks for '@t5' (since 't' was sent to process_command()).
                  5) Failing to find anything appropriately inscribed, it clears the queue and asks again "Take off what item?".

                  Kevin

                  Comment

                  • shevek
                    Rookie
                    • May 2008
                    • 16

                    #10
                    Aha. Yes. It would appear that it is indeed a keymap.

                    Comment

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