About Us
Products
Purchase
Downloads
Support
Forums
Contact Us
Site
 Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: Mon Jul 14, 2008 12:07 pm   

[2.30] Bug? - commands sent to focussed child windows instead of main session
 
Something odd has happened which I have not noticed before..

If I have a script busy sending commands, and I click on a child window, giving that window focus, the commands are send to the focussed child window rather than the main session window.

The child window are set to have 'No network connection.'
All packages are disabled for the child windows.

I don't have time right now to test this properly, but I will do later on and post whatever information I discover.
_________________
Athlon 64 3200+
Win XP Pro x64
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Mon Jul 14, 2008 12:16 pm   
 
Some commands do do things in the currently focused window - one of #say and #echo does, I can never remember which. I assume you mean literal commands, though.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: Mon Jul 14, 2008 12:34 pm   
 
Yeah, things like:

stand;claw @target;claw @target

sip health
etc.

I'm having a bit of a look at it now, but its hard. I have a task I'm trying to get done in game within a certain time frame. I was playing around with resizing my windows while I was bashing, and half the bashing script got sent to the child windows.


Edit: Oh, and its #echo that goes to all windows.
_________________
Athlon 64 3200+
Win XP Pro x64
Reply with quote
Nicodareus
Wanderer


Joined: 24 Jun 2008
Posts: 68
Location: Texas

PostPosted: Mon Jul 14, 2008 5:05 pm   
 
Yeah, this has been one of my irritations as well. I think game commands should at the very least default to the main window.. But I have found one way around this. I'm just moving copies of all of my keys into each of the windows and using the #EXECWIN command to default them to the main window..

Edit: If you want an easy way to do that, bring up a command line for the window in question and just input normal #KEY commands..

Code:

#VAR windowname {Insert the name of the main window to redirect the commands to}
#KEY KEY2 {#EXECWIN @windowname {s}}
#KEY KEY4 {#EXECWIN @windowname {w}}
#KEY KEY6 {#EXECWIN @windowname {e}}
#KEY KEY8 {#EXECWIN @windowname {n}}
#KEY KEY1 {#EXECWIN @windowname {sw}}
#KEY KEY3 {#EXECWIN @windowname {se}}
#KEY KEY7 {#EXECWIN @windowname {nw}}
#KEY KEY9 {#EXECWIN @windowname {ne}}
#KEY KEY5 {#EXECWIN @windowname {look}}
#KEY KEY0 {#EXECWIN @windowname {out}}
#KEY CTRL-KEY0 {#EXECWIN @windowname {x}}


Feel free to take out the #var command and just replace @windowname with the name of the window your main client info is coming through.. I find it easier to just use the #var since I have about 7 windows I do this for..

If you do use the #var than just fill in the caption for the main window for the mud between the brackets there.
Reply with quote
Nicodareus
Wanderer


Joined: 24 Jun 2008
Posts: 68
Location: Texas

PostPosted: Mon Jul 14, 2008 5:38 pm   
 
Seems that doing the above overwrites KEY1, KEY3, KEY7 and KEY9 in the 'KeypadDiag' class of the 'English Keypad' package instead of creating them for the window itself.. Which is mildly irritating because it basically takes effect for every session window...
_________________
Email: nikodareus@gmail.com

or

avonarys@gmail.com
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Mon Jul 14, 2008 6:07 pm   
 
Each window can have it's own macro definitions, so yes, when you click on a window, it's only going to use the macros assigned to that window.

Nicodareus: Yes, the #KEY command will overwrite existing macros. Just like the #VAR command will change the value of any existing #VAR that it finds within scope. You need to turn off the English Keypad package for those windows that you don't want to have it. In the future I'll look at trying to not overwrite settings from packages that are read-only.

I think some people are thinking too much of how zMUD worked with "inherited" and child windows. The proper way to handle this in CMUD is to create a Package that contains your macros. Then you just enable your package for each window that you want to have those macros.

