-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue with numbered seats (design flaw) #29
Comments
But is there something that we could do to change this? |
Is it possible to distinguish which prim is touched? This would be the only alternative I can think of to determine where the new sitter intended to sit. Also a thought, if we could possibly use llDetectedTouchST to determine where the sitter intended to sit on a single prim build. I find this discovery very enlightening as I've always assumed that the sit target played a roll in sitting a new sitter. In fact there is a sit engine that changes the sit target position to the existing seat position when a new sitter sits (I assume a smoother sit experience). However, I have also seen where many new sitters can successfully sit a single mesh prim if the physics layer of the mesh is set up correctly. |
No, there isn't anything that fires before the sitting is completed and only the change event that fires after.
yes it could be smoother for a new sitter. In nPose a new sitter "jumps" to the next free sitTarget but the sitTarget is not at the final sitting position, so there is a second "jump" when the avatar is moved to his final position (by nPose). This second "jump" could be removed (reduced) if the sitTarget is at (or near) the final position. But of course we can not remove this second "jump" if ther are more sitters than sitTarget.
This is my view of how sitting works in SL. It is a "model" gathered from different sources in the internet as well as different observations I made. It may be completly wrong.
|
All works well if the numbered seats are used, the problem arises if the numbered seats are not used and new sitters click the root prim to sit. Here's what happens:
The first sitter will sit as usual and uses the root prims sit target (link number 1).
The second sitter is assigned to the sit target in link number 2. All is well if link number 2 prim is not numbered or is numbered for seat 2. However if this linked prim is using numbered seats and this particular prim with link number 2 is using seat 3, then the sitter will be assigned to seat 3.
The third sitter is assigned to the sit target in link number 3. Same story as with the second sitter. It can work or it will be messed up depending on the seat numbering.
((The same issue occurs in SL and on OS where it was discovered.))
The text was updated successfully, but these errors were encountered: