Anyhow, since the discussion (or, at least, my own posts) lead me to consider the differences between MUSHclient and the client most of my MUSHing acquaintances prefer, namely SimpleMU, I decided to take a closer look at the current features of the latter.
Having done so, I came up with a list of a few features that for me probably would mean that if I was picking my client today, I'd pick SimpleMU over MUSHclient. Several of these I have also seen mentioned when MUSHers talk about why they prefer SimpleMU or why they picked it over MUSHclient.
Certainly, I don't think that all clients should be copies of each other ... but some these features do fall (at least in my mind) under the heading 'what every good mu* client should have'.
To those features I count:
'Spawned Windows' for any type of messages (channel/chat, pages, ooc conversations, messages via puppets, etc) that you want to separate out.
A 'mail editor' that allows several mails per world to be written out in their entirety (including with whatever commands are needed to start & send the mails) and saved for later sending. Sure, one could do this in notepad (unless one runs over the length allowed) after a fashion, but for me this is one thing that is important enough to deserve a dedicated feature.
Not quite in the 'must have' category are these:
Minimize to tray option. Third-party programs can do this, but none of the free that I have found do a good job, and on the whole I've found that it works best when integrated into the program you want to minimize. But, if anyone can suggest a solid, bug-free and free third-party program that does the job, I'd be happy with that too.
A Thesaurus as well as a Spell Checker. Actually, that's one feature alone that made me seriously consider SimpleMU, because I use one fairly consistently when I RP. If the license for the current Spell Checker could be upgraded to include a Thesuarus I think it would be appreciated by a lot of MUSHers.
The Spawning windows can be done with scripts
and/or triggers. and as far as the mail system,
how would this be possible with so many different
systems out there. Mushclient supports so many more
Features then simpleMU. I really can't see how anyone
can make a Comparison. I mean the only real competition
that Nick has is Zugg if you really want to call it
competition. Even that is like comparing Windows 2k
and windows ME(ZMud bieng ME). SimpleMU would be a
Commodore in comparison. In fact I thing Gmud32 kicks
the pants off of SimpleMU anyday.
Sorry, but I can't agree with the 'you can spawn windows' from scripts theory. As I said, you only have two options, notepad windows, which are almost totally useless or a browser windows, which is like borrowing the Exxon Valdize (complete with drunk pilot) to delivery a single loaf of bread. It may get you there, but the environmental damage in terms of possible bugs, overhead, potential crashes and memory leaks is way to high. lol
Besides, some of these things have come to be seen as 'common' features in clients. It is a bad idea to ignore things people start expecting to see.
As far as the mail handler goes, SimpleMU allows for some 7 or 8 (I just glanced quickly at how it was setup) different ways of configuring it, to allow for the most common MUSH and, I think, MUD mailers. And, seeing how standard PennMUSH @mail today doesn't include any sort of editing, I think PennMUSHes in particular would appreciate a client interface. If it could also preview (since basic Penn @mail sends as soon as you enter text, it doesn't have the option to add a bit at a time and then preview) that would be even better.
And I do disagree that SimpleMU isn't 'competition' (if one wants to call it that); it is by far the most commonly mentioned and recommended client on the MUSHes where I play. ZMud, in general, is not particularely popular.
But in any case, I agree with Shadowfyr: some of these features now fall under what people expect to find in a client.
Taking a look at how SimpleMU's mail interface works might be easiest, but I'll try to explain the features of it that I like. :)
Basically, it opens up a window which looks like a regular form with a field for subject, a field for recipient(s) and a field for the text itself.
It can also be configured (per world) to use the proper method +mail/@mail, -<text>, --/@sent, etc) of sending this information to the MU* to create a regular mail message.
It also appears to allow for saving of several completely pre-made messages for later sending.
What it doesn't allow for (as far as I could see when I gave it a quick try), but which I wouldn't mind seeing, is a way of previewing the message (that is, with any %r's and %t's and so on evaluated).
And, of course, allowing spell-checking to work within the mailer would be needed, I think.
In my favorite MUD I need *lots* of macro and the current macroable keys are very unwieldly (try pressing F7 followed by SHIFT-F2 and then CTRL-F5 in 3 seconds) and pressing F1 (I sometimes press F1 when I want to press F2 or F3) opens up the help window and change the focus from mushclient to the help file, which usually means a quick death for my character.
Macro's are fairly easy to emulate with creative aliases and linked triggers. The truly skilled among us have even been known to write plugins for such commonly used things as speedwalking paths. Client macros in all honesty generally have to be restricted to function keys to avoid conflicting with any potential mudbased features though.
-How about a function to turn off all triggers ?
I know about the enable grop triggers function but if you have lots of grouped triggers or lot of triggers without groups then it's a bit unwieldly to turn em off one by one.
- how about enabling talking during speedwalking, for example commands will not be queued after the speedwalks unless it's a command that involve movement (n, s, ne, etc). Because if you receive a tell or someone talk to you in channels during speedwalk, they might think that you are impolite if you wait for 2 minutes before answering their tells.
First of all, the mail system thing is ridiculously easy to do, just edit your mail in notepad and use paste to world to send anything you like together with commands or whatever. Secondly, irzadi is right, you can't currently turn off group triggers except through script... it would be nice if there was a "Toggle trigger group" menu item or something. Also, about the 2nd feature, i think it is easy to do that. when the user sends something that isn't one of the standard directions, send immediately instead of queueing... Great idea.
As to the addition of an @mail/+mail/whatevermail handler, that -would- be nice, though I confess that I myself use a side-by-side session of UltraEdit32 for such things, since it blows far past the Notepad size limits, and has quick and easy features for tab, end of line, etc. substitutions. It also does character counts, which is very handy for someone like me who writes -way- too long all the time. Just FYI.
The one feature I didn't see mentioned that I myself would honestly like to see would be some enhancements to the 'activity bar'. I'd like to be able to increase the number of available buttons, even if it meant I had to sacrifice ctrl-# functionality. I'd also love to be able to put 'separators'/spaces in between buttons on the bar to separate out those which are going to different worlds - I have a few worlds where I have two, three, even four or five different alts logging in at the same time and I'd like to be able to group them together.
The ability to specify a preamble of some sort and then configure to break that out into sub-windows (loggable, please, just in case?) for channels, puppets, etc. would also be wonderful if possible.
As a feature to help a friend, I'd also love to find a way to get MushClient to accept input from Dragon Naturally Speaking, but I'm guessing that might be a configuration failure on my part rather than anything else right now.
"As I said, you only have two options, notepad windows, which are almost totally useless or a browser windows, which is like borrowing the Exxon Valdize (complete with drunk pilot) to delivery a single loaf of bread."
Since it is almost Christmas again, I figured I'd resurrect this thread and ask again whether any of the enhancements mentioned in the first post ('properly' spawned windows such as SimpleMU has, a dedicated mail editor, minimize to tray and a thesaurus) might be added in the future?
I know alternatives were offered for some of the suggestions (such as spawing windows into notepad, or just saving mail in the notepad), but I think all of those solutions are less than ideal work-arounds and that they rely too heavily on people being able to script their own solutions. And even with the scripting you can't do quite what I was looking for.
the point of giving scripting flexibility, and coding plugins is to allow individuals to add to their own client, rather than be forced to carry around bulk that the majority of the other people might not ever feel the need for.
I am aware of this. However, how many people can script? Making enhancements only to the scripting engine, and telling people to script their own add-ons rather than adding them to the program itself, turns the program into something that is only for the specialists, at least if you want new features.
Sure, a lot of people are really generous and share their scripts, but the majority (if not more or less everyone) of those who script seem to be MUD players who, naturally, do stuff that is useful for playing MUDs. This rather leaves MUSH players in the dust, since the things they'd like to see never gets added. And while the client may have been renamed MUclient, it did start out as MUSHclient, and a large number of MUSHers rely on it.
I think the scripting is a good idea, and one that allows great flexibility, but I don't think it should replace development on the client itself, and I must admit that I feel like it has. I think that if features are suggested that sound like good ideas which can be done without excessive bloat and which can't be done perfectly through scripting (and this is the case for the spawned windows and the mail interface; scripting can only do a clunky work-around solution), they ought to be added into the program itself.
I see where you are coming from Linda, but I am still a bit conscious of not wanting to gradually bloat the client with extra features every few months, although I know other clients do just that.
The last major "extra feature" was the chat system, and that was largely because it was almost impossible to script that because of the tight integration needed with the bulk of the client for accepting incoming TCP/IP calls, messages and so on.
However as I demonstrated recently with the "fancy health bar" external VB program, you can do virtually anything if you write a script or separate program.
Now I know this doesn't help if you are not a scripter, and of course you should be able to use the client if you are not. The possibility exists, though, to find someone who will write a plugin/separate program to do what you want (eg. the mailer), and this can be done tomorrow without waiting for a new MUSHclient version.
I'll bear your comments in mind - in fact I'm not sure they made it to the official suggestion database, so I'll put them there now ...
I do agree that bloat is a bad idea, but what one person considers bloat, another might consider necessary.
The chat system, for example, always seemed like bloat to me, whereas 'properly' spawned windows is the kind of thing I'd love to be able to have without having to resort to redirecting things to the notepad which does not give you what I see as a crucial part of spawned windows, namely a separate input window for each.
The notepad method also ends up sticking them rather 'out of the way' (I always seem to 'lose' my notepad windows), and it subjects them to the size limit of the notepad, but the most crucial problem is definitely the lack of a separate input window.
That would cost me $US 499 to buy it, and redistribute it.
I suppose the question is, is it cost-effective? It would be great to have a thesaurus, but MUSHclient is currently selling without one, and to my mind, if you need to look up a synonym most people would have a program like Word where they could quickly swap across to look something like that up.
The spell checker I can see the point of, because "spell check before you send" is a useful thing, and it would be tedious to copy and paste every command from MUSHclient into Word every time you sent it, but would you really need the thesaurus that often?
Personally, yes, I'd use the thesaurus regularely. Especially when working on descs and other write-ups in the notepad window, but also during actual roleplay. As it is, I tend to partially work around it writing descs and similar things in Word, but since it eats memory I usually don't keep it open during roleplay, so I can't use it for synonym-checking when writing poses.
Of course, I can't say whether it'd make the program sell better. It would have been neat if it was possible for those who were interested to purhase it as an add-on for themselves.
Could always use webpages, Dictionary.com (or thesaurus.com I guess).
Uses less resources than word, Im sure you can find stand alone thesaurii out there, and you could with a little work integrate it to the command like through scripting (COM calls)
Personally I dont see a need to have real time Thesaurus lookup, Spellcheck could be used in a real time thing, but a thesaurus just doesnt fit in my mind. Sure, for building or whatever, but thats time independant.
Sure, you can use a webpage, but I do prefer programs that I write a lot in (which includes MUSHclient during RP sessions) to have both a spell-checker or a thesaurus included. Otherwise I wouldn't have brought it up. :)
And, no, I doubt I could include a thesaurus myself through scripting. I really don't understand it at all.
I quite understand if some people don't see the use for a real-time thesaurus, but some other people do see it as useful. Certainly, I know a lot of MUSHers who would use it.
But, as I said, I don't know if it would end up being cost-effective or not.
Given a COM-object thesaurus, I or probably a bunch of other people here could make a script that outputs a list of synonyms to the world via echo or something.
I just don't have time to go looking for one or anything, but if you gave me one I could probably futz around with it and get it to work...
The problem with having it built into MUSHclient is that Nick would have to pay $500 for it, and he'd probably have to either rise the price for MUSHclient, lose money, or have two separate pricings (one with and one without thesaurus), none of which look like attractive options from anybody's perspective (i.e. we pay more, he pays more, or he does a lot of work and ends up with two separate versions of MUSHclient to register/maintain/everything.)
Well.. One option, though admittedly not too integrated would be to do:
dim IE
set IE = createobject("InternetExplorer.Application")
sub Lookup(name, output, wilds)
'In case some fool closed our window.
if typename(IE) <> "IWebBrowser2" then
set IE = createobject("InternetExplorer.Application")
end if
IE.Visible = -1
IE.Navigate "http://thesaurus.reference.com/search?q=" & wilds(1)
end sub
Of course, this isn't quite as good as direct integration and it would imho be a lot nicer with a lot less bloated and simpler browser that could just display the page, but it works as a solution for the time being.
Yeah, point being, everyone doesnt have to learn to script, We've got a plugins page, with plugins that you can drop into mushclient with minimal tweaking for your own situations.
So, people dont nessisarily need to know how, just have to know what they want, the community is pretty efficient at creating things of the sort.
Technically it could be done via thesaurus.com, but thatd add the lag time needed while the webpage loaded.
Just with an initial search, Rogets thesaurus has a freeware version on TuCows, its 2.1 Mb so thats a bit bulky.
There are also some others, point being, theres a bunch of freeware thesaurii out there, someone just needs to figure out which one would be the easiest to code a COM interface for.
I think for a thesaurus to actually be useful, however, you need to be able to use it by right-clicking on the word you want synonyms for, selecting the thesaurus option of the menu (just like you select spell-check) and then being presented with a list of synonyms where you can click on the word you want to have it replace the original word. And that seems terribly complex to manage through scripting.
One thing you could do is use an external VB application that talks to the thesaurus. MUSHclient would need to have added functionality to do things like:
- retrieve currently selected text (from input line or from output window)
- modify currently selected text (from input line only)
The basic idea being that you would select the text, launch the VB application using a keyboard shortcut, it would get the text from MUSHclient using the selected-text-getter, it would then give you a nice fancy list-box where you can double-click, further look up words, etc., and finally when you double-click it tells MUSHclient to replace current word with the word you just selected.
How's that for a good alternative? It only needs two things added to MUSHclient's scripting engine, and then it becomes that much easier to have a nice interface and all that.
When I have time I'll do some browsing around for a thesaurus COM object. Not sure when that'll be, because I don't have a lot of spare time these days.
Could double click the word, (to highlight it) then ctrl-c (to copy) then ctrl-click (to bring up the menu) and then select thesaurus (this ctrl-click could also be macrod to a key combination) then you get a list of words (perhaps a brevity could be set so you dont get spammed with 100 entries) then if we made them hyperlinks, could click that word then it would pushcommand, search that from the history, find/replace the word, and send the text back to the command window.
Personally, I would hate that, since it would keep spamming the output list. Furthermore, you'd have to be able to click on the output window while more text is coming in... or have to keep pausing the output.
The VB window could even be in float-always-on-top mode, you could stick it in a corner of your application and it would do that stuff on its own. Another fairly cool feature of the VB app would be to be able to do lookups on the synonyms you found.
About the only thing you could do is have a function key programmed to cause an alias to execute, have that alias' script copy out the entire line, then run each individual word through the thesaurus, if you changed the line at all, then the script would clear the existing one and replace it with the altered one. The major pain with this is a) you would need a 'local' thesaurus database to check, or it would hit you with a 20-30 second of freezing Mushclient every time it executed the INET control command to retrieve a page (using IE here wouldn't work), b) you can't tell it to only check one word (or even get the cursor position to have the script figure out which one to request and last c) it would be a pain in the rear for even me, knowing how the control works, to do it. Oh yeah, and it would only be able to retrieve the first page or choices, without even more mind bending code to check for multiple ones (add another 20-30 seconds 'per' page here).
An external and inexpensive solution is to make it possible to do GetWordUnderCursor and ReplaceWordUnderCursor and then have an alias (for the right click menu) or a macro key call a script that did those things and called an external thesaurus to find the needed words. This would be a lot more usable and could allow for not just thesauruses, but word translators, etc.
As for spawned windows.. I had this idea for additions to that:
Added to the XML:
<!-- Control events would allow response to Click, DblClick, Change and other
events from the controls. -->
<trigger
match="OnButton1Click"
ControlEvent="y"
script="ClickThis">
</trigger>
<!-- Option 14 would be 'Send to Window'. -->
<trigger
match="gossip: *"
label="Text1"
send-to="14">
</trigger>
<!-- Responds to the Enter key being pressed and can thus work like an
input box for a chat window. -->
<trigger
match="OnText1Enter"
ControlEvent="y"
</trigger>
<window>
name="Window1"
top="0"
height="70"
left="300"
width="100"
<Button
name="Button1"
caption="Click This!"
top="50"
height="15"
left="1"
width="20">
</button>
<Textbox
name="Text1"
text=""
top="35"
height="10"
left="1"
width="98">
</Textbox>
<Picture
name="Pic1"
picture=""
top="1"
height="29"
left="1"
width="29">
</picture>
</window>
To the script command set>
World.CreateEventTrigger (BSTR match, BSTR Script)
World.CreateWindow (BSTR Name, INTEGER Top, INTEGER Height, INTEGER Left, INTEGER Width)
World.MoveWindow (BSTR Name, INTEGER Top, INTEGER Height, INTEGER Left, INTEGER Width)
World.CloseWindow
World.CreateButton (BSTR Name, BSTR Caption, INTEGER Top, INTEGER Height, INTEGER Left, INTEGER Width)
World.RemoveButton (BSTR Name)
World.MoveButton (BSTR Name, INTEGER Top, INTEGER Height, INTEGER Left, INTEGER Width)
World.SetCaption (BSTR Name, BSTR Caption)
'This I assume would use your fast output window object, since the only real alternative is the RichText control.
World.CreateTextbox (BSTR Name, INTEGER Top, INTEGER Height, INTEGER Left, INTEGER Width)
World.MoveTextbox (BSTR Name, INTEGER Top, INTEGER Height, INTEGER Left, INTEGER Width)
World.RemoveTextbox (BSTR Name)
World.SetText (BSTR Name, BSTR Text)
World.AppendText (BSTR Name, BSTR Text)
World.ColourAppendText (BSTR Name, BSTR Foreground, BSTR Background, BSTR Text)
World.GetText (BSTR Name)
World.GetLine (BSTR Name, LONG Line)
World.GetTextLines (BSTR Name)
World.ClearText (BSTR Name)
World.CreatePicture (BSTR Name, BSTR filename, INTEGER Top, INTEGER Height, INTEGER Left, INTEGER Width, INTEGER Mode)
'Mode would be stretch, tile or center. I think it is center anyway..
World.MovePicture (BSTR Name, INTEGER Top, INTEGER Height, INTEGER Left, INTEGER Width)
World.SetPicture (BSTR Name, BSTR Filename, INTEGER Mode) ' Should probably reload
'if the filename is the same, in case an external program changed the image.
World.FillePicture (BSTR Name, BSTR Color)
Optional>
World.Draw (BSTR Name, BSTR Commands)
'Simple implimentation of QBasics DRAW command. Not 'quite' as good as real drawing commands, but simpler than coding them all. They can use a real program for that. ;)
World.SavePicture (BSTR Name, BSTR Filename)
' Only useful if the above is allowed or real drawing can be somehow allowed. It should only work when the image mode is 'center', since tile would be confusing and I am not sure how stretch deals with drawing.
Hopefully everything is more of less self explainatory.
Not sure how much actual bloat this would add. It does add a mess of new commands, but while the window creation code and means to handle 'where' the events get sent are possibly complicated, the actual controls are just standard things you plug in when you need them. Then again, I don't have much experience with C++, so it may be insanely more complex in reality.
Anyway, I figure those three controls cover 'most' things you may want to do. A grid control would however be nice to have for databases, etc, but I am not sure how events on that are handled. If there are other useful controls, then the biggest hassle is figuring out what commands are needed to set things up and what events you actually want to keep track of. Most only use 'Click', 'DblClick' and 'Changed' though.
I figure having the events defined as part of the list of triggers would make them easier to keep track of. Though, it makes no sense for them to have a sequence number and should probably always appear in the list either first or last.
Making this sort of spawnable window also makes suggestion 496 'a mail editor' redundant, since you could easilly code one in script using such a window, not to mention a mess of other stuff.
---
Oh yeah, QBasic's DRAW feature:
'These draw by 1, if # is not given.
D# - Down by #
E# - Up and right by #
F# - Down and right by #
G# - Down and left by #
H# - Up and left by #
L# - Left by #
R# - Right by #
U# - Up by #
M<+,->#,<+/-># - Move to #,# or relative + or -.
C% - Sets color (an integer or in Mushclients case also maybe a color name).
I assume these work like [B D2 U L4], only way it makes sense..
[B] - Move but don't draw.
[N] - Draw, then return to first position.
There are also commands that do scaling and rotation, but that would get complicated, since instead of just drawing, you could need to keep track of each thing drawn as a seperate object to be scaled and rotated. I am not even sure how QBasic handled that. lol
Hmm. Almost forgot.. Since you can ImportXML, then:
World.ExportWindowXML(BSTR Name, BSTR Filename)
would be nice for saving all the stuff you set up from in script. I am not sure saving it in a state file is practical. Making a plugin with the result could be as simple as adding an option to 'import XML file' in the process of using the plugin wizard to create one. ;)
I have to admit that I can't quite figure out how your suggested spawned windows would work, especially not how the separate input window would be handled. :) And there's still the issue of the size limit in the notepad, isn't there?
Also, regarding the mail editor suggestion, one of the main advantages of that (as I see it) would be to be able to work on and save (for later sending) several different mail at any given time, and also to be able to have it be setup to handle the mailsystem in each world correctly.
Well Linda, a spawned window is just an object. as far as the program is concerned. If you use Spy++ then mushclient with one window open looks like this:
Basically any window 'you' created would in the above case become another child of Window 000000A8 (since that is the 'world' window). If you click a button on your new window, that message gets passed to your window, then if nothing in that can handle the message, it gets handed to 000000A8, which would then check 'what' the event was. If it was a 'click', then it would look for On<object>Click in the triggers and do whatever that trigger specified. Same with other any other events. The trigger could do any of the things that a trigger or alias could do, including executing scripts. I know this would work, I have seen examples of it and in C++ it is probably more likely to work than in VB, which the examples I saw where for.
So, for your mail editor, you could concievably store messages to be posted later (just copying out the textbox contents and storing it until needed), edit multiple ones at a time, by opening multiple new windows, etc. Yes, you still need someone to write all the script to manage this, but you also don't get nailed with a program that 'almost' does what you want, but not quite and which you can never ever fix. Any third party solution would be like that. Any built in would require waiting for Nick to fix a problem or worse, convincing him it needed to behave differently than what it does.
Assuming a Grid control was also made available, then you could make a plugin that would work and look like any normal mail or email client, it is just a matter of someone coding one. This is a 'major' improvment over the kind of spawned window most people are talking about, which are basically a notepad that does color and 'maybe' also its own input box. Better yet, if you can get a handle to your new window (something I left out) then any control you can use CreateObject with could be bound to that window and its Click, DblClick, Changed or other supported events automatically supported by event triggers.
An external application would still be better in maybe half the cases, where time consuming things need to happen, but for the other half the time you can make a simple (or complex) plugin that does what would otherwise require the use of a compiler, which not everyone has. It is the inability to create or use such a thing in Mushclient that makes even the simplest addon require an expert in VB or C++ to code. I think this would make life a lot easier to even those of us that can do that.
I don't know about mail systems, I have never used one, but i'm sure all the saving/loading could be easily done with a plugin, but adding mail functionality to the client would be bloated, since it's probably only useful on MUSHes. The minimise to tray, on the other hand, it pretty easy to implement (on VB anyway), and it would be useful to many people, without bloating the client more. I agree that the thesaurus wouldn't be a very cost-effective addition, but there are also many free thesaurus files in CSV format that you can add... Maybe script a little window with alternatives like Word has... That would, however, add a lot (2-3+ MB) to the client, so i propose that while thesaurus functionality would be built in (using only a small window that displays synonyms), the default thesaurus file would be very small on nonexistent, but people who want to use the Thesaurus would be able to download the extra 3 MB file from the website... That could also be done for the spellchecker, but since those files are only like 100kb zipped, it doesn't matter that much...
Having the thesaurus functionality (for example allowing you to right-click on a word to get a list of synonyms in a pop-up window which you then can select a replacement word from) built into the client, but letting those who want to use it handle the downloading a free thesaurus sounds like an excellent compromise. And, in fact, it might not be a bad idea to do that for the spell-checker either, if people want to use a more updated dictionary. Now, if the same approach could be used to make the spell-checker more 'intelligent', that'd be even better. And hooking into Words English Grammar checker would be nice too. ;)
However, when it comes to the mail, I think it is wrong to say 'its bloat because it would only be useful on MUSHes'. Judging by the name, at least, MUSHclient clearly started out as a client for MUSHers, so why shouldn't a feature be included if it is only used on MUSHes? There are plenty of current features in the client that are only useful on MUDs, after all.
Still, if it can be done well through scripting, that's one thing, but I still remain rather unconvinced that you could use scripting to do a good job of either properly spawned windows or a mail editor. Partly, I don't quite follow the technicalities of how it could be done, so I really only could say whether something was a good solution after seeing it in action.
Another old topic, but I wanted to bring up the thesaurus issue again. I am not at all sure what sort of dictionary and thesaurus packages are needed to work with something like MUSHclient, but looking around some through Google, there does seem to exist various kinds of freeware and open source solutions for these things.
Might this not be something to look into to be able to add this functionality without having to purchase a license for a thesaurus?
I don't recall that being mentioned. However the current spellchecker is implemented as a separate Lua module, and there is nothing really preventing that module loading a DLL with the Aspell code in it.
In other words, that could be a good 3rd party project for someone who is keen. :-)
I haven't had heaps of complaints about the current spellchecker, it is reasonably fast and uses the metaphone algorithm to make suggestions, which works reasonably well. This helps make the suggested corrections be the closest to the original word, in terms of number of changes needed to reach it. I note from the Aspell web page that using metaphone is something he is planning as an enhancement, so switching to Aspell might actually take functionality away.
I have one further question question to the spell checking functionality. Is there a different method available except 'Spell check on send'? Something like underlining misspelled words? I don't want that a spell correction dialog is popping up in a hecktic situation like battles.
You can turn off spellcheck on send and instead use Ctrl+J to spellcheck when you want. Also someone recently (can't remember who) was doing an experimental spellchecker which popped up a little window above the command window and underlined misspelt words.
I kind of stopped working on it due to lack of interest and the fact I am still waiting for a new version of MUSHclient with a callback I can use when the content of the textbox changes (since I started it out as wanting a live preview of what I am typing).
Anyhow, if you are interested, I could go back on fleshing some of the last problems with it out.
Ah yes, I tried to find that thread but my keyword search failed. :(
Anyway, it looked good:
I am such a pessimist when it comes to coding, I keep thinking of things that might go wrong. For example, if there was a callback when you changed the input box, and that callback changed the input box, then you get an infinite loop. However there would be ways around that.
Yeah, I see the potential problems. But similar issues have been dealt with in the past for similar issues, like the deleting of a trigger/alias while in the execution of said thing. So that didn't seem like too much of a stretch.
Anyhow, if you are going back to work on some features, I recall another thing I hoped you'd implement was an ability to position the caret / place a selection in code. (I wanted to make Alt+<number> select the <number>th misspelled word for direct replacement.)
Edit: And yeah, English/American/Australian spelling bugs me. I am from none of those countries, but have friends in each of them I converse a lot with. So I tend to mingle the different spellings by mere influence.
I think the standard way to do it would be to handle the hole thing in the text control: Underline misspelt words on the fly and supply a context menu to supply corrections of the individual words. I think its very unusual to show an extra window representing the text you are typing with some extra styles.
I don't know which controls you are using, probaply it isn't possible to style text in the current conrol. But simulating such a cotrol as an extra window shouldn't be an option.
This is the closest thing I can do currently. I believe the fact the RichEdit control has quite a bit of history incompatibility-wise is the reason it isn't being used as input control. I know that I tend to dislike the RichEdit control as it is used for input in several programs, mostly because of small details that involve margins, styles remaining upon pasting and all those details that just bug me (given the fact they're side effects of the control and have no use in the program itself.) A simple text control is simple, to the point, and it works wonderfully.
In a similar line of thinking, one should not forget MUSHclient still supports Windows 95, and I believe a fair number of users still like to use the client on such old systems. Any version of the RichEdit control used should still work with the oldest supported OS, too.
Quote: This is the closest thing I can do currently.
Yeah I know and it is great, I never thought about implementing something like that with the current possibilities.
Quote: I tend to dislike the RichEdit control mostly because of small details that involve margins, styles remaining upon pasting and all those details that just bug me
I really know what you mean and I hate it, too. It is completely cumbersome to copy text from the browser and to get a completely messed up text.
Quote: MUSHclient still supports Windows 95
Yeah a RichText control would probably break this compatibility, which would then be out of question. But perhaps it is possible to get the position of text in the standard controls and then draw on its canvas. I don't know it that is possible with your GUI-Toolkit.
Separate chat window. So many times I'm walking around the mud and miss some chat info because it happened while I was walking. If we could separate the various chats into a different window, We could easily see what we may have missed. Possible option is to split window the chat from the rest.
Can already be scripted, either with miniwindows or easier, with normal dummy world windows. Take a search around the forums - it should not be too hard to do.
I'd like to see Tabbed Notepad. It seems I've got several of them up for various different reasons and instead of minimizing one andpulling up another, It would be nice just to hit a different tab on the side
Have you tried going into File -> Global Preferences -> General and changing Window Tabs to Top or Bottom? That way you can see all your notepad windows.
I've tried that, But I don't see any difference. I don't see it putting any tabs anywhere. I still have to minimize them one at a time and pull up the right one.
I haven't taken the time to read through the entire thread, so forgive me if this request has already been made, but...
I would really appreciate the dialogs in MUSH being made non-modal. Especially, but not limited to, the config dialogs. It would make my life much easier to be able to copy and paste from my output window without needing to close the triggers window entirely.
Also, every once in a while I get a misc. dialog from my system (a bug) that I have to close manually... interrupting combat flow.
If people like the modal windows, why not give an option for it?
Ah, no. That simply prints a notification that you were unable to connect to a world to the output screen, rather than using a dialog to do so.
What I'm looking for is all dialogs and windows within mushclient to be non-modal, meaning you could keep the window open and allow it to fall to the background, rather than having to close it.
Also, every once in a while I get a misc. dialog from my system (a bug) that I have to close manually... interrupting combat flow.
Worstje put you on the right track for fixing that. As for the dialog boxes, that isn't particularly easy to make them all modeless. In fact, modeless dialogs are a bit of a pain, they tend to get hidden under other things and you forget you have them open.
Quote:
It would make my life much easier to be able to copy and paste from my output window without needing to close the triggers window entirely.
You can always run two copies of the client - one to grab stuff from the output window, the second one to configure.
Actually, the error that I get isn't an error from the script, but rather a UTF-8 error. When the mud sends a bad UTF code two things happen: a message is printed to the screen telling me that there was a bad UTF-8 code in the previous line, so it was not processed. Then, when the next line comes up, a modal dialog is displayed telling me the exact same thing.
I tried forcing through a bad UTF-8 sequence, and only got an inline message, like this:
Previous line had a bad UTF-8 sequence at column 48, and was not evaluated for trigger matches
What did the modal dialog box say?
Anyway, why are you getting bad UTF-8 sequences? Do you have UTF-8 turned on for a MUD that doesn't support it? Or is the MUD server sending bad sequences? Surely that needs looking into?
I just checked the code, the message about bad UTF-8 sequences only appear in one spot, namely here:
// check for bad UTF8 in the line - otherwise all triggers will fail
if (m_bUTF_8)
{
iBad = _pcre_valid_utf8 ((const unsigned char *) (const char *) strCurrentLine,
strCurrentLine.GetLength ());
if (iBad >= 0)
{
m_iUTF8ErrorCount++;
// every 128 lines, warn them
if ((m_iUTF8ErrorCount & 0x7F) == 1)
ColourNote ("white", "red",
TFormat ("Previous line had a bad UTF-8 sequence at column %i, and was not evaluated for trigger matches",
iBad + 1));
}
}
You see it does a ColourNote, not a modal dialog box.
When I get the box again, I'll make certain to post the contents here.
I think the problem has to do with me messing with telnet being sent to me. I play the IRE games, which send a hidden command through telnet that displays all the vitals, in more detail than the prompt gives. The problem started not long after I implemented the system, but it doesn't have any support for creating such a dialog.
Yeah, I think that it's being caused by trying to mess with telnet (which I don't know much about) using someone elses code. I havn't been able to figure out exactly what's going wrong.
I am getting the "Previous line had a bad UTF-8" line. I see it shortly before the dialog comes up.
I'm honestly not certain if I'm calling regex from script handlers or not when the error is occuring.
