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
➜ Bug reports
➜ Serious problem with version 3.20?
|
Serious problem with version 3.20?
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Pages: 1 2
| Posted by
| Rage
(15 posts) Bio
|
| Date
| Mon 17 Jun 2002 11:07 PM (UTC) |
| Message
| I work on a MOO, and have encountered the following problem. The following text:
if (player.race_name == "Human" && player.weight < 9999)
is converted to the following as it is being sent to the game:
if (player.race_name == "Human"
I have connected to the MOO with Zmud and this problem did not occur. I didn't have this problem in my previous version of MUSHclient, but I can't recall what version that was... pretty recent tho.
-- Rich | | Top |
|
| Posted by
| Rage
(15 posts) Bio
|
| Date
| Reply #1 on Mon 17 Jun 2002 11:19 PM (UTC) |
| Message
| More details... It seems this actually stemmed from a setting I changed, not the upgrade. I was playing with MXP and set the world file to "always use MXP" despite the fact the MOO does not have MXP support built in. Unfortunately, however, I don't know if this is a foreshadowing of a potential MXP problem in MUSHclient, or if it is simply relative to the fact that the client was trying to intepret MXP that didn't exist.
I don't know of a game off hand that supports MXP, but all I needed to do to test this problem was say
if (player.race_name == "Human" && player.weight < 9999)
and it would come out as
if (player.race_name == "Human"
I'd be interested to hear if this is in fact a MXP intepretation problem or not. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,165 posts) Bio
Forum Administrator |
| Date
| Reply #2 on Mon 17 Jun 2002 11:38 PM (UTC) |
| Message
| You shouldn't turn on "always use MXP" unless you are sure the MUD is sending MXP. This option was added to allow for servers that were sending MXP but not negotiating correctly (eg. if you manually typed "mxp on" to the MUD server).
You can turn on "MXP debug level" to other than "none" and you will see a message for the lines in question.
MUSHclient is taking the ampersand as the start of an "entity" (eg. & ) and is discarding it because it doesn't match a recognised entity. The error message will say as much.
Various MUDs support MXP, including the Dawn Of Time implementations around. Also the SMAUG server on this site has MXP added (see downloads page).
In the example you quoted, if the MUD was using MXP, then the ampersands (and < sign) should have been turned into entities, eg.
if (player.race_name == "Human" && player.weight < 9999)
So, either the MUD server should be doing the conversion *if* it is trying to send MXP, or don't turn on "use MXP" if it isn't. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Rage
(15 posts) Bio
|
| Date
| Reply #3 on Mon 17 Jun 2002 11:57 PM (UTC) |
| Message
| Nick:
Does this mean that the mud has to turn off MXP support whenever it wants to use an ampersand, then turn it back on after, if it's going to support MXP? | | Top |
|
| Posted by
| Shadowfyr
USA (1,791 posts) Bio
|
| Date
| Reply #4 on Tue 18 Jun 2002 12:11 AM (UTC) Amended on Tue 18 Jun 2002 12:51 AM (UTC) by Shadowfyr
|
| Message
| If I might point out.. this is similar to another problem I mentioned previously about <>. The arguement for not fixing it was that it would not be 'standard' implimentation. The only problem with that theory is that I recently found out that Zugg, the creator of zmud created the original specification for MXP and thus 'should' be assumed to be the one setting the standard for how it is implemented and handled. If zmud does not do this, but MUSHClient does, then who is the one failing to impliment the tags and other things correctly?
Just a thought.
Addebdum-
Hmm. Ok.. I see what you mean about entities. That is an interesting complication. Perhaps when editing it would be a good idea to have it turned off. But I am slightly unclear why the client should be converted 'as' it is sent to the mud, if this is in fact what is happening. The fact that zmud doesn't make these 'always do this' assumptions is however I think a possibly valid point though. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,165 posts) Bio
Forum Administrator |
| Date
| Reply #5 on Thu 20 Jun 2002 03:58 AM (UTC) |
| Message
|
Quote:
Does this mean that the mud has to turn off MXP support whenever it wants to use an ampersand, then turn it back on after, if it's going to support MXP?
No, it means the mud has to "escape" ampersands, the same as a web server. That is, if a MUD is MXP-aware, then its output routine should convert:
& to &
My example code snippets for "converting a MUD to MXP" demonstrate that at some length. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Rage
(15 posts) Bio
|
| Date
| Reply #6 on Thu 20 Jun 2002 04:06 AM (UTC) |
| Message
| Nick:
Would it be possible to disable MXP intepretation of commands sent to the game via send file? I ran into this problem when I was uploading a text file with code in it and it presents the problem that I'd have to alter the compiler to intepret & as an ampersand, or force-disable MXP. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,165 posts) Bio
Forum Administrator |
| Date
| Reply #7 on Thu 20 Jun 2002 04:36 AM (UTC) Amended on Thu 20 Jun 2002 04:40 AM (UTC) by Nick Gammon
|
| Message
|
Quote:
The only problem with that theory is that I recently found out that Zugg, the creator of zmud created the original specification for MXP and thus 'should' be assumed to be the one setting the standard for how it is implemented and handled.
Let's get one thing clear. We are arguing about how the client should handle an incorrect MXP document. In other words, a MUD server should convert & to & so that the question about what happens if it doesn't should not arise. It's like arguing about what a TV set should do if you pour honey into it. You shouldn't be pouring honey into it in the first place, and if you do, they may all do something different.
The original MXP spec, at:
http://www.zuggsoft.com/zmud/mxp.htm
is silent on the question of ill-formed documents, so MUSHclient cannot be said to be going "against the spec".
The behaviour of MUSHclient is well-documented, see this forum post "Handling of improper MXP tags":
This was made in June 2001, and describes that that unknown entities will be dropped with an error message. So, this is hardly a bug, or a new problem.
Quote:
But I am slightly unclear why the client should be converted 'as' it is sent to the mud, if this is in fact what is happening.
I don't understand this point. MUSHclient does not convert anything sent to the MUD, MXP interpretation applies from the MUD. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,165 posts) Bio
Forum Administrator |
| Date
| Reply #8 on Thu 20 Jun 2002 04:41 AM (UTC) |
| Message
|
Quote:
Would it be possible to disable MXP intepretation of commands sent to the game via send file?
As I said in the post I was writing while you wrote yours :P it doesn't interpret MXP sent to the MUD, including by 'send file'. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Rage
(15 posts) Bio
|
| Date
| Reply #9 on Thu 20 Jun 2002 05:05 AM (UTC) |
| Message
| I'm sorry if I'm misunderstanding you, Nick, but when I send a file to the MOO thru mushclient with MXP always on, it truncated the lines where & was followed by something invalid. Setting MXP to auto-detect (noting that MXP isn't supported in the MOO) caused the lines to be passed without problem.
So, is this behavior a) intended but only affects MXP enabled when MXP is not supported b) intended and should happen in any case where MXP has been enabled (i.e both if it was forced on and if it was triggered on by the MOO), or c) not intended ? | | Top |
|
| Posted by
| Nick Gammon
Australia (23,165 posts) Bio
Forum Administrator |
| Date
| Reply #10 on Thu 20 Jun 2002 05:22 AM (UTC) |
| Message
| I find it hard to believe that having MXP on affects text sent to the MUD (MOO). The whole MXP detection and interpretation system is built around the incoming lines, not the outgoing ones.
What is probably happening is that when you view the uploaded data, stuff after the ampersand is truncated, so it *looks* like it was not sent. Turn on the MXP error messages in the MXP window and you'll see what I mean. You should get an error line every time you view the data, proving that the truncation is taking place at viewing time.
So, my answer to your question is:
d) the affect is in fact not happening, but appears to be happening as a side-effect of turning MXP on when it isn't supported. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Rage
(15 posts) Bio
|
| Date
| Reply #11 on Thu 20 Jun 2002 05:39 AM (UTC) |
| Message
| Nick:
You're correct and I'm terribly sorry for the confusion. Further tests found that this was in fact the case. The discovery of how MXP affects output coincided with an unexpected error that -seemed- to be related to missing code.
I tested it further and found that you are correct, the text was only missing from output but had been sent as intended.
Thanks for your help (and patience). | | Top |
|
| Posted by
| Shadowfyr
USA (1,791 posts) Bio
|
| Date
| Reply #12 on Thu 20 Jun 2002 07:41 PM (UTC) |
| Message
| >Let's get one thing clear. We are arguing about how the
>client should handle an incorrect MXP document.
Hmm. I do see your point to an extent, however your extending the specification by assuming that it was intended to function like a web browser and process the contents even when invalid. Until Zugg provides some info to the effect of 'if' invalid tags should produce errors your version is reasonable. It could be he chose to make erroronous ones visible in his implimentation so he wouldn't need to have special error processing, in which case the difference is simply cosmetic.
However while trying to work around the problem of it being turned on and not being on an MXP mud, (I know, I know you already said enough about this... lol), I did see a minor problem. When errors where generated, the error routine never returned the full contents of the tag in some cases. i.e. a tag in the form <abc def ghi> would get truncated to 'abc def' in the error. Since it was a while since I abandoned the attempt, there may have been a , in the tag or something where it truncated, but it definitely never returned the full tag. If my intent had been testing and I had wanted to world.note the tags to see the contents of ones that where invalid the result would not have been very helpful. This also makes 'matching' on a non-standard tag a problem if the intent is to perform some non-standard behaviour like calling a COM object. Right now it is (I assume) the only way someone can theoretically extend the implimentation unless the extension is color, variable or command definition. It is also the easiest way to extend the implimentation short of convincing someone to compile support for it into their client. | | Top |
|
| Posted by
| Kalahn
United Kingdom (138 posts) Bio
|
| Date
| Reply #13 on Sun 23 Jun 2002 05:05 PM (UTC) |
| Message
| I realise I have come late in this post, but I feel I have an independant perspective on MXP having developed a very extensive MXP implementation into Dawn (my codebase) while testing with both the MushClient and ZMud mud clients for a long period of time. I am a registered user of both Zmud and MushClient, and prior to discovering MushClient used ZMud as my main mud client for 4 years.
I can honestly say that the MushClient implementation of the MXP protocol far superior to ZMud. I would even go as far as saying that it is more true to the 'official' specification on the Zuggsoft site than the implementation within ZMud. This may sound strange, because Zuggsoft wrote most of the specification - but implementing a specification correctly is harder than writing it.
Zmud's flawed implementation of MXP frustrated me so much about one year ago that I now refuse to develop and test any MXP development against it (because of its inconsistant and incorrect behaviour). Prior to this point I had to write a number of work arounds and delay implementing features because of Zmud. This decision also was a result of Zmuds flawed MCCP implementation and the ZMUD plugin system (I was the first developer to get a plugin working with version 1.0 of the ZMud plugin API). I don't believe it is the job of the mud server developer to write work arounds for buggy mud clients. In contrast - I have not encounted a single bug in MushClient's implementation of the MXP protocol since 3.15. I have not had a release copy of mushclient crash on me ever - and only two crashes on a prerelease copy while testing some new tags.
My most recent experience with ZMud was a few months ago when a ZMud user commented that some MXP popup menus weren't working correctly on Dawn with Zmud 6.26a. I downloaded 6.26a (the latest at the time) to determine what the problem was. I spent about ten minutes isolating the fault and confirming that what Dawn was sending to ZMud conformed to the official MXP spec on Zuggsoft website. During this time Zmud crashed on my twice. The actual bug was related to popup menus which use &text; within elements.
E.g.
<!ELEMENT rmvnum ATT='uid=0' '<send href="goto &text;|at &text; look">'>
Then send:
[ <rmvnum>3016</rmvnum>] Kalahn is in Dancing Dragon Bar (Mekali City)
When the link is right clicked it will give you a menu with a single option (Goto 3016), if you click that option it sends 'goto 3016' to the mud. But if you left click the entry it will send 'goto 3016|at 3016 look' to the mud. It should give you two menu options with a right click, and left click should send 'goto 3016'.
Regarding the whole issue of MushClient extending the official specification, this has been out of necessity. The specification has been lacking and is still lacking in technical details. The two key areas which MushClient has extended the spec to make its own implementation consistant and future proof are the root causes of this message.
1. MushClient has the ability to detect if MXP is to be used... By default it will only use MXP if a MUD server tells MushClient it can speak MXP. ZMud on the other hand assumes the mud is speaking MXP. Dawn originally did not support MXP but versions of ZMud would display a strike through with all your text because the mud sent an S (south) at the start of a prompt... e.g. <S in v26014 gnometown.are - 11:37:35 - 12:08am>. Because MushClient has to be compatiable with the official spec, you have the ability to lock MXP on (what was done in this case).
2. MushClient hides tags it doesn't know about (what could be considered an incorrectly formatted MXP stream). This enables the MXP specification to be extended in a more predicatable way, and has is the approach taken with the official HTML specs. (I assume XML as well, but can not comment). ZMud on the other hand tries to predict what someone intended and acts accordingly. Hence you send a && and it displays it, even though it is incorrectly formatted and is better ignored. One of many advantages in ignoring it is then a developer who sends that from their mud server will be aware there is a problem in what they are sending and fix it.
My two cents anyway,
- Kalahn
Developer of the Dawn of Time Codebase.
http://www.dawnoftime.org/ |
Kalahn
Developer of the Dawn of Time codebase
http://www.dawnoftime.org/ | | Top |
|
| Posted by
| Shadowfyr
USA (1,791 posts) Bio
|
| Date
| Reply #14 on Sun 23 Jun 2002 07:45 PM (UTC) Amended on Sun 23 Jun 2002 07:48 PM (UTC) by Shadowfyr
|
| Message
| Ok Kalahn, to a address a few points>
>Zmud's flawed implementation of MXP
Agreed and when I asked Zugg about something related to it he admitted it was bugged, but then so is his scripting, his timmer triggers and probably half the ohte stuff in the program. I don't think he ever 'fixed' any feature of the program before adding a new feature.
>MushClient has the ability to detect if MXP is to be used...
Zmud is supposed to (I think), but this is one of the things that doesn't work right.
>MushClient hides tags it doesn't know about...
It is definitely a better system I agree, but it does have at least one annoying habit I don't like when it hits some non-standard tag or other data. If that worked as expected then I wouldn't have a problem. However.. The basic flaw seems to be that when it hits an unknown it 'assumes' that the first recognizable word is a tag, I think it also returns the second one, if there, as data, but ignores everything else. So if I ever manage to piece together a rendering engine for near-real time pictures as I had considered, then this:
<render stream "object{sphere<0,0,0>pigment{color Red}}">
would get truncated to 'render stream' in the error. I think anyway. It has been a while since I fiddled with trying to grab the original data from the errors, but I do know that the client will not return the entire string in certain cases and thus you can't reliably support such a thing through a plugin. Since there is also no way to 'match on tag', there is no way to even work around the problem. | | 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.
66,298 views.
This is page 1, subject is 2 pages long: 1 2
![[Next page]](/images/thin_next.gif)
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top