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
chamenas
Wizard


Joined: 26 Mar 2008
Posts: 1547
PostPosted: Fri Apr 30, 2010 1:44 am   

Neither non-command nor #EXEC text firing
 
Here's another odd issue for today, sorry for all the posts:

Code:

<trigger name="spell-rec" priority="5820" regex="true" enabled="false" id="1283">
  <pattern>(@_spell_rec_list)</pattern>
  <value>#EXEC {affects gather}
#T- spell-rec</value>
</trigger>


This trigger used to work, now it doesn't. So I tested the patterns and found that they worked just fine. However, it's not sending "affects gather" to the MUD. Thinking that it was the use of the #EXEC command, I decided instead to take that away and just allow it to fire alone, with just "affects gather" but that didn't work either. So I then put it in #send "affects gather". That time it worked and was sent to the MUD, but it's an alias and I can't make use of it if affects gather has to be sent via a #SEND command. Anyone know what's up? (should be noted that the trigger turns itself off just fine)
_________________
Listen to my Guitar - If you like it, listen to more		 Reply with quote
charneus
Wizard


Joined: 19 Jun 2005
Posts: 1876
Location: California
PostPosted: Fri Apr 30, 2010 2:25 am   
 
(@_spell_rec_list) should be {@_spell_rec_list}

{} is used to denote multiple items, whereas () only captures, and since you're not using %1, you just need to change the () to {}.

Charneus
Reply with quote
chamenas
Wizard


Joined: 26 Mar 2008
Posts: 1547
PostPosted: Fri Apr 30, 2010 2:42 am   
 
I didn't know that. Thank you. I did make the change though, and I'm still having the same problem.
_________________
Listen to my Guitar - If you like it, listen to more		 Reply with quote
chamenas
Wizard


Joined: 26 Mar 2008
Posts: 1547
PostPosted: Fri Apr 30, 2010 3:08 am   
 
And yes, it does become enabled, via
Code:

<trigger name="spell-cap-on" type="Command Input" priority="5810" regex="true" id="1282">
  <pattern>(@_spell_cap_list)</pattern>
  <value>#T+ spell-rec</value>
</trigger>


Which could also be made {}, but fires just fine right now.
_________________
Listen to my Guitar - If you like it, listen to more		 Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA
PostPosted: Fri Apr 30, 2010 3:18 am   
 
when @_spell_cap_list only has one item it will fire. It will stop firing when the variable gets two or more items, unless the purpose of this trigger is to match a #SAY/#ECHO/#SHOW of the list (directly referencing the variable, a stringlist will show in its literal text format of item|item|item).
_________________
EDIT: I didn't like my old signature		 Reply with quote
chamenas
Wizard


Joined: 26 Mar 2008
Posts: 1547
PostPosted: Fri Apr 30, 2010 3:42 am   
 
Well, spell_cap_list fires normally, it fires to spell command inputs which are recorded in the list:

Code:

<class name="Auto-Gather" id="1087">
  <var name="_spell_rec_list" type="StringList" id="1090">You are surrounded by a white aura|You are filled with holy wrath|You feel someone protecting you|Your skin turns to stone|You feel righteous|You are surrounded by a force shield|Your feet rise off the ground|You feel blessed with a vitalizing aura|A feeling of divinity overtakes your presence|You feel yourself moving more quickly</var>
  <var name="_spell_cap_list" type="StringList" id="1091">c sanc|c frenzy|c frenz|c armor|c arm|c stone|c bless|c shield|c ston|c fly|prayer|quaff greenish|c haste</var>
</class>


Right now, it fires fine. And does what it's supposed to do, turn on the trigger for _spell_rec_list. _spell_rec_list fires and turns itself off, but it seems it will only send "affects gather" if I use a #send command. It wont send it if I dont prefix anything to it, and it won't send it via exec. The problem is that affects is an alias and I need it to be sent as an alias.
_________________
Listen to my Guitar - If you like it, listen to more		 Reply with quote
chamenas
Wizard


Joined: 26 Mar 2008
Posts: 1547
PostPosted: Fri Apr 30, 2010 4:05 pm   
 
I still haven't the slightest clue what's up here. It makes no sense that #send "affects gather" would work and yet #exec {affects gather} wouldnt. One is sent to the mud and the other isn't, the trigger is otherwise firing both times.
_________________
Listen to my Guitar - If you like it, listen to more		 Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
PostPosted: Fri Apr 30, 2010 4:22 pm   
 
Remember that *ANY* time you use a @stringlist variable in a trigger pattern, you MUST enclose it in {}. The {} operator in a trigger is used to match multiple values, such as {item1|item2|item3} etc. In normal zScript, {} act as quotes that allow variables to be expanded. But within a trigger patter, {} have completely different meanings. So it's easy to get them confused. But consider the following two cases:

Code:
#VAR @list {item1|item2|item3}
#TRIGGER trig1 {(@list)} {do whatever}
#TRIGGER trig2 {({@list})} {do whatever}

