Unwanted behavior: MUSHclient window scrolls "up" by 1

Posted by Blixel on Wed 13 Mar 2019 01:08 AM — 12 posts, 42,142 views.

Blixel Wed 13 Mar 2019 01:08 AM #0

I have a trigger in my game where a "chest" is seen on the ground by a player. If that player's dexterity is lower than 14, they are not capable of opening the chest. So that player will "say openTheChest" out to the room. This "openTheChest" string is used as a trigger by other player's to signal to them to open the chest ... so long as their dexterity is sufficiently high.

All of this works.

My only complaint is that the "say" messages get a bit spammy, so I'm using a script that calls a function that does DeleteLines(2) to get rid of the say message spam. (All say messages span 2 lines, so that's why I'm deleting 2 lines and not 1.)

Again, this works great as well.

However, every time DeleteLines(2) runs, it causes the MUSHclient window to scroll "up" 1 space.

So I'm wondering if I can run a command right after DeleteLines(2) that will make the window scroll down 1 space to correct for this scrolling issue? Or is something I can do with DeleteLines(2) that will correct the scroll up before it ever happens?

Hopefully this is clear.

Fiendish USA Global Moderator Wed 13 Mar 2019 01:10 AM #1

Quote:
All say messages span 2 lines

Preceded by a blank line?

Show the output.

Blixel Wed 13 Mar 2019 01:14 AM #2

Fiendish said:

Quote:
All say messages span 2 lines

Preceded by a blank line?

Show the output.

Scan this thread from when I first set this up. It should help.
https://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=14065

Nick Gammon Australia Forum Administrator Wed 13 Mar 2019 02:51 AM #3

However, every time DeleteLines(2) runs, it causes the MUSHclient window to scroll “up” 1 space.

Do you mean scroll up one line?

Are you saying that when this particular action happens a blank line appears in the output window?

Assuming that is the case, why not delete 3 lines?

Perhaps show the trigger, and also any script the trigger calls.

Blixel Wed 13 Mar 2019 03:21 AM #4

Nick Gammon said:

> However, every time DeleteLines(2) runs, it causes the MUSHclient window to scroll "up" 1 space.

Do you mean scroll up one **line**?

Are you saying that when this particular action happens a blank line appears in the output window?

Assuming that is the case, why not delete 3 lines?

Perhaps show the trigger, and also any script the trigger calls.

Here's what I mean: https://i.imgur.com/XHbYi7W.jpg

In the first picture, I have walked into a new area and notice there is "loot" on the ground. (Indicated by the $ in the text graphic.)

I type "look" to look at what's in the room. There is a chest in the room. Since there is a chest in the room, and since my character's dexterity is not high enough to successfully open a chest, a trigger sends "say openTheChest" to the room. When this happens, another trigger deletes the 2 lines that appear on the screen, and then the window scrolls up 1 line. This is what you are seeing in the second picture.

In the third picture, I have moved my mouse over to the scroll bar in the lower right, clicked the scroll bar, and the screen has scrolled back down 1 line.

What I'm trying to prevent is what's happening in the second picture. When I delete those two lines, it scrolls the window up by 1 line.

Trigger

^There is a (.*)chest(.*?)|(.*?)chest here.|(.*?)a chest,(.*?)$

Send

-- If the active player is a ninja or has a high
-- enough dexterity, then there is no need to send the
-- "openTheChest" message because the active player is
-- capable of opening chests themself.

if ((playerClass ~= "ninja") and (playerDex < requiredDex)) then
  require "wait"
  wait.make (function ()
    wait.time (0.25)
    Send ("say openTheChest")
  end)
end

Trigger

  <trigger
   enabled="y"
   group="Follow the Leader"
   lines_to_match="2"
   match="^\&gt;?say openTheChest$\n^\&gt;?[*][*][*]$"
   multi_line="y"
   name="hideOpenChestMessage"
   regexp="y"
   script="delTwoLines"
   sequence="100"
  >
  </trigger>

from my lua script file


function delTwoLines ()
  DeleteLines(2)
end

