Another rotation difficulty - for me

[Phil Deakins]

I'm making a round object on which I want people to sit for chatting in a group. The way I'm doing it is that each person touches it in the spot where s/he wants to sit, and then sits on the object. I reset the sit target to the location of the touch and that works fine. The item can be rotated and it still works fine, so I've managed the positioning part, taking the rotation of the object into account. What I'm struggling with is rotating the avatar to face the x-y coordinates (centre) of the object.

I could struggle for ages and maybe, just maybe, I might stumble into the solution, but if anyone here can help, it will save me a *lot* of trials and errors, crossings of fingers, and gnashings of teeth.

[Innula Zenovka]

I would feel a lot happier if I could see your code, or at least a picture of the object, but I think that you can calculate the rotation you need with 

llRotBetween(<1,0,0>,llVecNorm(<vTarget.x - vPos.x,vTarget.y - vPos.y,0>))

 where vTarget is what you want to look at (llGetPos()? ) and vPos is where you touched the object (sim coordinates).   Without the code, I can't really suggest how to get the value of vPos but you should be able to calculate it, I think, since you're getting the positioning right.

[Trinity Yazimoto]

/me jumps up and down and starts dancing and singing "yayyyyyy !!! Phil is back to creating !!! Phil is back to creating !!!! yay yay !!!!!! noooooo, i wont be sorry for this ! no no no :smileyvery-happy:"

yepppeeee !!!!

 

[Phil Deakins]

LOL Trinity. I'm not really back to creating. I'm doing it for a customer probably as a one-off that won't be sold in the store

[Trinity Yazimoto]

---

Phil Deakins wrote:

LOL Trinity. I'm not really back to creating. I'm doing it for a customer probably as a one-off that won't be sold in the store

---

naaaa... its already a good start...see, somehow you are itching to go back to creation :smileywink: you just need someone motivate you a lil... and im here for that ! :smileyhappy:

[Phil Deakins]

Thank you, Innula. That certainly does what I asked for. I haven't got the whole thing working properly yet.. When object's rotation vector is <0,0,0>, the avatar sits where it touched and faces the centre. But with the object rotated 180 degrees (<0,0,180>), the avatar still sits in the right place but now faces out instead of in - 180 degrees wrong.

I think I'll get there but perhaps you can see something obvious. Here's my current code:-

 

vector posTch = llDetectedTouchPos(0);vector posObj = llGetPos();vector posTgt = posTch - posObj;//posTgt.z += 1.0;rotation rot = llRotBetween(<1,0,0>,llVecNorm(<posObj.x - posTch.x, posObj.y - posTch.y, 0>));llSitTarget(posTgt / llGetRot(), rot); 

 

 

[Phil Deakins]

hehe, Trinity.

You are partially correct. In the last few days, I have got into doing some stuff, especially writing systems. I wrote that camera system, and I've made a significant change to the camping chairs, and other bits of things. But what none of it is doing, is changing my decision to allow it all to fade away. It's just that once in a while I fancy doing something, and you were the catalyst that caused it this time

[Qie Niangao]

Try replacing that last line with:

        rotation myRot = llGetRot();        llSitTarget(posTgt / myRot, rot / myRot); 

I'm not sure I quite understand everything that you want to have happen here, but that may get you closer.