However, I can see that if a window doesn't have any network connections, text sent to the MUD *should* be sent to the main window instead. That's something I can look into. The problem is that CMUD doesn't have the parent/child relationship between windows that zMUD had. In CMUD, for example, you could have 3 windows:

Window A: Main session window for MUD 1
Window B: Main session window for MUD 2
Window C: Consolidated "Tells" window that captures data from both MUDs.

So now you click on Window C and press a macro key to move south. So which MUD do you want to move south on? MUD 1 or MUD2?
Reply with quote
Nicodareus
Wanderer


Joined: 24 Jun 2008
Posts: 68
Location: Texas

PostPosted: Mon Jul 14, 2008 6:19 pm   
 
Interesting that you brng that up because I do exactly that for a roleplay mush I play on.. Could you have a simple option for it for the window itself on which window to default commands to that is only available if the window is set to 'No network connection' (Which isn't even a necessity.. I could find it being useful even on windows that DO have a connection..) I'd say the best thing it could do is default to sending to the window with the lowest id that has a connection. That way it works flawlessly for sessions that only have 1 such 'main' window.. And for other windows that are meant for consolidated tells and such like that will default to what was probably the first 'main session' window but could be changed to default to other windows or just turned off completely so that they don't accept commands. (Or at the very least, don't forward them.. As I could see an option to 'not accept commands' going very very badly for alot of users...)

Quote:
Nicodareus: Yes, the #KEY command will overwrite existing macros. Just like the #VAR command will change the value of any existing #VAR that it finds within scope. You need to turn off the English Keypad package for those windows that you don't want to have it. In the future I'll look at trying to not overwrite settings from packages that are read-only.


Actually, it only overwrote the ordinal directions, ne, se, sw, nw.. 9, 3, 1, 7 on the keypad.. It did -not- overwrite 2, 4, 6, or 8.

Edit: This only applies with the windows I've created with MXP.. I'm not sure if windows created in other ways will behave the same way.. If I create the key bindings in the main window, 2, 4, 6 and 8 are replaced along with 1, 3, 7 and 9..
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Mon Jul 14, 2008 7:24 pm   
 
Weird, I don't know what is different between the 9,3,1,7 keys and the 2,4,6,8 keys. CMUD shouldn't care. They *are* in different class folders (normal directions vs Diagonal directions), so was one of the class folders disabled or something?

For MXP-created windows, it should be trivial to set the default "parent" window, since that's the window that issued the FRAME command in the first place. But I think you are correct that there needs to be some sort of "parent" setting for windows that don't have their own network connection.
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Mon Jul 14, 2008 8:41 pm   
 
Use the 'relative to' postioning field for the windows. It makes a certain amount of sense that if the window has no connection and is trying to send a command it should pass it window that controls its postion in the layout.

I think before you could actually use that field you should coordinate redocking by draging the window with the value in that field (and the tabbbed/right/top/etc relation). I would even go so far as to say that the order during session loading would place adjusting this relationship last. This would allow a user to have 2 different sessions with nearly identical layouts, using the same packages, where the layout was actually causing a child window to send it commands to different windows in each session. I know it makes a headache for support, but it is only for those user that actively engage in multiple sessions with shared child windows.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: Mon Jul 14, 2008 8:59 pm   
 
Zugg wrote:

I think some people are thinking too much of how zMUD worked with "inherited" and child windows. The proper way to handle this in CMUD is to create a Package that contains your macros. Then you just enable your package for each window that you want to have those macros.


My scripts (in this case a semi-auto bashing script, and an autosipper) are in separate packages.
The package list for the 'child' window, has every package, these ones included, disabled.
The commands generated by these scripts, were sent to the child window when I gave it focus.

I've never noticed this happen before, and its probably the sort of thing I would notice, since I commonly play around with my settings while I bash.
However, I need to go to work now, and will play around with it properly when I get home.
_________________
Athlon 64 3200+
Win XP Pro x64
Reply with quote
Nicodareus
Wanderer


