[Opensim-dev] another little can of worms: attachments :-)

[Melanie]

Hi,

Dalien Talbot wrote:
> 1) from Dan's: "how are the 'huge dino' avatars are made - whose height is
> above the max height of the avatar"

Simple...

You can make an animation that offsets the visible avatar from the 
true position. Now, the physics aspect is very interesting:

For the purpose of physics, an animation doesn't cause the avatar to 
move at all!
The avatar is always represented in physics at the point where the 
server sees it, as it's bounding box, at it's position.

Now, your wyrm avatar:

For physics, the avie is located at ground level. Typically about 
where the legs are. So, you can bump into the legs. You actually 
bump into the avatar!
The animation lifts the _visible_ avie 5 m into the air, sets it at 
an angle and folds in the arms and legs, so that the avie is 100% 
within the dragon body.
Finally, the attachments are put on. They are attached to the limbs, 
  which makes for some unusual joint translations. That is why these 
avies have their own set of animations, AO style. They are phantom.

If you want to do battle with this dragon, you have to attack it's 
legs, since, for collision purposes, that's where the avatar is. The 
translation which is effected by the animation is simply not a 
factor here.

Try to collide with such a beastie while flying - you'll fly 
straight through it!
Airspace above a Tiny? No, you'd bump into an avatar. Tinies cannot 
go through tiny doors! The door must be at least the height of the 
bounding box of the shortest possible "normal" avatar.

So:
Physics: serverside, bounding box @ position. That simple.
Animation: clientside. It has no bearing on physics interaction, 
even if it visually translates the avatar somewhere else.
Attachment: in world, phantom, and always rooted at the avatar's 
center of mass. The true offset of an attachment from the avatar's 
physics center is always 0,0,0. The asset contains a separate set of 
offsets, which are a display offset. This is added to the offset for 
the attachment point, clientside.

In an attachment: (from memory)
llGetPos() = world position (avatar center)
llGetLocalPos() = offset from attachment point
llGetRot() = world rotation of the AVATAR. The looking direction is 
always parallel to the ground plane, unless in mouselook.
llGetLocalRot() = rotation at the attachment point.
llGetRootRotation() = llGetRot()

llSetPos() = sets attachemnt point offset
llSetRot() = does nothing
llSetLocalRot() = rotates attachemnt.

ALL the above is clientside!

Attachments are phantom, but collisions of the AVATAR trigger 
collision() events in attachments.

Attachments can enable physics. That makes them no less phantom, but 
allows them to use damping motion to move the AVATAR. This is how 
the windwalker/wallwalker work. The object, going physical, actually 
just links their physics functions the the avatar's physics.

Here is a little bug that LL has in there: If a script makes an 
attachment physical, and the script is then restarted/resaved/reset, 
the attachment will not behave as a physical attachment anymore, but 
will claim it is one. So, physics can not be re-enabled, since the 
LSL interpreter thinks it already is.
In order to edit/test a script that does physical movement, you need 
to unwear and re-wear the attachemnt, which resets that flag.

Weird, but I make weapons, I know. I wish there were swords that 
actually collide with the avie they visually hit!

Melanie