Follow Camera Hair Pulling

I've been pulling my hair out on this one, it's driving me *nuts*.

I've writen a script (posted below) for dragging hud attachments around. It works ok when the av is standing (the camera snaps to the updated av rot on drag end), but fails when the av is sitting. It does some really weirds stuff when the av is sitting; including screw with AV rendering.

I wish there was a status flag llSetStatus(STATUS_STATIC_GRAB, TRUE);

integer perms;
vector pos;

default
{
    state_entry()
    {
        if(llGetAttached() == 35)//HUD CENTER
        {
            perms = PERMISSION_TRACK_CAMERA | PERMISSION_CONTROL_CAMERA;
            llRequestPermissions(llGetOwner(), perms);
        }
    }
    on_rez(integer a)
    {
        llResetScript();
    }
    run_time_permissions(integer a)
    {
        if((a & perms ) == perms)
            state go;
    }
}

state go
{
    state_entry()
    {
        llClearCameraParams();
        llSetPos(<0,0,0>);
    }
    on_rez(integer a)
    {
        llResetScript();
    }
    touch_end(integer a)
    {
        pos = llGetCameraPos();
        llSetCameraParams([ CAMERA_ACTIVE, TRUE,
                            CAMERA_FOCUS, pos + (<10.0,0.0,0.0> * llGetCameraRot()),
                            CAMERA_FOCUS_LOCKED, TRUE,
                            CAMERA_FOCUS_LAG, 0.0,
                            CAMERA_POSITION_LAG, 0.0,
                            CAMERA_POSITION, pos,
                            CAMERA_POSITION_LOCKED, TRUE
                            ]);
        state drag;
    }
}

state drag
{
    state_entry()
    {
        pos = llGetLocalPos();
        llSetTimerEvent(2.0);
        llOwnerSay("start drag");
    }
    on_rez(integer a)
    {
        llResetScript();
    }
    touch_start(integer a)
    {
        llOwnerSay("touch start");
        llSetTimerEvent(0.0);
    }
    touch(integer a)
    {
        do
        {
            vector c = (llDetectedGrab(--a) / llGetCameraRot()) / 5;
            llSetPos(pos + <0.0, c.y, c.x>);
        }
        while(a);
    }
    touch_end(integer a)
    {
        llOwnerSay("touch end");
        llSetTimerEvent(2.0);
    }
    timer()
    {
        llSetTimerEvent(0.0);
        llOwnerSay("stop drag");
        state go;
    }
}

Nice find, I can't really answer you on that one. This is a long shot and it's probably a no, but is the camera fighting with another script (in the sit object?) making it bounce back and forth? Does it bounce and act erratic on it's own, or only after you touch it? Try putting a sit detection and flushing camara controls when you sit, see if that does anything.

No the sit script doesn't manipulate the camera. And you can see in the script that it flushes the camera each cycle.

Well, even pre-1.9, cameras worked differently if you were sitting, even without any scripted intervention. So I'm pretty sure there's "under the hood" stuff where sitting causes some changes to the camera, and it wouldn't surprise me if they didn't play well with the new camera controls.

For instance. Use alt-click to focus on an object. Use ctrl/alt/arrow keys to move the camera around (still focussed on that object). Tap the right arrow key. The camera will return to the default position.

Now try the same thing while sitting. The camera won't return to the default position.

Right-click on an object, open up the edit window, then close it. Now the camera will return to its default position, both while standing or sitting.

Going from memory here, but I think those are some of the 'inconsistencies' I've noticed. *shrug*

I've come to relize that you cannot capture the camera when it is in free mode (as opposed to strict av follow). I've dropped a notecard on Kelly's cylinder with some feature suggestions.

I was hoping it wasn't 'under the hood' :\

Hi scripters,
I am not sure if this does really fit to the things mentioned before, but the wiki -> camera sections has some notes about camera modes in various states:

----- ZIP -----
Camera Modes
1. seated avatar
1. normal sitting cam (llSetCamEyeOffset, llSetCamAtOffset)
2. scripted "follow cam" (llSetCamParams)
2. standing avatar
1. normal avatar cam
2. scripted "follow cam"
3. alt-zoom
1. another object or avatar
2. a fixed point in space or the ground
4. customize avatar mode
5. mouselook

Hitting Esc in modes 3-5 will pop out to modes 1-2, depending on the situation (whether you are sitting or not, for example).

When grabbing/touching, the camera mode is 3b where the camera is locked to a fixed point in space. It isn't a special "grab" camera but just a variation of alt-zoom.
------ ZIP -----

So, sitting and grabbing touching (at least in scripted ways) seem to be exclusive.

But probably there seems to be a way around.
In one of the linden demo scripts about camera control there is a mysterious
llSitTarget(<0,0,.1>, ZERO_ROTATION), that lifts the avatar slightly above while sitting.
I am not sure why this is there. Probably a slightly above sitting avatar cannot be linked to ground and doesn't go into one of the modes for sitting, though itself is sitting. This however is just an assumption, as I don't know much about linking and the distance needed to link.

Addition: in my tests ( I am sitting on a mountain), I experimented with different values than .1 and experienced minor to none artefacts. Unfortunately on my system (lousy ibook) and my isp connection (ping between 200-300ms) the camera behaves really lame and annoying. Is this by design, that the HUD doesn't stay in the middle or is this due to worse technical conditions here.

Regards,
Leff.

Well, the formatting of this quote is somewhat messed up. But I think, you can see that there are the main conditions and the one or two camera modes.
Regards,
Leff.

I wanted to add, what I have found in the scripting wiki about llDetectedGrab. It sounds like your used combination of lsl library calls might not work together or at least may break in the future.
Leff.

HUD Attachments
In the case of HUD attachments, llDetectedGrab will always be relative to the direction the avatar is facing. This means that you can produce a script that will allow you to use llDetectedGrab in HUD attachments; however, it will not perform correctly if you move the camera around. Regardless of where they appear to be on your screen, HUD attachments are still attachments, which are fixed to the avatar's rotation, despite appearances to the contrary.