Joined: 24 Jun 2008
Posts: 68
Location: Texas

PostPosted: Mon Jul 14, 2008 9:18 pm   
 
Vijilante wrote:
Use the 'relative to' postioning field for the windows. It makes a certain amount of sense that if the window has no connection and is trying to send a command it should pass it window that controls its postion in the layout.

I think before you could actually use that field you should coordinate redocking by draging the window with the value in that field (and the tabbbed/right/top/etc relation). I would even go so far as to say that the order during session loading would place adjusting this relationship last. This would allow a user to have 2 different sessions with nearly identical layouts, using the same packages, where the layout was actually causing a child window to send it commands to different windows in each session. I know it makes a headache for support, but it is only for those user that actively engage in multiple sessions with shared child windows.


This wouldn't really work for me.. I have a single command for new users on my MUD to type to open up some predefined MXP windows (7 of them) and some of them are created relative to each other but I'd still want all of them defaulting to the main window, not the one they were created next to/inside of.
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Mon Jul 14, 2008 9:27 pm   
 
First thing to keep in mind is what Zugg said.
Quote:
For MXP-created windows, it should be trivial to set the default "parent" window


Now condiser what I am suggesting:
Window A--main session window
Window Tells-- docked right of A, no connection
Window Channels-- docked bottom of Tells, no connection

