llForceMouselook()

While I think this is extremely handy, as it works now seems either borked, or not as useful as it could be. I was playing around in preview with a vehicle I have been working on, and I changed the script to use mouselook banking for steering it. I then went to use llForceMouselook() to cause the driver to enter mouselook upon sitting on the vehicle. This works if and only if the driver right clicks on the prim that the sit target / script are in. While this is nice, it would be nice to have it work similar to sit targets. What I mean by this is, if you have 2 sit targets for a vehicle, and the root prim has the target for the driver, and the second prim in the linkset has the passenger sit target, the first person to sit on the vehicle ends up in the driver location, the second in the passenger. There are some exceptions to this, but for the most part, this is how things work. I think the force mouselook should be effective anytime an avatar sits on the associated sit target, regardless of which prim in the linkset was used to sit down.

Just some thoughts,
McW

Another nice lil touch would be to add a function to determine if the user is in mouselook. This would be handy for vechiles as well as attachments. Vehicles could automatically update their parameters for mouselook control or standard key control. Even better yet, how about an event that's fired when mouselook is entered or exited. Just another random idea.

McW

Good feedback, I'll pass it along.

Thanks for the heads up on the llGetAgentData updates. I read through the changes, but obviously forgot about that particular new feature.

After doing some tests in both 1.5 and the 1.6 preview, here is what I have determined about the llSetCameraXXOffset functions, and llSitTarget.

(Test was 3 cubes, two of which had sit targets and different camera offsets, the 3rd cube was empty. They were linked such that the two with scripts were the root and first child of the link set.)

User 1 (first person to sit on the empty object)
User 2 (second person to sit on object, after User 1 is seated)

- User 1 can use the root prim or other prims without sit targets, and they will sit in the first sit target location, and receive the root prim camera offset.
- If User 1 sits on the second prim in the test case, they get the second sit target and camera offset.
- User 2 can sit on either of the two remaining prims and get the second sit target. User 2 will have the same camera offset as User 1 unless they specifically click on the first child prim, containing the 2nd sit target and camera offset.

I know this is a little confusing, but after testing, the prim with the lowest link number seems to take precedence for the entire linkset as far as camera offsets are concerned. The only exception being if a prim with a higher link number sets a different offset, and a user explicitly clicks on that prim to sit down. Given this behavior, it would be nice for the llForceMouselook to work in a similar manner. Currently, the only way it forces mouse look is with an explicit click on the prim containing it. The problem arises when the root and child prims have differing settings.

Ideally the way things should work, would be, if a user comes along, and sits on a linkset, they are automatically placed on the lowest empty link number's sit target, they would also get that prims camera offset and/or mouselook behavior. If all sit targets are full for the linkset, sit behavior would then work like it does with normal prims. The exception to the above would be if a user explicitly clicks on a prim with a sit target that is not the lowest empty link. In this case they should take on all attributes of that particular prim. This exception is required for furniture and the like. The chaining behavior is most useful for vehicles.

This reminds me.

Has the sim-crossing mouselook bug been fixed yet? Sometimes when crossing sims, the mouselook camera ends up facing the wrong direction and mouselook steering gets completely borked until you exit mouselook steering or exit the vehicle. This bug in conjunction with llForceMouselook() would have even uglier consequences.

I don't remember off the top of my head, but I am pretty sure I have only seen this mouselook bug (lately) when using the decoupled camera, and I can provide LL a vehicle that replicates the problem fairly consistently in 1.5 if necessary.

Kelly, I think that solution will more closely match the camera offset functionality. Thank you for taking the time to discuss this internally, and providing feedback to the community.

Is there any hope that we could expect camera offsets and mouselook to work like sit targets do at some point? Meaning that if I have a 27 prim link set with four prims containing sit targets, camera offsets, and mouselook settings, if I 'sit' on the linkset without using one of the 4 prims with settings, I am put on the lowest link number with a sit target. The second person gets the second lowest link number with a sit target, etc. It would be nice for the camera offsets and mouselook settings to work in this manor as well. Again with an explicit click on for instance the 3rd lowest link number prim with a sit target taking precedence over the lowest. This seems like the most logical way for these things to be implemented.

One other thing. I understand that we can now query to see if a user is in mouselook or not, but as far as items that would most likely use this feature, wouldn't it make more sense if it was implemented as something like mouselook_start(key id) and mouselook_end(key id) or even rolled into changed(integer change)? The reason I mention this, is that items that would most likely use this functionality, would be attachments and vehicles. While we can set up a timer and poll to see if an avatar is in mouselook or not, it would be a lot more efficient if the script was notified of changes. This would obviously be limited to attached objects, or objects that are being sat upon by the avatar. My main example for this would be custom animations for attachments (think guns, swords, etc) that would override both holding and 'aiming' animations, or vehicles that can dynamically change settings between arrow steering and mouselook steering based on the user state. Again, I think a timed poll to monitor the state would be a much bigger hit on sim resources than updated/new event routines. Just my silly ramblings on the subject.

Best Regards,
McW

Although I haven't done extensive testing Apotheus, the vehicle I was using in preview was utilizing both mouselook banking and a decoupled camera. I didn't have any problems with sim border crossings and the camera being aimed in the wrong direction, however I did notice that when sitting on the vehicle with the llForceMouselook(TRUE), sometimes the camera would be pointing backwards initially. Once pointed forward, everything seemed to work as expected. I will do some further testing though, and see if I can give definitive answers regarding this.

McW