Experience Key Value Structure

[Ruthven Ravenhurst]

I'm finding a lack in experience script example and not sure what is a typical way to structure key values.

I see that it is fed a string or a uuid cast as a string, rather than a key. For one script's use of the experience keys, I can see how that would be just fine to create a key value for the avatar uuid alone, but for multiple scripts that will look for varying type of info, i don't think it would be practical to update the key value for all the scripts in order to update one piece of a comma separated value.

For example in a health/stamina/power meter. Would it make sense to append the specific type of value to the uuid and create/update the value for that?

for example for avatar1 it would be

 string keystr1 = (string)avatar1key;

string av1health = keystr1+"health";

and so on for each other type you're looking for

 

and then define a different global dataserver key for each value being looked up like:

 

key avhealthquery;

key avstaminaquery;

key avstrengthquery;

etc.

 

I can see that being ok in a hud where it's only looking for the wearer/owner's stats, but what about a sim object that needs to look up the stats of multiple avatars?

[Rolig Loon]

I'm a little confused about what you are asking.  The value in a key-value pair (KVP) is a string.  You can put anything you like into that string, including a piles of separate bits of data set apart by delimiters.  If you use commas, you can pack many different parameters into the string and then interpret them separately later with llCSV2List, which will cast your string into a list.  If you don't like commas or can't use them for some reason (your parameters are all vectors with embedded commas, for example), then you can use some other delimiter.  Personally, I like using the tilde (~).  When you go to read the value later, you use llParseString2List to break the string apart where your delimiters are.

You could choose to create a KVP with an avatar's UUID as the key and a delimited string of characteristics as the value.

Or you could create a KVP with a parameter (Health, maybe) as the key and a delimited string of avatar UUIDs and numerical values as the value.

It's all determined by what you want to use the KVP for.  There's no rule other than whatever makes sense in your application. If you want to review all the stats of a collection of avs, you might either llReadKeyValue ("AvUUID") for every av in the area and search for the particular stat in each av's KVP.  Or, if you had set things up with one key per type of stat, you could use llReadKeyValue("Health") and then unpack pairs of av UUIDs and numerical values from the string.

[Ruthven Ravenhurst]

yeah, i see that I made it a little confusing say object one is using a health/stamina/strength stats system and object2 is using a clan/age/security level stats system. it wouldn't make sense to me to create a whole list of all the stats for each avatar, cast it to a string, update the value, then query their stats, desconstruct, update the individual stat as necessary, resconstruct, and update the value

 

3 ways I can see to structure it is

 

avatar kvp =  avUUID, [healthm, stamina, strength, clan, age, security level] then each script would have to break down the key value, list replace the appropriate index with the stat update. recast the list to a string, and update the value

 

or. as you suggested,

 

stat kvp = "Health", [av1uuid, av1healthvalue, av2uuid, av2healthvalue, etc...]then the script would query the health for everyone, break down the value to a list, llListFindList the avuuid, get/update their stat in that list, recast to a list, and update the whole list of healthvalues

 

or, the way I did it is

 

string id = (string)llDetectedKey(n);key healthupdate = llUpdateKeyValue(id+"health", "5.0", FALSE, "");key staminaupdate = llUpdateKeyValue(id+"stamina", "3.5", FALSE, "");

 

and so on

this way it creates a key for each stat for each avatar, and only needs to look it up with

key healthquery = llReadKeyValue(id+"health");

[Rolig Loon]

Sure.  That works too.  It's all a matter of how you want to package the data so that you can update/read/ manipulate it conveniently. If it makes sense to you, do it.

[Qie Niangao]

Several considerations here:

We can safely assume that the system is way more efficient at fetching the value for a very specific key than our scripts can be at teasing it out of a longer value string matching a more general-purpose key.

On the other hand, we may have operations that use multiple attributes of some key, and fetching them all up with one KVP operation will be faster than a bunch of those operations for individual, attribute-specific keys.

LSL's JSON functions are ideally suited for serializing multiple related attributes into a string, getting and setting those individual attributes, and munging them back out into a list.