Strings and vectors.

[Kenbro Utu]

Hello benevolent ones.  I am sending a vector to a child prim as a string, creating a list from the string, and then trying to use llList2Vector to try convert the string back to a vector.  I am getting nowhere.  I must be missing something along the way.  In the example below, why does vector 1 return <1.00000, 2.00000, 3.00000>, but vector 2 returns <0.00000, 0.00000, 0.00000>.

 

string src="<1,2.3>";
default
{
    state_entry()
    {
        list my_list = [<1,2,3>];
        list src_list = [src];
        {
            llOwnerSay("vector 1 = " + (string)llList2Vector(my_list,0));
            llOwnerSay("vector 2 = " + (string)llList2Vector(src_list,0));
        }
    }
}

[NeoBokrug Elytis]

Essentially llList2Vector and llList2Rotation doesn't work, if it's ever cast as a string in a list (like link message).

This is a very very very old bug, you need to cast it as a vector or rotation from a string.

vector vec = (vector)llList2String(my_list, 0);

rotation rot = (rotation)llList2String(my_list, 0);

 

 

[Void Singer]

list 2 vector does not automatically cast the data, so if it's in string format in the list, it will come out as ZERO_VECTOR.

you have two choices... you can cast the string to a vector before saving it to your list (a good idea since it takes less space that way), or you can use (vector)llList2String( listName, indexNumber ) when you retrieve a string.... this has the advantage of being automatically cast to string and back to a vector if it already was a vector, or being properly convertert to a vector if it wasn't already

 

[Kenbro Utu]

Aha!  Many thanks to both of you. :smileyhappy:  I will probably be back as I delve into some math involving vectors.

[Dora Gustafson]

 

---

Kenbro Utu wrote:

Hello benevolent ones.  I am sending a vector to a child prim as a string, creating a list from the string, and then trying to use llList2Vector to try convert the string back to a vector.  I am getting nowhere.  I must be missing something along the way.  In the example below, why does vector 1 return <1.00000, 2.00000, 3.00000>, but vector 2 returns <0.00000, 0.00000, 0.00000>.

String src="<1,2.3>";

default

{

    state_entry()

    {

        list my_list = [<1,2,3>];

        list src_list = [src];

        {

            llOwnerSay("vector 1 = " + (string)llList2Vector(my_list,0));

            llOwnerSay("vector 2 = " + (string)llList2Vector(src_list,0));

        }

    }

}

---

You made a typo I guess.
LSL has only 3 dimensional vectors, so writing: string src="<1,2.3>"; is not valid. It has only 2 dimensions

It is still correct that llList2Vector do not cast a string element to a vector.
llList2Vector is only valid for vector elements

 

[Kenbro Utu]

---

Dora Gustafson wrote:

You made a typo I guess.

LSL has only 3 dimensional vectors, so writing:

string src="<1,2.3>";

is not valid. It has only 2 dimensions

It is still correct that

llList2Vector

do not cast a string element to a vector.

llList2Vector

is only valid for vector elements

 

---

Yes, I noticed the typo too, but this was only an example I wrote up for the post.  I had tried multiple times, multiple different ways.  I am sending the vector information from one prim to another, so it arrives as a string, and therein was the problem...

[Vixie Darkfury]

I just got bit by this same problem. Fortunately I hit upon the solution quickly. What I'd like to know is, why is this considered correct behavior? I generally expect the llList2whatever functions to make a whatever as needed, am I wrong to expect this?

I will grant that the bug is well documented, but it seems to me it's still a bug and should be fixed. Casting the wrong type to the right one has adverse side effects, as explained in the docs.

Vixie

[Lucinda Bulloch]

It is as void says, vectors from a note card or from between"" are strings, as void says list2vector don't cast then, so it is safe to always treat them as strings and cast them yourself, like (vector)llList2String, to use llList2Vector they must be loaded as vectors in the first place, like vectorlist += (vector)DATA; then llList2Vector(vectorlist,x) will work, i use vectors and rotations a lot, my deck guns on all the warships talk to the AV and ship all the time so to stay in position and rotation, while in chat they are strings so must be converted before they can be used

