Animesh Adjuster

[LeonaMorro]

I have rewritten parts of the Adjuster and Slave script to do a proof-of-concept of Animesh adjusters. The problems I saw are all solved but there is one problem I didn't saw, which will make the project (almost?) impossible:
In the Slave script there is the function "MoveLinkedAv" where the Avatar is moved to his final postion. But this positon isn't the position where the adjuster is, but it is offsetted by a few fancy lines:
avpos.z += 0.4;
llSetLinkPrimitiveParamsFast(linknum, [PRIM_POSITION, ((avpos - (llRot2Up(avrot) * size.z * 0.02638)) * localrot) + localpos, PRIM_ROTATION, avrot * localrot / llGetRootRotation()]);

Questions:
a) Why? Are these lines to do some offset for different Avatar heights?
b) What are these values: 0.4 and 0.02638?

Whith this offset the Animesh Adjusters had to be offsetted the same way like the Avatars inside the slave, while still reporting the unoffsetted pos/rot values to the slave (because these unoffsetted values are going to the NC) and even if this would work then the piviot point of the adjusters are at the wrong place making rotations around the x and y axis nearly impossible.

There is a feature request https://jira.secondlife.com/browse/BUG-139336 that would solve this problem but until something like that is implemented, Animesh Adjusters will not working in a good way.

[HowardBaxton]

The below is in the oldest slave script I have. I believe it is an attempt to center AV hips which is something I tried not to change from the original. It does have a reference to pose balls using the .4 offset. If there is a better way, maybe it is time to explore that way.

        llSetLinkPrimitiveParams(linknum, 
            [ PRIM_POSITION, ((avpos
                - (llRot2Up(avrot) * size.z * 0.02638)) * localrot) 
                + (<0,0,0.4> / llGetRootRotation()) //Qie added...
                // 0.4 is in the poseball's coord system; MLP ~balls are zero global rot
                + localpos
            , PRIM_ROTATION, avrot * localrot / llGetRootRotation()
            ]);

[LeonaMorro]

Thank you Howard. With this piece of code I was able to find some more reference:
http://forums-archive.secondlife.com/54/09/242119/1.html
http://wiki.secondlife.com/wiki/Talk:LlSitTarget#GetSitTarget

[LeonaMorro]

After reading the above references and following a few links given in them I would say that theses fancy lines are obsolete. I guess (please correct me if I'm wrong) at some time the nPose adjusters (or its ancestor) are used to set up sittargets (llSitTarget). The llSitTarget command seems to have a bug which offsets the avatar (mainly in z-direction) by 0.4m and an aditional offset based on the avatar height (0.02638). To eliminate this bug the sittarget was offsetted the oposite way. At some point nPose (or its ancestor) switched from the position via llSitTarget to the direct manipulation of the sitting Avatar (llSetLinkPrimitiveParams). At this time the offset correction had to be removed from the code (but it wasn't).

[HowardBaxton]

I think you are probably correct about using sit targets. Though I did not find the references you did above. I believe there was this theory that changing sit targets could move a seated AV, however my experiments showed sit targets only affected new sitters and did not move a seated AV. I always thought I was as confused as everyone else and did not implement properly.
I also assumed that applying some sort of offset based upon AV size would allow the position to work with a wider variety of AV sizes but never attempted to prove this for myself.
That code snippet I pasted came from Sept. 5 2008 which would have been very close to beta time of the original nPose script set.

[LeonaMorro]

If this (- (llRot2Up(avrot) * size.z * 0.02638)) * localrot)) was intended to allow a wider variety of AV sizes it is buggy because the result of it is to place smaller Avatars higher than taller avatars.

To summerize this, I would say that these lines are doing nothing usefull anymore and to make things easier in the future we should drop them.
Maybe we could add a global option to offset all positions by a userdefined vector (without the part that uses the avatar height) to make an update less painful? I don't know if tihs is worthwhile.

[HowardBaxton]

I have no opinion which would differ from what you're saying. Seems the global offset might make updating less painful but the pain would still be there. My opinion on that is less painful == very painful in the eyes of those who update. Using the animesh adjusters are enough "less painful" to offset any hack we could use. My vote is not to add a global option to offset all positions as it would never work well for all AV's, only some AV's. Make the AV position match the animesh adjuster position and we suffer the consequences of the updates.