Zugg Software :: View topic

Apprentice Joined: 01 Nov 2006 Posts: 114

Ok, i tried setting up a #capture setup for my tells and such, and when i did so, the original window looses the command line and i can no longer enter commands. NOw this only happens if I close the extra window, and even closing program and reopening doesn't fix it.

#CLASS {Tells}
#TRIGGER {(*) responds to your petition with '} {#cap tells}
#TRIGGER {(*) group-says '} {#cap tells}
#TRIGGER {(*) group-says in (*) '} {#cap tells}
#TRIGGER {(*) tells your guild '} {#cap tells}
#TRIGGER {You petition} {#cap tells}
#TRIGGER {You say} {#cap tells}
#TRIGGER {You group-say} {#cap tells}
#TRIGGER {You tell} {#cap tells}
#TRIGGER {(*) tells you '} {#cap tells}
#TRIGGER {(*) tells you in (*) '} {#cap tells}
#TRIGGER {(*) says '} {#cap tells}
#TRIGGER {(*) says in (*) '} {#cap tells}
#TRIGGER {(*) chitters '} {#cap tells}
#TRIGGER {(*) chitters in (*) '} {#cap tells}
#CLASS 0

Posted: Wed Jan 03, 2007 1:41 pm

You should be able to recheck the command line option for the window in the package editor. Sounds like a bug to me though, since I don't think there's a way to do that even if you want to.

Newbie Joined: 28 Jun 2001 Posts: 4

Is there any way to stop the output command line from scrolling when the coms are captured? I capture all communications to a comms window so I don't miss things. In ZMUD I have a nice little plugin that was written by Charbal, and I can't use it for CMUD. The Plugin actually intercepts the mud output and stops the command line from scrolling.

Posted: Tue Jan 16, 2007 1:03 am

Not sure what you mean by the command line scrolling.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

I think what he means is that the mud output window does not scroll when he enters a command.

The effects of this plugin could be reproduced with the new oninput stuff.

Newbie Joined: 28 Jun 2001 Posts: 4

What I mean is the output prompt appears and the text has been caputred, but even when the text is caputred, I still get another new prompt. Each line of comms puts another empty prompt line in my output window. With ZMUD I have a plugin that removes the prompt or intercepts it all together to where I don't see it in the output window.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Why not #gag the prompt? create a sub-state of your capture trigger that matches the prompt and gag it?

Newbie Joined: 28 Jun 2001 Posts: 4

I have gagged it at the prompt.

Trigger is set for yells: {#CAP COMS;#GAG} is the instruction.

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

Not what I meant, create a sub-state that gags the prompt something like this

#TRIGGER {yells} {#CAP COMS;#GAG}
#cond {prompt matching trigger pattern here} {#gag} {within|1}

BTW even though it is obvious that this is not the correct syntax I'm going to mention it anyway.

Something like this would capture your text to the window, gag the text in the main window, and if the prompt follows on the next line delete it as well.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Gagging the prompt can be a very bad thing at times. Removal of the prompt, for instance, seems to make the mapper not find the darn thing (I'm on a Simutronics game, however, so this might be a bit different for the rest of you).

Wizard Joined: 11 Jul 2002 Posts: 1265 Location: USA

That's why I told him to do it the way I did. It only gags the prompt after he enters a command. If the mud sends one on it's own the prompt remains.

So after the game shows you a room description it will show the prompt and the mapper can see it.

I only suggested this because he said this plugin that he can't use at the moment gagged the prompt after it captured his command.