llClearCameraParams

[EnCore Mayne]

i'm working on an animation script that sets the camera parameters from a dialog. aside from all the usual insanity of trying to script anything, i've managed to get close to what i intended. of course, close isn't what i wanted. i actually wanted to clear the camera parameters on resetting the scripts. i've got llClearCameraParams() at a number of places, unsitting, state_entry, listen, changed, and run_time_permissions. if there were other events, i'd put llClear.. in that too.

unfortunately, on resetting the script, the earlier setting remains on first sit then it's cleared on the second sit. any hints as to why that might be?

i don't have a workaround. is there something funky about llClearCameraParameters() i'm missing? can i clear it so it's cleared on a reset of the scripts?

[OptimoMaximo]

2 hours ago, EnCore Mayne said:

i'm working on an animation script that sets the camera parameters from a dialog. aside from all the usual insanity of trying to script anything, i've managed to get close to what i intended. of course, close isn't what i wanted. i actually wanted to clear the camera parameters on resetting the scripts. i've got llClearCameraParams() at a number of places, unsitting, state_entry, listen, changed, and run_time_permissions. if there were other events, i'd put llClear.. in that too.

unfortunately, on resetting the script, the earlier setting remains on first sit then it's cleared on the second sit. any hints as to why that might be?

i don't have a workaround. is there something funky about llClearCameraParameters() i'm missing? can i clear it so it's cleared on a reset of the scripts?

Stupid question maybe, but when resetting the script, is the call to clearcameraparams stated before or after the call to reset? Because if it's placed after the reset, well it resets the script and the clearing command doesn't run, so it should be placed right before the call to reset

[sandi Mexicola]

I'm not in-world atm, so I can't test this right now.  But looks like resetting the script won't reset the camera.  In fact, resetting the script is probably the opposite of what you want.   This is because resetting the script removes all the permissions the user granted the script, including the  PERMISSION_CONTROL_CAMERA permission, which is necessary for running llClearCameraParams().  

I am curious what your run_time_permissions event handler looks like.  My guess is that you would want to clear the camera parameters in the run_time_permissions event handler.  If you try it this way, you need to make sure that the run_time_permissions event is raised by calling llRequestPermissions agian.  

At least, that is what I would try for starters.  

One thing I don't understand without actually going in-world and writing a script for it is this: in LlClearCameraParams caveats section is this line: "The PERMISSION_CONTROL_CAMERA permission is automatically revoked when the avatar stands up from or detaches the object, and any scripted camera parameters are automatically cleared."    ... which sounds like just standing up should fix the problem.  So a 2nd thing I might try is removing the calls to LlClearCameraParams, and just see what happens when you stand up.  

 

[sandi Mexicola]

1 minute ago, OptimoMaximo said:

Stupid question maybe, but when resetting the script, is the call to clearcameraparams stated before or after the call to reset? Because if it's placed after the reset, well it resets the script and the clearing command doesn't run, so it should be placed right before the call to reset

You beat me to it.   That is probably the answer.   

 

[Jenna Huntsman]

37 minutes ago, sandi Mexicola said:

 This is because resetting the script removes all the permissions the user granted the script, including the  PERMISSION_CONTROL_CAMERA permission, which is necessary for running llClearCameraParams(). 

 

This, 100%.

All actions that are being performed on the user's camera should take place in the perms event, otherwise you'll get an endless amount of perms errors when you try to interact with the user's camera.

(ps. If the item you're creating for uses AVSitter, I actually already have a product which manages the user's camera in accordance to their pose on my MP store, inc. camera transitions)

[EnCore Mayne]

i physically reset the script from the button in the contents tab. there's no llResetScript() ... yet.

as to the requests on sit, i have trigger_animation, track_camera, and control_camera. in my run_time i put in a conditional for whether the camera had or had not been set. if it had been set it just passes through (only animating). if it hasn't been set, the camera is set at a default position in front of the poseball and a dialog comes up providing a button to Save the camera where the user positions it.

that all works fine in testing except the earlier setting (made before resetting) persists. so, to make it work i have to sit twice. on the second sit, the default camera setting i put into the code works. i'd rather not have the next user have their camera go wild if they're in another region.

if it helps, here's the rough layout i'm working with:

