Pressing 2nd social while 1st is running causes 2nd social to start at random line rather than first

Discussion in 'Bug Reports' started by Bernel, Aug 17, 2023.

  1. Bernel Augur

    First off, I'm sure this behavior has existed for a long time, but it's so odd I have to believe it's a bug rather than intentional.

    If you press a new social button while a multi-line social is currently running, the new social starts from the current line number of the currently running social rather than line #1 of the new social. So rather than starting on line #1, the 2nd one may start on line #4 or whatever the currently running macro is on. For example, start with two socials called "Numbers" and "Letters" like this:

    Code:
    Numbers      Letters
    -------      -------
    /say 1      /say A
    /say 2      /say B
    /say 3      /say C
    /say 4      /say D
    /say 5      /say E
    
    If you start the Numbers social and then quickly press the Letters social while Numbers is running, you'll get output like this:

    1
    2
    3
    D
    E

    Rather than the Letters macro starting at line #1 and printing 'A', it starts on line #4 and prints 'D'. That's because the Letters social starts at the line number of the currently running macro. So if the Numbers macro is about to run line 4 when you press the Letters hotbutton, the macro engine will run line #4 of Letters rather than line #1.

    This behavior can be problematic and makes using socials harder. If I press a new social, I want that social to run from line #1 rather than from some random line. It would be much more beneficial for the behavior to be to start the new macro at line #1 rather than the current line number of the old macro. It would be better if the output was like this:

    1
    2
    3
    A
    B
    C
    D
    E

    Socials are frequently created with each line is dependent on a previous action, such as one line to select the target and another line to cast a spell. If the macro starts at a random place, then the social will likely not work or will have unintended behavior. Having a social always start at line #1 regardless of whether a social is already running would be a better and more dependable behavior. Having a 2nd social start at a random line is so problematic that I can't imagine anyone actually wanting it to work that way.

    I know there are workarounds to deal with this behavior--such as right-clicking on a hotbutton to abort the active macro sequence before starting a new social--but they are clunky and cumbersome. It would be much better to have the macro engine work as expected so users don't have to deal with workarounds.

    A subset of this problem is what to do when the same hotbutton is pressed multiple times. So if I press the Numbers hotbutton repeatedly, should it start over from line #1 each time or continue through? The current behavior is that it continues through rather than start over. I can see the benefit of that behavior since I may be slamming a button in a panic situation. Rather than starting over each time, the macro engine marches through the lines to the end. Having the macro engine execute the lines in order seems okay in the case where the same social is hit time after time. But if a new social is pressed, then the new social should start at line #1 regardless of the line number of the current social.
    Barton, Velisaris_MS and Brickhaus like this.
  2. Soulbanshee Augur

    A macro will fire off each line simultaneously without any /pause, in your example it will technically be trying to /say 5 lines at the same time (with very micro seconds just because CPU cycles). You are probably just bumping up against something dealing with the interpreter and not a bug. Put some 10th second or some such pause on each line and see if you can still interrupt the macro the same way. Without pause the interpreter has no concept of what is or should be running and is just shoving commands into the pipeline. If you shove 5 /say commands into the pipeline, the macro is "running" for less than 1/10th of a second, regardless of how long it takes chat to actually process the /say commands. Its why you have to use /pause for cast commands because there is nothing monitoring the cast time.
  3. Bernel Augur

    I wanted to make my example as simple as possible. In any case, it works like this on my system with this example without any pauses. It's the same with pauses anyway. For my real macros, I have pauses, spell castings, etc. All stuff that takes time. It was from trying to use the real macros and switching from one to another where I first noticed this behavior. If the 1st macro is running, the 2nd macro starts on whatever line the first macro happens to be.

    [IMG]
  4. Brickhaus Augur

    You should actually listen (read, whatever) to what he is saying.

    He's correct. The social behavior seems to have changed. It used to be that if one social was going (with pauses so it was clearly in the middle and not some insta processing issue), no others would start until that first social was finished. It would not queue up ... just wouldn't work for the second social (unless you were catching the tail end of the first social).

    Now it seems that socials automatically interrupt each other, but the interrupt starts at the line the previously running social was about to be on (or I guess on ... it's tough to say since there's only one action per line and it always occurs at the beginning of a line).

    Easy example:

    Make two socials.

    Test 1
    /pause 20, /say 1
    /pause 20, /say 2
    /pause 20, /say 3
    /pause 20, /say 4
    /say 5


    Test 2
    /pause 20, /say a
    /pause 20, /say b
    /pause 20, /say c
    /pause 20, /say d
    /say e

    Press Test 1.

    1 appears

    2 appears

    Press Test 2

    c appears

    d appears

    Press Test 1

    5 appears

    This is new behavior (although how new I cannot say).

    Hopefully a developer will chime in to what the game SHOULD be doing/processing when hitting a second social when a first social is still running. The current behavior really doesn't do players any good.
    Bernel likes this.
  5. Soulbanshee Augur

    I think I remember people wanting that behavior for macros to cancel the first macro, but yeah it sounds like the interpreter is not resetting its array indexer after it cancels the first macro. Difference with hotkeys that do resepect cast time of another hotkey (not a macro), you can just mash those until it casts.
    Bernel likes this.
  6. Bernel Augur

    I didn't realize that macros used to run as an uninterruptible block. I guess they changed things so that a new macro would interrupt a running macro, but this current behavior doesn't seem like it would be intended to work that way.
  7. Brickhaus Augur


    I know when I first started playing with macros way back when, this was the behavior (or at the very least, this was the behavior I thought I saw) so I have always used macros assuming this behavior.

    At this point, I'd just like clarification from a developer on what SHOULD be the behavior with macros like this so we can determine if we need to make a stink and/or adjust our play behavior to accommodate the current status quo.
    Bernel likes this.
  8. Bernel Augur

    Is there any advantage to the current behavior? I can understand aborting one macro when the other is started, but I can't see any benefit to having the 2nd macro start somewhere in the middle. If they changed the behavior to always start the 2nd macro at the beginning, I would think that would be universally a good change.

    The current behavior makes things like boxing that much harder. I'm just doing simple boxing where I alt-tab to the other window, press a hot key, and alt-tab back to the main window. This current behavior is aggravating since I have to take steps to stop any currently running socials before starting a new one. It's certainly not a show-stopper, but it seems an unnecessary hassle. If they just started a social from the first line always, it seems like everyone would be happy with that behavior.