The only think MUSHClient is missing is an automapper. A nice graphical one, i mean. Or it would be nice if there was a separate program, that could connect to your server and map the rooms as you walk, like ZMud's automapper. I can't find a program like that no matter how much i search. Also, it would be great if we could add more failure messages to the existing mapper, apart from "Alas, you cannot go that way", like "The door is closed" "you are sleeping", etc, and also, it would be nice if speedwalk stopped on "Alas, you cannot go that way" or something, so that you do not wander in strange areas by mistake.
Automapper suggestion
Posted by Poromenos on Sat 24 Aug 2002 07:57 PM — 24 posts, 82,537 views.
Regarding the second part of your message, that can already be accomplished:
If you select the "Game" pulldown menu, then "Mapper", you have a large box where you can indicate failure messages. For example, here's what I have for my favourite mud:
Although your request that speedwalks automatically be dropped or paused on failure is a valid request, you can currently work around that by creating triggers to call script. The script in turn could disregard the rest of the speedwalk queue. I don't know the scripting functions offhand since I haven't bothered with this aspect myself. To learn more, visit:
http://www.mushclient.com/functions.htm
(Nick, could you add that URL to the "Help" pull-down as well?)
On the subject of graphical mapping: Doing so can be a very complex task. zMUD actually works fairly well in that department considering the difficulty. Of course, the many drawbacks to zMUD, such as it's slowness, and that it's a buggy piece of crap make it non-worthy for many mudders, such as myself.
I find I don't actually want a map most of the time I play, but just the first few times I visit a new area, when I'm trying to solve any riddles, etc. Once those are taken care of, the only reason to return is to kill mobs. :) Given that, I wouldn't mind constructing a map in a seperate application. This site looks good, but I have found the map/screen size too small. They are still in development though, so perhaps that will change:
http://www.dungeoncrafter.com
Also, this plugin addition to MUSHclient is still pretty new. I wouldn't be surprised if sooner or later some enterprising programmer designed a nifty mapper. It prolly wouldn't look as pretty as zMUD's, but would still be usable. (No, not me - I don't care enough about this to invest work into it).
If you select the "Game" pulldown menu, then "Mapper", you have a large box where you can indicate failure messages. For example, here's what I have for my favourite mud:
(You can't go that way!|You inhale a lot of water and pause to catch your breath.|What ?|You aren't skilled enough to go there!)
Although your request that speedwalks automatically be dropped or paused on failure is a valid request, you can currently work around that by creating triggers to call script. The script in turn could disregard the rest of the speedwalk queue. I don't know the scripting functions offhand since I haven't bothered with this aspect myself. To learn more, visit:
http://www.mushclient.com/functions.htm
(Nick, could you add that URL to the "Help" pull-down as well?)
On the subject of graphical mapping: Doing so can be a very complex task. zMUD actually works fairly well in that department considering the difficulty. Of course, the many drawbacks to zMUD, such as it's slowness, and that it's a buggy piece of crap make it non-worthy for many mudders, such as myself.
I find I don't actually want a map most of the time I play, but just the first few times I visit a new area, when I'm trying to solve any riddles, etc. Once those are taken care of, the only reason to return is to kill mobs. :) Given that, I wouldn't mind constructing a map in a seperate application. This site looks good, but I have found the map/screen size too small. They are still in development though, so perhaps that will change:
http://www.dungeoncrafter.com
Also, this plugin addition to MUSHclient is still pretty new. I wouldn't be surprised if sooner or later some enterprising programmer designed a nifty mapper. It prolly wouldn't look as pretty as zMUD's, but would still be usable. (No, not me - I don't care enough about this to invest work into it).
It should be noted that the mapper in mushclient has a flaw. One that could be corrected fairly easilly imho, but seems Nick is unsure if it would work or what I mean. Basically, if you move to fast. The mapper can't deal with this correctly and deletes more than the number of move you made. So if you had a stored path like '4new3s' and you tried to move 5 west (when you couldn't) you end up with '4ne'. Until that glitch is fixed a true graphical mapper is impossible.
Magnum, thanks a lot, your suggestion really helped me. And the reason i need the mapper for is for when i get to new areas, and, being a programmer myself i know the difficulty behind it. Having a separate program to do it is nice, i just would prefer to do it online, like zmud does, without having to place all the rooms around myself. As for shadowfyr's bug, you're right, MUSHClient does erase moves. that happens when you buffer like, "3s 2w n", but then you can't move west at "3s". MUSHClient gets 2 "You can't move" messages, and deletes the last 2 commands, namely "w n", although "n" is valid. There doesn't seem to be a way around this, unless mushclient can tell when you've actually moved or not (or if you don't move until it has processed your last move).
Yes, your point is valid... However, I disagree with Shadowfyr, and I do not think that problem can be easily fixed.
I just take my sweet time when creating a new speedwalk alias. I move one room at a time, and wait for the mapper to catch my moves.
Of course, if an error occurs, you can always repair it manually by editing the alias. Indeed, I edit every speedwalk alias anyway to add (brief/brief) statements, which turns off room descriptions on the mud.
I just take my sweet time when creating a new speedwalk alias. I move one room at a time, and wait for the mapper to catch my moves.
Of course, if an error occurs, you can always repair it manually by editing the alias. Indeed, I edit every speedwalk alias anyway to add (brief/brief) statements, which turns off room descriptions on the mud.
Can't agree with you magnum. ;) The problems with the current mapper are:
None of these things are difficult or unfixable, but the current mapper is lazy and doesn't do much more than keep track of what directions you use and if a fail message is recieved. It isn't surprising it doesn't work all the time.
Of course, for a full mapper you also need to capture exits. Though, once again differ from mud to mud. Being able to use a regular expression to set up such a line would help, though it would be helpful to have some sort of color aware regular expression, to help avoid false matches. Only.. You can't currently really build such a thing even in scripting. :p Still it may not even be necessary. You do need a way to set it to catch more than one line, since some muds insist on wrapping lines, without the option to turn it off, but for most there should be a way to correct for this.
Valid commands>
A) Accepts 4e, etc. But most muds use 4 e, so typing that
will mess it up, since it doesn't know how many directions
where actually added. Fixing is simple.
B) You can't set things like 'climb *', 'fly *', etc. as
valid options, you have to insert them manually, which
isn't very automatic.
Invalid exit deletion>
Currently mushclient doesn't bother to check if an invalid
response is produced 'only' after a valid movement. So any
command that triggers an invalid messages erases the last
one in the list of stored moves. (It would help if all muds
had a seperate message for movement and for commands,
but...) This is however not hard to fix, as long as the
mapper knows what are valid direction commands and only
responds with a deletion if the fail message follows an
actual direction command. The only other option is to
capture 'all' commands in the mapper and that would be
counter productive.
Exits & Room name>
Room name is 'partially' fixed, but only for muds that
use MXP or happen to work with the capture plugin Nick
designed. Some may not be fixable, but most have some
color, etc. that could maybe capture the title (again
you need to make sure that this is only done after
some valid movement, or other things could get captured
if you want it to always work right.) Providing a direct
non-script way to set up the needed matching for this
could be nice, since I am not sure how you could do it
otherwise.
A trigger assumes that 'any' line that is color x will be
a room name and that is not a valid assumption, nor is
there any way to use the mapper to tell such a script
that it should be looking. To do so, the mapper would
have to, again, keep track of valid moves and have a
'call this script on a valid move' setting. Then you
could use that script to turn on the needed triggers and
the triggers themselves to do the capture and turn
themselves back off.
None of these things are difficult or unfixable, but the current mapper is lazy and doesn't do much more than keep track of what directions you use and if a fail message is recieved. It isn't surprising it doesn't work all the time.
Of course, for a full mapper you also need to capture exits. Though, once again differ from mud to mud. Being able to use a regular expression to set up such a line would help, though it would be helpful to have some sort of color aware regular expression, to help avoid false matches. Only.. You can't currently really build such a thing even in scripting. :p Still it may not even be necessary. You do need a way to set it to catch more than one line, since some muds insist on wrapping lines, without the option to turn it off, but for most there should be a way to correct for this.
Have to agree with Magnum here, The problems aren't that easy to fix. I'm fairly certain that under the current MushClient design, the program runs as a single thread. Having the program start parsing the mud output when a move is entered then leaves the program waiting for the mud's response. You Lag, your client locks up waiting for a prompt. Kind of defeats the claim of MushClient being one of the fastest mud clients on the windows platform. :)
Fixing MushClient to do this would require rewriting the entire application to use a different threading model, which is neither easy nor trivial.
The scripting engine blocks the thread waiting for a return, so even with a script that echos each line to either itself or a plugin will again block the client while waiting for thread execution.
In theory if a timer polls the line number of the display and retrieve the lines that have scrolled within the last interval; It could parse where there's a valid prompt and where there's a failure and edit the moved dirs queue.
Logic of timer code:
ScriptParseDef would search for directions and prompts.
Logic is done in Python, by the way.. Hopefully we'll see more of it soon :)
Fixing MushClient to do this would require rewriting the entire application to use a different threading model, which is neither easy nor trivial.
The scripting engine blocks the thread waiting for a return, so even with a script that echos each line to either itself or a plugin will again block the client while waiting for thread execution.
In theory if a timer polls the line number of the display and retrieve the lines that have scrolled within the last interval; It could parse where there's a valid prompt and where there's a failure and edit the moved dirs queue.
Logic of timer code:
if World.GetLinesInBufferCount() != varLastLineNum :
varThisLineNum = World.GetLinesInBufferCount()
for x in range(varLastLineNum, varThisLineNum) :
ScriptParseDef(World.GetLineInfo(x, 1))
#1 is line text
varLastLineNum = varThisLineNum
ScriptParseDef would search for directions and prompts.
Logic is done in Python, by the way.. Hopefully we'll see more of it soon :)
Huh?? Why would it need a different threading model. I am not suggesting looking for a prompt or otherwise. I am just saying that the current behaviour is this:
>command
--Is it a direction?
----Yes, add to speed walk.
--Is there a fail message?
----Yes, delete the last move.
--Is there a fail message?
----Yes, delete the last move.
--Is there a fail message?
----Yes, delete the last move.
>command
--Is it a direction?
----No, don't add to speedwalk
--Is there a fail message?
----Yes, delete the last move. <----Oops!
The behavior should be:
>command
--Is it a direction?
----Yes, add to speed walk, set a movement enable flag.
--Is there a fail message?
----Yes, delete the last move.
--Is there a fail message?
----Yes, delete the last move.
--Is there a fail message?
----Yes, delete the last move.
>command
--Is it a direction?
----No, clear movement flag, so fail messages are ignored.
--Is there a fail message?
----Yes, 'ignored' since flag is (off).
This doesn't require a special threading model. The rest is just scripted or built in triggers that capture the needed information, using the same movement flag to determine if it should be even looking for a room name, etc. Why would it be so hard to do?!?
Magnum and some of you other people always over complicate things. ;) lol
>command
--Is it a direction?
----Yes, add to speed walk.
--Is there a fail message?
----Yes, delete the last move.
--Is there a fail message?
----Yes, delete the last move.
--Is there a fail message?
----Yes, delete the last move.
>command
--Is it a direction?
----No, don't add to speedwalk
--Is there a fail message?
----Yes, delete the last move. <----Oops!
The behavior should be:
>command
--Is it a direction?
----Yes, add to speed walk, set a movement enable flag.
--Is there a fail message?
----Yes, delete the last move.
--Is there a fail message?
----Yes, delete the last move.
--Is there a fail message?
----Yes, delete the last move.
>command
--Is it a direction?
----No, clear movement flag, so fail messages are ignored.
--Is there a fail message?
----Yes, 'ignored' since flag is (off).
This doesn't require a special threading model. The rest is just scripted or built in triggers that capture the needed information, using the same movement flag to determine if it should be even looking for a room name, etc. Why would it be so hard to do?!?
Magnum and some of you other people always over complicate things. ;) lol
Given your proposed behaviour:
n
w
tell shadowfyr Betcha the mapper still is gunna mess up
<lag>
Another room (e,s)
You can not go west.
You tell Shadowfyr: ...
Your parser would leave w in the queue even though it's a bad alias. MushClient would catch the tell as being a non dir and not catch the failure for the last dir entered.
So a different threading model to keep track of a command queue and number of prompts would need to be implemented to 'reliably' keep things in sync.
Or not use speedwalks when mapping....
n
w
tell shadowfyr Betcha the mapper still is gunna mess up
<lag>
Another room (e,s)
You can not go west.
You tell Shadowfyr: ...
Your parser would leave w in the queue even though it's a bad alias. MushClient would catch the tell as being a non dir and not catch the failure for the last dir entered.
So a different threading model to keep track of a command queue and number of prompts would need to be implemented to 'reliably' keep things in sync.
Or not use speedwalks when mapping....
Hmm.. Ok. I see your point here. :p I didn't think about what happens if you send a series of commands all at once, one of which disables the flag. This is one instance in which there is 'no' way to fix it. Since there is no way to be sure if the text from the mud is 100% certain to be from a command, there is now way to deal with these sort of things, even with a different threading model (which assumes you can actually tell what has happened).
I think the one thing we can agree on though is that the current method barely works right and that mine at least would limit the problem. Short of forcing every mud to use some sort of transaction thing that tells the client that the following text belongs to x command sent by the client at time y, there is no way to completely fix it. My solution minimizes what can go wrong, but I would never claim that anyone has found a way to solve 'all' of the problems, or that they can be with the way muds work. However the current design tends to maxumize the problems instead.
I think the one thing we can agree on though is that the current method barely works right and that mine at least would limit the problem. Short of forcing every mud to use some sort of transaction thing that tells the client that the following text belongs to x command sent by the client at time y, there is no way to completely fix it. My solution minimizes what can go wrong, but I would never claim that anyone has found a way to solve 'all' of the problems, or that they can be with the way muds work. However the current design tends to maxumize the problems instead.
Of course there are only two cases where this can happen:
[b][w]
[e]
[tell Sam Hello![/b]]
---lag---
-moves
-tell
or
[w;e;tell Sam Hello!]
w
e
tell Sam Hello!
-moves
-tell
In both cases there is no text recieved from the mud in between the commands. It wouldn't be that hard to also add a 'new data recieved since last command' flag and reset the 'movement' flag only if the command is non-movement [b]and[/b] new text has in fact been recieved, otherwise you ignore the fact that the command was sent. In my experience lag tends to happen in bursts and it is quite rare for a mess of commands to lag more than once, before the mud output from them is displayed. If it is lagging badly enough to cause such a thing, mapping is likely the last thing you need to worry about. ;)
[b][w]
[e]
[tell Sam Hello![/b]]
---lag---
-moves
-tell
or
[w;e;tell Sam Hello!]
w
e
tell Sam Hello!
-moves
-tell
In both cases there is no text recieved from the mud in between the commands. It wouldn't be that hard to also add a 'new data recieved since last command' flag and reset the 'movement' flag only if the command is non-movement [b]and[/b] new text has in fact been recieved, otherwise you ignore the fact that the command was sent. In my experience lag tends to happen in bursts and it is quite rare for a mess of commands to lag more than once, before the mud output from them is displayed. If it is lagging badly enough to cause such a thing, mapping is likely the last thing you need to worry about. ;)
Right, see my post from Mon 26 Aug 2002 02:26 AM (UTC) for a suggestion on how to do that yourself. :)
One of the greatest things about MushClient is that it's rich enough to be full featured, but lean enough to be fast.
The script suggested below could somewhat easily implemented in a plug in, and if it turns out to be too intensive for every day use, it's easily toggled off. :)
Nick's been gracious enough to give us the tools to do pretty much anything we want, the best solution isn't always to integrate it in the client's source.
A swiss army knife is great, but some times all you need is a screwdriver. :)
One of the greatest things about MushClient is that it's rich enough to be full featured, but lean enough to be fast.
The script suggested below could somewhat easily implemented in a plug in, and if it turns out to be too intensive for every day use, it's easily toggled off. :)
Nick's been gracious enough to give us the tools to do pretty much anything we want, the best solution isn't always to integrate it in the client's source.
A swiss army knife is great, but some times all you need is a screwdriver. :)
Which one of your posts from there? The one with the timer? I hope you realize that your supposed solution is like taking a sledgehammer to something that need a spring replaced, and not "...but some times all you need is a screwdriver."
I so agree that scripts are a good solution in most cases. Unfortunately doing this in a script is A) redundant (most of the function is there, it just doesn't account for some things it should) and B) there is still no support for accessing the keypad macros in the script or 'pre-processing' commands through the plugin in any useful sense (though Nick has said he plans to add them). If the key issues involved where fixed in the built in part, then we would have something to work with. As it is now... There is no point of even having a non-fuctional mapper in the client, if the only way to make it work right is writing a plugin to replace it.
I understand needing to keep the client fast and non-bloated, but no fixing this is imho, going to far in that direction. I have posted back and forth with Nick about it and there 'seems' to be some possibility of fixing it. If not, then why bother even keeping the one we already have? It doesn't really work. As for the idea that it adds stuff that could slow down or bloat the cient, I truly do not understand why adding one extra 'if moveflag and newdataflag then' to the existing mapper will slow anything down significantly.
There is a routine whos sole job is to catch new data 'if' it arrives. Adding 'newdataflag = TRUE;' to it is not going to have even the slightest effect on the program, unless your maybe running it one a 8Mhz 286. The recent feature, of setting variables within the triggers match field, had no visible effect on the clients speed and required far more changes than fixing this. This is like complaining that a single misquito could effect the aerodynamics of your 747.
As for the mapper itself... If turned off, the changes would have 0 effect, but even when running you are looking at maybe 5 additional lines of code (two if thens) which it has to perform. To write a version that works through scripting though, you would have to turn off the existing mapper and rewrite the entire thing, in scripting in order to actually make one that does what it should, something that 'will' slow down the client.
I admit there may be something that I have overlooked, but just these few changes would make it sufficiently reliable to eliminate 'most' cases where it currently fails. You timer can't, unless you know before hand what 'should' be in those lines when it arrives. unfortunately part of the problem is that you can't know.
I think you seriously overestimate both how complicated it is to fix and how much of an impact it would have, even if I have overlooked something. But even if so, it fixes 90% of all cases where things go wrong.
I so agree that scripts are a good solution in most cases. Unfortunately doing this in a script is A) redundant (most of the function is there, it just doesn't account for some things it should) and B) there is still no support for accessing the keypad macros in the script or 'pre-processing' commands through the plugin in any useful sense (though Nick has said he plans to add them). If the key issues involved where fixed in the built in part, then we would have something to work with. As it is now... There is no point of even having a non-fuctional mapper in the client, if the only way to make it work right is writing a plugin to replace it.
I understand needing to keep the client fast and non-bloated, but no fixing this is imho, going to far in that direction. I have posted back and forth with Nick about it and there 'seems' to be some possibility of fixing it. If not, then why bother even keeping the one we already have? It doesn't really work. As for the idea that it adds stuff that could slow down or bloat the cient, I truly do not understand why adding one extra 'if moveflag and newdataflag then' to the existing mapper will slow anything down significantly.
There is a routine whos sole job is to catch new data 'if' it arrives. Adding 'newdataflag = TRUE;' to it is not going to have even the slightest effect on the program, unless your maybe running it one a 8Mhz 286. The recent feature, of setting variables within the triggers match field, had no visible effect on the clients speed and required far more changes than fixing this. This is like complaining that a single misquito could effect the aerodynamics of your 747.
As for the mapper itself... If turned off, the changes would have 0 effect, but even when running you are looking at maybe 5 additional lines of code (two if thens) which it has to perform. To write a version that works through scripting though, you would have to turn off the existing mapper and rewrite the entire thing, in scripting in order to actually make one that does what it should, something that 'will' slow down the client.
I admit there may be something that I have overlooked, but just these few changes would make it sufficiently reliable to eliminate 'most' cases where it currently fails. You timer can't, unless you know before hand what 'should' be in those lines when it arrives. unfortunately part of the problem is that you can't know.
I think you seriously overestimate both how complicated it is to fix and how much of an impact it would have, even if I have overlooked something. But even if so, it fixes 90% of all cases where things go wrong.
The changes you suggested would indeed catch many of the deletion errors. It still doesn't fix the non-standard exits and room name issues that you listed before.
So yes, it'll make it better, but still won't fix it. :)
So yes, it'll make it better, but still won't fix it. :)
Quote:
There is a routine whos sole job is to catch new data 'if' it arrives. Adding 'newdataflag = TRUE;'
There is a routine whos sole job is to catch new data 'if' it arrives. Adding 'newdataflag = TRUE;'
More specifically, I believe there is a single trigger, which is a regular expression, and who's match line is the contents of the "Failure message:" box.
If the trigger fires while recording a speedwalk, then the last item in the speedwalk queue is deleted.
There are no other built-in speedwalk triggers to check for incoming text.
Now, It seems what you are proposing is that the single trigger mentioned above be toggled on/off depending on weather the last command sent was a direction or not.
It could be beneficial to do so, although the possible flaw in that logic was pointed out.
You said that the current mapper is totally unusable. That may be your opinion, but I find it works well for me. As I said before, I just take my time moving while using it. I only need it to make speedwalks to new areas, which, as you know are rare.
Perhaps all you need is for the speedwalking delay to be enforced during recording as well, and to set it high enough to handle most lag you recieve. :)
The reason I say it is unusable is that it can't be extended. Any attempt to use it as the core to a real mapper will fail as it exists. Also, you are not always in a position when you first start mapping a world of always being able to be slow, methodical and careful about what movements you type. I did think of one flaw in my logic, but it stems from the fact that the mapper only remembers movements commands and completely ignores others, thus a fail message from a non-movement command will trigger an incorrect deletion. I do think that such a change as I suggest will limit the odds of this happening, even if it didn't completely fix it. A better solution would probably be to keep track of all commands when more than one is typed on a line or no new text has arrived and only build the mapping data after the next command, 'after' new text arrives, is sent. For instance 'w;e;blah;s' will always fail, even with my fix, since the mapper only sees the directions, blah is what generates the failure.
The 'flaw' in logic here is not in my understanding of how the mapper works, but it seems to me in other peoples assumption of what needs to be done to fix it. The only real suggestion I have heard so far doesn't solve the real problem, it mearly delays the result, since it assumes by reading the actual lines of output you can somehow miraculously tell which lines where send in response to which command. Sorry, but it can't work that way. Not doesn't mind you, but due to the way Telnet works, it litterally can't.
If all you do use it for is to get from point A to point B and back, then it is pretty useless imho, since you are probably better off writing a script like I have, with lets you type 'g mine' and feeds the needed commands to the mud, without needing to rely on the mapper. The fact that you find it useful doesn't mean it isn't seriously broken.
As a sort of side note:
If I could figure out a way to get a script to respond to the num-pad, I would try to write something that worked right. However, as a plugin it would be seriously difficult to make user friendly and easy to configure. At the least it would be nice to call ActiveX controls, but Mushclient is not a control/document container and other than IE's core, there are exactly 0 available to use for such a purpose. :p I am not 100% certain, but IE's core code probably couldn't talk back to the script properly anyway and I am fairly sure you would need to have the script build more html and vbscript itself, in order to display the control in the IE core. All in all, it is not practical. :p
Of course the other option is to write a COM program, whose sole purpose is to set things, but that is a bit silly and doesn't do much to help anyone else that has the same problem.
So, does anyone out there have the slightest clue how to design an ActiveX Container? :p A COM that provided that would actually be extremely useful.
The 'flaw' in logic here is not in my understanding of how the mapper works, but it seems to me in other peoples assumption of what needs to be done to fix it. The only real suggestion I have heard so far doesn't solve the real problem, it mearly delays the result, since it assumes by reading the actual lines of output you can somehow miraculously tell which lines where send in response to which command. Sorry, but it can't work that way. Not doesn't mind you, but due to the way Telnet works, it litterally can't.
If all you do use it for is to get from point A to point B and back, then it is pretty useless imho, since you are probably better off writing a script like I have, with lets you type 'g mine' and feeds the needed commands to the mud, without needing to rely on the mapper. The fact that you find it useful doesn't mean it isn't seriously broken.
As a sort of side note:
If I could figure out a way to get a script to respond to the num-pad, I would try to write something that worked right. However, as a plugin it would be seriously difficult to make user friendly and easy to configure. At the least it would be nice to call ActiveX controls, but Mushclient is not a control/document container and other than IE's core, there are exactly 0 available to use for such a purpose. :p I am not 100% certain, but IE's core code probably couldn't talk back to the script properly anyway and I am fairly sure you would need to have the script build more html and vbscript itself, in order to display the control in the IE core. All in all, it is not practical. :p
Of course the other option is to write a COM program, whose sole purpose is to set things, but that is a bit silly and doesn't do much to help anyone else that has the same problem.
So, does anyone out there have the slightest clue how to design an ActiveX Container? :p A COM that provided that would actually be extremely useful.
Quote:
since it assumes by reading the actual lines of output you can somehow miraculously tell which lines where send in response to which command. Sorry, but it can't work that way. Not doesn't mind you, but due to the way Telnet works, it litterally can't.
since it assumes by reading the actual lines of output you can somehow miraculously tell which lines where send in response to which command. Sorry, but it can't work that way. Not doesn't mind you, but due to the way Telnet works, it litterally can't.
Actually, Telnet works via the IP stack, which works sequentially. Without getting too much into the details of IP Packet sequencing, You send cmd1, cmd2, cmd3; even if the packets containing cmd2 get corrupted/dropped, the servers ip stack requests those packets to get resent before it can reassemble and process the packets of cmd3. Every mud I know of works on a command queue, not a stack (FIFO vs FILO (First In First/Last Out). So you're guaranteed to know that response1 matches up with cmd1 (Unless you're on 3 Kingdoms fighting the LagMonster ;))(Given logic checking that ensures that there's not a command outstanding in the given timer interval)
So how can we find out how many commands in a given interval?
World.GetLineInfo(lineNum, 5) knows the difference between if it's something you inputted (true) or if it's a note/sent from the mud (false).
And How many responses?
A RegExp Looking for ^(Prompt).*$ in your subroutine (Nick posted a tip/trick article on the RegExp obect) can check for a prompt. So for any given timer subroutine, You can keep track of: How many commands you inputted, how many prompts were returned, and when exactly failures occur (between which prompt occurances) And figure out which command generated the failure.
As an aside, Any version of VB from version 5 on has a wizard on how to make an ActiveX control that can implement the container interfaces. But having a Control that's a container for a control puts you right back where you started.
Hmm. Didn't think about that WillFa. It could maybe work, but I am not sure. If the mapper didn't assume that all responses where from a movement to begin with, this may not even be necessary, though stacked commands are likely 'always' a problem. Anyway, the only way to know is to write it and that can't really be done with the primary source of movement commands (the num-pad) not being capturable. :p In any case I think it is possible to make it more reliable, even if there is no 'perfect' fix.
As for the VB thing.. Yes and no. IE core 'is' a cntainer, specifically it is a Document Container, and the document is a COM Container. The problem with using it is that you have to create a document to stick the controls in to make it work. Now the irony here is that Word and virtually all other such programs are also merely containers. It is just a matter of providing a means to give it the needed COM info and having a way to let them talk back and forth.
The two major problems I am having are that I can't seem to get the documentation for VB to install properly (it insists I have the wrong CD regardless of the one I put in) and there seems to be no resources on the subject on the net that don't assume you are using COM with a blasted web page. :p I find this quite annoying.
As for the VB thing.. Yes and no. IE core 'is' a cntainer, specifically it is a Document Container, and the document is a COM Container. The problem with using it is that you have to create a document to stick the controls in to make it work. Now the irony here is that Word and virtually all other such programs are also merely containers. It is just a matter of providing a means to give it the needed COM info and having a way to let them talk back and forth.
The two major problems I am having are that I can't seem to get the documentation for VB to install properly (it insists I have the wrong CD regardless of the one I put in) and there seems to be no resources on the subject on the net that don't assume you are using COM with a blasted web page. :p I find this quite annoying.
Actually Specific problem> Command lag.
This is where you do something like:
n
tell Fred Hi!
w
and the mud comes back with:
[gossip] Jim: Yeah that's right.
[gossip] Grug: No i think you are wrong.
The sun rises as the day begins.
...
But it takes some time before the mud responds to you commands at all (assuming you don't just get unplugged). This is why I don't think looking at the time solved anything. In such a case you need to know what 'should' have arrived to be sure when the command was actually responded to. Thinking things through I am not sure there is any thing that can with certainty fix the problems, but I think your idea tries to be a bit too specific for it to be a viable solution.
This is where you do something like:
n
tell Fred Hi!
w
and the mud comes back with:
[gossip] Jim: Yeah that's right.
[gossip] Grug: No i think you are wrong.
The sun rises as the day begins.
...
But it takes some time before the mud responds to you commands at all (assuming you don't just get unplugged). This is why I don't think looking at the time solved anything. In such a case you need to know what 'should' have arrived to be sure when the command was actually responded to. Thinking things through I am not sure there is any thing that can with certainty fix the problems, but I think your idea tries to be a bit too specific for it to be a viable solution.
World.GetLineInfo(lineNum,5) returns true for macros as well, including the key pad.
My suggestion is to use a timer to review the buffer at an interval (like every 3 seconds), not to try and have the numpad script adding movement to a queue.
My suggestion is to use a timer to review the buffer at an interval (like every 3 seconds), not to try and have the numpad script adding movement to a queue.
Hmm. Well maybe.. For merely mapping it may be useful, but if the intent was for the map to update as you move, then delaying it for 3 second is not helpful. And I can't think of any instance where I wouldn't want it to update immediately. Put simply, your idea doesn't really fix the problem any better than mine does and only adds a delay before you know something has gone wrong. The question for both of us is, 'Can you make it work?'.
At the moment yours is more likely to work, but doesn't handle the situation any better. Once Nick adds script call support to macros, delayed processing becomes pointless, because it doesn't really deal with the real issue of 'which' command goes with 'which' line. With some clever code it may be able to make a decent guess, but I don't see it being any better than mine at solving that key issue. (See my last example.) And from the stand point of partial fixes, the delay in processing could make it less useful.
At the moment yours is more likely to work, but doesn't handle the situation any better. Once Nick adds script call support to macros, delayed processing becomes pointless, because it doesn't really deal with the real issue of 'which' command goes with 'which' line. With some clever code it may be able to make a decent guess, but I don't see it being any better than mine at solving that key issue. (See my last example.) And from the stand point of partial fixes, the delay in processing could make it less useful.
I seem to remember that we went over a lot of this ground a few weeks back, and I commented that the main problem is that the MUD does not confirm whether, or not, a particular direction command succeeds.
It would be helpful, if somewhat stilted, if you saw something like this:
However that doesn't happen, and the mapper has to deduce what is going on as best it can. Perhaps a more elaborate "movement" technique (like the recent automapper helper) would help, where you detect room changes, by the fact that the room name is in white-on-black bold text. However that would only work in certain cases (ie. certain MUDs).
In particular, as I commented earlier, if you feed directions to the MUD too quickly, the automapper can get confused as to which direction failed exactly.
However for anyone that wants to demonstrate how it is done, plugins now have access to all the information that MUSHclient has, so you can show us the technique.
Personally I would be using OnPluginSend (to catch outgoing text) with OnPluginLineReceived (to catch incoming messages) and see what I could do with them. Their prototypes are below.
It would be helpful, if somewhat stilted, if you saw something like this:
west
You succeed in going west. OR
You fail to go west.
However that doesn't happen, and the mapper has to deduce what is going on as best it can. Perhaps a more elaborate "movement" technique (like the recent automapper helper) would help, where you detect room changes, by the fact that the room name is in white-on-black bold text. However that would only work in certain cases (ie. certain MUDs).
In particular, as I commented earlier, if you feed directions to the MUD too quickly, the automapper can get confused as to which direction failed exactly.
However for anyone that wants to demonstrate how it is done, plugins now have access to all the information that MUSHclient has, so you can show us the technique.
Personally I would be using OnPluginSend (to catch outgoing text) with OnPluginLineReceived (to catch incoming messages) and see what I could do with them. Their prototypes are below.
Function OnPluginCommand (sText)
World.Note "Command '" & sText & "' received."
OnPluginCommand = vbTrue ' process it
End Function
Function OnPluginSend (sText)
World.Note "About to send '" & sText & "'."
OnPluginSend = vbTrue ' process it
End Function
Function OnPluginLineReceived (sText)
World.Note "Received: '" & sText & "'"
OnPluginLineReceived = vbTrue ' display it
End Function
Sub OnPluginPacketReceived (sText)
World.Note "Received PACKET: '" & sText & "'"
End Sub
Quote:
If I could figure out a way to get a script to respond to the num-pad, I would try to write something that worked right.
If I could figure out a way to get a script to respond to the num-pad, I would try to write something that worked right.
If the numpad configuration sends some sort of word that can be caught by an alias, and the alias can call a script.
eg.
Numpad 0 sends "--NumPad-0--"
Alias: --NumPad-0--
Script: OnNumPad0
Yes. Much of our discussion here has also been about not being able to see a good response. lol I hope though that we can come up with something that is at least slightly more reliable. ;) I believe we can, so long as the movement commands are not interrupted by a non-movement.
I.e. I am 100% sure that this:
w
s
e
What?
>
What?
>
What?
>
can be fixed, but
w
tel fred Hi!
s
e
What?
>
What?
>
What?
>
What?
>
is probably not something that can be fixed, save in cases where you can be sure that the mud won't respond with a generic result. :p Right now, neither will work in the cases where they happen. I plan to build a mimic of the mapper soon (though not for a few days) that will hopefully be more realiable (if not perfect, which is probably not possible anyway).
>If the numpad configuration sends some sort of word that can be caught by an alias...
Ok.. A bit of a roundabout way to do it. lol It wouldn't have occured to me to do that.
I.e. I am 100% sure that this:
w
s
e
What?
>
What?
>
What?
>
can be fixed, but
w
tel fred Hi!
s
e
What?
>
What?
>
What?
>
What?
>
is probably not something that can be fixed, save in cases where you can be sure that the mud won't respond with a generic result. :p Right now, neither will work in the cases where they happen. I plan to build a mimic of the mapper soon (though not for a few days) that will hopefully be more realiable (if not perfect, which is probably not possible anyway).
>If the numpad configuration sends some sort of word that can be caught by an alias...
Ok.. A bit of a roundabout way to do it. lol It wouldn't have occured to me to do that.