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
➜ General
➜ Matching Triggers Without Hard Returns
|
Matching Triggers Without Hard Returns
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Zebulon
Australia (5 posts) Bio
|
| Date
| Sun 28 Oct 2001 02:04 AM (UTC) |
| Message
| Hiya,
I've been looking into switching to MUSH because of the scripting but I have hit one major obstical.
I cannot get triggers to be processed until the input from med sends a hard return. Which is painful because the mud i use does not send hard returns on the last line sent (which is the status line e.g. <1000hp 500m 100mv>)
Have I missed something or is this a limitation of MUSH?
I have roughly 15 scripts that i would like to port to MUSH client, except almost all of them use a status line trigger to process information.
If it is a limitation of MUSH not being able to process the last line sent from a mud makes it impossible to write some of these scripts...
Zebulon
| | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #1 on Sun 28 Oct 2001 08:51 PM (UTC) |
| Message
| It is true that MUSHclient does not match on triggers until a "hard return" is received. The reason for this is that TCP/IP is a "stream" protocol, and that data from the MUD might be broken up by the network protocol into packets, and there is no way of knowing when the line has arrived completely.
If MUSHclient simply matched triggers at the end of every packet, then you would have quite frequent false matches, as the trigger fired when only half a line had arrived.
Thus, it waits for the hard return (newline) before any trigger matching is done. Of course, for "prompt" lines this never arrives, until you reply to the prompt.
I am considering adding as an option for a future version to match on partial lines. Being an option you would only choose it when a partial match was OK.
Meanwhile, you could make do with "delayed" matching - for example if you are matching on HP etc. then you will be "one behind" as it will have matched on the second last prompt line, rather than the last, which might not be too bad.
Alternatively, if you are on an MXP-enabled MUD then details like HP may well be sent down as MXP tags, which you can detect in scripts, even before the newline arrives.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Zebulon
Australia (5 posts) Bio
|
| Date
| Reply #2 on Tue 30 Oct 2001 03:32 AM (UTC) |
| Message
| Heya,
I see your point about TCP/IP breaking up packets but is this a issue in Mud communications?
E.G. Does TCP/IP ever break the packet up so small that something like a single line from a mud will be broken up?
(In most cases the header information would be larger than the message body).
I've never seen this as an issue for other clients.
A Match on partial lines would make alot of scripts possible.
Delayed matching on stats is not an option with alot of the scripts I write because im reporting what has just happened to a chat server or using hp/mana information to analise an action.
The mud im on (Medievia) dosn't use MXP, or even have custom status lines so i could add a hard return.
Also while I have your attention, are you looking into implementing MM/zMud chat protocol in the near future?
Or should us script kiddies write something :P.
Thanks in advance,
Zebulon | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #3 on Thu 01 Nov 2001 03:52 AM (UTC) |
| Message
| Yes, I see what you mean. Nevertheless, my understanding of TCP/IP is that the operating system, or intermediate routers, are permitted to break packets up into smaller ones as required.
When MUSHclient was originally developed (for MUSHes) they typically had room descriptions as a paragraph that could be many lines *without* a newline at the end of each one, and in those cases it was quite likely that you would get more than one packet without a newline.
At least one other client (zMUD) has considered this to be an issue, as it has an option to check the trigger on "newline" or "prompt". In my case I only check on newline at present, and the option to check on "prompt" (ie. when the packet is received) is on the list of things to do.
As for chat protocol that is also on the list of things to do. :) As an interim solution you would always fire up a private server (eg. a MUSH server which doesn't require you to eat and drink every 5 minutes) and use that as a chat medium. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Zebulon
Australia (5 posts) Bio
|
| Date
| Reply #4 on Thu 01 Nov 2001 12:23 PM (UTC) Amended on Thu 01 Nov 2001 12:35 PM (UTC) by Zebulon
|
| Message
| Hiya,
Ive just written a basic chat server/client using the mm protocol with an ActiveX dll that plugs into a vbscript in MUSH.
Going to clean it up over the next couple of days (Uni finished YAY!)
Does this mean that you can write the option to check on "prompt" sooner? *grin*
Zebulon
P.S. Anything else thats on your todo list (g)...
| | 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.
17,949 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top