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
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4691
Location: Pensacola, FL, USA

PostPosted: Sun Mar 20, 2011 9:52 am   

#ADDKEY nested dbvar
 
Code:
<alias name="KeySetter" id="3">
  <value>#FORALL "A|B|C|D|E|F|G|H|I" {#LOOP 9 {
    #ADDITEM sudoku.key.rows.Row-%i {%i%j}
    #ADDITEM sudoku.key.cols.Col-%j {%i%j}
    }}</value>
</alias>


It gets the keys right, or seems to, but for some reason, they have no values, much less a list of them.
_________________
Discord: Shalimarwildcat
Reply with quote
chamenas
Wizard


Joined: 26 Mar 2008
Posts: 1547

PostPosted: Sun Mar 20, 2011 2:25 pm   
 
That syntax hasn't ever worked for me properly. Generally I reduce down to the inner-most db var and then use a series of #ADDKEYs in order to get back to the top. For example:

Code:

$nestedDB = %db( dbVar, someKey)

#ADDKEY $nestedDB anotherKey val
#ADDKEY dbVar someKey $nestedDB
_________________
Listen to my Guitar - If you like it, listen to more
Reply with quote
DraxDrax
Apprentice


Joined: 22 Mar 2009
Posts: 149

PostPosted: Sun Mar 20, 2011 11:05 pm   
 
I've found that embedded items or keys need to be initialized before they can be modified by #ADDITEM or #ADDKEY. I'm not sure if it's meant to work that way, but it's another way to work around the issue.

Code:
<alias name="KeySetter" id="3">
  <value>#FORALL "A|B|C|D|E|F|G|H|I" {sudoku.key.rows.Row-%i = ""}
  #LOOP 9 {sudoku.key.cols.Col-%i = ""}
  #FORALL "A|B|C|D|E|F|G|H|I" {#LOOP 9 {
    #ADDITEM sudoku.key.rows.Row-%i {%i%j}
    #ADDITEM sudoku.key.cols.Col-%j {%i%j}
    }}</value>
</alias>
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Mon Mar 21, 2011 1:20 am   
 
That is correct, #ADDITEM and #ADDKEY will not work unless the variable already exists. That includes a new level within a complex json variable.
Reply with quote
DraxDrax
Apprentice


Joined: 22 Mar 2009
Posts: 149

PostPosted: Mon Mar 21, 2011 8:31 am   
 
That's not the case, Rahab.

#ADDITEM and #ADDKEY can generate new variables and they can generate new json levels within newly created variable, but only so long as they only need to generate a single new level to reach the key or list to be modified. It's only when you try to use #ADDKEY or #ADDITEM to create a json object that is embedded by two or more levels and all of those levels don't yet exist that it has problems and treats the 'key.key' syntax as a literal instead of parsing it as different levels within the json variable. I'm not sure if levels is the right terminology but hopefully the example clarifies.

#ADDKEY KeyVariable.LevelOne NewKey NewValue <-- works
#ADDKEY OtherKeyVariable.LevelOne.LevelTwo NewKey NewValue <-- does not work
#ADDITEM ListVariable.4 NewItem <-- works
#ADDITEM OtherListVariable.4.2 NewItem <-- does not work

If the red bit contains the 'key.key' or 'list.list' syntax and all of those levels don't already exist, it fails.
Reply with quote
shalimar
GURU


Joined: 04 Aug 2002
Posts: 4691
Location: Pensacola, FL, USA

PostPosted: Mon Mar 21, 2011 9:55 am   
 
There was my problem then, I was trying when the root variable didn't even exist yet, much less any of the branches.
I assumed the parser would understand me.
_________________
Discord: Shalimarwildcat
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Mon Mar 21, 2011 12:06 pm   
 
Hm. I think I've had trouble in the past with #ADDITEM when the variable didn't exist. I'll check that again. Perhaps I'm misremembering and it was a case of missing intermediate levels, as you describe. Thanks for the correction.
Reply with quote
DraxDrax
Apprentice


Joined: 22 Mar 2009
Posts: 149

PostPosted: Mon Mar 21, 2011 1:25 pm   
 
I've done the same thing a lot, Rahab, and so has Chamenas, going by the solution he described... There are different issues in zMUD or Cmud we all run in to and, in order to work around the issue, you get in to the habit of doing things a particular way. Somewhere along the line, with a new version of Cmud or zMUD, the behavior may have changed, but we all still keep our old habits, oblivious to the fact the anomalous script behavior those habits were developed to avoid no longer exists.

That's also part of why I'm really not sure if this counts as a bug or not. It probably is, and a later version of Cmud may resolve the issue, such that shalimar's original code will work. For the moment though, in 3.33, it's possible to isolate exactly what's going on and work around it.

Whatever issues the client may have, it's still the best thing that ever happened to mudding.
Reply with quote
Zugg
MASTER


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

PostPosted: Mon Mar 21, 2011 6:08 pm   
 
Sounds like a bug to me, so I've added it to the list. The syntax:

#ADDITEM List.1.2.3.4 item

was supposed to work, but I confirmed that it doesn't. I think this worked in one of the beta versions and then somehow was broken by some other bug fix and then never reported. I'll try to get this into the next update.
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