[Opensim-dev] Sit position changes in OpenSimulator b6df9e9 (Sat 5th Nov 2011)

[Dahlia Trimble]

In SL, sitting behavior differs between objects which have a sit target set
and those which do not. When a sit target is set, sitting will occur
immediately when an object is selected and "Sit" is chosen from the menu,
even from a large distance. For default sit positions distance appears to
have an effect, the avatar must be close to the object or the sit is
ignored or fails.

The suggested existence of an unset sit target state offers another
alternative: don't change any sit target properties in a prim, rather alter
the sitting procedure to compute a sit target on the fly if no target has
been explicitly set in the object. Setting it on the fly could offer
additional benefits, such as a future enhancement to allow multiple sitters
on a single larger object with no preset targets.



On Fri, Dec 2, 2011 at 1:55 PM, Justin Clark-Casey <jjustincc at googlemail.com
> wrote:

> OpenSimulator commit b6df9e9 (dev code) changed the sit target adjustment
> to better match that used in Second Life.
>
> Unfortunately, this has the effect of making all existing sit positions
> set by scripts using llSitTarget() inaccurate (e.g. avatar ends up hovering
> above a chair).
>
> From a user/scripter point of view this is a bad thing.  Not only do
> existing objects with user inventory/prim inventory now have wrong values,
> but positions loaded from OARs/IARs will now be wrong without adjustment,
> and OARs/IARs saved in dev code or future 0.7.3 will have wrong sit values
> when loaded into older OpenSim releases.
>
> However, I believe that's it's practically impossible to have old objects
> correctly use the old sit adjustment and new objects the new one.  Here are
> the alternative courses of action and my considered pros/cons of each
>
> 1.  Change sit adjustment with no other action.
> PROS: llSitTarget() is now implemented correctly.  No legacy mess in the
> code.  No extra complexity required.  No development work required.
> CONS: Without adjustment, all region, inventory objects and scripts now
> use wrong sit values.  Wrong sit values in OARs and IARs.  Wrong sit values
> when OARs/IARs/objects moved between dev/future 0.7.3 versions and older
> OpenSim versions.
>
> 2.  Provide a tool to correct sit values in scripts
> CONS: Too difficult since requires massive amount of script analysis.
>  Might be possible in a limited way to catch 80/20 cases.
>
> 3.  Use different sit adjustment depending on prim creation date (pre Sat
> 5 Nov 2011 use old value).
> PROS: Stops older sit positions from being wrong.  Doesn't require much
> code change.
> CONS: A user has to know an opaque magic date when the sit position
> changed.  Somewhat messy legacy code.  Future upgraders from 0.7.2 will get
> some prims with 'wrong' sit positions and others with 'right' depending on
> when they were created, which is in the long term possibly more confusing
> than everything needing adjustment.
>
> 4.  Revert llSitTarget() behave and create an osSitTarget() using the new
> adjustment instead.
> PROS: All existing sit targets continue to be 'correct', and old scripts
> still work correctly in new objects.
> CONS: llSitTarget() remains wrong for all time (could warn on use and
> eventually change, but users don't pay attention to such warnings).
>
> 5.  Store new sit positions in a different field on SOP and use this if
> present with new sit adjustment, otherwise use old field with old sit
> adjustment.
> PROS: Works invisibly as long as old scripts don't set new values.
> CONS: Messy legacy code.  Old scripts probably will set new values - then
> would need to act differently on script item creation date, with same
> issues as 3.
>
> 6.  Provide a config switch to use old sit adjustment or new.
> PROS: Administrator controllable.  In a future OpenSim release, admin can
> decide when they are going to flip to using the 'new' value.  This might be
> done anyway for the use case where OpenSim is being used with content in
> isolation from elsewhere.
> CONS: Encourages the creation of more objects using the old sit values,
> encouraging a continuous mix of old and new values which can't both be used
> on the same region.
>
> Doubtless there are other strategies, but on the face of it there doesn't
> seem to be an ideal solution.  It's made much more difficult by the fact
> that these values can only be scripts rather than as properties on the part
> (a decision which I find hard to swallow).
>
> On the whole, I think that it's better to accept the pain of change as
> early as possible and move to a world where all values are correct rather
> than remain with one where things are incorrect or a mish-mash in the long
> term.  As I said to Akira, the alpha nature of OpenSim is meant to be a
> signal that these things can change as bugs are fixed.
>
> However, I'm certainly happy to hear alternative opinions or
> well-researched and intelligent alternative proposals.
>
> --
> Justin Clark-Casey (justincc)
> http://justincc.org/blog
> http://twitter.com/justincc
> ______________________________**_________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20111205/5b060135/attachment-0001.html>