(One gotcha that may be ahead is moving around the already-seated avatar. The sitTarget geometry undergoes a fairly strange transformation to arrive where the avatar's origin ends up when seated. Scripts like nPose deal with that, as does MLP in a different way, but we can cross that bridge when/if we get to it.)

[Phil Deakins]

Brilliant! That did it, Qie. Between you and Innula, the problem is solved Thank you both very much!

 

I'll try and explain better what I'm doing. The object is a round bed. The bed part is a flat disc and around that is a ring which is higher than the disc. On one side are 3 pillows. Behind the pillows the ring is raised by adding part of a tilted ring. The customer was looking for a bed on which up to 8 or 10 avatars can sit and chat, like sitting round a campfire.

So, instead of the idea of a separate prim for each av that may sit, I'm doing it so that, if you want to sit, you touch the bed in the spot where you want to sit, and then right-click > Sit as normal. Touching it changes its Sit Target to the spot you touched, and it must also face the avatar towards the centre or they will all face the same direction, which would be silly. It's facing the centre every time that gave me problems - as many things concerning rotations do. If I do get them right, it's usually because I've stumbled into the solution. For instance, I stumbled into getting the first Sit Target parameter right (offset divided the bed's rotation) but I've no idea why dividing the offset by the bed's rotation works.

 

I don't understand the "gotcha" effect that you mentioned. I used to use the MLP system in my furniture but I wrote my own no-balls system for my beds last year, and I haven't had any oddities with it  This bed I'm working on doesn't have any of that because the customer doesn't want those animations - it's just for group chats - and it does seem to work ok with, so far, two avs sitting, but yesterday I did encounter problems with a 3rd av. I'll look at that today.

 

[Phil Deakins]

I spoke too soon, dammit.

I could have sworn that I had the changing Sit Target working fine when a second avatar touched and sat, even though the first avatar was on the first (previous) sit target. That was before I got the all-facing-the-centre sorted out. Now it only works for the first avatar. The second avatar can change the sit target ok, but sitting on the bed doesn't cause it to sit on the new sit target.

I'll do some testing with a bench (no changing rotations),but I'd welcome ideas and thoughts.

 

ETA: I'm now certain that I never had the second avatar working because it simply doesn't work. I must have misunderstood what I saw along the way. The Sit Target does get changed when the object is touched but the first avatar is still registered as being on the Sit Target, even though the target is now in a different place. So a second av can't sit on the newly positioned target because that property is already in use.

I really need a way to unoccupy the Sit Target and leave the av sitting, and I don't think there's a way to do that. Unfortunately, clearing the Sit Target by setting it with a zero offset doesn't clear the fact that there's an av on the sit target, even though there is no longer a Sit Target. I could do with a means of either clearing the Av-On-Sit-Target, or unlinking each avatar after it has sat down but without causing it to stand up. Unfortunately, breaking the link with the av causes it to stand up, so that won't work.

Any thoughts and ideas would be very welcome, even if they are that what I'm trying to do can't be done. At least then I'd stop trying to do it 

 

ETA (again): I've finally come to the conclusion that what I was trying to do can't be done. I was trying to make it so that no extra prims (for sit targets) were needed to allow multiple avs to select and use sit targets, but I really don't think there's a way of doing it, and the only options are (1|) use extra prims, (2) use nothing and let the avs sit where they can, but that limits them to the edges of the bed's prims, and (3) instead of a sit target, let the avs touch where they want to be and position the av (link) accordingly. That last one might do it.

[Innula Zenovka]

If I've properly understood what you're saying, then I agree.  Grab the coordinates of the touch and then, if the toucher sits,  use llSetLinkPrimitiveParamsFast(llGetNumberOfPrims(), [....]) to move them to the spot and rotate them.

The only gotcha there would be that, if the object is inside the bounding box of another object (sim surrounds and large sculpties in particular) then if more than one person tries to sit on the object, you'll get "no room to sit here" errors.    If this is a custom job, then that might not be an issue.

[Phil Deakins]

It works, Innula - position and rotation with multiple avatars.

Now all I have to do are some tweaks of other parts, and it's ready

[Phil Deakins]

You won't believe this...

It all works perfectly now - as long as the bed is not rotated at all. But when it's rotated 180 degrees, the avatar face out instead of in to the centre. Any in between rotation faces the avatars accordingly. If you remember, that's what it did earlier, and that problem was fixed by a combination of Innula and Qie. It was also when I was using the Sit Target to place the avs.

Now I'm placing the avs with llSetLinkPrimitiveParamsFast() in in the run_time_permissions event handler, and that earlier problemis back. I'm using the same code that worked before and, since it's a rotation problem, I have no idea how to fix it.

This is my current code (sorry but I don't know how to post the code with the syntax highlighting that you two get):-

    run_time_permissions(integer perm)    {        if (perm & PERMISSION_TRIGGER_ANIMATION)        {            // Kep this posTouch to disallow others from sitting            // in the sampe spot.            lastSit = posTouch;                        vector posObj = llGetPos();            vector posTgt = posTouch - posObj;            posTgt.z += 1.1;            rotation rot = llRotBetween(                <1,0,0>,                llVecNorm(<posObj.x - posTouch.x, posObj.y - posTouch.y, 0>)                );            rotation myRot = llGetRot();            // Place the av at the touched point and rotate it accordingly            llSetLinkPrimitiveParamsFast(curPrims, [            PRIM_POSITION, posTgt / myRot,            PRIM_ROTATION, rot / myRot            ]);            llStopAnimation("sit");            string animation = "sit_ground";            llStartAnimation(animation);        }

 posTouch is picked up in the touch_start handler and it's global..

 

This is the code that worked when using the Sit Target method:-

    touch_start(integer num)    {        vector posTch = llDetectedTouchPos(0);        vector posObj = llGetPos();        vector posTgt = posTch - posObj;        posTgt.z += 0.7;        rotation rot = llRotBetween(            <1,0,0>,            llVecNorm(<posObj.x - posTch.x, posObj.y - posTch.y, 0>)            );        rotation myRot = llGetRot();        llSitTarget(posTgt / myRot, rot / myRot);             }

 

I see no difference in them except for the name of the variable, posTouch / posTch. So, because it's about the rotation, I'm clueless again.

I can demonstrate it if it would help to understand.

 

[Phil Deakins]

Oh my! I've cracked it!

I decided to read up on LSL rotation, in the hope of finding something that will help, but not really thinking that I could solve my problem, and definitely not thinking that I could actually understand it in the same way as understanding rotations as vectors. And my expectations lived up to my expectations 

But I did spot PRIM_POS_LOCAL and thought that my problem might be because, with the non-use of Sit Targets method, I was setting the av's rotation to the global rotation. So I tried it as local, and it works! Who's a happy bunny then? lol

I've changed the following parameter from:-

PRIM_ROTATION, rot / myRot

to

PRIM_ROT_LOCAL, rot / myRot

and that has solved the problem. I can now rotate the bed to anywhere in the x-y plane, and the avs always face the center when sitting, after first touching the bed. I've no idea about the other planes, but rotating the bed in either of those will never be needed.

I really don't think I'm going to get a grasp on rotations, but I need them so infrequently, and even then my use of them is usually well satisfied by only thinking in vectors, that I don't really need to grasp it. And any grasping that I manage now will be forgotten long before I need to understand it again.

 

[Qie Niangao]

---

But I did spot PRIM_POS_LOCAL and thought that my problem might be because, with the non-use of Sit Targets method, I was setting the av's rotation to the global rotation. 

 

---

Not so much. Instead, you independently discovered a very old bug, which PRIM_ROT_LOCAL was introduced to fix.

The workaround, pre-PRIM_ROT_LOCAL, would have been to use

PRIM_ROTATION, (rot / myRot) / myRot

 which is hideous, of course, but should get you the same result, and otherwise worth knowing when reading old code.

[Phil Deakins]

Well, old bug or not, I'm still feeling rather pleased at finally having completed the script so that it does what I was trying to do I was beginning to despair of it.

My jaw dropped when I found that changing from the Sit Targets method re-introduced the problem that you and Innula solved for me earlier - avatars not facing the centre when the bed is rotated. I felt almost embarrassed to ask how to fix the same problem again.

Btw, how do you include color-hilighted code in your posts? When I copy-paste from a color-highlighted script, it posts in black and white.

[Qie Niangao]

---

Btw, how do you include color-hilighted code in your posts? 

---

Cerise made that. I never really studied it. I'm just using a Chrome extension version of it, and I know there's one for Firefox.

[Innula Zenovka]

Congratulations on fixing it!

To do the colour highlighting, you need to install  this LSL posting tool created by Cerise Sorbet.   It needs Greasemonkey or similar installing in Firefox.   It should work as is with Chrome, but I find userscripts in Chrome are a lot easier if you first install Tampermonkey.   I don't know how, if at all, it works in IE.

[Phil Deakins]

In that case, I can't use it because I use IE. But ty both anyway.