I'm haveing..... Problems with the way that the output from a Linux box connection is being displayed.. Nothing like it should.. And some output I'm getting from it is just being... Forgotten and not displayed at all... Now.. I'm assuming that MUSHClient was just not ment to work with a connection like this.. But.. Well.. I just love MUSHClient and all it's uses and wish it /would/ work right...
Problems with MUSHClient & Linux Box interaction
Posted by Lothar323 on Sat 02 Jun 2001 09:40 PM — 12 posts, 43,268 views.
If you tell me the MUD address and port I'll check it out. Many, many MUDs are run on Linux boxes (including the ones I test with here) and I don't have that problem, and virtually no-one else has reported it.
It's not a MUD, it's an actual Shell... It's wizmoo.dhs.org:23 ...... I truthfully... Cant' give you a way to test that here seeing as it's my business's box.... But I will allow you the use of my spare shell if you'll contact me privately.. Then maybe we can clear this up... And I can finally be a happy Lothy... :)~
Oh I see. It's not a MUD. :)
MUSHclient is not really designed as a Linux shell interface. For design reasons relating to logging, triggers etc. it isn't really feasible to do things like cursor jumping (ie. go to line 5, column 6).
Thus, doing things like VI in Unix simply won't work.
For example, if I allowed the telnet sequences to jump around on the screen and put characters at arbitrary locations how could a trigger ever fire, if lines are being modified after they were received? Or logging - what if you logged a line and then it was changed?
MUSHclient will support line-by-line output, so you can do CAT, LS and stuff like that. For commands like VI, TOP, and other stuff like that, it just isn't the right tool for the job, sorry. :)
MUSHclient is not really designed as a Linux shell interface. For design reasons relating to logging, triggers etc. it isn't really feasible to do things like cursor jumping (ie. go to line 5, column 6).
Thus, doing things like VI in Unix simply won't work.
For example, if I allowed the telnet sequences to jump around on the screen and put characters at arbitrary locations how could a trigger ever fire, if lines are being modified after they were received? Or logging - what if you logged a line and then it was changed?
MUSHclient will support line-by-line output, so you can do CAT, LS and stuff like that. For commands like VI, TOP, and other stuff like that, it just isn't the right tool for the job, sorry. :)
Yea.. I'm not wanting to do any major stuff like that.. I'm having problems with TF (Tiny Fugue)... In the non-visual mode... (How else am I to keep my MOO's alive all the time? *purrs with a smile*) Idea why this won't work....
Ok.. So I fixed my own problem.. For future referance all I had to do was 'export TERM=vt100' and.. *poof* It loved me again... (Side note.. I was also useing 'screen' as a means of.. Detaching the TF and still being connected... But it now works.. Thanks Nick..)
Ok... One last connected question.. There a way I can get it to pause in between sending the commands in the little box under the 'Connecting' tab? It get's my Name through just fine.. But the password is sent a little too fast...
Check out my response to a similar question: optional pause in autoconnect
Ok.. This script stuff's getting fun! Whoo! There a way I can get the scripts to happen when a line comes through? *idles to look at the obvious 'Triggers' before he hits send* Ok.. I see a place where I can call a trigger.. What's 'Label' A 'name' for the trigger that's getting called? *I ask many questions, but I hate help files* :)
Yes, the trigger can have a name.
The name gets passed to the trigger routine (so you can share routines between multiple triggers and know which one called it), and also is used to delete the trigger in a script.
The name gets passed to the trigger routine (so you can share routines between multiple triggers and know which one called it), and also is used to delete the trigger in a script.
Let's keep this chain going for a moment.... Now.. I have a trigger that matches:
#$# edit name: * upload: *
And a script that does some things to it.. Like opens a new Notepad with 'theWildcards (1)' as the title and 'theWildcards (2)' as the first line.. what I want to do is continue reading from the point the trigger is called untill a '.' is found... Remove all that gunk from the output and put it all including the '.' in the notepad...
#$# edit name: * upload: *
And a script that does some things to it.. Like opens a new Notepad with 'theWildcards (1)' as the title and 'theWildcards (2)' as the first line.. what I want to do is continue reading from the point the trigger is called untill a '.' is found... Remove all that gunk from the output and put it all including the '.' in the notepad...
I haven't tried this exactly but it should work. :)
I would make a trigger that matches everything, eg.
*
... and then give it a low sequence number so it is done first. Leave it disabled for the moment.
Now in your other trigger, once you have done the notepad window stuff, do an "enable trigger", like this:
This new trigger then just appends wildcard (1) to the notepad.
Then if it finds that the wildcard has matched on "." then it disables itself and it is done, eg.
I would make a trigger that matches everything, eg.
*
... and then give it a low sequence number so it is done first. Leave it disabled for the moment.
Now in your other trigger, once you have done the notepad window stuff, do an "enable trigger", like this:
World.EnableTrigger "capture_trigger", TRUE
This new trigger then just appends wildcard (1) to the notepad.
Then if it finds that the wildcard has matched on "." then it disables itself and it is done, eg.
World.EnableTrigger "capture_trigger", FALSE