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
