Register forum user name Search FAQ

Gammon Forum

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 ➜ Suggestions ➜ Automapper suggestion

Automapper suggestion

It is now over 60 days since the last post. This thread is closed.     Refresh page


Pages: 1 2  

Posted by Poromenos   Greece  (1,037 posts)  Bio
Date Sat 24 Aug 2002 07:57 PM (UTC)
Message
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.

Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
Top

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #1 on Sun 25 Aug 2002 03:04 AM (UTC)
Message
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:

(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).

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top

Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #2 on Sun 25 Aug 2002 08:55 AM (UTC)
Message
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.
Top

Posted by Poromenos   Greece  (1,037 posts)  Bio
Date Reply #3 on Sun 25 Aug 2002 11:38 AM (UTC)
Message
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).

Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
Top

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #4 on Sun 25 Aug 2002 02:19 PM (UTC)
Message
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.

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top

Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #5 on Sun 25 Aug 2002 07:12 PM (UTC)

Amended on Sun 25 Aug 2002 07:16 PM (UTC) by Shadowfyr

Message
Can't agree with you magnum. ;) The problems with the current mapper are:

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.
Top

Posted by WillFa   USA  (525 posts)  Bio
Date Reply #6 on Mon 26 Aug 2002 02:26 AM (UTC)
Message
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:

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 :)
Top

Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #7 on Mon 26 Aug 2002 05:48 PM (UTC)

Amended on Mon 26 Aug 2002 05:49 PM (UTC) by Shadowfyr

Message
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
Top

Posted by WillFa   USA  (525 posts)  Bio
Date Reply #8 on Mon 26 Aug 2002 08:00 PM (UTC)
Message
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....
Top

Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #9 on Mon 26 Aug 2002 08:14 PM (UTC)
Message
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.
Top

Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #10 on Mon 26 Aug 2002 08:34 PM (UTC)
Message
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. ;)
Top

Posted by WillFa   USA  (525 posts)  Bio
Date Reply #11 on Mon 26 Aug 2002 11:03 PM (UTC)
Message
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. :)
Top

Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #12 on Tue 27 Aug 2002 02:44 AM (UTC)
Message
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.
Top

Posted by WillFa   USA  (525 posts)  Bio
Date Reply #13 on Tue 27 Aug 2002 04:09 AM (UTC)
Message
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. :)
Top

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #14 on Tue 27 Aug 2002 06:56 AM (UTC)
Message
Quote:

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. :)

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
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.


61,327 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.