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

[Trinity]

i say fix it and let the chips fall where they may

On Fri, Dec 2, 2011 at 3: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/20111204/08151f69/attachment-0001.html>