Gammon Forum : MUSHclient : Suggestions : Automapper suggestion

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

Shadowfyr USA (1,792 posts) Bio

Date

Reply #15 on Tue 27 Aug 2002 06:49 PM (UTC)

Amended on Tue 27 Aug 2002 07:08 PM (UTC) by Shadowfyr

Message

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.

Top

Posted by

WillFa USA (525 posts) Bio

Date

Reply #16 on Tue 27 Aug 2002 09:39 PM (UTC)

Message

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.

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.

Top

Posted by

Shadowfyr USA (1,792 posts) Bio

Date

Reply #17 on Tue 27 Aug 2002 10:58 PM (UTC)

Amended on Tue 27 Aug 2002 11:02 PM (UTC) by Shadowfyr

Message

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.

Top

Posted by

Shadowfyr USA (1,792 posts) Bio

Date

Reply #18 on Tue 27 Aug 2002 11:13 PM (UTC)

Message

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.

Top

Posted by

WillFa USA (525 posts) Bio

Date

Reply #19 on Tue 27 Aug 2002 11:46 PM (UTC)

Message

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.

Top

Posted by

Shadowfyr USA (1,792 posts) Bio

Date

Reply #20 on Wed 28 Aug 2002 12:13 AM (UTC)

Message

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.

Top

Posted by Nick Gammon Australia (23,173 posts) Bio Forum Administrator

Date Reply #21 on Thu 29 Aug 2002 12:15 AM (UTC)

Message

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:



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

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Nick Gammon Australia (23,173 posts) Bio Forum Administrator

Date

Reply #22 on Thu 29 Aug 2002 12:17 AM (UTC)

Message

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

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Shadowfyr USA (1,792 posts) Bio

Date

Reply #23 on Thu 29 Aug 2002 01:24 AM (UTC)

Message

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.

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.

81,002 views.

This is page 2, subject is 2 pages long: 1 2

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

Go to topic: Search the forum

top