Library: Packing and Unpacking Keys into Integers

Code removed to make sure no one inadvertently uses this technique

very useful

Oh nice, why didn't I think of that... I think that just doubled my storage capacity, extended my storage time before dump, AND shrank my effective size for regular dumps... may need to rewrite for speed, or out process... but yes thanks a bunch

Yumi has something similiar here:

/15/84/72058/1.html

And an extremely small one from Giggs Taggart:

http://www.lslwiki.net/lslwiki/wakka.php?wakka=Example32BitHash

o/ did anyone ever tell you, 'you're my hero'..... o/

Actually, a list of 4 integers takes up more memory than a key.

A key takes up 54 bytes of memory, a list of 4 integers takes up 60 bytes of memory.

Source:
http://www.lslwiki.net/lslwiki/wakka.php?wakka=MemoryUsage

I love LSL.

::looks at overhead values:: o.0 OMFG mystery my $%^ that's just insane

ok so the above example is a no go.... but the idea is viable for higher base numbers and strings...

anyone feel like coding a base64 conversion routine? I doubt I'll get around to it anytime soon

Yes, this technique does not work to reduce memory usage and shouldn't be used due to the fact that LSL stores an integer as 10 to 15 bytes rather than the expected 4 bytes. Amazingly, one could actually store an array of integers as hex strings and have them be smaller, which boggles the mind.

It's still useful if you need to pass keys in cases where you can't use strings.

ok so this bugged me a bit so I decided to write a base 64 converter for keys.... pretty fast if I don't say so myself....

  //-- WARNING Insertable functions, NOT a working script
  string vStrHex = "0123456789abcdef";
  
  string vfInteger2Hex(integer vIntInput){
  	integer vIntIndex;
  	string vStrReturn;
  	integer vIntCounter = 8;
  	do{
  		vIntIndex = vIntInput & 15;
  		vStrReturn = llGetSubString( vStrHex, vIntIndex, vIntIndex) + vStrReturn;
  		vIntInput = vIntInput >> 4;
  	}while (--vIntCounter);
  	return vStrReturn;
  }
  
  string vfKeyToBase64( key vKeyInput ){
  	string vStrInput = (string)vKeyInput;
  	if (vKeyInput){
  		string  vStrReturn;
  		integer vIntDashIndex;
  		integer vIntCounter = 4;
  		do{
  			vIntDashIndex = llSubStringIndex( vStrInput, "-" );
  			vStrInput = llDeleteSubString( vStrInput, vIntDashIndex , vIntDashIndex );
  		}while (--vIntCounter);
  		vIntCounter = 3;
  		do{
  			vStrReturn += llGetSubString( llIntegerToBase64( (integer)("0x" + llGetSubString( vStrInput, vIntCounter * 8, vIntCounter * 8 + 7 )) ), 0, 5);
  		}while (~(--vIntCounter));
  		return vStrReturn;
  	}else{
  		return vKeyInput;
  	}
  }
  
  key vfBase64ToKey( string vStrInput ){
  	string vStrReturn;
  	integer vIntCounter = 3;
  	do{
  		vStrReturn += vfInteger2Hex( llBase64ToInteger( llGetSubString( vStrInput, vIntCounter * 6, vIntCounter * 6 + 5 ) ) );
  	}while (~(--vIntCounter));
  	vIntCounter = 3;
  	do{
  		vStrReturn = llInsertString( vStrReturn, 8 + (vIntCounter * 4), "-" );
  	}while (~(--vIntCounter));
  	return (key)vStrReturn;
  }
  

please note that this set of functions uses 827 bytes by itself... so you won't see your first byte of savings till storing your 92nd key, if it's in the same script... after that it's a 25% savings guaranted.. or you could offload to another script to reap the full benefits (minus the extra link msg code) sooner...

yes I COULD have transcoded directly from base 64 back to base 16, but A) it seemed like more work, B) using the built in 64toInt seemed faster, C) I'm lazy, D) all of the above

also note since strings take up less space in lists, the same concept could be applied to large integer or float lists, for space savings of ~60% after the second item (minus overhead for code), IF you put them in one huge string... but since parsing huge strings in lsl is
a bit painful I'm told, it may not be a good option... but it may even be workable for other variable type (vetors, rotations) if storing a lot of them in a list... if I can make it feasible I'll post them all combined as a library entry with comments

Base64 is very useful if you need to pass lots of integer data around using systems with limits on the data length. Think maximum length of a chat message, maximum size of a http request, etc.

Lol

Doh! All that coding for naught! lol

don't be so down about it, it still has uses... that's the nice thing about code, sometimes the intended use, isn't the best use

I enhanched some code to store 15 bits in one UTF8 unicode symbol (encoding much faster than decoding).
A 16th "sign"-bit can be "1" if 5 other bits are all "0" (or just 4 other bits are all "0"with one more condition).

A description of a prim (and any string) can store 84 of those (and more, but than it loses its ability to be rezzed (but not the ability to be copied inworld).
I for one welcome (a little more than) 15*84=1260 bits of transferable data (in one string).


Thanks to this thread I got the snips to read hexadecimals (and 5bit'ers) quickly into integers.
So, who wants the code to transfer 7 UUIDs IN ONE STRING of 84 UTF8 symbols (plus an 8 more fragmented UUID) ?

I think the original code should have remained in this topic and perhaps simply add a disclaimer if it does not work for it's intended purpose. There may very well be other uses which could be very beneficial for other reasons, such as simplifying or reformatting keys to be sent for script linking or say/listen relations between scripts/objects.

Note that the character limits for object names and descriptions may have been reduced since some of the above comments were made. For example, you now cannot set an object name/description via script to a longer value than is saved when the object is taken into inventory.