EDIT: Here are 2 very short videos showing what I'm describing.

When the trigger is disabled: https://youtu.be/L4kZLQvCyno

When the trigger is enabled: https://youtu.be/iNxvPpoADXI

As you can see, when the trigger is enabled, the window scrolls back 1 line.

Nick Gammon Australia Forum Administrator Wed 13 Mar 2019 05:15 AM #5

What I think I am seeing is the prompt being deleted (so you get the scroll) and then a new prompt appears and the screen jumps back up.

What could help here is to make the prompt end with a newline.

If that doesn't work, can't you just make two triggers, as you suggested in the linked thread?

The first trigger could enable a match for the second trigger, and both could omit from output. Then the second trigger could disable itself.

Nick Gammon Australia Forum Administrator Wed 13 Mar 2019 05:31 AM #6

I can't actually reproduce that.

Please help us by advising the version of MUSHclient you are using. Use the Help menu -> About MUSHclient.

Nick Gammon Australia Forum Administrator Wed 13 Mar 2019 05:34 AM #7

This is how I would do it with two triggers:


<triggers>
  <trigger
   match="^\&gt;?[*][*][*]$"
   name="ThreeAsterisks"
   omit_from_output="y"
   regexp="y"
   send_to="12"
   sequence="100"
  >
  <send>

EnableTrigger ("ThreeAsterisks", false)

</send>
  </trigger>

  <trigger
   enabled="y"
   group="Follow the Leader"
   lines_to_match="2"
   match="^\&gt;?say openTheChest$"
   name="hideOpenChestMessage"
   omit_from_output="y"
   regexp="y"
   send_to="12"
   sequence="100"
  >
  <send>

EnableTrigger ("ThreeAsterisks", true)

</send>
  </trigger>
</triggers>

For advice on how to copy the above, and paste it into MUSHclient, please see Pasting XML.

Blixel Wed 13 Mar 2019 01:10 PM #8

Nick Gammon said:

What I think I am seeing is the prompt being deleted (so you get the scroll) and then a new prompt appears and the screen jumps back up.

What could help here is to make the prompt end with a newline.

...make the prompt end with a newline. Hmmm... I'm not sure I follow.

Nick Gammon said:
If that doesn't work, can't you just make two triggers, as you suggested in the linked thread?

The first trigger could enable a match for the second trigger, and both could omit from output. Then the second trigger could disable itself.

I'm trying to avoid two triggers because this "openTheChest" example I gave is just 1 case where I'm doing this. I have 4 or 5 other examples where I'm using the say command to send message to other players, and I want that information to be removed from the output. So being able to do 1 multi-line trigger with DeleteLines is more desirable. However, if I can't fix the scrolling issue, then I guess I'll have to rebuild them all as 2 triggers.

Nick Gammon Australia Forum Administrator Wed 13 Mar 2019 10:01 PM #9

Quote:

...make the prompt end with a newline. Hmmm... I'm not sure I follow.

I thought I saw the prompt appear and disappear. However partial (prompt) lines are not processed until a newline. If you can configure the prompt line (at the MUD server) to terminate with a newline that might help.

Quote:

I'm trying to avoid two triggers because this "openTheChest" example I gave is just 1 case where I'm doing this.

Yes, but the second line could be a generic trigger that omits anything (ie. match on "*" not as a regexp). Then each of the other ones is a single trigger which enables this "omit the next line whatever it is" trigger, which then disables itself. So you aren't doubling the number of triggers you need.

Or if that doesn't work reliably have each trigger (the one matching the first line) put into a variable what the next line is expected to be, and have the "second line" trigger match that variable.

Like this:


<triggers>
  <trigger
   expand_variables="y"
   group="Follow the Leader"
   match="@!what_to_omit"
   name="OmitNextLine"
   omit_from_output="y"
   regexp="y"
   send_to="12"
   sequence="100"
  >
  <send>

EnableTrigger ("OmitNextLine", false)

