Jump to content

Strings and vectors.


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

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

Recommended Posts

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));
        }
    }
}

Link to post
Share on other sites

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);

 

 

  • Thanks 1
Link to post
Share on other sites

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

 

Link to post
Share on other sites

 


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

 

Link to post
Share on other sites


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...

Link to post
Share on other sites
  • 11 months later...

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

Link to post
Share on other sites

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

Link to post
Share on other sites
  • 9 months later...

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>

Link to post
Share on other sites

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. 

Link to post
Share on other sites
  • 3 years later...

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);
}

}

Link to post
Share on other sites

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.  

Link to post
Share on other sites

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.

Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 1647 days.

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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...