Two memory related questions

1 - Is there any function in existance that "crunches" a key into a smaller string value for more efficient storage? If there isn't, I'm going to write one, but I wondered if there was one already.

2 - Would it be possible to have a self-extending storage pipeline? What I mean by this is that you have a bunch of storage server scripts in an object. When some data needs to be stored, a linkmessage is sent to the first one; if it has memory free, it stores the data, else it passes on the linkmessage to the next one in the chain.

What I'm wondered is if it's possible for the chain to extend itself if the last script in the chain also finds it has no space. Two possibilities suggest themselves:

a) rez an object which holds a copy of the "storage server script", which immediately loads the extra storage server into the original object via remote update, then kills itself.
or
b) rez a 0.01 square 100% alpha cube with a storage server script (or more likely, several such scripts) in it, link it, and then pass "store this" link messages to it as with the other storage scripts. (Problem: the extra prim counts against the parcel limit)

When the memory is no longer needed, the extra scripts can be deleted, either by unlinking and killing the objects or by deleting the extra storage servers from inventory.

a) would be ideal to do but I'm not sure how to do it as I'm not familiar with remote updates. b) seems possible although I'd be concerned about security. Do folks here think either of these is possible?

I believe 2 is possible while 1 is not. 2 I have actually done more or less.

The problem with compressing a key is that it is a 32 bit alphanumeric value, unless you don't actually ever need to get the orginal key back, I don't see how you can effectively compress it to take up less space, since there is really no information you can do without, while still getting back the orignal key. The most efficient way to store each character is as a the character itself, since there are 37 possible characters for each digit of the key, converting it to a pure numeric value would double the size of it...

Is it alphanumeric or hexadecimal? I don't think I've seen characters past f.

You *could* do something crazy if you had access to the whole ASCII character set... but I don't know of a way to generate/manipulate characters as numbers in LSL. But in theory... if it's hex, then that's 16 possible values. So 2 characters is 256 possible values, which can be mapped to one ASCII character. So you could compress a hex string down to half its size, by making a new string where each character of the new string (which uses all ASCII characters) represents two characters of the original string (which uses only 0-9 a-f).

If this were C, it could be done pretty easily. I'm not sure LSL allows characters to be manipulated as numbers and vice versa.

And of course, you could try using real compression techniques, I'm sure there are algorithms out there. But I'm not sure how easily they can be translated to LSL, and if they'll end up making the string any shorter.

Edit: You could fake it by storing the new ASCII string as a list of integers. Again, if this were C with arrays, that would save space, but in LSL I think this might very well end up taking more memory than the original key string.

No your right Ziggy I wasn't thinking, of course it IS a hex value, so there are only 16 possible characters for each, which does mean you should be able to compress the string length of a key in 1/2. Although I'm not certain it would take less memory, it stands to reason that it would. I don't think LSL allows letters to be manipulated as numbers, so you would need to convert them with a function first. The idea is worth some review, excuse me for answering without thinking it over.

I really find it funny how all this is just working around the memory limit. If the lindens would realize this and just expand the limit they would cause us a lot less trouble lol.

Ok, here's my attempt at 1) - this doesn't use any actual proper data compression or anything like that, but there doesn't seem to be much redundancy in the output anyway.

// 4 bits per char, boo.
string hexchars = "0123456789abcdef";

// 6 bits per char, yay!
string chref = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!@#$%^&*()[]{}?+-_\|',.<>~`;:";
                
string crunchkey(key thekey) {
   integer t;
   string skey = (string)thekey;
   integer buffbits = 0;
   integer buffval = 0;
   string outkey = "";
   
   for (t=0; t<36; t++) {
       string curchar = llGetSubString(skey,t,t);
       if (curchar != "-") {
           integer curval = llSubStringIndex(hexchars,curchar);
            
           buffval+=(curval << buffbits);
           buffbits+=4;
           if (buffbits > 5) {
              integer lval = buffval & 63;
              outkey += llGetSubString(chref,lval,lval);
              buffval = buffval >> 6;
              buffbits -= 6;
           } 
       }
   }
   outkey += llGetSubString(chref,buffval,buffval);
   return outkey;
}

key uncrunchkey(string crunched) {
  integer t;
  string outkey;
  integer buffbits = 0;
  integer buffval = 0;
  integer outchars = 0;
  
  for (t=0; t<22; t++) {
         string curchar = llGetSubString(crunched,t,t);
         integer curval = llSubStringIndex(chref,curchar);
         buffval += (curval << buffbits);
         buffbits += 6;
         while (buffbits > 3) {
             integer lval = buffval & 15;
             if (outchars < 32) outkey += llGetSubString(hexchars,lval,lval);
             outchars++;
             if (outchars == 8) outkey += "-";
             if (outchars == 12) outkey += "-";
             if (outchars == 16) outkey += "-";
             if (outchars == 20) outkey += "-";
             buffval = buffval >> 4;
             buffbits -= 4;
         }
        
  }
  return (key)outkey;
}

That's pretty clever I didn't actually try it out, but I think I understand what you're doing, and it's a neat idea.

Since lval can't be bigger than 63, you really only need 64 charachers in chref. Which is 10 digits, 26 + 26 for upper and lower case letters, and 2 more. And I'd mention that anyone copying your script should remove the two spaces that the forum inserts between N and O.