</send>
  </trigger>

  <trigger
   enabled="y"
   group="Follow the Leader"
   lines_to_match="2"
   match="^\&gt;?say openTheChest$"
   name="hideOpenChestMessage"
   omit_from_output="y"
   regexp="y"
   send_to="12"
   sequence="100"
  >
  <send>

SetVariable ("what_to_omit", "^\\&gt;?[*][*][*]$")
EnableTrigger ("OmitNextLine", true)

</send>
  </trigger>
</triggers>

Now you have a generic trigger (the first one) that omits whatever matches the (regular expression) variable contents of what_to_omit.

It's not particularly obvious above, but in the script you could just use ">" rather than ">" because this is not XML. Also you double the number of ~~underscore~~ backslashes because this is a Lua literal.

In other words, in the script "send to" box you would type:


SetVariable ("what_to_omit", "^\\>?[*][*][*]$")
EnableTrigger ("OmitNextLine", true)

Nick Gammon Australia Forum Administrator Wed 13 Mar 2019 10:04 PM #10

The simpler version, that just omits the next line, whatever happens to be in it, looks like this:


<triggers>
  <trigger
   group="Follow the Leader"
   match="*"
   name="OmitNextLine"
   omit_from_output="y"
   send_to="12"
   sequence="100"
  >
  <send>

EnableTrigger ("OmitNextLine", false)

</send>
  </trigger>

  <trigger
   enabled="y"
   group="Follow the Leader"
   lines_to_match="2"
   match="^\&gt;?say openTheChest$"
   name="hideOpenChestMessage"
   omit_from_output="y"
   regexp="y"
   send_to="12"
   sequence="100"
  >
  <send>

EnableTrigger ("OmitNextLine", true)

</send>
  </trigger>
</triggers>

Now you only need one copy of the first trigger, and enable it in all of your triggers that are going to match two lines. I think that is pretty simple.

Blixel Thu 14 Mar 2019 02:49 AM #11

Nick Gammon said:

Yes, but the second line could be a generic trigger that omits anything (ie. match on "*" not as a regexp). Then each of the other ones is a single trigger which enables this "omit the next line whatever it is" trigger, which then disables itself. So you aren't doubling the number of triggers you need.

Or if that doesn't work reliably have each trigger (the one matching the first line) put into a variable what the next line is expected to be, and have the "second line" trigger match that variable.

Like this:


<triggers>
  <trigger
   expand_variables="y"
   group="Follow the Leader"
   match="@!what_to_omit"
   name="OmitNextLine"
   omit_from_output="y"
   regexp="y"
   send_to="12"
   sequence="100"
  >
  <send>

EnableTrigger ("OmitNextLine", false)

</send>
  </trigger>

  <trigger
   enabled="y"
   group="Follow the Leader"
   lines_to_match="2"
   match="^\&gt;?say openTheChest$"
   name="hideOpenChestMessage"
   omit_from_output="y"
   regexp="y"
   send_to="12"
   sequence="100"
  >
  <send>

SetVariable ("what_to_omit", "^\\&gt;?[*][*][*]$")
EnableTrigger ("OmitNextLine", true)

</send>
  </trigger>
</triggers>

Now you have a generic trigger (the first one) that omits whatever matches the (regular expression) variable contents of what_to_omit.

It's not particularly obvious above, but in the script you could just use ">" rather than ">" because this is not XML. Also you double the number of underscore because this is a Lua literal.

In other words, in the script "send to" box you would type:


SetVariable ("what_to_omit", "^\\>?[*][*][*]$")
EnableTrigger ("OmitNextLine", true)

Thanks for the reply again. I think I've set this up... or something like it. It seems to be working well and doesn't cause the window frame to scroll back up 1 line any more.

I think this is the better way to handle it in my case ... having the say message enable the 3 stars trigger, and then having the 3 stars trigger turn itself back off and omit its own output.

The other method you mentioned looks simpler, but I think it may be possible for the game to send a message at such a time as a line could come between the say message and the 3 stars. Probably unlikely, but seems like it could happen. So I don't think I can rely on always deleting the very next line.

At any rate, this issue seems to be resolved. Now on to the next problem :)