|
Palek Wanderer
Joined: 28 Sep 2005 Posts: 55
|
Posted: Mon Jul 05, 2010 2:34 am
[3.22] Database Variables cannot contain Variables in the name |
Here is the deal, Executing the following script:
Code: |
#VAR VarTest 1
#VAR @VarTest.VarName Test
|
This creates a Variable called VarTest with a value of 1 and then should create a DB Variable named 1 with a key Called VarName and value of Test. Actually no DB Variable is ever created, no errors are thrown out either, checked script debugger and when the second command is sent nothing shows at all, here is a log of the debugger:
0.0020 | c SWMudNew | [1] SWMudNew Comline : start :
0.0020 | k SWMudNew | [1] Var "VarTest" changed from "" to "1"
0.0019 | d SWMudNew | [1] SWMudNew Comline : stopped
20.082 | ---
0.0024 | c SWMudNew | [1] SWMudNew Comline : start :
0.0018 | d SWMudNew | [1] SWMudNew Comline : stopped
This did work in 3.20 but not in 3.21 and above.
Thanks,
Jamie |
|
|
|
charneus Wizard
Joined: 19 Jun 2005 Posts: 1876 Location: California
|
Posted: Mon Jul 05, 2010 3:48 am |
First of all, using numbers as variables shouldn't be allowed, and in fact, isn't in at least 3.22. Can you test this with using an actual word instead of a number?
Second, you'd be better off probably doing:
Code: |
#ADDKEY @VarTest VarName Test |
instead.
Charneus |
|
|
|
Palek Wanderer
Joined: 28 Sep 2005 Posts: 55
|
Posted: Mon Jul 05, 2010 4:43 am |
charneus wrote: |
First of all, using numbers as variables shouldn't be allowed, and in fact, isn't in at least 3.22. Can you test this with using an actual word instead of a number?
Second, you'd be better off probably doing:
Code: |
#ADDKEY @VarTest VarName Test |
instead.
Charneus |
I understand that numbers should not be used as variable names, here is a better example and the issue still holds true:
Code: |
#VAR VarTest Test 1
#VAR @VarTest.VarName Test
|
It still never creates a DB variable with the second line, I would prefer not to change the entire section of code when this did work on 3.20 and earlier.
Thanks,
Jamie |
|
|
|
charneus Wizard
Joined: 19 Jun 2005 Posts: 1876 Location: California
|
Posted: Mon Jul 05, 2010 5:32 am |
In your second example, you have:
Code: |
#VAR VarTest Test 1 |
I'm assuming you meant to take out the 1.
For all intents and purposes, the proper way to do that using #VAR is this:
Code: |
#VAR @{VarTest}.VarName Test |
It has always been the proper way. Remember, just because something worked in a previous version doesn't mean it wasn't a bug or that it was intended. Therefore, you may be required to make some changes. Normally, I would say 'thankfully the find and replace command does regex in CMUD,' but that appears to be broken. You CAN, however, put the code in a text editor like Notepad++ or EditPad or something and do a regex replace there. Saves you a ton of work.
Charneus |
|
|
|
Palek Wanderer
Joined: 28 Sep 2005 Posts: 55
|
Posted: Mon Jul 05, 2010 6:14 am |
Actually the space between test and 1 was the typo, it should have been Test1. The syntax you showed does work and I have implemented it at this time, what brought this about is I have this section of code:
When running properly it creates a DB Variable named Droid# where number is specified by @NumDroidPlusOne, inside that DB variable will be fields for Name, Ammo, AmmoMax etc, instead it creates a autotype variable called Droid with the value of no. The workaround I was trying was setting the inserting #VAR DroidName Droid@NumDroidPlusOne then creating the DB variables with #VAR @DroidName.DBKey test, either way the system does not like reading Variables in the DB Variable Name.
Thanks,
Jamie |
|
|
|
GeneralStonewall Magician
Joined: 02 Feb 2004 Posts: 364 Location: USA
|
Posted: Mon Jul 05, 2010 7:52 am |
I would suggest trying:
Code: |
#VAR %concat( "Droid", @NumDroidPlusOne.DroidFollow) no |
|
|
|
|
Palek Wanderer
Joined: 28 Sep 2005 Posts: 55
|
Posted: Mon Jul 05, 2010 8:20 am |
Actually the braces that Charneus recommended worked when I do:
#VAR Droid@{NumDroidPlusOne}.DroidName {@NewDroid}
This is much easier to implement than my other workaround at the time.
Thanks for the assistance all.
Jamie |
|
|
|
|
|