[Vixie Darkfury]

Well, I'm not having a problem dealing with it, I just think it's kind of dumb. But thanks anyhow.

Vixie

[Lucinda Bulloch]

Sorry, i was replying to the OP, just when i click the left one it had you, but i was not talking to you.

[perfectslam]

Well, casting from string to vector REFUSES to work for me.  Not sure why.

 

sScale = (vector) llList2String(l,10);

 

Results in a ZERO_VECTOR.

 

if I do 

    llOwnerSay("Item at 10: " + llList2String(l, 10));

 

Then I get

Item at 10: <1.00000, 1.00000, 1.00000>

[Rolig Loon]

Try intering a few strategically-placed llOwnerSay statements in your script to see what's being loaded into your list called "l".  My guess is that the list is defined globally but you are overwriting its contents locally somewhere. 

[Electorite]

i know this is an old post, but it has a lot of hits and i wanted to offer my "transfer vector between objects" solution.  instead of fumbling with type casting in an old framework like LSL, i program my way around the "holes" in the commands.  

 

i put this example in script format, so the newbies can copy and paste the parts of the script (not the titles ## ##), and then "touch" the first object and the second object will pop 1 meter above the first object showing how to send a vector between 2 objects.  

 

## put in first object ##

default
{
on_rez(integer start_param)
{
llResetScript();
}
touch_start(integer total_number)
{
llSay(1011,(string)llGetPos());
}
}

## put in second object ##

integer lha;

default
{
on_rez(integer start_param)
{
llResetScript();
}
state_entry()
{
lha = llListen(1011, "", NULL_KEY, "");
}
listen(integer channel, string name, key id, string message)
{
string m = message;

integer spaceIndex = llSubStringIndex(m, ",");
string x1 = llGetSubString(m, 1, spaceIndex-1);

m = llDeleteSubString(m, 0,llStringLength(x1)+1);

spaceIndex = llSubStringIndex(m, ",");
string y1 = llGetSubString(m, 0, spaceIndex - 1);

m = llDeleteSubString(m, 0,llStringLength(y1)+1);

spaceIndex = llSubStringIndex(m, ",");
string z1 = llGetSubString(m, 0, spaceIndex - 1);

vector position = <(float)x1,(float)y1,(float)z1>;

llSetPos(position + <0,0,1>);
llListenRemove(lha);
}

}

[Rolig Loon]

or simply write vector position = (vector)message;  :smileywink:

[Electorite]

yes you are correct rollig.  there seems to be no problem typecasting strings to vectors in LSL.  thank you for replying.  

 

now only if all commands in LSL worked.  i keep a list of LSL commands which have bugs.  i guess you can see bugs in the  http://wiki.secondlife.com/wiki/LSL_Portal under 'caveats'.  i wonder if SL removed the known bugs in LSL commands forum area.  i have a couple bugs in LSL i could add from commands not working how they "should".  i guess LSL commands were made so they worked in one situation, not all situations.  typecasting usually works between commands in LSL, but not between every type it "could".  LSL has less major bugs than i thought it did, but let's not kid ourselves, LSL is buggy.  

[Rolig Loon]

One challenge with typecasting in LSL is that we don't always know when it's being done.  One common, frustrating example occurs when we're given a list that supposedly contains vectors, so we write

vector New_Vector = llList2Vector(My_list,0);

and we get an error because it turns out that the items in the list were not saved as vectors at all, but as strings. We can't typecast strings to vectors implicitly, but we didn't realize that we were asking the script to typecast anything at all..  This happens often enough that we learn to mistrust implicit typecasting and to write

vector New_Vector = (vector)llList2String(My_list,0);

explicitly instead, just in case. It's a shame. Even the nominally "safe" pair of variable types, string and key, can't always be typecast implicitly.