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

[Melanie]

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