A command (xyz) is issued in the Channels window, it has no connection. It looks at what it is doccked relative to and passes the command for sending (already marked as #SENDRAW equivalent} to the Tells window. The Tells window tries to send the 'xyz' command it received from the Channels window. However the Tells window has no network connection, so it passes it to the window it is docked relative to, A. The window A is now told by Tells to send the 'xyz' command, it has a netowrk connection and does it...all the windows and some of the users are happy.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Nicodareus
Wanderer


Joined: 24 Jun 2008
Posts: 68
Location: Texas

PostPosted: Mon Jul 14, 2008 9:42 pm   
 
Yeah. I suppose that makes a bit more sense. Not quite what I thought you were saying.
_________________
Email: nikodareus@gmail.com

or

avonarys@gmail.com
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Mon Jul 14, 2008 11:00 pm   
 
Well, first I was going to post that this wouldn't work in my session either, where I have multiple chat windows "tabbed" to my Tell window (which is aligned to the top of the main window). But then I read Vijilante's update a bit more carefully and now I understand. Yes, if it recursively looked for a window with a network connection, then using the positioning would work.

The other nice thing about using this method is that it doesn't change as you move all of your windows around the screen. It allows CMUD to determine the parent "session" window based upon the default positioning rather than the current positioning. So even if the Tell window in the example above got somehow docked to your Session #2, it would still send commands to Session #1 since that is still listed as the "position relative to" in the properties of the tells window.

So yes, I think Vijilante's idea works well and that's what I'll try to implement. It actually shouldn't be too hard.
Reply with quote
Caled
Sorcerer


Joined: 21 Oct 2000
Posts: 821
Location: Australia

PostPosted: Tue Jul 15, 2008 9:09 am   This bug linked to expression triggers.
 
Turns out this bug is linked to expression triggers, as I discovered when testing.

1. Create a new session for IRE mud. I used Aetolia.
2. To clarify, this means brand new, blank package files.
3. Create the following settings:
Code:
<module name="WindowtestingP" global="true">
  <uid>{FEA45535-294A-4AA6-A78B-240C4FC9C309}</uid>
  <class name="Prompt" id="1">
    <trigger priority="20" prompt="true" id="2">
      <pattern>H:%d M:%d E:%d W:%d B:%d~% ~[%w (%x) %x~]</pattern>
      <value>eqbal=%1</value>
    </trigger>
    <var name="eqbal" id="4">eb</var>
  </class>
  <class name="Auto" id="5">
    <trigger type="Expression" priority="60" prompt="true" id="6">
      <pattern>@eqbal="eb"</pattern>
      <value>touch boar</value>
    </trigger>
    <trigger priority="70" id="7">
      <pattern>You have recovered balance on all limbs.$</pattern>
      <value>frown</value>
    </trigger>
  </class>
</module>


4. Make sure the prompt trigger is working, and if you don't have the ability to 'touch boar', pick some other command you can send which uses balance and/or equilibrium. (custom emote would work for brand new character, as these use balance "emote I'm testing CMUDs wonderfulness"
5. Create a second window, with no network connection, and make sure it has no packages enabled for it.

6. With the focus on the main window, send the command 'touch boar' from the command line. Make sure that each time you regain balance, the expression trigger sends the command 'touch boar'. Also make sure that the other trigger send the command to 'frown' or similar - i.e. anything that does not use balance.

7. Now, click on the other window, and wait. The command 'touch boar' will be sent to the focussed window, but the other command (frown) will go to the main window.





Quote:
0.0022 |
0.0019 | a WindowTe |You have recovered balance on all limbs.
0.0014 | f WindowTe |Pattern: You have recovered balance on all limbs.$
0.0018 | c WindowTe |exec : Pattern "You have recovered balance on all limbs.$" : frown
0.0019 | a WindowTe |frown
0.0016 | j WindowTe >frown
0.1769 | a WindowTe #Telnet 200: Char.Vitals<LF>H:3740/3740 M:3020/3020 E:17600/17600 W:14000/14000 NL:30/100
0.0024 | a WindowTe ]H:3740 M:3020 E:17600 W:14000 B:100% [cdb eb lr] [Vote]
0.0015 | f WindowTe |Pattern: H:%d M:%d E:%d W:%d B:%d~% ~[%w (%x) %x~] : (%1="eb")
0.0020 | c WindowTe |exec : Pattern "H:%d M:%d E:%d W:%d B:%d~% ~[%w (%x) %x~]" : eqb...
0.0014 | k WindowTe |Var "eqbal" changed from "e-" to "eb"
0.0016 | f WindowTe |Expression: @eqbal="eb"
0.0019 | c WindowTe |[12] ExpTrig : start : Expression "@eqbal="eb"" : touch boar
0.0030 | a WindowTe |H:3740 M:3020 E:17600 W:14000 B:100% [cdb eb lr] [Vote]touch boar
0.0030 | j WindowTe >touch boar
0.0015 | d WindowTe |[12] ExpTrig : stopped
0.0047 | d WindowTe |[12] ExpTrig : terminated
0.1887 | a WindowTe #Telnet 200: Char.Vitals<LF>H:3740/3740 M:3020/3020 E:17600/17600 W:14000/14000 NL:30/100
0.0019 | a WindowTe |
0.0017 | a WindowTe |You crease your brow in a frown.
0.0024 | a WindowTe ]H:3740 M:3020 E:17600 W:14000 B:100% [cdb eb lr] [Vote]
0.0015 | f WindowTe |Pattern: H:%d M:%d E:%d W:%d B:%d~% ~[%w (%x) %x~] : (%1="eb")
0.0019 | c WindowTe |exec : Pattern "H:%d M:%d E:%d W:%d B:%d~% ~[%w (%x) %x~]" : eqb...
0.3034 | a WindowTe #Telnet 200: Char.Vitals<LF>H:3740/3740 M:3020/3020 E:17600/17600 W:14000/14000 NL:30/100
0.0019 | a WindowTe |H:3740 M:3020 E:17600 W:14000 B:100% [cdb eb lr] [Vote]
0.0020 | f WindowTe |Pattern: H:%d M:%d E:%d W:%d B:%d~% ~[%w (%x) %x~] : (%1="eb")
0.0019 | c WindowTe |exec : Pattern "H:%d M:%d E:%d W:%d B:%d~% ~[%w (%x) %x~]" : eqb...
0.0019 | a WindowTe |Your boar tattoo tingles slightly.
0.0021 | a WindowTe |Balance Used: 4.25 seconds
0.0034 | a WindowTe ]H:3740 M:3020 E:17600 W:14000 B:100% [cdb e- lr] [Vote]
0.0018 | f WindowTe |Pattern: H:%d M:%d E:%d W:%d B:%d~% ~[%w (%x) %x~] : (%1="e-")
0.0019 | c WindowTe |exec : Pattern "H:%d M:%d E:%d W:%d B:%d~% ~[%w (%x) %x~]" : eqb...
0.0014 | k WindowTe |Var "eqbal" changed from "eb" to "e-"
3.8721 | a WindowTe |H:3740 M:3020 E:17600 W:14000 B:100% [cdb e- lr] [Vote]
0.0021 | f WindowTe |Pattern: H:%d M:%d E:%d W:%d B:%d~% ~[%w (%x) %x~] : (%1="e-")
0.0019 | c WindowTe |exec : Pattern "H:%d M:%d E:%d W:%d B:%d~% ~[%w (%x) %x~]" : eqb...
0.0090 | a WindowTe |You have recovered balance on all limbs.
0.0022 | f WindowTe |Pattern: You have recovered balance on all limbs.$
0.0019 | c WindowTe |exec : Pattern "You have recovered balance on all limbs.$" : frown
0.0015 | a WindowTe |frown
0.0016 | j WindowTe >frown
0.1774 | a WindowTe #Telnet 200: Char.Vitals<LF>H:3740/3740 M:3020/3020 E:17600/17600 W:14000/14000 NL:30/100
0.0023 | a WindowTe ]H:3740 M:3020 E:17600 W:14000 B:100% [cdb eb lr] [Vote]
0.0015 | f WindowTe |Pattern: H:%d M:%d E:%d W:%d B:%d~% ~[%w (%x) %x~] : (%1="eb")
0.0022 | c WindowTe |exec : Pattern "H:%d M:%d E:%d W:%d B:%d~% ~[%w (%x) %x~]" : eqb...
0.0016 | k mapwindo |Var "eqbal" changed from "e-" to "eb"
0.0012 | f mapwindo |Expression: @eqbal="eb"
0.0019 | c mapwindo |[13] ExpTrig : start : Expression "@eqbal="eb"" : touch boar
0.0028 | a mapwindo |touch boar
0.0017 | j mapwindo >touch boar
0.0011 | d mapwindo |[13] ExpTrig : stopped
0.0067 | d mapwindo |[13] ExpTrig : terminated
0.3637 | a WindowTe #Telnet 200: Char.Vitals<LF>H:3740/3740 M:3020/3020 E:17600/17600 W:14000/14000 NL:30/100
0.0019 | a WindowTe |H:3740 M:3020 E:17600 W:14000 B:100% [cdb eb lr] [Vote]
_________________
Athlon 64 3200+
Win XP Pro x64
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Jul 15, 2008 4:44 pm   
 
Expression Triggers always run in the context of the currently selected window. So that is correct. The "fix" that is planned is to take text that is normally sent to the MUD and send it to the "parent" window if the current window doesn't have any network connection. This would fix your problem since it would send "touch boar" to your main window.
Reply with quote
Nicodareus
Wanderer


Joined: 24 Jun 2008
Posts: 68
Location: Texas

PostPosted: Tue Jul 15, 2008 6:17 pm   
 
I'm assuming this will also fix the issue with MXP <SEND> statements in frames sending the command to the frame instead of the main session window. I've been using <SEND href="#EXECWIN @windowname { buy 1 potion }">x1</SEND> in the meantime.. Well, for private testing really.. This isn't something I'd want to have to fully implement in that manner..
_________________
Email: nikodareus@gmail.com

or

avonarys@gmail.com
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Tue Jul 15, 2008 6:33 pm   
 
Nic: Yes, it should take care of that problem too.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net