[Does Second Life plan to get into NFTs ?]

20 hours ago, Coffee Pancake said:

You're sure about that ?

The best part of this comic is that it doesn't imply Gollem is paying to own it, just to put his name in a database listing him as an owner.  Not even a relevant or meaningful database, just A database.

[Not Quite Right Rotation]

That fixed it, awesome.

[Proposal to connect the Zindra to the rest of the mainland]

Maybe they could just.... move Zindra a wee bit closer.

[World Map Mainland Screen Shot. What is thoughts on what is going on?]

I keep seeing these.  What really gets me is that whomever is running these has to have some pretty crazy bot set up going.  They all teleport together in groups and there are soooo many of them.  Bot software is probably lower resource usage than a single full viewer but it still feels like a lot of dedicated resources and scripts to run what is probably hundreds of them.

[Not Quite Right Rotation]

So, I've read quite a bit but it seems like I am not quite getting how to work with rotations.  The script below basically creates a (useless) moving object.  Everything mostly works except the rotation isn't quite right.  Basically, when it runs, one cube, will "roll" around a second linked root prim cube in a sort of stepping motion. 

It moves around fine, it even rotates in the expected direction, except it rolls 180 degrees every step, when it should only roll 90 degrees.  For example, I've textured it with a Dice Texture, and it only ever shows 6 or 1 on the top face.  I've tried replacing my rotation vector set with PI/2 and 1.58xx and removing the DEG_TO_RAD and using rotation instead of vectors.   I think the main issue lies somewhere in the conversions between vectors and rotations and degrees and radians.

//Prim Positions 
vector pos = <0.00000, -.5000, 0.0>;
rotation rot = <0.00000, 0.00000, 0.0, 1.0>;

list x_range = [  0, -.5, -.5, -.5,  0, .5, .5,  .5];
list y_range = [-.5, -.5,   0,  .5, .5, .5,  0, -.5];
list rot_range = [<0, -90, 0>,<0, -90, 0>,<-90, 0, 0>,<-90, 0, 0>,<0, 90, 0>,<0, 90, 0>,<90, 0, 0>,<90, 0, 0>];
integer position;

rotation NormRot(rotation Q)
{
    float MagQ = llSqrt(Q.x*Q.x + Q.y*Q.y +Q.z*Q.z + Q.s*Q.s);
    return <Q.x/MagQ, Q.y/MagQ, Q.z/MagQ, Q.s/MagQ>;
}

prim_mover()
{
        float next_x=(float)llList2String(x_range,position);
        float next_y=(float)llList2String(y_range,position);
        
        pos = <next_x, next_y, pos.z>;
        vector rot_vector = (llList2Vector(rot_range,position)* DEG_TO_RAD);
        rotation next_rot = <rot_vector.x, rot_vector.y, rot_vector.z, 0.0>;
        rot = rot * next_rot;
        rot = NormRot(rot);
        
        llSetPrimitiveParams([
        PRIM_POS_LOCAL,pos,
        PRIM_ROT_LOCAL,rot]);

        if(position== 7)
        { position = 0;
        
         }
        else
        { position++;}
}       

default
{
    state_entry()
    {
        position = 0;
        prim_mover();
        
        llSetTimerEvent(1);
    }
    
    timer()
    {
         prim_mover();
    }
    
}

 

[List to Integer Not Working As Expected]

12 hours ago, Wulfie Reanimator said:

Technically, the (integer)llList2String is kind of working. (By that I mean it could be considered "correct" depending on what you want.)

The values returned by List2String are something like "0.00000" and "0.50000" and then you cast them to integers, which throws out the ".00000" part and you're left with the whole number 0. You can see what I mean if you try a value like 1.5 or 253.0.

But yeah, if you want fractional values, you need llList2Float or just llList2String without anything extra.

 

You know in hind site, casting a .5 to int really was an obvious problem. 

In the larger script, I am using the list to control regular movement positions.  The adjustments being made will loop through the list and move a prim around as needed along one axis on a timer.

[List to Integer Not Working As Expected]

That makes sense, thanks.

[List to Integer Not Working As Expected]

I've striped this down to basically the bare bones of my issue  The resulting integer, next_x, is used elsewhere in the complete script, the llSay aspect just exists for troubleshooting.

The expected action here, when touched, the Prim will say the same number (picked from x_range) twice.

Instead what happens is the first llSay (string)next_x, always says 0, while the second, with the llList2String, works as expected.

I'm not sure what I'm doing wrong here and it feels like a simple issue.

list x_range = [-.5, 0, .5, 0];
integer counter;
 
default
{
    touch_start(integer total_number)
    {
    integer next_x=(integer)llList2String(x_range,counter);
    llSay(0,(string)next_x);
    llSay(0,llList2String(x_range,counter));
    counter++;
    }
}