dialog (key av)
{
    "Save" button
}

    state_entry() 
    { 
        camera setting = FALSE;   
        llClearCameraParams();//this may speak of my futility        
    }
    
    changed(integer change) 
    {
        if (change &  CHANGED_LINK) 
        {
            if (llAvatarOnSitTarget() != NULL_KEY) 
            {
                llRequestPermissions(llAvatarOnSitTarget(), PERMISSION_TRIGGER_ANIMATION | PERMISSION_TRACK_CAMERA | PERMISSION_CONTROL_CAMERA);
            } 
            else 
            {
                llStopAnimation(llGetInventoryName(INVENTORY_ANIMATION, 0));
                llClearCameraParams();
            }
        }
    }
                        
    run_time_permissions(integer perm) 
    {
        if ( perm ) 
        {
            llStopAnimation("sit");
            llStartAnimation(llGetInventoryName(INVENTORY_ANIMATION, 0));
            	//this is where the dialog on first sit comes up
				//BUT
				//somehow, it only sets correctly if i unsit and sit again.
				//first sit has the last setting saved.
			if (set == FALSE) 
            {
                llClearCameraParams();
                llSetCameraEyeOffset( <2.5, 0.0, 0.0> );
                llSetCameraAtOffset( <0,0,0> );//looking at
                selections(llGetPermissionsKey());
            }
        }
    }
                  
    listen()
    {
        if (message == "Save")
        {
            llClearCameraParams();
			camera settings voodoo
            camera setting = TRUE;
        }
    }                  

 

 

[Jenna Huntsman]

12 minutes ago, EnCore Mayne said:

i physically reset the script from the button in the contents tab. there's no llResetScript() ... yet.

as to the requests on sit, i have trigger_animation, track_camera, and control_camera. in my run_time i put in a conditional for whether the camera had or had not been set. if it had been set it just passes through (only animating). if it hasn't been set, the camera is set at a default position in front of the poseball and a dialog comes up providing a button to Save the camera where the user positions it.

that all works fine in testing except the earlier setting (made before resetting) persists. so, to make it work i have to sit twice. on the second sit, the default camera setting i put into the code works. i'd rather not have the next user have their camera go wild if they're in another region.

if it helps, here's the rough layout i'm working with:

dialog (key av)
{
    "Save" button
}

    state_entry() 
    { 
        camera setting = FALSE;   
        llClearCameraParams();//this may speak of my futility        
    }
    
    changed(integer change) 
    {
        if (change &  CHANGED_LINK) 
        {
            if (llAvatarOnSitTarget() != NULL_KEY) 
            {
                llRequestPermissions(llAvatarOnSitTarget(), PERMISSION_TRIGGER_ANIMATION | PERMISSION_TRACK_CAMERA | PERMISSION_CONTROL_CAMERA);
            } 
            else 
            {
                llStopAnimation(llGetInventoryName(INVENTORY_ANIMATION, 0));
                llClearCameraParams();
            }
        }
    }
                        
    run_time_permissions(integer perm) 
    {
        if ( perm ) 
        {
            llStopAnimation("sit");
            llStartAnimation(llGetInventoryName(INVENTORY_ANIMATION, 0));
            	//this is where the dialog on first sit comes up
				//BUT
				//somehow, it only sets correctly if i unsit and sit again.
				//first sit has the last setting saved.
			if (set == FALSE) 
            {
                llClearCameraParams();
                llSetCameraEyeOffset( <2.5, 0.0, 0.0> );
                llSetCameraAtOffset( <0,0,0> );//looking at
                selections(llGetPermissionsKey());
            }
        }
    }
                  
    listen()
    {
        if (message == "Save")
        {
            llClearCameraParams();
			camera settings voodoo
            camera setting = TRUE;
        }
    }                  

 

 

That script does need a lot of work as I can see that most of the camera interactions are taking place outside of the perms event - also no verification that PERMISSION_CONTROL_CAMERA happens which could also see the camera fail to set correctly.

I can also see that you're trying to use llClearCameraParams when the avatar gets up - but this isn't needed as the permissions are revoked and camera position reset automatically, and likely will throw a perms error.

It's also worth noting that in the event that an object can have multiple people sitting on it, when one person gets up the perms for the second (still sitting) person is also revoked and must be re-acquired and their camera set to it's desired position again.

