Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum
Fizban1216
Apprentice


Joined: 03 Feb 2007
Posts: 170
PostPosted: Sat Mar 27, 2010 9:53 pm   

Database Help
 
Trying to setup a database to automatically have data entered into it when I identify an object.

If I click on the bolded:

Quote:
Adding data from the MUD

Because the CMUD database can be controlled from the CMUD scripting language, you can set up triggers and aliases to automatically capture the result of an "identify" spell on the MUD and create a new record with this data. For information on how to do this, see the help section on Scripting the Database.


It simply takes me to a page which reads:

Quote:
Select a subtopic from the list on the left


Anyone able to show example syntax of how to make CMUD create a new record and fill in the 'name' field? (I can use the example to make the rest of the field be automatically filled in)?

Identify output looks like so:

Quote:
You feel informed:
Object 'a pair of chainmail boots', Item type: ARMOR
Item is: ANTI_MAGE ANTI_THIEF
Weight: 20, Value: 2100, Rent: 0, Min. level: 2
Wearability: TAKE FEET
Can affect you as :
Affects: DAMROLL By 1
Affects: DEX By -1
Affects: ARMOR By -3
Reply with quote
Fizban1216
Apprentice


Joined: 03 Feb 2007
Posts: 170
PostPosted: Sat Mar 27, 2010 9:57 pm   
 
Also am curious what the procedure is to take advantage of the mapper and database integration to be able to speedwalk to the location of a given item.
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA
PostPosted: Sat Mar 27, 2010 10:19 pm   
 
#NEW "" $identified_item

#NEW "" Name=%1 Type=%2 and so on
#NEW "" {Name=%1|Type=%2|and so on}

#NEW %concat(%2,"|ItemsDBName") etc

I assume that given your desire to tackle database scripting you have already gained proficiency in building triggers, so I didn't take the time to write something you already know how to handle.
_________________
EDIT: I didn't like my old signature		 Reply with quote
Fizban1216
Apprentice


Joined: 03 Feb 2007
Posts: 170
PostPosted: Sun Mar 28, 2010 7:13 pm   
 
Tried the following, but doesn't seem to work:

Text from the MUD:

Quote:

You feel informed:
Object 'a spiked mace', Item type: WEAPON
Item is: ANTI_THIEF
Weight: 12, Value: 1500, Rent: 0, Min. level: 0
Damage Dice is '2D5' for an average per-round damage of 6.0.


Trigger:
Code:

<trigger priority="270" id="27">
  <pattern>^Damage Dice is '~(*)~' for an average per-round damage of (*).$</pattern>
  <value>#COND {^Object ~'(*)~', Item type~: (%w)$} {
  #VAR name %1
  #VAR type %2
}
#COND {^Item is~: (*)$} {#VAR restrictions %1}
#COND {Damage Dice is ~'(*)~' for an average per-round damage of (*).} {
  #VAR damage %1
  #VAR average %2
}
#NEW Equipment {Name=@name|Type=@type|Restrictions=@restrictions|Damage=@damage|Average=@average}
#UNVAR name
#UNVAR type
#UNVAR damage
#UNVAR average
#UNVAR restrictions</value>
  <trigger>
    <pattern>^Object ~'(*)~', Item type~: (%w)$</pattern>
    <value>  #VAR name %1
  #VAR type %2</value>
  </trigger>
  <trigger>
    <pattern>^Item is~: (*)</pattern>
    <value>#VAR restrictions %1$</value>
  </trigger>
  <trigger>
    <pattern>^Damage Dice is '~(*)~' for an average per-round damage of (*).$</pattern>
    <value>  #VAR damage %1
  #VAR average %2</value>
  </trigger>
  <trigger>
    <pattern>^Object ~'(*)~', Item type~: (%w)$</pattern>
    <value>  #VAR name %1
  #VAR type %2</value>
  </trigger>
  <trigger>
    <pattern>^Item is~: (*)</pattern>
    <value>#VAR restrictions %1$</value>
  </trigger>
  <trigger>
    <pattern>^Damage Dice is '~(*)~' for an average per-round damage of (*).$</pattern>
    <value>  #VAR damage %1
  #VAR average %2</value>
  </trigger>
  <trigger name="">
    <pattern>^Object ~'(*)~', Item type~: (%w)$</pattern>
    <value>  #VAR name %1
  #VAR type %2</value>
  </trigger>
  <trigger name="">
    <pattern>^Item is~: (*)</pattern>
    <value>#VAR restrictions %1$</value>
  </trigger>
  <trigger name="">
    <pattern>^Damage Dice is ~'(*)~' for an average per-round damage of (*).$</pattern>
    <value>  #VAR damage %1
  #VAR average %2</value>
  </trigger>
</trigger>


Same trigger is easier to read format:

Code:

#COND {^Object ~'(*)~', Item type~: (%w)$} {
  #VAR name %1
  #VAR type %2
}
#COND {^Item is~: (*)$} {#VAR restrictions %1}
#COND {Damage Dice is ~'(*)~' for an average per-round damage of (*).} {
  #VAR damage %1
  #VAR average %2
}
#NEW Equipment {Name=@name|Type=@type|Restrictions=@restrictions|Damage=@damage|Average=@average}
#UNVAR name
#UNVAR type
#UNVAR damage
#UNVAR average
#UNVAR restrictions
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA
PostPosted: Sun Mar 28, 2010 7:59 pm   
 
1)Can you spot what you did wrong in your example? Also, as an FYI you really shouldn't be typing stuff into the XML tab.

Code:
#trigger {pattern} {value}
#condition {pattern} {value}


Code:
<trigger>
  <pattern>pattern</pattern>
  <value>value</value>
  <pattern>pattern</pattern>
  <value>value</value>
</trigger>


Notice the lack of #CONDITION in both the <value> block as well as in the XML entirely.

2)Learn to think logically. Putting the #NEW command in the trigger that will fire first isn't very smart because there's no information available to capture yet. At best, you add a duplicate copy of the previous record added; at worst, you added a blank record because the variables aren't yet filled.

3)#UNVAR is slow. It's faster to leave the variables created instead of creating/removing them each time.
_________________
EDIT: I didn't like my old signature		 Reply with quote
Fizban1216
Apprentice


Joined: 03 Feb 2007
Posts: 170
PostPosted: Sun Mar 28, 2010 11:39 pm   
 
MattLofton wrote:
1)Can you spot what you did wrong in your example? Also, as an FYI you really shouldn't be typing stuff into the XML tab.


I didn't type in the XML tab. I simply copied and pasted it.

MattLofton wrote:
Code:
#trigger {pattern} {value}
#condition {pattern} {value}


Code:
<trigger>
  <pattern>pattern</pattern>
  <value>value</value>
  <pattern>pattern</pattern>
  <value>value</value>
</trigger>


Notice the lack of #CONDITION in both the <value> block as well as in the XML entirely.


Indeed I do not notice the lack of #CONDITION, because there isn't a lack, it is in the XML I posted above.


MattLofton wrote:
2)Learn to think logically. Putting the #NEW command in the trigger that will fire first isn't very smart because there's no information available to capture yet. At best, you add a duplicate copy of the previous record added; at worst, you added a blank record because the variables aren't yet filled.


Thinking logically is certainly not in any way shape or form the issue. The variables were given values earlier in the the trigger, I have never seen any programming language where after doing the following you could not immediately use a.

Code:

a = b;



MattLofton wrote:
3)#UNVAR is slow. It's faster to leave the variables created instead of creating/removing them each time.


I don't want them remaining defined after the information is put into the database, otherwise if I identified a weapon, and then later identified a boot, it would imput the damage field from the weapon for the boot, which clearly should not have a damage field.
Reply with quote
MattLofton
GURU


Joined: 23 Dec 2000
Posts: 4834
Location: USA
PostPosted: Mon Mar 29, 2010 4:42 am   
 
Quote:

Thinking logically is certainly not in any way shape or form the issue.


Touche. I must've imagined a "You feel informed" trigger, which was the basis of the comment. Late nights are fraught with many dangers, it seems.Mr. Green

Quote:

I didn't type in the XML tab. I simply copied and pasted it.


Ah, that explains the weird xml then. Should pay closer attention to where the cursor is when posting multiple code fragments.Wink

Quote:

Indeed I do not notice the lack of #CONDITION, because there isn't a lack, it is in the XML I posted above.


That was my point. If you were using #CONDITION correctly, you would not see "#CONDITION" anywhere in the XML code you were pasting. I supplied the two codeboxes so you could see the difference in format between the zscript and xml formats without all your real data making it hard to read, and then once you had that difference figured out you could then review your code and spot the error being made.

NOTE:if you wanted to create your trigger within the Package Editor window, you would first select New Trigger and then follow up with New Trigger State for each condition you wanted to make.

Beside that obvious error, you also created separate triggers on the same lines your #CONDITIONs were matching. Aside from naming issues that CMud will obviously warn you about (a popup would appear asking you to rename, overwrite, or delete), there's just no logical reason to trigger twice on the same line and execute the same bit of code twice.

Quote:

I don't want them remaining defined after the information is put into the database, otherwise if I identified a weapon, and then later identified a boot, it would imput the damage field from the weapon for the boot, which clearly should not have a damage field.


This suggests you aren't doing anything else with the data, and in that case why have the variables created in the first place? Using multistate triggers opens up %t1...%t99 variables for you to use, and these variables are always local to the multistate trigger.
_________________
EDIT: I didn't like my old signature		 Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum 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