OK, all of the {} and () can make your head hurt, but take it step by step:

1) The outer-most {} around the trigger pattern just acts like "quotes" in CMUD to enclose the trigger pattern. It tells CMUD: Whatever is inside the {} is the pattern for the trigger. So that leaves us with these two patterns:
Code:
(@list)
({@list})

2) When CMUD tests the trigger pattern, it expands the variables. After the variable expansion, the patterns now look like this:
Code:
(item1|item2|item3)
({item1|item2|item3})

3) The () around an item just tells the pattern matcher to save the matched text to the %1 variable. What confuses some people is that with REGULAR EXPRESSIONS, the (a|b|c) syntax *does* perform an OR-list match. But that is with regular expressions and not with the zScript trigger syntax. With zScript patterns, the () is ONLY used to save matched text and has no other purpose. The {a|b|c} syntax performs the OR-match.
4) When these zScript patterns get converted to regular expressions to actually perform the pattern matching against the MUD text, the {} for the OR-list gets converted to (?:list) so now we get the following regular expressions:
Code:
(item1|item2|item3)
((?:item1|item2|item3))

the ?: inside the ( just tells the regular expression *not* to save the subpattern to %1.

So guess what, *both* patterns end up working. That explains why your triggers sometime still work even without the {} around the list.

So what's the difference between the two? When CMUD converts the {value} into the (?:value) regular expression, it does some extra work to ensure the list works properly. With regular expression OR-lists, it's important to order the values in the list correctly or else multiple items in the list that start with the same text will not work properly. CMUD also checks to see if there is any "null value" in the list variable and handles that properly too. So this conversion is actually complicated. By using {} around your list variable, you ensure that it will always work properly. If you forget the {} and just have () around the list variable, then you need to know more about regular expressions and the order of items in your list to know if it will work.

That is probably way more information than you wanted, but hopefully seeing the internals of how CMUD is handling this will help.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
PostPosted: Fri Apr 30, 2010 4:24 pm   
 
Quote:
It makes no sense that #send "affects gather" would work and yet #exec {affects gather} wouldnt.

Yes, it makes perfect sense. The #EXEC command is used to execute a CMUD script. "affects gather" is not a script. It is just plain text. Unless "affects" is an Alias reference, then nothing will happen. That actually only worked in zMUD because of a bug in the zMUD parser (if something wasn't a script or alias, it was automatically sent to the MUD).

So, use #EXEC to EXECUTE a script/alias. Use #SEND to SEND DATA to the MUD.
Reply with quote
chamenas
Wizard


Joined: 26 Mar 2008
Posts: 1547
PostPosted: Fri Apr 30, 2010 5:36 pm   
 
But affects IS an alias. That's the problem :-/

Here's the alias, affects gatherer works just fine when you type it in (assuming, of course, you're playing DSL)
Code:

<alias name="affects" id="565">
  <value>$_send_aff=0
#switch (%begins( "add", %1)) {#IF (%ismember( %-2, @_accept_spell)) {
    $_mem_num=%ismember( %-2, @_accept_spell)
    $_spell=%item( @_accept_spell, $_mem_num)
    #show "The spell, "$_spell", is already in the list."
    } {
    #ADDI _accept_spell %-2
    #show %-2" added to the accepted spells list."
    show_aff
    }}
  (%begins( "remove", %1)) {#IF (%ismember( %-2, @_accept_spell)) {
    $_mem_num=%ismember( %-2, @_accept_spell)
    $_del_spell=%item( @_accept_spell, $_mem_num)
    #DELNI _accept_spell $_mem_num
    #DELKEY _spell_list %-2
    #show $_del_spell" has been deleted from the accepted spells."
    show_aff
    } {#show %-2", is not currently listed on the accepted spells."}}
  (%begins( "gather", %1)) {#IF (!@_spellup) {
    #T+ gag-aff
    #T+ gag-aff-off
    #send "aff"
    }}
  (%begins( "auto", %1)) {#switch (%begins( "capture", %2)) {#IF (%ismember( %-3, @_spell_cap_list)) {
      $_mem_num=%ismember( %-3, @_spell_cap_list)
      $_spell_name=%item( @_spell_cap_list, $_mem_num)
      #DELNI _spell_cap_list $_mem_num
      #show $_spell_name" has been removed from the spell capture list."
      } {
      #ADDI _spell_cap_list %-3
      #show %-3" added to the capture list."
      #show "Remember to use 'affects auto record ' in order to complete the auto-spell refresh of affects."
      }}
   (%begins( "record", %2)) {#IF (%ismember( %-3, @_spell_rec_list)) {
      $_mem_num=%ismember( %-3, @_spell_rec_list)
      $_spell_name=%item( @_spell_rec_list, $_mem_num)
      #DELNI _spell_rec_list $_mem_num
      #show $_spell_name" has been removed from the spell record list."
      } {
      #ADDI _spell_rec_list %-3
      #show %-3" added to the record list."
      #show "Remember to use 'affects auto capture ' in order to complete the auto-spell refresh of affects."
      }}}
  {
  #send "aff"
  $_send_aff=1
  }
 
