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 <[email protected]> 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 < > [email protected] > >> 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 > >> [email protected] > >> https://lists.berlios.de/**mailman/listinfo/opensim-dev< > https://lists.berlios.de/mailman/listinfo/opensim-dev> > >> > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > [email protected] > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev >
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
