Lag on trigger

I have a little issue doesn't really bother me at all figured I'd report it tho.


<aliases>
<alias
match="reco"
enabled="y"
send_to="12"
sequence="100"
>
<send>Disconnect()
Connect()</send>
</alias>
</aliases>


Doesn't lag but this does


<triggers>
<trigger
enabled="y"
group="Xpquest Request"
match="You may now do another XP Quest!"
send_to="12"
sequence="100"
>
<send>Disconnect()
Connect()</send>
</trigger>
</triggers>


upwords of some minute to 2 for the mud to resolve and on a few times has caused mushclient to totally freeze

I tested it myself and it seems to work fine.

Are you using V 4.41? im running atm

4.40 on windows 7 RC build 7000

I'm using MUSHclient 4.40 on Ubuntu 9.04 (with Wine) and Windows XP SP3. I couldn't make it lag in the slightest in either OS.

hmm odd atleast with wine it should if there was any problem os wise...maybe my world file is bugged somewhere no clue...going to make a fresh world file and see if that doesn't resolve the issue

Well, I wouldn't do this in a trigger anyway:



Why? When MUSHclient is processing a trigger, it is probably half-way through processing the current packet (in other words, there might be another line following the one you are triggering on, like a prompt line).

Now, in the middle of processing an incoming packet, and sending back responses to the MUD, you yank the connection away by doing Disconnect ().

Then you reconnect by doing Connect() - but connecting is asynchronous. That is, a connecting to anything on the Internet takes time. For a start, the client sends out a SYN packet, then the server responds with ACK or RST, and if you get an ACK the client then ACKs the ACK. After all this, the connection is established.

To save the client "hanging" whilst connecting, all this is happening in the background. This is noted in the help for the Connect function:


Note that since connecting is "asynchronous" you are not actually connected when this command completes. A return value of eOK simply means that the connection process has successfully started.


So, once your trigger fires, you aren't connected any more. Maybe a couple of seconds later you might be. Meanwhile any packets queued up for processing now have to work on a dropped connection.

I just wouldn't do that sequence, any more than I would switch off my car's ignition whilst cruising down the highway, and turn it back on.

The Connect function was really intended to be used when not connected - that is, for something like the auto-reconnector plugin. To use the car analogy, the ignition switch is for starting the engine while the car is stationary.

Anyway, why are you disconnecting when you see the message "You may now do another XP Quest!"? Does the MUD have some strange design, that you can't do another quest without disconnecting first?

Well no, But If i have alot of commands stacked I have to wait for them to complete or simply just disconnect and reconnect