#if (!$_send_aff) {#send %cr}</value>
</alias>


So the problem isn't with affects gather. It's with #EXEC, for some reason, not even seeing affects as an alias and thus not firing it off.
_________________
Listen to my Guitar - If you like it, listen to more		 Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
PostPosted: Fri Apr 30, 2010 5:56 pm   
 
It's got to be something specific to your script, or maybe your script is located in some other package/module that #EXEC isn't seeing. I just did this simple test:
Code:
#ALIAS affects {#SHOW fired with %1}
#EXEC "affects gather"

and it worked fine.

But #EXEC is compiling and executing the script at runtime, so maybe the "context" of where #EXEC is running isn't correct and it can't see your alias. We'd need more information about your script module and package structure to help more with this.
Reply with quote
Taz
GURU


Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom
PostPosted: Fri Apr 30, 2010 6:08 pm   
 
chamenas wrote:
So the problem isn't with affects gather. It's with #EXEC, for some reason, not even seeing affects as an alias and thus not firing it off.
I just did a test in an untitled session using:
Code:
#alias affects {#if (%1 = "gather") {#show "Yes!"} {#show "No!"}}
#exec {affects gather}
#exec {affects gathe}
and the output was
Yes!
No!

Do the same just copy and paste into the command line.

If instead you want proof that #exec used within scripts works then use the following as a test:
Code:
#alias affects {#if (%1 = "gather") {#show "Yes!"} {#show "No!"}}
#alias test {#exec {affects gather};#exec {affects gathe}}
#exec {test}
the output again is
Yes!
No!

It means there is something wrong somewhere with your script.
_________________
Taz :)		 Reply with quote
Martaigne
Wanderer


Joined: 05 Jan 2002
Posts: 88
Location: Atlanta, GA
PostPosted: Fri Apr 30, 2010 7:18 pm   
 
Zugg wrote:
So, use #EXEC to EXECUTE a script/alias. Use #SEND to SEND DATA to the MUD.


I beg to differ. In 2.37, I use #EXEC to send commands to the MUD instead of #SEND because #EXEC allows it to show up in the command buffer and can be referenced by another script later. It works just fine to send to the MUD. The URL in my signature has a download link for the XML file.
_________________
Unwritten Legends		 Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
PostPosted: Fri Apr 30, 2010 8:01 pm   
 
Quote:
#EXEC allows it to show up in the command buffer and can be referenced by another script later

Not sure what you mean by the "command buffer". Can you elaborate?

Using #EXEC instead of #SEND is highly not recommended. For one thing, #EXEC is causing your string to be parsed and compiled each time which is a slower operation.
Reply with quote
Martaigne
Wanderer


Joined: 05 Jan 2002
Posts: 88
Location: Atlanta, GA
PostPosted: Fri Apr 30, 2010 8:21 pm   
 
I wrote a small but useful utility that will attempt to re-send commands if the user is caught in round time which prevents the commands from being executed in the MUD.

While working with this, I noticed that it didn't work for aliases as it would just send the alias directly to the MUD instead of parsing them, so I used #EXEC to resolve this. (This works pretty much as you state.) I also discovered that any macros keys would send a command directly to the MUD without going through the command buffer.

So, for example, if a user is navigating using the directional numpad macros, and hits a spot of round time, the directional command sent to the mud from the macro key wasn't in the command buffer when %lastcom or %lastinput is used. I found this to be true with a raw string (e.g. 'north'), #SEND, and #SENDRAW.

To work around this, my macro keys all utilize #EXEC, because for some reason #EXEC will cause the command from the macro key to be in the command history, whereas all the previously mentioned methods wouldn't. But #EXEC seems to work just as well for sending raw game commands as it does for executing scripts and aliases.
_________________
Unwritten Legends		 Reply with quote
chamenas
Wizard


Joined: 26 Mar 2008
Posts: 1547
PostPosted: Fri Apr 30, 2010 8:38 pm   
 
I will look around and see if I can figure out why. The trigger and the alias are now in the same class. They used to be cross-package, but I put them together and still have the issue.
_________________
Listen to my Guitar - If you like it, listen to more		 Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320
PostPosted: Sat May 01, 2010 9:30 pm   
 
Quote:
To work around this, my macro keys all utilize #EXEC, because for some reason #EXEC will cause the command from the macro key to be in the command history, whereas all the previously mentioned methods wouldn't. But #EXEC seems to work just as well for sending raw game commands as it does for executing scripts and aliases.

Yes, you could say it is "working just as well" for raw game commands as for executing scripts and aliases. But "just as well" is not the same as "working well". There are good reasons why #EXEC should only be used when necessary. It really is much slower (noticeably slower, in many cases). It may be that EXEC is necessary for your particular application (I can't tell for sure from the description), but it should not be recommended except in cases where it _is_ necessary.
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