Jump to content

Store 700+ Unique UUIDs In World


LepreKhaun
 Share

You are about to reply to a thread that has been inactive for 3796 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

seeing as how you posting my own codes back at me. I suppose i better do some work now (:

have inlined the encoding and put a table full flag in as well

can squeeze in 1 or 2 more keys if mod more but i quite like 1661. dunno why just do (:

 

// stores 1661 encoded keys in a table// call this script with table id -1661 in num // llMessageLinked(LINK_THIS, -1661, "", yourkey);// return codes in num//   0 = table full//   1 = key found in table //   2 = key added to table  //  link_message(integer sender_num, integer num, string message, key id)//  { llOwnerSay((string)num + " " + (string)id); }    list d;default{    link_message(integer n, integer b, string s, key k)    {        if (b != -1661) return;        b = 0;        if (llGetListLength(d) < 1661)        {            s = llDumpList2String(llParseString2List((string)k, ["-"], []), "");             string e;            integer i;            for (i = 28; i >= 0; i -= 4)            {                n = (integer)("0x" + llGetSubString(s, i, i + 3));                b = (b << 1) | (n & 0x1);                n = (n >> 1);                e += llBase64ToString(llIntegerToBase64(                    0xE0808000 | (((n + 0x800) << 12) & 0xF000000) |                     (((n + 0x800) << 10) & 0x3F0000) | ((n << 8) & 0x3F00)));            }            e += llBase64ToString(llIntegerToBase64(                0xE0808000 | (((b + 0x800) << 12) & 0xF000000) |                 (((b + 0x800) << 10) & 0x3F0000) | ((b << 8) & 0x3F00)));                          b = !~llListFindList(d, [e]);            if (b) d += [e];            b++;        }        llMessageLinked(LINK_THIS, b, "", k);    } }

 

edit: i made a typo in the codes. Should be < 1661 and not <= 1661. so i change to that

 

 

 

  • Like 1
Link to comment
Share on other sites


Dora Gustafson wrote:

LSL is not at all suited for data base jobs

 

weellll dunno about that (:

has always been possible to create very large scale apps in LSL

why people dont much do it is bc they get stuck on the asynch/synch problem when working with lots of scripts

in the link to the other forum i put some codes that is a framework which show one way of dealing with this. i made as a page control system to help answer a question. It show tho how scripts can be used like subprograms/subroutines in a procedural way

if use the same techniques then can make a pretty massive in-memory dB system just like you can in any language

program -> dbManager script -> [1..n] table scripts

in dBManager can manage it all. partitioning, hash table indexes, business rules, etc

when have a dbManager then can add worker scripts to it as well. Like push/pull to webserver, etc

in the codes I just posted here above just before. can see I am already doing in a dB way. by having a named table id

i not write any dBManager harness tho. bc apples apparently (: for now anyways

+

can make all kinds of things this way. Like a game engine for example. program -> gameEngine -> gameBuffRebuff(s) -> dbManager

not only can you do muli-script procedurals can also do parallel programing as well. a multi-dance ball is a parallel app for example. can also be applied to  a dB or game engine that might have many many tables of unstructured data

+

ps. is some people do this already and been doing for years. but I think they think is a trade secret or something. Well is not now (:

 

Link to comment
Share on other sites

i notice in the above header you refer to the encoder as a compression algo

is not a compression. is an expansion. the set of all keys can be stored natively in 16 bytes per element. the key as we use/see in LSL is an expansion of this native element to 72 bytes. The encoder algo expands native to 18 bytes

so is why is referred to as an encoder in the field of compression bc it it dont actual compress

Link to comment
Share on other sites


irihapeti wrote:

i notice in the above header you refer to the encoder as a compression algo

is not a compression. is an expansion. the set of all keys can be stored natively in 16 bytes per element. the key as we use/see in LSL is an expansion of this native element to 72 bytes. The encoder algo expands native to 18 bytes

so is why is referred to as an encoder in the field of compression bc it it dont actual compress

I'm uncertain how the word "compression" translates to your language but I was using it in its computer science definition, as did .Adam Wozniak and Doran Zemlja in their early implementation of this algorithm.

 

Basically, not all encoding is compression but all compression is an encoding, if that makes sense. If your encoding wasn't a compression algorithm, you would've ended up storing the same number or fewer keys in the available memory. And, since more keys are stored and the original keys can be recovered from their compressed state, it is specifically a lossless compression.

 

[ETA] There is an "expansion algorithm" there but that's what you're calling the decoder. It expands 9 UTF-16 characters back into the 32 UTF-16 characters (which are the original hexadecimal characters you compressed in the first place). Got it?

Link to comment
Share on other sites


irihapeti wrote:

seeing as how you posting my own codes back at me. I suppose i better do some work now (:

have inlined the encoding and put a table full flag in as well

can squeeze in 1 or 2 more keys if mod more but i quite like 1661. dunno why just do (:

 
// stores 1661 encoded keys in a table// call this script with table id -1661 in num // llMessageLinked(LINK_THIS, -1661, "", yourkey);// return codes in num//   0 = table full//   1 = key found in table //   2 = key added to table  //  link_message(integer sender_num, integer num, string message, key id)//  { llOwnerSay((string)num + " " + (string)id); }    list d;default{    link_message(integer n, integer b, string s, key k)    {        if (b != -1661) return;        b = 0;        if (llGetListLength(d) <= 1661)        {            s = llDumpList2String(llParseString2List((string)k, ["-"], []), "");             string e;            integer i;            for (i = 28; i >= 0; i -= 4)            {                n = (integer)("0x" + llGetSubString(s, i, i + 3));                b = (b << 1) | (n & 0x1);                n = (n >> 1);                e += llBase64ToString(llIntegerToBase64(                    0xE0808000 | (((n + 0x800) << 12) & 0xF000000) |                     (((n + 0x800) << 10) & 0x3F0000) | ((n << 8) & 0x3F00)));            }            e += llBase64ToString(llIntegerToBase64(                0xE0808000 | (((b + 0x800) << 12) & 0xF000000) |                 (((b + 0x800) << 10) & 0x3F0000) | ((b << 8) & 0x3F00)));                          b = !~llListFindList(d, [e]);            if (b) d += [e];            b++;        }        llMessageLinked(LINK_THIS, b, "", k);    } }

 

Very interesting.

Link to comment
Share on other sites


LepreKhaun wrote:


irihapeti wrote:

i notice in the above header you refer to the encoder as a compression algo

is not a compression. is an expansion. the set of all keys can be stored natively in 16 bytes per element. the key as we use/see in LSL is an expansion of this native element to 72 bytes. The encoder algo expands native to 18 bytes

so is why is referred to as an encoder in the field of compression bc it it dont actual compress

I'm uncertain how the word "compression" translates to your language but I was using it in its
, as did .Adam Wozniak and Doran Zemlja in
of this algorithm.

 

Basically, not all encoding is compression but all compression is an encoding, if that makes sense. If your encoding wasn't a compression algorithm, you would've ended up storing
the same number or fewer
keys in the available memory. And, since more keys are stored
and
the original keys can be recovered from their compressed state, it is specifically a
lossless compression
.

 

[ETA] There is an "expansion algorithm" there but that's what you're calling the
decoder
. It expands 9 UTF-16 characters back into the 32 UTF-16 characters (which are the original hexadecimal characters you compressed in the first place). Got it?

i realise that people refer to this kinda algo as compression. Which is understandable when look at it in the most general sense

in the field of compression is different classes of algos. compressors, packers and encoders

is what I mean when say that this algo is not a compression algo. As it doesnt attempt to reach the entropic state of the ordinal set of inputs by exploiting commonalities that may be found in the inputs. it does the opposite. it dont try to reach the entropic state. it goes in the opposite direction algorithmically by design. Even tho space saving occurs. is a class of algo thingy this which makes sense to people who work in this field

+

can call this algo a packer tho. I never refer to it as a packer bc is not a very good one as wrote. So just refer to it as a encoder

if was writing a packer then can losslessly encode 30 keys in 256 UTF chars. 17.067 bytes per. Instead of 18 bytes per as wrote  

if was writing a compressor then exploiting commonalities in keys, as well as the above. Order 0, 1, 2, etc

+

i have never looked closely at avatar keys myself in any exhaustive way, but I read once somewhere that one of the symbols near the middle (dont remember exactly now which one) is typically hex 0xF in many avatar keys. So that could be exploited for some bit savings. like for example if was 0xF 1/2 of the time then can gain approx. 31 bits for every 30 keys win some lose

i also read some other time that the last bytes of keys seem to be generated by noise from the system clock in whole or part. Is not confirmed that just seems to be. if so can exploit that as well as a clock has known bounds. So can maybe get some gains in that area as well in a compressor

this last two things are Order 0 techniques. If go to Order 1, 2, etc then might identity some other areas of commonality as well. Might maybe

+

if we ever were allowed access to the codes that LL do use to generate keys then could pretty probably easy compress to under 128bits per. The entropy being the ordinal set of the keys generated to date

not that LL will ever ever let us see them codes. bc spoof. SL would get pretty messy for the residents in that situation

 

Link to comment
Share on other sites


irihapeti wrote:


LepreKhaun wrote:


irihapeti wrote:

i notice in the above header you refer to the encoder as a compression algo

is not a compression. is an expansion. the set of all keys can be stored natively in 16 bytes per element. the key as we use/see in LSL is an expansion of this native element to 72 bytes. The encoder algo expands native to 18 bytes

so is why is referred to as an encoder in the field of compression bc it it dont actual compress

I'm uncertain how the word "compression" translates to your language but I was using it in its
, as did .Adam Wozniak and Doran Zemlja in
of this algorithm.

 

Basically, not all encoding is compression but all compression is an encoding, if that makes sense. If your encoding wasn't a compression algorithm, you would've ended up storing
the same number or fewer
keys in the available memory. And, since more keys are stored
and
the original keys can be recovered from their compressed state, it is specifically a
lossless compression
.

 

[ETA] There is an "expansion algorithm" there but that's what you're calling the
decoder
. It expands 9 UTF-16 characters back into the 32 UTF-16 characters (which are the original hexadecimal characters you compressed in the first place). Got it?

i realise that people refer to this kinda algo as compression. Which is understandable when look at it in the most general sense

in the field of compression is different classes of algos. compressors, packers and encoders

is what I mean when say that this algo is not a compression algo. As it doesnt attempt to reach the entropic state of the ordinal set of inputs by exploiting commonalities that may be found in the inputs. it does the opposite. it dont try to reach the entropic state. it goes in the opposite direction algorithmically by design. Even tho space saving occurs. is a class of algo thingy this which makes sense to people who work in this field

+

can call this algo a packer tho. I never refer to it as a packer bc is not a very good one as wrote. So just refer to it as a encoder

if was writing a packer then can losslessly encode 30 keys in 256 UTF chars. 17.067 bytes per. Instead of 18 bytes per as wrote  

if was writing a compressor then exploiting commonalities in keys, as well as the above. Order 0, 1, 2, etc

+

i have never looked closely at avatar keys myself in any exhaustive way, but I read once somewhere that one of the symbols near the middle (dont remember exactly now which one) is typically hex 0xF in many avatar keys. So that could be exploited for some bit savings. like for example if was 0xF 1/2 of the time then can gain approx. 31 bits for every 30 keys win some lose

i also read some other time that the last bytes of keys seem to be generated by noise from the system clock in whole or part. Is not confirmed that just seems to be. if so can exploit that as well as a clock has known bounds. So can maybe get some gains in that area as well in a compressor

this last two things are Order 0 techniques. If go to Order 1, 2, etc then might identity some other areas of commonality as well. Might maybe

+

if we ever were allowed access to the codes that LL do use to generate keys then could pretty probably easy compress to under 128bits per. The entropy being the ordinal set of the keys generated to date

not that LL will ever ever let us see them codes. bc spoof. SL would get pretty messy for the residents in that situation

 

very interesting.

Link to comment
Share on other sites

i just add to the discussion for people thinking about table/page/script ids

in the linked forum post as i mention before is a technique of partitionning integer num into caller/callee pairs

the idea being that a called/script can know who has called it. it use the form:

num = (callerid << 16) | (calleeid);  where caller and callee are uniqueids

so caller goes:

   llLinkMessage(LINK_THIS, (myid << 16) | (calleeid), msg, id)

callee goes:

   link_message(integer sender, integer num, string msg, key id)
   { 
       if (num & 0xFFFF == myid) // then is for me
       whocalledme = (num >> 16) & 0xFFFF;

+

ok

can partition this down further. for example if only have 256 scripts in app

      num = (myid << 8) | calleeid;

this allows the top 16 bits for messages as well as string msg

in the example encoded key table codes then can mod so tableid is some number less than 0xFF. where 0xFF is reserved for the Manager script

if (!(b & 0xFF == myid)) return;
whocalled = (num >> 8) & 0xFF;
if whocalled is not on my list of valid callers then error
do the encoding and search etc
then pass message back to caller

b = (returncode << 16) | (myid << 8) | whocalled;

llLinkMessage(LINK_THIS, b, "", k);

caller can then reverse to get the return codes. and can know which table return this result. So Manager can fire off lots of messages/tasks to lots of scripts and know when they complete and what is status of job complete. if fire a task then can know not to fire another task at a script until get message back

Link to comment
Share on other sites


irihapeti wrote:

i just add to the discussion for people thinking about table/page/script ids

in the linked forum post as i mention before is a technique of partitionning integer num into caller/callee pairs

the idea being that a called/script can know who has called it. it use the form:

num = (callerid << 16) | (calleeid);  where caller and callee are uniqueids

so caller goes:

   llLinkMessage(LINK_THIS, (myid << 16) | (calleeid), msg, id)

callee goes:

   link_message(integer sender, integer num, string msg, key id)

   { 

       if (num & 0xFFFF == myid) // then is for me

       whocalledme = (num >> 16) & 0xFFFF;

+

ok

can partition this down further. for example if only have 256 scripts in app

      num = (myid << 8) | calleeid;

this allows the top 16 bits for messages as well as string msg

in the example encoded key table codes then can mod so tableid is some number less than 0xFF. where 0xFF is reserved for the Manager script

if (!(b & 0xFF == myid)) return;

whocalled = (num >> 8) & 0xFF;

if whocalled is not on my list of valid callers then error

do the encoding and search etc

then pass message back to caller

b = (returncode << 16) | (myid << 8) | whocalled;

llLinkMessage(LINK_THIS, b, "", k);

caller can then reverse to get the return codes. and can know which table return this result. So Manager can fire off lots of messages/tasks to lots of scripts and know when they complete and what is status of job complete. if fire a task then can know not to fire another task at a script until get message back

Absolutely fascinating.

Link to comment
Share on other sites


irihapeti wrote:

yw (:

is there anything else I can help you with understanding?

No, that will do here, you've contributed more than enough as it is.

 

Getting back on topic and summing up:

Using my simple, basic database script and it's accompanying test harness, one not only can store over 700 unique keys but also compare different compression algorithms, of which four were suggested, each with a possible use for a specific need.

Sassy Romero rightly pointed out that hashes could be used, albeit with a chance of collision (meaning the hash of two or more keys are the same and the risk is both such being used in any given program). This risk may be allowable in some circumstances but the programmer should be aware exactly what the odds are of it failing before going that route. The gains to be achieved with this approach is limited only by the risk of collision one feels they can live with.

Dora Gustafson pointed out that using Resident Names not only might require less memory than their UUIDs but there may be circumstances it is preferable. I agree on both counts, especially where any last name of "Resident" may safely be chopped before storage. Unsure what the "average" Resident Name length might be, but watching free memory after each addition in the data store would avoid problems.

Then irihapeti suggested the use of a combined work of her(elizabeth), Adam Wozniak, Doran Zemlja, Becky Pippen and Strife Onizuka. This effectively doubled the number of keys that could be stored than my simplistic "drop the hyphens" approach..

Of course, if all one was interested in was stuffing more keys into the box, the optimal approach would be to not to use strings at all. Rotations (quaternions) store 4 float values very efficiently in lists, a UUID can be easily broken into 4 integers and (after much hard work!) Strife Onizuka, Pedro Oval and Omei Qunhua have developed a way to convert between integers and floats. That raises the limit of lossless compression of Keys to above 2,000 within a single script.

 

// "Store 700+ Unique UUIDs In World" by LepreKhaun 4/18/2014// Modified 4/29/2014 to use the "fui" and "iuf" functions // developed by Strife Onizuka, Pedro Oval and Omei Qunhua// from the "Combined Library" found at https://wiki.secondlife.com/wiki/Combined_Library// This version will store ***2,071*** unique UUIDs with the (possibly unneeded) decoder function "fui"//// See http://community.secondlife.com/t5/LSL-Library/Store-700-Unique-UUIDs-In-World/td-p/2669408 for usage// May be freely used, modified and distributed ONLY with this header intact!  2071// NOTE! Always obtain and use the latest version of these functions from//  https://wiki.secondlife.com/wiki/User:Strife_Onizuka/Float_Functionsfloat iuf(integer a) {;}integer fui(float a) {;}list keysStored;default{    link_message(integer sender_num, integer num, string str, key id)    {        if (~num) // abort unless num != -1            return;                    // delete hyphens from key        string str = (string)id;        string shortKey = llDumpList2String(llParseStringKeepNulls((str = "") + str, ["-"], []), "");                 rotation rotKey =         <   iuf((integer)("0x" + llGetSubString(shortKey, 0, 7))),            iuf((integer)("0x" + llGetSubString(shortKey, 8, 15))),            iuf((integer)("0x" + llGetSubString(shortKey, 16, 23))),            iuf((integer)("0x" + llGetSubString(shortKey, 24, 31)))        > ;                // see if the key is in list        if(~llListFindList(keysStored, [rotKey]))        {            // it was found            llMessageLinked(LINK_THIS, TRUE, "", id);        } else {            // it was not found, so            // store it first            keysStored += rotKey;            llMessageLinked(LINK_THIS, FALSE, "", id);        }    }}

 

But, of course, there is an upper limit to all that. The reader is advised to use a web based data storage solution for anything more than this. Attempting to implement a DBMS (Data Base Management System) in LSL is going to be more complicated than one might realize. And there's no need to try to reinvent the wheel in an unsuitable environment when all one needs to do is learn a bit of PHP, MySQL (which is a simple-to-use-and-learn DBMS loaded with features!) and how the llHTTP* functions work together.

 

I do hope the reader has been able to glean something useful from this topic and I do thank you for reading this far.

Link to comment
Share on other sites

edit more

Leprekhaun point to bugs in this script. So ty to him for that (:

I not fix this one anymore here. I just leave with the bugs in. Soooo....

DONT USE THIS SCRIPT IS BROKEN

latest fixes version here: http://community.secondlife.com/t5/LSL-Scripting/3300-oranges/m-p/2706236#M23657

 

edit:

i made some mod/opt to the oranges script i put here before. If anybody got that one already then delete and have this one if you want

the other post script has a count flow error in it. so best not to use that one at all. bc counts the duplicates as well as the adds. I was testing that and forgot to change before post

the main change I made was to the coding style of the search algo. i made all inline style bc is more consistent readability wise than to mix classic and inline coding styles in same code block as i was doing. I think anyways

removed a unecessary int var, a else, and a modulus as well

 

// store 3339 encoded keys losslessly// call this script with table id -3339 in num // llMessageLinked(LINK_THIS, -3339, "", yourkey);// return codes in num//   0 = table full//   1 = key found in table //   2 = key added to table  //   link_message(integer sender_num, integer num, string message, key id)//   { llOwnerSay((string)num + " " + (string)id); }   // // Public Domain May 2014 by elizabeth (irihapeti)// Base64 codes credit Strife Onizukastring d;integer c;default{    link_message(integer n, integer b, string s, key k)    {        if (b != -3339) return;        b = 0;        if (c < 3339)         {            // encode            s = llDumpList2String(llParseString2List((string)k, ["-"], []), "");             string e;            integer i;            for (i = 28; i >= 0; i -= 4)            {                n = (integer)("0x" + llGetSubString(s, i, i + 3));                b = (b << 1) | (n & 0x1);                n = (n >> 1) & 0x7FFF;            
e += llBase64ToString(llIntegerToBase64( 0xE0808000 | (((n + 0x800) << 12) & 0xF00000) | (((n + 0x0800) << 10) & 0x3F0000) | (n & 0x3F00))); }
b = (b & 0xFF); e += llBase64ToString(llIntegerToBase64( 0xE0808000 | (((b + 0x800) << 12) & 0xF00000) | (((b + 0x0800) << 10) & 0x3F0000) | (b & 0x3F00))); // search b = 0; i = llSubStringIndex(d, e); if (~i) { n = (i % 9); if (!n) jump y; i += (9 - n); n = llStringLength(d); @x; if (llGetSubString(d, i, i + 8) == e) jump y; if ((i += 9) < n) jump x; } d += e; c++; b++; @y; b++; } llMessageLinked(LINK_THIS, b, "", k); } }

 

 

 

 

Link to comment
Share on other sites


irihapeti wrote:

edit:

i made some mod/opt to the oranges script i put here before. If anybody got that one already then delete and have this one if you want

the other post script has a count flow error in it. so best not to use that one at all. bc counts the duplicates as well as the adds. I was testing that and forgot to change before post

the main change I made was to the coding style of the search algo. i made all inline style bc is more consistent readability wise than to mix classic and inline coding styles in same code block as i was doing. I think anyways

removed a unecessary int var, a else, and a modulus as well

 
// store 3339 encoded keys losslessly// call this script with table id -3339 in num // llMessageLinked(LINK_THIS, -3339, "", yourkey);// return codes in num//   0 = table full//   1 = key found in table //   2 = key added to table  //   link_message(integer sender_num, integer num, string message, key id)//   { llOwnerSay((string)num + " " + (string)id); }   // // Public Domain May 2014 by elizabeth (irihapeti)// Base64 codes credit Strife Onizukastring d;integer c;default{    link_message(integer n, integer b, string s, key k)    {        if (b != -3339) return;        b = 0;        if (c < 3339)         {            // encode            s = llDumpList2String(llParseString2List((string)k, ["-"], []), "");             string e;            integer i;            for (i = 28; i >= 0; i -= 4)            {                n = (integer)("0x" + llGetSubString(s, i, i + 3));                b = (b << 1) | (n & 0x1);                n = (n >> 1);                e += llBase64ToString(llIntegerToBase64(                    0xE0808000 | (((n + 0x800) << 12) & 0xF000000) |                     (((n + 0x0800) << 10) & 0x3F0000) | (n & 0x3F00)));            }            e += llBase64ToString(llIntegerToBase64(                0xE0808000 | (((b + 0x800) << 12) & 0xF000000) |                 (((b + 0x0800) << 10) & 0x3F0000) | (b & 0x3F00)));                        // search            b = 0;            i = llSubStringIndex(d, e);            if (~i)             {                 n = (i % 9);                if (!n) jump y;                i += (9 - n);                n = llStringLength(d);                @x;                if (llGetSubString(d, i, i + 8) == e) jump y;                if ((i += 9) < n) jump x;               }                    d += e; c++; b++;            @y; b++;         }        llMessageLinked(LINK_THIS, b, "", k);    } }

 

I'm unsure why you feel the LSL Scripting Library is a place to practice coding.

 

As it is, in your careless haste to squeeze a few more keys in, you FUBAR'ed Strife's [edited for correctness after being informed they only lent a hand in the script and bits and pieces were written by others] the original code completely. This is your most obvious error. Can you see what you did wrong or shall I explain it to you?

e += llBase64ToString(llIntegerToBase64(                    0xE0808000 | (((n + 0x800) << 12) & 0xF000000) |                     (((n + 0x0800) << 10) & 0x3F0000) | (n & 0x3F00)));

 There's at least two more besides that. Perhaps you'd best stick with modding simpler things until you get the hang of all this.

Link to comment
Share on other sites


irihapeti wrote:

ty (:

i fixed that one

and the mask. well spotted. ty

 

No, you made it worse.

e += llBase64ToString(llIntegerToBase64(        0xE0808000 | 

(((n + 0x800) << 12) & 0xF00000) | (((n + 0x0800) << 10) & 0x3F0000) |

(n & 0x3F00)));

 Should read:

e += llBase64ToString(llIntegerToBase64(        0xE0808000 |

(((n + 0x800) << 12) & 0xF000000) | (((n + 0x800) << 10) & 0x3F0000) |

((n << 8) & 0x3F00)));

 Otherwise, the last part is missing the bytes it should be masking.

 

But as I said, this isn't the correct forum to practice in. OK?

Link to comment
Share on other sites

This may help you understand what is happening:

// get next four nybbles and make integer from them////    0000 0000 0000 0000 abcd efgh ijkl mnopn = (integer)("0x" + llGetSubString(s, i, i + 3));// copy lowest bit (p), stash in b after shifting b upb = (b << 1) | (n & 0x1);// shift n right 1 place and mask with 32,767////    0000 0000 0000 0000 0abc defg hijk lmno       n = (n >> 1) & 0x7FFF;            // OK, here we encode the integer (except for p, which is now stored in "b", which will be encoded at the last)            e += llBase64ToString(llIntegerToBase64(
// Start with -528,449,536
0xE0808000 |//// 1110 0000 1000 0000 1000 0000 0000 0000 OR// ADD 2048 to n then SHIFT LEFT 12 places AND mask that with 25,165,824(((n + 0x800) << 12) & 0xF00000) |// 0000 0000 0000 0000 0abc defg hijk lmno +// 0000 0000 0000 0000 0000 1000 0000 0000 =// 0000 0000 0000 0000 0abc Defg hijk lmno << 12// 0000 0abc Defg hijk lmno 0000 0000 0000 &// 0000 1111 0000 0000 0000 0000 0000 0000 =//// 0000 0abc 0000 0000 0000 0000 0000 0000 OR // ADD 2048 to n then SHIFT LEFT 10 places AND mask that with 4,128,768(((n + 0x0800) << 10) & 0x3F0000) | // 0000 0000 0000 0000 0abc Defg hijk lmno << 10// 0000 000a bcDe fghi jklm no00 0000 0000 &// 0000 0000 0011 1111 0000 0000 0000 0000 =// 0000 0000 00De fghi 0000 0000 0000 0000 OR// SHIFT LEFT 8 places AND mask that with 16,128((n << 8) & 0x3F00)));// 0000 0000 0000 0000 0abc defg hijk lmno << 8// 0000 0000 0abc defg hijk lmno 0000 0000 &// 0000 0000 0000 0000 0011 1111 0000 0000 =//// 0000 0000 0000 0000 00jk lmno 0000 0000 EQUALS
// RESULT HERE ===>>> // 1110 0abc 10De fghi 10jk lmno 0000 0000

 

Link to comment
Share on other sites


LepreKhaun wrote:

irihapeti wrote:

ty (:

i fixed that one

and the mask. well spotted. ty

 

No, you made it worse.
e += llBase64ToString(llIntegerToBase64(        0xE0808000 | 

(((n + 0x800) << 12) & 0xF00000) | (((n + 0x0800) << 10) & 0x3F0000) |

(n & 0x3F00)));

 Should read:
e += llBase64ToString(llIntegerToBase64(        0xE0808000 |

(((n + 0x800) << 12) & 0xF000000) | (((n + 0x800) << 10) & 0x3F0000) |

((n << 8) & 0x3F00)));

 Otherwise, the last part is missing the bytes it should be masking.

 

But as I said, this isn't the correct forum to practice in. OK?

ty. my copypasta skills sux (:

ok. i leave you alone now. i take my oranges and play in another post

ty for the debugs as well (:

ps. i still do like your 700+ version. is ideal for a library script i think

Link to comment
Share on other sites

  • 3 weeks later...


irihapeti wrote:

ty. my copypasta skills sux (:

ok. i leave you alone now. i take my oranges and play in another post

ty for the debugs as well (:

ps. i still do like your 700+ version. is ideal for a library script i think

Leaving me alone sounds like an excellent idea. Unsure about "playing" in the forums though. Good luck with all that...

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3796 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...