EchoInput False after modifying World Properties.

I am surprised no one has mentioned this before, so I hope it's not a problem unique to me...

Whenever I return to the main screen after making changes in the World Properties (Adding an alias, trigger, etc), the EchoInput is set to False.

My workaround is that I have created an alias specifically set to turn EchoInput on, but I consider this a bug.

Can anyone verify this bug?

I can't reproduce that. What version are you using? When you say "false" you mean it becomes zero?

So, you do this ... ?

• You type: /world.note world.getoption ("EchoInput")
• You see -1 echoed
• You modify world properties
• You type: /world.note world.getoption ("EchoInput")
• You see 0 echoed

Between the lines '---' is pasted output from the MUD:

---
>
think Testing.
You . o O ( Testing. ).
>
-1
think About to press trigger button on menu bar, then ok on dialog box...
You . o O ( About to press trigger button on menu bar, then ok on dialog box... ).
> You . o O ( Testing ).
>
-1
You . o O ( -1, but notice my commands are NOT echoed to the mud. ).
> You . o O ( About to use 'eon' alias to set EchoInput to True... ).
> >
think Alias 'eon' was used.
You . o O ( Alias 'eon' was used. ).
-1
---

Musclient version 3.17

Perhaps EchoInput is not being set to False, but the client is acting like it has. The alias to set EchoInput to True works as a means of currecting the problem.

I can't really explain that. No-one else has reported it. Judging by the -1 which I presume is the echoinput variable, it is not in fact changing.

There are a couple of other ways input might not be echoed:

1. An alias which has "omit from output" checked. I can't explain why that would suddenly activate after showing the world configuration.

2. Check under the Display menu to see if "no command echo" has become checked. This is controlled by a telnet sequence from the MUD. Perhaps that variable is somehow becoming corrupted.

If that is the case go to the Output configuration and check "Ignore 'echo off' messages"

I have found the problem.

Blame it on me. Chalk another one up to human error. Doh!

Configuration | Input | Commands | [checkbox]Echo My Input In:

..was UNchecked.

Of course, now everything makes sense.

When I brought up the configuration menu, and clicked "ok", that setting would turn off the echo. I almost never visit that particular configuration screen anymore, so it must have slipped past me when I was looking for the cause of my problem.

Thanks Nick, and my appologies for error on my part.

I see that you are very quick to respond to questions. Your software DOES work reliably.
You are one awesome dude. :)

Actually, I have had some problems with echo input as well. Occasionally, it seems to turn itself off, although the box stays checked. I can fix it by unchecking the box, applying and then rechecking the box and applying again, but I haven't been able to track down what it is that causes it.

It could be the telnet sequence that stops echo, as I mentioned earlier. For instance, if you enter a password, servers typically turn echo off.

Just to update...

I've found that the setting I mention above, is somehow being turned off without my explicit permission.

I've now also checked the box that Nick recommended, and I'll see how the client reacts from this point forward.

Ok, I've had both boxes checked, and the problem still occurs.

For some reason, the checkbox I mentioned above ([x]Echo My Input In: [Color]) keeps getting unchecked!

This happens even when "[x]Ignore 'Echo Off' Messages" is checked.

I don't want to have to re-check that box every time I make a configuration change (elsewhere). It's easir to keep using my 'eon' alias.

I don't know why the box keeps unchecking itself. IMHO, this IS a bug. I don't know what could be causing it, although if I were to speculate, I would guess that maybe issueing "EchoInput = False" in a script somehow unchecks the box ... (yet setting it to True does not check it again).

I can't speculate as to why I seem to be the only one with this problem. Is it because I am a 'rare' person who uses "EchoInput = False" in my script?

This isn't similar to the earlier problem is it? Make sure you save the world file after making changes, otherwise they'll be back to where they were next time you load the world.

I hit the "save" icon after every change I make, and also save the world file via prompt when I close the program.

Better email me the world file so I can try it myself. You are the only one to report this, and it certainly never happens to me.

I have "echo input" on, and am always making configuration changes, partly to repond to messages here. :)

I can see one problem - there is a discrepancy between what EchoInput usually is, and what you are setting it to in the script. :)

For example, in your script:


Sub World_Initialize
' ... other things here ...
World.Note "World Initialized."
World.EchoInput = vbTrue
End Sub


You are setting EchoInput to vbTrue. However if you try this, you will see that there is a discrepancy between vbTrue and using the configuration screen ...


/world.note world.EchoInput
(response) 1
/world.EchoInput = vbFalse
/world.note world.EchoInput
(response) 0
/world.EchoInput = vbTrue
/world.note world.EchoInput
(response) -1


Note how EchoInput has gone from 1 to -1?

Now when you bring up the configuration screen a second time, it interprets -1 as "not true" and sets EchoInput to zero.

Thus, your problem will go away if you change your scripts to do this:


/world.EchoInput = 1 ' make true
/world.EchoInput = 0 ' make false


I admit this is a semi-bug, but in my defence I refer you to the web page:


http://www.gammon.com.au/scripts/function.php?action=prototypes


In it it refers to boolean values and says:


"The safest way to test for "true" or "false" is to assume that zero (0) is false, and any other value is true.

Similarly, to supply the value "true" simply supply a 1, and to supply the value "false", supply the value 0."


Thus the web page explicitly recommends using "1" as true and not some other non-zero value. :)

Ahh, looks like I made an 'ass' out of 'u' and 'me' (as the old saying goes).

:)

For convenience, I created the following variables in my script:

Const vbsTrue = 1
Const vbsFalse = 0

...I then did a search & replace, changing all 'vbTrue' to 'vbsTrue' and similar S&R for 'vbsFalse'.

Hopefully, this will correct all problems. :)

For consistency's sake, if you haven't already, you may wish to add this to your bug list. (I also noticed that the plain built-in constants 'True' and 'False' also use '-1' and '0' ...like their vb- counterparts).

I have added this as bug #429.

As usual with computers, different languages do things in different ways. MUSHclient is written in C, where the inbuilt value of 'true' is 1, not -1.

However Visual Basic uses -1 as true, not 1.

About the only thing that various languages agree on is that "false" is zero.

Thus MUSHclient should really check incoming boolean variables to be "zero" or "not zero".

In other words, rather than this:


internal_echo_input = supplied_echo_input;


it should read:


internal_echo_input = supplied_echo_input != 0;


(In C "!=" means "is not equal to").

I've noticed that I'm experiencing the same effect. There is no input echo being displayed in the output buffer. The "Echo My Input In" box has been checked and when I open the input configuration window it is still checked with no output buffer echo.

Incidentally, the input buffer isn't storing commands either even though it's set to the default 5000 lines. This same world file works with my windows 2000 installation so I'm thinking that this will get filed under "More XP problems."

Anyone else?

Try checking "Ignore 'echo off' messages".

Just tried checking the Ignore echo off box. Same problem. I just noticed that the only line that seems to be getting stored in the input buffer is my login name for the mud. This wasn't happening when I was using the last version - is there a new feature I'm overlooking?

The only relevant new feature is the one to recognise "echo off" messages. You would need to check that box *before* connecting, so check it, save the world, disconnect, and reconnect.