Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ General ➜ Problem in receiving text from the mud.
Problem in receiving text from the mud.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Posted by Kvothe   (9 posts)  Bio
Date Sun 19 Apr 2020 02:34 PM (UTC)
Message
Hello, I have a problem when creating new characters in muds. First of all, I clarify that I am blind and I have no idea if the same thing happens to those who see it or not.
I will try to explain the problem as best as possible.
When I enter a command, the response from the mud does not reach me, so for example, if I put the name of the player, the message that I enter the password does not appear.
It is strange because the only way I found to read in this type of cases, is to send anything to my client locally and there if it is updated.
I give an example and sorry for my English:
the mud sends: Character name:
I write: test
There the mud sends me to enter the key, but I cannot read it, for this, in an alias I put a Note ("update")
And there if the following appears in the output:
Password:
update
That is, I see the text that did not come to me from the mud and below my Note.
This only happens to me in character creation, login or very specific situations such as password change.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #1 on Mon 20 Apr 2020 06:03 AM (UTC)
Message
It sounds like the "echo off" telnet message which the MUD sends (so people can't see your password) is confusing the screen reader.

Under the world configuration -> Input -> Commands tab there is an option "Ignore 'Echo Off' Messages".

If you check (activate) that then the problem will hopefully go away.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Kvothe   (9 posts)  Bio
Date Reply #2 on Mon 20 Apr 2020 07:18 AM (UTC)
Message
Hello, thanks for answering. I have that option checked and still it remains the same.
I also have checked the option: "Convert IAC EOR / GA to new line".
The funny thing is that it is not only when you have to put passwords, in the whole process of creating character the same thing happens to me, when putting attributes, race, etc.
Greetings.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #3 on Mon 20 Apr 2020 07:44 AM (UTC)
Message

then the problem will hopefully go away.

Sadly, hope was not matched by reality. :)

OK, well now I think the issue is that the screen speaking stuff reads out the line when it has fully arrived. That is, there is a newline. Now, questions like “What race do you want?” do not have a newline because they want your answer next to the question, and not on a new line.

This is why the client, since 19th Dec 1995, displays lines on the screen even before the newline. However the screen reader plugins only speak when the entire line has arrived.

So, what you probably need is some plugin that forces a newline if, say, 2 seconds have elapsed without a newline arriving.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Kvothe   (9 posts)  Bio
Date Reply #4 on Mon 20 Apr 2020 08:43 AM (UTC)
Message
That may be, how could I do it?
Wouldn't it be possible to add a line break to all text received from the mud in the plugins used with the screen reader?
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #5 on Mon 20 Apr 2020 09:40 PM (UTC)
Message
You can't really do that, because output from the MUD is broken into packets, and a packet may end once a certain amount (like 1000 bytes) have been sent. So you may get a newline in the middle of a line or even in the middle of an ANSI colour sequence, turning it into rubbish.

This timer might achieve what I was talking about:


<timers>
  <timer enabled="y" 
         second="2.00" 
         send_to="12"
>
  <send>

local lastLine = GetLinesInBufferCount ()

if not GetLineInfo (lastLine, 3) and  -- if no newline
   not GetLineInfo (lastLine, 4) and  -- not note line type
   not GetLineInfo (lastLine, 5) then -- not player input (ie. an output line)
   
   local timeThere = utils.timer () - GetLineInfo (lastLine, 12)
   
   if timeThere &gt; 2 then
     Simulate (string.char (10))
   end -- if
  
end -- if this is an output line with no newline

</send>

  </timer>
</timers>


To install, see:

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



What this does is:


  • Every two seconds, check if the most recent line from the MUD has no newline, and is an output line
  • If so, it checks if the line has been there for two or more seconds
  • If so, it simulates a newline arriving


That should force the SAPI speaker to say the line. It seemed to work when I tested it.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Kvothe   (9 posts)  Bio
Date Reply #6 on Mon 20 Apr 2020 10:12 PM (UTC)
Message
Thank you very much, it worked. I would like to know if it is possible to check this every much less time, for example every 0.2 seconds or something like that.
It works as it is, but it has quite a delay until the missing part of the text arrives.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #7 on Tue 21 Apr 2020 02:45 AM (UTC)

Amended on Tue 21 Apr 2020 05:07 AM (UTC) by Nick Gammon

Message
Doesn't this only happen occasionally? Like, when you log in?

However you can reduce the time by changing the number of seconds for the timer from 2.0 to something smaller. And also change the test in the code (testing timeThere) to be less than 2.

In a worst-case scenario the timer will take 2 seconds to fire, and then it will wait another 2 seconds to send the newline. If you change both of those to 0.5 it should be a reasonable compromise (however see my post below).
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #8 on Tue 21 Apr 2020 05:06 AM (UTC)
Message
I don't think you should make the time really low, because then you may get it splitting lines in two. For example, a packet is received and processed, taking 0.3 seconds, and then this code kicks in and adds a newline (if you made the interval very small).

The reason I went with two seconds was that I thought that if no newline arrived in that time, it probably wasn't going to.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

28,126 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home