Zugg Software :: View topic - Question about Multi-Word Keys in Record Variables

Wizard Joined: 26 Mar 2008 Posts: 1547

This isn't a bug report, I know the bug has already been reported (I even reported it myself before being shown the other post). However, I remember Zugg saying something about how he didn't really think people should be using multi-word keys anyways. He did seem to imply that he was going to fix it, but it's left me with a question that I've been pondering while waiting for the next version to come out.

Should I continue using multi-word keys?

Now, to be clear. I have something like 4 or 5 of my largest scripts which use multi-word keys. It's sort of funny, because, what Zugg has seen as a minor problem is sort of a major one for me and my script work has been sort of halted until it can be fixed. But I don't use multi-word keys because I like using them, it just happens that with the way my scripts run, the most unique identifier for something often has multiple words.

For instance, I have a damage script. The damage script sorts out damage done and taken, but the key identifiers are the names of the source of damage. For players, this is one word. For mobs, this can often be several words.

Another example is a script which shows the remaining time on my blesses and fireproofs. The most unique identifier is the short of the object, since that's what appears in the bless echo. This is most often multiple words.

I also have a crafting script which, the key identifier for the crafting objects is generally multiple words. So when I store data for the object, I use the words for the object in the echo in order to place it.

Then there's the affects window script which uses spells. Most spells are, thankfully, one word. However, several of the spells are multiple words.

It goes on and on. Maybe I'm weird, but I've simply found using multi-word keys as being a highly convenient way of doing a lot of what I do.

It occurred to me in my thinking that I could make a work around. I could easily write a parse function which substitutes spaces with underscores for storage purposes, and, in the reverse, substitutes underscores for spaces for display purposes. It would be tedious, but would likely serve its purpose flawlessly since, to my knowledge, the game I play uses underscores very rarely. And I could always design the parser with an escape for actual underscores in order to preserve them.

But while that thought occurred to me, I've been asking myself whether or not it's worth it. Thus far, multi-word keys have worked for me. And it seems that it's Zugg's intention to fix the problem. So, in that environment, it doesn't seem necessary, save for shortening the time I have to wait until I can work on those scripts again. Thus the reason for this post. If multi-word keys are something that Zugg truly doesn't intend as part of record variables, then I think I will go about the path of the parser, so as to avoid any future compatibility issues. However, if they are simply something Zugg never saw being used but he fully intends to support, then I will simply wait until another version of CMUD is released to fix the present problem and not worry overmuch about it.

Posted: Thu Aug 26, 2010 7:07 pm

Multiword keys should be fine. I've already fixed this for the next version, and the next version also supports the syntax:

@dbvar."multi word key"

with " quotes around the key.

The issue was that the JSON parser I was using didn't support multi-word keys, but it turned out to be pretty easy to patch their parser to allow it. So they will be fully supported now.

Wizard Joined: 26 Mar 2008 Posts: 1547

Thanks Zugg. I just wanted to be sure that they would be supported going forward, otherwise the parser might have been a better option. It's good to know that it's being supported. Smile