[EnCore Mayne]

4 minutes ago, Jenna Huntsman said:

That script does need a lot of work as I can see that most of the camera interactions are taking place outside of the perms event - also no verification that PERMISSION_CONTROL_CAMERA happens which could also see the camera fail to set correctly.

I can also see that you're trying to use llClearCameraParams when the avatar gets up - but this isn't needed as the permissions are revoked and camera position reset automatically, and likely will throw a perms error.

It's also worth noting that in the event that an object can have multiple people sitting on it, when one person gets up the perms for the second (still sitting) person is also revoked and must be re-acquired and their camera set to it's desired position again.

you coulda just said it was a pile a poo, Jenna.

how do i verify the camera control perm? in the conditional? [> if (perm) <] should be more specific? having the crucial camera settings in the listen is a no no?

i threw in llClears in just about every event there was. note futility. this is for a single avatar.

[arton Rotaru]

The llClearCameraParams function is used in conjunction with the llSetCameraParams function. Which controls the avatars camera.

llSetCameraAtOffset and LlSetCameraEyeOffset are Prim properties, though. They don't update while seated. They have to be set in advance.

Edited February 26, 2022 by arton Rotaru

[Jenna Huntsman]

2 hours ago, EnCore Mayne said:

you coulda just said it was a pile a poo, Jenna.

how do i verify the camera control perm? in the conditional? [> if (perm) <] should be more specific? having the crucial camera settings in the listen is a no no?

i threw in llClears in just about every event there was. note futility. this is for a single avatar.

You can use:

if(perm & PERMISSION_CONTROL_CAMERA)

Which will pass when the permission PERMISSION_CONTROL_CAMERA is given (it will fail if not, and is not affected by the status of other perms)

7 minutes ago, arton Rotaru said:

The llClearCameraParams function is used in conjunction with the llSetCameraParams function. Which controls the avatars camera.

llSetCameraAtOffset and LlSetCameraEyeOffset are Prim properties, though. They don't update while seated. They have to be set in advance.

Oops, you're absolutely right - that flew straight over my head!

In that case, llClearCameraParams() won't do anything, as they are part of scripted camera controls ( used as part of llSetCameraParams() ).

You may actually be interested in the llSetLinkCamera command, as this combines the 2 camera commands you're currently using into a single command.

You should shift the camera commands into your state_entry event, and if they are set at another offset, add them into your function to do so. As arton said, this isn't applied retroactively, so only avatars sitting down after will have their camera set accordingly.

[Qie Niangao]

5 hours ago, arton Rotaru said:

The llClearCameraParams function is used in conjunction with the llSetCameraParams function. Which controls the avatars camera.

llSetCameraAtOffset and LlSetCameraEyeOffset are Prim properties, though. They don't update while seated. They have to be set in advance.

Yeah. This I think is why after a reset the cam behaves differently on first sitting than on subsequent sittings: At first the sitter gets the camera At- and EyeOffset prim properties, whereas in subsequent sittings the sitter's permission will give them the full-on CameraParams settings. If the camera settings are supposed to adjust after sitting, it may be simpler to clear those persistent prim properties and use only the CameraParams approach.

[Lucia Nightfire]

llSetCameraAtOffset() and llSetCameraEyeOffset() should already be declared before anyone sits, not in the run_time_permissions() event.

These are used mainly to establish an initial camera angle on sit.

If only furniture makers actually bothered to use them so the camera doesn't go behind a wall when you sit on a bed...

[EnCore Mayne]

excellent results from all of you, once again. i thank the community for its wealth of knowledge. i now perfectly understand the addressed phenomenon. i am your humble servant.

for anyone still wondering, i crafted this routine to automate the setcamera vectors. it works for that so i'm saved from the indomitable brain crushing mathematics of figuring them out manually. thinking that i had a world changer for healing (heeling?) the backwards default camera pose position (who thought of that?) will have to wait. explaining the potential wild behaviour to a prospective user would inevitably have them weighing convenience against complicated incomprehensible details.

nonetheless, i'm happy with what i hath wrought. if my life's made happier, isn't everyone's?

btw, cudos to the nameless faceless entity who's corrected the wiki formatting. have the gatekeepers been vanquished? might normal people be given the privilege to add/edit pages next?