i say fix it and let the chips fall where they may<br><br><div class="gmail_quote">On Fri, Dec 2, 2011 at 3:55 PM, Justin Clark-Casey <span dir="ltr"><<a href="mailto:jjustincc@googlemail.com">jjustincc@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">OpenSimulator commit b6df9e9 (dev code) changed the sit target adjustment to better match that used in Second Life.<br>

<br>
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).<br>
<br>
>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.<br>

<br>
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<br>

<br>
1.  Change sit adjustment with no other action.<br>
PROS: llSitTarget() is now implemented correctly.  No legacy mess in the code.  No extra complexity required.  No development work required.<br>
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.<br>

<br>
2.  Provide a tool to correct sit values in scripts<br>
CONS: Too difficult since requires massive amount of script analysis.  Might be possible in a limited way to catch 80/20 cases.<br>
<br>
3.  Use different sit adjustment depending on prim creation date (pre Sat 5 Nov 2011 use old value).<br>
PROS: Stops older sit positions from being wrong.  Doesn't require much code change.<br>
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.<br>

<br>
4.  Revert llSitTarget() behave and create an osSitTarget() using the new adjustment instead.<br>
PROS: All existing sit targets continue to be 'correct', and old scripts still work correctly in new objects.<br>
CONS: llSitTarget() remains wrong for all time (could warn on use and eventually change, but users don't pay attention to such warnings).<br>
<br>
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.<br>
PROS: Works invisibly as long as old scripts don't set new values.<br>
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.<br>
<br>
6.  Provide a config switch to use old sit adjustment or new.<br>
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.<br>

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.<br>
<br>
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).<br>

<br>
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.<br>

<br>
However, I'm certainly happy to hear alternative opinions or well-researched and intelligent alternative proposals.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Justin Clark-Casey (justincc)<br>
<a href="http://justincc.org/blog" target="_blank">http://justincc.org/blog</a><br>
<a href="http://twitter.com/justincc" target="_blank">http://twitter.com/justincc</a><br>
______________________________<u></u>_________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-dev</a><br>
</font></span></blockquote></div><br>