LindaB Helendale

hi Qie, the usable storage upper limit comes from the llCreateKeyValue limits (see http://wiki.secondlife.com/wiki/LlCreateKeyValue) the key is limited to 1011 bytes and the value to 4095 bytes. I added the explanation to the original post, thanks for pointing out that it may not be clear unless you are familiar with the Key-Value functions.

The key-value record is allocated 240 bytes even if the key and value were 1 byte each. It's a bit odd number, perhaps there's additional 16 byte header that is not counted in the experience key-value quota, but we get charged for 240 bytes.

My bad if the table is not clear. The two first columns are what a scripter may need. The left column tells how much key-value quota is charged for storing a key-value that fits in the payload (the second column). The third column is just nice to know -stuff, listing the chunks added to the previous block size to make the next size, thus the memory is added in increments [240, 256, 512, 1024, 2048, 4096] bytes. Oh *blush* I just realized a typo there on the second block size, no wonder the numbers didn't make sense.

I digged out the memory usage and memory allocation for experience key-value storage, and here are the results. Should this info be in the wiki and if, where? Comments are welcome. Strings use UTF-8 encoding The data is stored with UTF-8 encoding, with basic 7-bit ascii characters one byte, extended ascii and few others two bytes and fancy characters (ℒℬ⇄ ⇈㐦 㐧) three bytes. (See http://wiki.secondlife.com/wiki/Combined_Library#Byte_Length_of_UTF-8_Encoded_String for checking the string length in UTF-8) The limits are in bytes, for example the Value part can fit 4095 7-bit ascii, and 2047 two-byte and 1365 three-byte unicode characters. Memory allocation There's pretty good amount of memory available (thanks LL), but it's always good to be aware of memory allocation, like overhead and fragmentation issues. The record overhead is 125 bytes. Each record needs 125 bytes + length of the Key in UTF-8 + length of the Value in UTF-8. Memory for the record is allocated in blocks. Key and Value share the same block, so only the total length of Key + Value affect the block size. (Key 100 bytes + Value 400 bytes uses the same amount of memory as Key400 bytes + Value 100 bytes). The memory block sizes are Block size Payload Added size 240 115 240 496 371 256 1008 883 512 2032 1907 1024 4080 3955 2048 8176 8051 4096 For longer records there's a chance for considrable fragmentation; if the key+value won't fit in the payload of 4080 block (3955 bytes) the record is allocated 8176 bytes (out of which only 1011 + 4095 bytes are available storage due to llCreateKeyValue limits on the Key and Value lengths). Each record has separate memory block, so the total memory usage is the sum the record block sizes. For example if one key-value has key+value length 884 bytes if gets 2032 bytes allocation (with the payload of 1008 block 883) and if another key-value has 5 bytes it gets 240 bytes block and the total usage is 1248 bytes. EDITS: - had a typo on the 3rd column of the block 496 bytes. (Was 512, should be 256) - added explanation for the usable storage limit due to key and value size limits

I made more comprehensive tests by choosing different return list lengths (4095, 4096, 4097, 4098) and setting up the key length to make the list length multiple of (keyLength+1) , which is the key cdl length excluding the status flag "1". The result is that the whole list can be 4097 characters, 8194 bytes, and the actual list exluding the status flag can be 8 kB or 4096 characters. For example 128 keys of length 31 characters,. I added it in the wiki http://wiki.secondlife.com/wiki/LlKeysKeyValue This function will attempt to retrieve the number of keys requested but may return less if there are not enough to fulfill the full amount requested or if the list is too large. The length of the returned list is limited to 4097 characters (the success flag "1" and 4096 characters). The order keys are returned is not guaranteed but is stable between subsequent calls as long as no keys are added or removed. Could someone who knows wiki policies check that it's in the right place and in suitable format (and move/edit if needed). I was not sure if it should be in the definition or 'Caveats'.

Thanks Rolig, so there may not be throttle in key-value request. I made some tests (that are pretty inconclusive as it goes with LSL) but it seems that the limiting factor is the event queue. Depending on the length of the available event queue, that's at least 64 but if the server is happy or has idle resources or whatever reason, it can be much longer, I was able to store up to 473 key-value pairs sent in a for loop. After testing a while the event queue reduced to the nominal value 64, but no throttle errors. For reading the keys, llKeysKeyValue returned 600 out of 1000 keys in one call, with the return value size 8182 bytes, which suggests that the max key list size could be 8 kB. To test that I made longer keys, so that 8kB can hold 66 keys with the comma delimiters, and llKeysKeyValue returned 66 keys, taking 8166 bytes. Conclusion: the size of the key list returned by llKeysKeyValue is limited to 8 kB.

I have two questions about experience tools for which I havn't been able to find any info on lsl wiki, JIRA, or the forum. There appears to be a quota for experience key-value requests, at least there's error code XP_ERROR_THROTTLED 1 exceeded throttle The call failed due to too many recent calls. Would anyone know about the quota and throttling? The other question is about requesting the key list http://wiki.secondlife.com/wiki/LlKeysKeyValue The returned list may contain less keys than requested "if there are not enough to fulfill the full amount requested or if the list is too large". Does anyone know what 'too large' means there? The keys may be 1011 bytes, so if the script has to assume they can all be max size, the script can request around 60 keys, max. If the keys are shorter (such as compressed keys, 18 bytes) a script can handle a list of 3 000 keys, but since there's no way to filter the keys in the request, some other script in the experience may add longer keys and cause a script assuming short keys to crash. Is the 'too large' related to script available memory (and if so, how?) or is it some fixed size?

When I log on the wiki and try to add a new page or edit the existing pages on my SL wiki user page http://wiki.secondlife.com/wiki/User:LindaB_Helendale I get error that only Administrators have permission to edit it. Also the 'edit' button on the top menu bar is missing. Wiki still says that everyone in group Users can create and edit pages. Am I missing something or what could this be about?

Kwakkelde Kwak wrote: LindaB Helendale wrote: LI (Land Impact) is server side cost, and transparent textures won't increase it, Display Cost is viewer side cost where it shows up. LI is determined by the combination of all the weights, or rather the highest weight. server cost is server side cost, so is physics weight. display weight is indeed viewer side. In other words, you can have something with little impact on the servers and still get a high LI. Download weigth, server weigth and physics weights all measure server side load, download cost is the bandwidth needed in the server to send the stuff to view, physics weight is the physics simulation cost in the server and the server weight is the prim bookkeeping cost in the server.

Pamela Galli wrote: Adding a partially transparent face increases the LI? I have not seen that. LI (Land Impact) is server side cost, and transparent textures won't increase it, Display Cost is viewer side cost where it shows up.

I made a simple in-world calculator to see the effect of mesh LOD reduction scheme on Download Cost in Land Impact. It prints a table of total LI and the contribution of each LOD on the LI for different mesh radii. The script is here: http://wiki.secondlife.com/wiki/User:LindaB_Helendale/meshLODschemeCalculator Note (or caveat actually): Download cost depends on the byte size of each LOD in the asset server, including the vertex and face data, UV vertices and faces, etc, and the data is compressed by gzip. In general it's not easy to know those numbers, but roughly the triangle counts are on the same order of magnitude as the numbers used in this script. The LI results should be taken as relative, showing the relative contribution of different LODs and the effect of the mesh scale for a given scheme, such as 2000 : 500 : 120 : 60. To see the actual mesh LOD sizes in the asset server for an uploaded mesh, to get absolute LI values, see http://wiki.secondlife.com/wiki/User:LindaB_Helendale/getMeshLODsize Partly the same information this script prints can be found in Drongle McMahon's graphs for some LOD schemes http://community.secondlife.com/t5/Mesh/Download-weight-and-size-Some-graphs/m-p/1058609#M5642 while this script lets you display any LOD scheme.

I don't know Maya at all, but sometimes the problems in loading the same mesh again are related to the cached copy the uploader saves as .SLM file and it tries to reuse the cached copy. Unset debug setting MeshImportUseSLM or delete the .SLM file before uploading the mesh to check if that's the problem.

Usually those 'Dump something' menus print some info or stuff as text or XML files, but never heard of the dump attachments... i checked the souce code http://doc.daleglass.net/llviewermenu_8cpp-source.html#l06311 and it prints the info about attachments on debug console. (Develop / Consoles / Debug and then Dump Attachments too see)

Thank you for the info Cerise Does this mean group settings is the only way to give terraforming rights and it's not possible any more to set up a terraforming sandbox parcel with public terraforming enabled? Lanscaping classes will be tedious to arrange.

Until 3.2.4 the option to let anyone terraform in the parcel was in About land / Options, but since 3.2.5 it has not been there and I can't find it. I checked 3.2.5 and 3.2.6 and 3.2.9. Would anyone know where it is now?