|
Larkin Wizard
Joined: 25 Mar 2003 Posts: 1113 Location: USA
|
Posted: Thu Jul 12, 2007 8:27 pm
[1.34] Data record variables and quoted script values |
I've got a data record variable, called def_mapping, that has simple keys which are defense names and values which are commands or script code to execute for putting up that particular defense. My current conundrum is that CMUD keeps automatically putting quotes around my script code values and then when I try to #EXEC them, I get a "script compilation error" message. I went in manually in the Package Editor and deleted the quotes, but CMUD put them right back again somehow. Am I doing something illegal here? (I've tried reproducing the same conditions in a clean profile, but the #EXEC just spits out the entire script line rather than actually executing it as code, meaning I can't yet find the minimal script that would cause this odd behavior.)
Basically, #ADDKEY def_mapping aethersight "aethersight on" will not keep the quotes when I look at it in the Package Editor. However, #ADDKEY def_mapping fire "#if (!%iskey(@auto, fire)) {i_toggle fire elixir} {sip fire}" will keep the quotes. |
|
|
|
Thinjon100 Apprentice
Joined: 12 Jul 2004 Posts: 190 Location: Canada
|
Posted: Thu Jul 12, 2007 9:48 pm |
Do any of your items in the database include parenthesis? I had an issue that sounds somewhat similar to this... and if I recall correctly it was the parenthesis that CMud was handling incorrectly... last report was Zugg added it to the bugs list.
A small example:
Take a string list - @Fruits
Apples
Oranges
(Peaches)
Grapes
If you were to request @Fruits to be printed out, it returns "Apples|Oranges|(Peaches)|Grapes" with the quotes, even though you didn't want them... so @Fruits.1 becomes "Apples and @Fruits.4 is Grapes"
For my script I coded-in a temporary workaround that replaced all instances of () with [] to avoid this. |
|
_________________ If you're ever around Aardwolf, I'm that invisible guy you can never see. Wizi ftw! :) |
|
|
|
Larkin Wizard
Joined: 25 Mar 2003 Posts: 1113 Location: USA
|
Posted: Thu Jul 12, 2007 10:49 pm |
Interesting observation. As you can see in my example above, I do have parentheses because it's scripted that way. I'll try a different script snippet without parentheses and see what results that yields. Thanks!
|
|
|
|
Thinjon100 Apprentice
Joined: 12 Jul 2004 Posts: 190 Location: Canada
|
Posted: Thu Jul 12, 2007 11:22 pm |
Heh, I completely misread your last code snippet... didn't even notice you were adding entire code segments into the variable, or I would've instantly seen the parenthesis. Seeing as you're using code segment, however, I doubt my temporary replace workaround will help you much (unless you find 2 characters you'll absolutely never use). I'm looking forward to Zugg getting this one fixed, as I have a few scripts on hold until it's done :)
|
|
_________________ If you're ever around Aardwolf, I'm that invisible guy you can never see. Wizi ftw! :) |
|
|
|
Solaras Wanderer
Joined: 11 Mar 2002 Posts: 93
|
Posted: Fri Jul 13, 2007 2:43 am |
This happens to me too in my sipping database.
Name: sipping
Key: mana_sip
Value: %int(@max_mana*7/8)
is ignored in my sipping alias when I do #if (@mana < @sipping.mana_sip)
while #show @sipping.mana_sip produces
"%int(@max_mana*7/8)" |
|
|
|
Fuego Ledrey Wanderer
Joined: 09 May 2007 Posts: 64 Location: Dustin Acres, California
|
Posted: Mon Jul 16, 2007 6:33 pm |
I played around with both Larkin's script and Solaras' script. I couldn't get Larkin's to execute properly, but I could get Solaras' to. Here's what I did.
Code: |
#if (@mana < %eval(@sipping.mana_sip)) {} {} |
When I tried:
Code: |
#show %eval(@sipping.mana_sip) |
it displayed
(I set max mana to 30)
This seems to be the desired result, though the same principle didn't seem to work for Larkin's script. |
|
_________________ EDIT: Image moved to Avatar FINALLY. |
|
|
|
Larkin Wizard
Joined: 25 Mar 2003 Posts: 1113 Location: USA
|
Posted: Mon Jul 16, 2007 8:45 pm |
Taking the parentheses out of mine made them execute, and that's a good workaround for now, but this is still a bug to keep on the list (assuming it's on a list somewhere already).
|
|
|
|
|
|