[#SVC-2901] Undesired Z displacement resulting from a cube with llSitTarget(<0.0, -.5, 0.0>,< -0.5,-0.5,0.5,0.5>);

2. Second Life Service - SVC

Undesired Z displacement resulting from a cube with llSitTarget(<0.0, -.5, 0.0>,< -0.5,-0.5,0.5,0.5>);

Created: 21/Aug/08 06:10 PM Updated: 25/Aug/08 06:37 AM

Return to search

Component/s:

Scripts

Affects Version/s:

None

Fix Version/s:

None

File Attachments:

Podium_001.bmp (2.07 MB)

Image Attachments:

1. Agent Rotation.jpg
(17 kB)

2. example.jpg
(74 kB)

Issue Links:

Relates

This issue Relates to:

~~SVC-1299~~ Sit Targets created under Havok 1 are offset under Havok 4

Description

« Hide

When sitting at a podium, Sit Target set by " llSitTarget(<0.0, -.5, 0.0>,< -0.5,-0.5,0.5,0.5>);" I find myself sitting on a displacement to the right, positive Z direction, of the cube. The displacement doesn't seem to be relative to the center of the object's bounding box.

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Darien Caldwell added a comment - 21/Aug/08 06:45 PM

hehe. I suspect what you are seeing is the intetional offset which was placed for historical backward compatibility when Havok 4 was rolled out.
Apparently there was a bug in the original simulator code which caused a Z offset. Havok 4 'corrected it', however, this broke all previously created content. After a lot of convincing, the offset was placed back to allow existing content to continue to work correctly.

You can read the JIRA on this here: http://jira.secondlife.com/browse/SVC-1299

In short, you will have to compensate for this offset in your scripts.

[ Permlink | « Hide ]

Arawn Spitteler added a comment - 21/Aug/08 07:36 PM

Nice Picture of Kitto and Andrew.
I hope this shows my agent target to the right of the box

[ Permlink | « Hide ]

Darien Caldwell added a comment - 22/Aug/08 12:12 AM

Attaching a picture I hope makes things clearer. The sit target positions and rotates the Agent, not the Avatar. The Avatar can be offset from the agent by the animation in use, I think what you may be seeing is an offset caused by the animation. Using this script created by Winter Ventura, you can visualize the Agent:

// AGENT Visualizer - By: Winter Ventura
// Permission is granted to fold, spindle, mutilate, slice, dice, and julianne.
// Use them together, Use them in peace.

init()
{
llSetObjectName(llKey2Name(llGetOwner()) + "'s Agent Stand-in");
llSetPrimitiveParams([
PRIM_COLOR, ALL_SIDES, <0,0,0>, .25,
PRIM_PHANTOM, TRUE,
PRIM_TYPE, PRIM_TYPE_SPHERE, 0, <0.0, 1.0, 0.0>, 0.0, <0.0, 0.0, 0.0>, <0.0, 1.0, 0.0>,
PRIM_TEXTURE, ALL_SIDES, "769681c6-9064-ab0f-e416-6a4eecc59e6a", <1,1,0>, <0,0,0>, 0.00,
25, ALL_SIDES, 0.05 // PRIM_GLOW
]);
llSensorRepeat("", llGetOwner(), AGENT, 96, PI, 0.1);
}

default
{
state_entry()
{
init();
}

on_rez(integer start_param)
{
init();
}

changed (integer change)
{
if (change & CHANGED_OWNER) init();
}

sensor(integer num_detected)
{
llSetPrimitiveParams([
PRIM_POSITION, llDetectedPos(0),
PRIM_ROTATION, llDetectedRot(0),
PRIM_SIZE, llGetAgentSize(llGetOwner())
]);
}
}

In the picture attached called "Agent Rotation", I use your sit target, but vary the rotations, pulling the script out of the Agent Visualizer each time to freeze it in place. As you can see, their center points all intersect, there's no offset.

Red is a rotation of <0.00000, 0.00000, 0.00000, 1.00000> (in degrees a rotation of 0,0,0)
Green is a rotation of <0.00000, 0.00000, 0.70711, 0.70711> (in degrees a rotation of 0,0,90)
Pink is a rotation of <0.50000, 0.50000, -0.50000, -0.50000> (in degrees a rotation of 0,-90,90)
White is a rotation of <0.00000, -0.70711, 0.00000, 0.70711> (in degrees a rotation of 0,-90,0)
Blue is a rotation of <0.70711, 0.00000, 0.00000, 0.70711> (in degrees a rotation of 90,0,90)

[ Show » ]

Darien Caldwell added a comment - 22/Aug/08 12:12 AM Attaching a picture I hope makes things clearer. The sit target positions and rotates the Agent, not the Avatar. The Avatar can be offset from the agent by the animation in use, I think what you may be seeing is an offset caused by the animation. Using this script created by Winter Ventura, you can visualize the Agent: // AGENT Visualizer - By: Winter Ventura // Permission is granted to fold, spindle, mutilate, slice, dice, and julianne. // Use them together, Use them in peace. init() { llSetObjectName(llKey2Name(llGetOwner()) + "'s Agent Stand-in"); llSetPrimitiveParams([ PRIM_COLOR, ALL_SIDES, <0,0,0>, .25, PRIM_PHANTOM, TRUE, PRIM_TYPE, PRIM_TYPE_SPHERE, 0, <0.0, 1.0, 0.0>, 0.0, <0.0, 0.0, 0.0>, <0.0, 1.0, 0.0>, PRIM_TEXTURE, ALL_SIDES, "769681c6-9064-ab0f-e416-6a4eecc59e6a", <1,1,0>, <0,0,0>, 0.00, 25, ALL_SIDES, 0.05 // PRIM_GLOW ]); llSensorRepeat("", llGetOwner(), AGENT, 96, PI, 0.1); } default { state_entry() { init(); } on_rez(integer start_param) { init(); } changed (integer change) { if (change & CHANGED_OWNER) init(); } sensor(integer num_detected) { llSetPrimitiveParams([ PRIM_POSITION, llDetectedPos(0), PRIM_ROTATION, llDetectedRot(0), PRIM_SIZE, llGetAgentSize(llGetOwner()) ]); } } In the picture attached called "Agent Rotation", I use your sit target, but vary the rotations, pulling the script out of the Agent Visualizer each time to freeze it in place. As you can see, their center points all intersect, there's no offset. Red is a rotation of <0.00000, 0.00000, 0.00000, 1.00000> (in degrees a rotation of 0,0,0) Green is a rotation of <0.00000, 0.00000, 0.70711, 0.70711> (in degrees a rotation of 0,0,90) Pink is a rotation of <0.50000, 0.50000, -0.50000, -0.50000> (in degrees a rotation of 0,-90,90) White is a rotation of <0.00000, -0.70711, 0.00000, 0.70711> (in degrees a rotation of 0,-90,0) Blue is a rotation of <0.70711, 0.00000, 0.00000, 0.70711> (in degrees a rotation of 90,0,90)

[ Permlink | « Hide ]

Winter Ventura added a comment - 22/Aug/08 08:10 PM

As seen in the attached illustration named "example.jpg". rotation might actually be the cause of your confusion.

"Hollow" in a cube, is a universal indicator of the z axis. No matter how much torturing or tapering, Hollow will always hollow down the Z axis.

I tried replicating your podium shape. Judging by the image you provided, the podium (if a single prim) MUST be made either by the method described in A & B, or in the method described in C & D. Hollow helps orient the Z (blue) axis for illustration purposes. It's obvious from the shape of the podium, and from your description, that the podium MUST be rotated on it's axis. The shape just isn't possible (using a traditional prim) with Z pointing up-down.

You say that you're trying to offset in the Y direction, yet you're seeing movement in the left->right axis.

Take a look at illustration D.
If the podium is created using taper and skew, then this is the most likely reason why you're seeing sideways movement when offsetting on Y.

Try varying the Y offset, and see which axis you're moving on. (0,1,0), (0,2,0) etc. If you move side to side, then you have solved the mystery. If you move up and down, then it's possible that the podium may be constructed more like illustration A.

Not knowing how the podium prim was constructed, I can only guess at what might be at play here. But hopefully this illustration will help you diagnose the problem.

[ Permlink | « Hide ]

Arawn Spitteler added a comment - 25/Aug/08 06:29 AM

https://wiki.secondlife.com/wiki/LlSitTarget seems to be the best we can do, until C# comes in after MONO. To Fix this in H4 would break H1 Content, that people worked very hard to refine, having no documentation of this bug.
The image I attached, since I haven't yet figured how to add a picture properly, shows the Agent Target to the right of where it's defined, which was positive Z Axis. That podium was shaped as a pathcut box.
This would be nice to fix, in C#, along with the ability to get the Agent Target. list llDetectedTarget(integer)

[ Permlink | « Hide ]

Arawn Spitteler added a comment - 25/Aug/08 06:37 AM

Under C#, I hope the issue of ~~SVC-1299~~ will be resolved finally. It should have been documented better, to prevent that problem, as it caused me much anxiety as a newbi builder.