Any ideas about how to / has anyone figured out how to pack two vectors into an int.?

Thanks to Apoth's generous posting, I see how it is possible to pack a vector into an integer. However, lets say I wanted to rez an object and tell it what size to be and what position to go to (without using object<->object communication). Any ideas about how to pack two vectors into a start param so that I can do this?

It's impossible to pack a vector into an integer, at least to full precision. A vector is 3, 32 bit floats. So, that is 96 bits of data. An integer is 32 bits. So, if you can pack it in, as long as you only do it to a third precision. For two vectors, you need to get it to a sixth precision, with about 5 bits per axis of the vector. Which gives you a grand total of 63 positions per axis per vector. [This is probably going to be fairly useless for whatever you want to do.]

-Adam

Crap, I just tried my method and it didn't work. I really need to get this to work too... anyone else think there is a possibility to pack two vectors into an int?

If you have a script inside the object you rez, I can think of a way. But, I'm at work so can't test my theory. I'm not sure about the limitations of LSL, but you may be able to pass more than two vectors with some trickery if it works.

Size vector: <3.25, 0.50, 2.50>
Pos vector: <105.00, 216.48, 028.50>

The problem I see is in handling leading zeros, but basically you multiply each vector by 100 to get:

Size vector: <325, 050, 250>
Pos vector: <10500, 21648, 02850>

String those together to get 325050250 and 105002164802850

Send as an integer:
<325050250105002164802850>

On the rezed object, just reverse the process to separate back into your different vectors?

I haven't read the post about packing a vector into an integer.... so I'm not sure if there's a better method of doing that.

Adam's analysis of how much information you can jam into an integer is correct. Depending on your application though, you may be able to use an integer.

For example, if the size you want for the object is equilateral then you only need one dimension to describe it. If the dimensions do not have an algebraic relation to the size you can use a lookup table, e.g.

size.x = llList2Integer([2, 3, 5, 7, 11, 13 ...], sizeIndex);
size.z = size.y = size.x;

As for the position of the new object, you could use polar coordinates with an angle (5 bits gives you a resolution of ~2 degrees) and a distance from the object root encoded as the size was above (assuming that you don't care about Z axis transforms).

Other variations on those themes might get you close to what you are looking for. If that doesn't serve your purposes blame Shannon.

DoteDote: That is really strange, because.. that's EXACTLY what I just went and tried. But I remembered that, those integers are too big to pass. When you try and pass those integers it just goes to -1.

Edit: WAIT A SECOND!!!!!!!

Why is the last parameter of llRezObject an integer type? Wouldn't it be more useful to use a string? A string can regularly handle ANY other variable type, and can be converted back to by just using typecasting. Now that I think about it, an integer is almost the WORST variable type to use... I guess LL thought that we would only be using integers for sending channels for objects to communicate on? Again, I can't use object>object communication, because my objects are being separated too far to communicate.

Maybe you could do a lot of math to squeeze the number into the 32-bit limit. You would just have to make sure the math is capable of downsizing the largest possible combination. Then, mirror the math in reverse on the opposite end.

Seems like a lot of trouble to avoid using communication features.

Well, I'm not doing this just for my own purposes. I'm trying to just make one function for packaging and another for unpackaging, and once/if I find it out, I'm just going to post it on the scripting library so nobody has to deal with THE DEVIL CHAT COMMUNICATION EVER AGAIN...

Ack..


I guess I got out of hand there. You get my point.

The problem with DoteDote's solution is that it's trying to pack 192 bits of information into a 32-bit number. It'll work in a few cases, but most of the time, it'll overflow or underflow.