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

Mic Bowman cmickeyb at gmail.com
Mon Dec 5 17:11:33 UTC 2011


This is a good fix (thanks for doing it Melanie!). And, so long as it isn't
back-patched into an existing release, only affects people when they
upgrade to the *next* release (or those who track daily... and they get
what you would expect... daily changes).

--mic


On Sun, Dec 4, 2011 at 11:42 PM, Melanie <melanie at t-data.com> wrote:

> As I am the one who did it, +1 on leaving it fixed. Items can be
> fixed and copy/paste compatibility for new objects coming in from sl
> is more important, IMHO.
>
> Melanie
>
> On 05/12/2011 04:14, Trinity wrote:
> > 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>
> >>
> >
> >
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20111205/48b1d708/attachment-0001.html>


More information about the Opensim-dev mailing list