Problem with command history

Posted by Kvothe on Wed 14 Aug 2019 07:50 AM — 3 posts, 15,105 views.

#0
Hello, I updated the MushClient to version 5.6 and I have a conflict with the command history since it seems that the option "No Commands Echo" is automatically activated and deactivated.
That is to say that some commands save them, then stop saving several and save them again.
I find it very strange because with previous versions I have no problem.
I could temporarily solve it by activating "Ignore 'Echo Off' messages", but I would like to know if there is another alternative because I don't want the passwords to be saved in the history.
Australia Forum Administrator #1
That's strange. I don't see anything in the release notes for 5.06 that might account for that.

http://www.gammon.com.au/scripts/showrelnote.php?version=5.06&productid=0

You didn't say what version you upgraded from, so if it was a somewhat earlier version you might need to check more release notes. Having said that, I wouldn't deliberately add in a "randomly turn command history off" feature.

As a work-around you could make a couple of triggers, like this:


<triggers>

  <trigger
   enabled="y"
   match="Welcome to XXX MUD"
   send_to="12"
   sequence="100"
  >
  <send>

SetOption ('no_echo_off', 0)  -- allow echoing of commands to be turned off

</send>
  </trigger>

  <trigger
   enabled="y"
   match="You have logged on"
   send_to="12"
   sequence="100"
  >
  <send>

SetOption ('no_echo_off', 1)  -- disallow echoing of commands to be turned off

</send>
  </trigger>

</triggers>


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


The first one should match some text that appears before you are asked for your password. That turns off the "Ignore 'Echo Off'" feature. That way your password can be entered securely.

The second one should match some text that appears after you log on with your password. That turns the "Ignore 'Echo Off'" feature back on.

I can't help with the actual bug unless you can reproduce it, preferably with a packet debug capture. That is, go to the Edit menu -> Debug packets. That captures what is actually being sent by the MUD so I can reproduce what it is that is causing this.

Be warned that capturing packets can potentially produce a lot of data in the packet debug window, which will slow the client down eventually.
#2
Thank you very much, I will try to find the problem with "Debug Packets".
It is very rare because I was using version 5.5 and before 4.94 and had no problem.
In fact I also looked at the release notes and found nothing related to this.