Zugg Software :: View topic - "Introduction to Multiplaying" out of date?

Posted: Sun Feb 04, 2007 5:29 am

The Introduction to Multiplaying help topic is out of date, or there are some bugs with the colon.

":command" and "1:command" to send a command to all windows or to a window by number send the command literally.
":win:#echo test" isn't echoing in "win", it's echoing in the mud output window, bizarrely. ":win:command" still works fine.

Posted: Mon Feb 05, 2007 8:19 pm

If you look at the help file for #ECHO you will see that it says

Posted: Mon Feb 05, 2007 9:18 pm

You know, I always wondered what the difference between #echo and #say was. I'd been using them interchangably ;)

Newbie Joined: 06 Nov 2007 Posts: 7

Any update on getting the :command to send the command to all windows? Right now it seems to be sending a literal ":command" directly to the the active window.

Can anyone help me with a workaround that would duplicate the desired functionality until this is fixed, while preserving the :win:command functionality?

Posted: Tue Nov 06, 2007 5:36 pm

Use #all instead.

Newbie Joined: 06 Nov 2007 Posts: 7

This helps, Fang, because I was unaware of the #ALL command, but would there be a way to set up an alias to have cmud recognize ":command" as "#ALL {command}", while keeping the ":win:command" functionality?

Posted: Tue Nov 06, 2007 10:10 pm

Hmm... perhaps. This might work:

#oninput {^~:(*)} {#all %1}

This depends on when exactly the parser splits the window names out of the commands. If the oninput trigger is getting called when you send ":win:whatever", you could try

#oninput {^~:(*)} {#if (!%pos(":",%1)) {#all %1}}

Newbie Joined: 06 Nov 2007 Posts: 7

Both of these cause a parse error - "illegal character: all"

Posted: Tue Nov 06, 2007 10:41 pm

Both these scripts are working exactly as intended for me in the untitled session on CMUD 2.10. Are you using 1.34?

Newbie Joined: 06 Nov 2007 Posts: 7

Yes, I am using 1.34. I guess I will just wait for the public 2.0

Apprentice Joined: 03 Feb 2007 Posts: 170

Hmm, I'm curious why exactly did the syntax change from:

#ALL say Testing

to

#ALL {say Testing}

That just seems to add more keystrokes for something that wasn't ambiguous beforehand.

Posted: Thu Nov 08, 2007 10:58 am

...as far as I'm aware, it hasn't. I tested just now in CMUD 2.10 and your first example is working just fine. What gave you impression that it'd changed?

Apprentice Joined: 03 Feb 2007 Posts: 170

Hmm, in 1.34 if I type: #ALL say Testing

I get this:

Error parsing command:
illegal token: y Testing

Beginner Joined: 28 Nov 2007 Posts: 15

I have some issues with the :win:command. When I try to use it in an alias, it seems to only send it as literal.

I.e. I have alias o1 for :G1:%-1
For that char I then have alias b for backstab. If G1 is active window, b alias works. If I from another window use :G1:b whatever, it works (but only after upgrading from 1.34 to new beta version).
But if I do o1 b whatever it sends b whatever in the G1 window. And given the difference between backstab and bounce, thats kinda fubar :)

Anyone that can help me with this?

Posted: Wed Nov 28, 2007 7:24 pm

You'd think that backstab would be used before bounce, given their positions in the alphabet. Or, failing that, the MUD wouldn't include completion like that =/

Anyway. It seems that this behaviour has been changed between 1.34 and the current beta 2.13, because it's working fine for me in that version.

What follows is a short explanation of why it's this way in 1.34. Read if you're curious :)

It's probably something to do with your settings tree looking like this:

Beginner Joined: 28 Nov 2007 Posts: 15

Hm, it's working fine for you.. Why not for me then? I actually do have a module, although the b alias isn't in that. But even if I try adding it there as a quick test, it doesn't help.

So what I have is beta 2.13
- Module with the aliases o1, o2, o3, o4
- 4 windows, G1-G4. Each of these set to include the module.
(I figure that'd resemble my old ZMud setup with a parent file and a specific per-char file)

It just seems whenever I use o# to fire :G#:something, it's sent as literal. o1 smile will work, but o1 o2 smile would not - this would send o2 smile to the mud inside G1. If you gave me the solution above, I'm sorry I didn't understand it :)

Posted: Wed Nov 28, 2007 7:56 pm

My test was this:

Open CMUD.
Close the Sessions Dialogue.
Click Settings on the toolbar to open the Package Editor.
Click the New... button, select window, name it test, tile it with the untitled window so you can see it.
Click on the untitled window in the package editor so it's selected.
Click New... Alias, name it "omg" with the script "#say ahahahaha!"
Close the package editor.
On the command line of the untitled window, type ":test:omg" and press enter
"ahahahaha!" should appear in the test window rather than "omg" being literally sent to it.

See if this works for you.

Beginner Joined: 28 Nov 2007 Posts: 15

Ah, but then you are missing one level of indirection. ":G1:b mob" works for me. This issue arises when :win: is an alias, which o1 is - "o1 b mob" give the problem.

So in your scenario does it still work if you make an alias nono for :test:%-1 in the untitled window and fire it as nono omg?

Posted: Wed Nov 28, 2007 9:55 pm

Ah yes, I see now. This is definitely a case of what I describe above - since it's the module running the :win: command, it can't see the alias inside the window. You should move any aliases you want to be available in all windows to a separate module, too.

EDIT: Having said that, even that doesn't work. There seems to be some kind of alias scoping bug here, and you should start another thread about it.

Posted: Wed Nov 28, 2007 10:31 pm

Please remember to keep posts about the BETA version in the BETA FORUM. If there is a bug in the beta version, post it there.

Beginner Joined: 28 Nov 2007 Posts: 15

Sorry, but that came a bit late - I've already posted it here. I did contemplate wheter that was proper, but as can be seen above I only "upgraded" to beta in the hope this problem would disappear.
So while my latest test was done with the beta version, I noticed the issue in 1.34

Should I still post it in the beta forum as well?

Wizard Joined: 03 Mar 2001 Posts: 1127 Location: London

Might be worth just putting another comment in it asking a moderator to move the topic to the beta forum

Posted: Thu Nov 29, 2007 5:05 pm

If this problem still exists in the 2.13 beta version, then yes, please make a new post in the Beta Forum to report it along with the exact procedure used to reproduce the problem. I'm not going to move this topic because most of the original information in the topic was for the public version.