Get Region Coordinate # Meteres Forward of Attachment

[Bloodsong Termagant]

i know i know how to do this... sorta.  but i can't seem to figure it out.

 

okay, i'm trying to ray cast from an attachment, and i want to get the spot straight down from the center of my avatar (easy, thats llGetPos and lower the z coordinate), and "ahead" of my avatar.  which i know is local pos + x, BUT... to get that in region coordinates, compared to which way my avatar is facing, i need to use (i think??)  Rot2Fwd.  i'm just... not sure where/how?

        vector fwd = llRot2Fwd( llGetLocalRot() );
        vector targetPos =  llGetPos() + (fwd* ht);

this is from the example on the wiki page... http://wiki.secondlife.com/wiki/LlRot2Fwd

it says 'to move an object 5 meters on its forward axis.'  in this case i'm moving it "ht" meters on its X axis.  or... not MOVING it, but getting a coordinate that is supposed to be ht meters ahead of where i am.  but when i face the Y axis... i'm not getting a change in the Y axis calculation?  :/  no.  i changed 'ht' to 10 meters, but only the x coordinate is ever changing.

it's been a long day...

[Ruthven Ravenhurst]

Not in world to check, but calling llGetRot() from an attachment will get the Avatar's rotation, so say to get 1 meter in front of the avatar would be 

Avpos = llGetPos()

Avrot = llGetRot()

Offset = avpos+<1.0,0.0,0.0>*avrot

[Bloodsong Termagant]

i'll try that!

 

[Bloodsong Termagant]

YES!  and using get local rot was totally wrong.  THANK YOU!

 

[Rolig Loon]

You can always get your rotation by asking an attachment that is attached to ATTACH_AVATAR_CENTER.  Then make any offset calculations the way that you would normally, as Ruthven says.  Try this in a prim attached to your AVATAR_CENTER:

default
{
    touch_start(integer total_number)
    {
        vector vAngle =  llRot2Euler(llGetRot()) * RAD_TO_DEG;
        llSay(0, "I am facing " + (string) vAngle.z + " ( <<< Z-coordinate in degrees anti-clockwise from due East)");
        llSay(0, "My Pos = " + (string)llGetPos() + "   A spot 2m in front of me  = " +(string) (llGetPos() + <2.0,0.0,0.0> *llGetRot()) );
    }
}

EDIT: According to the LSL wiki, llGetRot() , "llGetRot will return an accurate facing for Avatars seated or in mouselook, but only a rough direction otherwise when called from an attached prim."  In practice, that "rough direction" is pretty reliable if the attachment is at ATTACH_AVATAR_CENTER.

Edited July 29, 2019 by Rolig Loon

[Wulfie Reanimator]

12 hours ago, Rolig Loon said:

EDIT: According to the LSL wiki, llGetRot() , "llGetRot will return an accurate facing for Avatars seated or in mouselook, but only a rough direction otherwise when called from an attached prim."  In practice, that "rough direction" is pretty reliable if the attachment is at ATTACH_AVATAR_CENTER.

llGetPos/llGetRot don't behave any differently based on which point the attachment is on, though. They're not getting the attachment's data at all.

Let me illustrate a bit what this "inaccuracy" looks like. I'm using an unattached prim with this script in it:

default
{
    state_entry()
    {
        llSetTimerEvent(0.1);
    }

    timer()
    {
        list od = llGetObjectDetails(llGetOwner(), [OBJECT_POS, OBJECT_ROT]);

        llSetLinkPrimitiveParamsFast(LINK_THIS,
            [PRIM_POSITION, llList2Vector(od, 0), PRIM_ROTATION, llList2Rot(od, 1)]);
    }
}

So all it does is try to mimic the avatar's physical position and rotation. You'll notice that:

1. The rotation can be off by around 45 degrees occasionally. (Best seen at the end.)
2. The rotation does not follow the avatar's facing direction while walking sideways or backwards. (Client-side effect)
3. The rotation changes on its own when no movement or turning is happening. (Alt-cam)
4. The rotation changes when the avatar's visual representation doesn't change. (Turning less than the visual threshold)

Edited July 30, 2019 by Wulfie Reanimator
Typos

[Estelle Pienaar]

17 hours ago, Rolig Loon said:

EDIT: According to the LSL wiki, llGetRot() , "llGetRot will return an accurate facing for Avatars seated or in mouselook, but only a rough direction otherwise when called from an attached prim."  In practice, that "rough direction" is pretty reliable if the attachment is at ATTACH_AVATAR_CENTER.

 

15 hours ago, Wulfie Reanimator said:

Let me illustrate a bit what this "inaccuracy" looks like. I'm using an unattached prim with this script in it: 

🤔 So let's say that I would like to script a hand to hand combat weapon (let's say a sword) one day. What would be the best solution to raicast and see if the weapon has hit someone? I probably should not raycast from the attachment...

Edited July 30, 2019 by Estelle Pienaar

[Wulfie Reanimator]

4 hours ago, Estelle Pienaar said:

So let's say that I would like to script a hand to hand combat weapon (let's say a sword) one day. What would be the best solution to raicast and see if the weapon has hit someone? I probably should not raycast from the attachment...

Just to reiterate -- you cannot raycast from an attachment. You can only raycast from the center of the avatar (positionally speaking) because scripts can't know where an attachment is relative to the avatar and its animations.

That said, I would primarily recommend llSensor with a low arc (<180 degrees).

llCastRay is too precise for melee weapons as it has no width. If your melee weapon has any kind of swing to it, it won't feel good because a swing is generally a relatively wide attack. Even for thrusting weapons I would recommend the same, because what you see on the screen isn't very accurate and an avatar might move out of the raycast's way due to script lag.

The minor inaccuracies of llGetRot are marginal when using an arc. You can still use llCastRay from your avatar's position to the target's position, to make sure there are no obstacles between you two. (Line-of-sight check)

That said, if your weapon can only be used while in mouselook, you can use llGetRot to get 100% accurate results.

Edited July 30, 2019 by Wulfie Reanimator