Hmm - I see the fur has been flying while I have been researching my reply. Neva, I try to support my software - less than 24 hours have elapsed and I believe I have a workable solution for you, partly thanks to Shadowfyr who reminded about the \xhh codes in regular expressions - thanks Shadowfyr. :)
Quote:
- That's the character in question being used. No, I don't know what it is, exactly.
How do you type it in if you don't know what it is?
Judging by your post, the character is hex 1C, which is Control-backslash.
However, if you go into "edit trigger" you can't type control-backslash into the "trigger" or "sent" fields. I am presuming that you are doing a copy and paste to get the character into those fields.
I was surprised to find a "major bug" in the loading/saving of worlds - this technique of using XML world files has been in MUSHclient since version 3.21 - released on 16th May 2002, over 7 months ago. No-one else has commented or complained, and if they had I would have looked into it.
My downloads web page warns about incompatibilities between version 3.21 onwards and earlier versions, particularly in saving world files, and advises you to back up your world files before upgrading. If you had done this then you could have stuck with the earlier version whilst this issue was resolved. The extra 10 minutes per day then wouldn't have been necessary.
Quote:
Neither Notepad nor Wordpad has any trouble whatsoever loading the world file.
Yes, they read them into memory, of course, because they treat a file as a block of data, they don't "parse" it. The fact that you cannot say what the character is, is surely some indication that it is an unusual character.
I deliberately built that check into the parsing routine, to stop "rubbish" getting into your world file - such as your character. You can't "look" at it - it just shows up as a black blob, and it isn't obvious what it is. I was suggesting that as a "suggested enhancement" the check could be disabled.
I stick by my earlier comment that if you can't type a character into the GUI dialogs, then it isn't that unreasonable for the client to not support loading it. For instance, you would have trouble putting the "tab" character into a trigger, because pressing tab moves from one field to another. However you can obviously fool it by copying it from a different program and pasting it. This is how you got the character into the trigger in the first case, I would guess.
Quote:
And considering that importing XML is essentially loading text and then parsing it, and other text editors do not in fact choke on this character,
MUSHclient hasn't choked - it has hit a design decision, indicated by a proper error message. I made a conscious decision to limit characters in the range 0 to 31 decimal, and your character failed that test. A major reason for that decision is that such characters cannot be represented on the screen (they all show up as black rectangles) and thus are pretty useless in the GUI interface, plus as a secondary consideration I had not heard of MUDs using such characters, other than as ANSI control codes (eg. colours) which are already correctly dealt with.
Solution
However having said all that, there is a solution. :)
Simply make your triggers (the ones with the problem) regular expressions if they are not already (click on the "convert to regular expression" button) and then change that character to be:
\x1c
That will make the regular expression parser convert the character "on the fly" and thus it can be saved and loaded without problems in the world file.
PS - as for the comments about "bugs" and "suggestions" I have a bugs/suggestions database, into which I place things to be implemented in future versions. My comment was merely intended to reassure you that your message hadn't been forgotten and was "on the database". There is a cross-over between bugs and suggestions - one person's bug might be another person's suggestion. For example, if I had allowed non-printable characters in, someone might have stuck them into an XML file, and then complained that they were *not* rejected.
|
![[Go to top]](/images/gototop.gif){kind=small}
top