Hex to int to float and back

I'm trying to pass a full key to a rezzed object using its rotation value. I convert 8 characters of the key at a time into an integer, and insert all four integers into the rotation. When I convert the floats back into hex strings, however, the last 1-2 bits are lost or added to. Why is this happening?
Here's my code:

string hexc="0123456789abcdef";
//0000000000000000000000000000000

integer hex2int(string hex) 
{
    if(llGetSubString(hex,0,1) == "0x")
        return (integer)hex;
    if(llGetSubString(hex,0,0) == "x")
        return (integer)("0"+hex);
    return(integer)("0x"+hex);
}
string int2hex(integer x) 
{
    integer x0 = x & 0xF;
    string res = llGetSubString(hexc, x0, x0);
    x = (x >> 4) & 0x0FFFFFFF;
    while( x != 0 )
    {
        x0 = x & 0xF;
        res = llGetSubString(hexc, x0, x0) + res;
        x = x >> 4;
    } 
    return res;
}
rotation key2rot(key sid)
{
    string id = (string)sid;
    integer x = hex2int("0x" + llGetSubString(id, 0, 7));
    id = llDeleteSubString(id, 8, 8);
    id = llDeleteSubString(id, 12, 12);
    id = llDeleteSubString(id, 16, 16);
    id = llDeleteSubString(id, 20, 20); //delete the hyphens
    integer y = hex2int("0x" + llGetSubString(id, 8, 15));
    integer z = hex2int("0x" + llGetSubString(id, 16, 23));
    integer s = hex2int("0x" + llGetSubString(id, 24, 31));
    rotation rot = <x,y,z,s>;
    return rot;
}

key rot2key(rotation rot)
{
    string id;
    id = llGetSubString(int2hex((integer)rot.x), 0,7);
    llWhisper(0, id);
    id += "-"; //Add hyphens in
    id += llGetSubString(int2hex((integer)rot.y), 0,3);
    id += "-";
    id += llGetSubString(int2hex((integer)rot.y), 4,7);
    id += "-";
    id += llGetSubString(int2hex((integer)rot.z), 0,3);
    id += "-";
    id += llGetSubString(int2hex((integer)rot.z), 4,7);
    id += int2hex((integer)rot.s);    
    return (key)id;
}

Any help would be appreciated. If anyone gets this to work, feel free to use it, as long as you credit me.

It's happening because rotations get normalized. Basically they get scaled to a given magnitude while retaining the same directional information.

You cannot really use rotations for this purpose, unfortunately.

But it's only one or two bits that change. Here are some of the tests I did:

8c5c8f00|-1dcb-c540|-fd9c-6b50|4707a000
8c5c8f12|-1dcb-c54c|-fd9c-6b51|4707a02f
00000012|-0000-000c|-0000-0001|0000002f
last 1-2 bits are changed to zeroes or added to

71968d14|-28b7-c76a|-2b3f-965a|b40cf985
71968d00|-28b7-c780|-2b3f-9640|b40cf980
00000014|-0000-006a|-0000-005a|00000005
Wouldn't normalisation change more than that?

Good question. I have not verified this for your case, but I do know that rotations get normalized and that is the standard response people get who are trying to store non-rotational data in a quaternion.

It is possible that only those bits are changing due strictly to the data you are trying to store, and that were you storing different test data you would see more of a change?

You can test whether a quaternion is normalized by calculating the magnitude with sqrt(w2 + x2 + y2 + z2). For a unit quaternion the result will be 1. Note that apparently the forums don't allow superscripts, so that forumala is square root of (w squared + x squared + y squared + z squared ).


.

You're losing precision by casting a 32-bit integer to float, which only has an effective size of 24 bits. So, if either of the 2 most significant hex chars are non-zero, you're gonna end up with zeros on the least significant end. Using your 2nd example:

Hex:     0x71968d14  0x28b7c76a  0x2b3f965a  0xb40cf985
Decimal: 1905691924   683132778   725587546  -1274218107
Float:   1905691904   683132800   725587520  -1274218112

Or, to spell it out in binary:

0x71968d14 == 0111 0001 1001 0110 1000 1101 0001 0100
               |<--------- 24 bits -------->||<Lost>|

0111 0001 1001 0110 1000 1101 0000 0000 == 0x71968d00

Though I'm going to guess that your examples were only transcribed from a key to a rotation and back to a key, without actually applying that rotation to a prim. Rotations, in and of themselves, don't need to be normalized, they're just a struct of 4 floats. But if you assign that rotation to a prim, what you get back from llGetRot() will be normalized, which is almost certain to corrupt any key you put into it far more than this.


Actually, if you're just testing for normality, you can skip the sqrt step, since sqrt(1) == 1.

Wouldnt it be simpler to just pass it an integer channel number and set up communications? I'ma ssuming this is related to the rezzing of the object?

The idea was that this would be faster than communications.

You could use the object desc.

How would I do that? I can only set the description of the object itself, not the child object, right?

If an object is in object inventory, do its scripts run? Could it receive a link message from its parent object?

You'd have to link and unlink the object, another way would be to send an email but if speed is the issue that wouldnt help much.

You know the format of a key is rigid so you can ignore any dashes which reduces it in size slightly? (but adds complexity to encoding/decoding)

Are the textures ina predefined list? i.e. could you include the list in the child object and then just pass it an index number?

I assume that using a notecard look up will be considered too slow for the same reason that a comms channel cannot be used?

Using the rotation may be part of the answer you also have an addition 4 bytes in the integer unless you are already using it.

Is using a comms channel really that slow when its a completely targeted system and you can destroy the link as soon as the texture id has been received?