Sunday, 3 January 2016

Paramour Product Support for Opensim 0.9

With an increasing number of people now using the Opensim 0.9 development branch (including the Opensim download) I guess I need to make some sort of comment about the products I make and how they will be supported since I'm constantly getting flooded with IMs when I'm in-world.

Opensim 0.9 is a highly unstable, untested development branch where it is currently the practice to drop commits directly to master and "see what happens" in terms of reports coming back to the developers. Things are in constant flux and many functions/features of Opensim that work perfectly under 0.8.2 and earlier are now broken or altered.

Affected Paramour Freebie Products


For my Paramour products I am already aware of a variety of serious affects that either completely break functionality or result in unintended/faulty behaviour. There may be additional issues that I'm not yet aware or, or more things may cease to function with future commits to 0.9. The ones I'm aware of are as follows:

Paramour Dancemaster Dance Ball

My danceball system, which is widely used throughout the metaverse, will not perform as intended under 0.9, although depending on your region configuration the differences may be minor. Known affects are:
  • Couples dance positions are all wrong.

    Cause: this occurs because 0.9 appears to have arbitrarily reverted the sit target offset back to the old base root value instead of the one that was implemented in the code in 2012. At that time there was much public furor which was met with assurances from the development team that it was essential in order to be "more like SL" and that they anticipated no further changes to sit target positioning would be implemented in future. No cogent explanation has been given for changing it again in 0.9 (or not that I've heard).

    Fix: you can do one of 2 things:
    • edit all couples dance positions to get them correctly positioned for use in your region either by using the dance system's built-in live position editor or by applying approximately a 0.15m global z-axis offset to each in the couples dances (both male and female positions) in the couples data notecard.
    • edit the script to have it adjust all couples position/rotation calculations to adapt to this global z offset on the fly (although this will result in a slight increase in the resources used during operation).
     
  • NPCs fail to rez

    Cause: this is probably due to the changes in Opensim.ini [NPC] section configurations and/or changes to the osslenable.ini files that were introduced in 0.9 and that weren't appropriately updated by your region manager at the time the new patch was applied.

    Fix: Please ask your region manager to consult the Opensim documentation to determine and make the necessary changes in the two ini files. They should contact the development team directly for support if the documentation fails to supply sufficient information.
     
  • NPCs rez but won't sit...instead they are sent hurtling to the edge of the parcel/region and the only thing you can do after that is kill them.

    Cause: parcel access permission handlings has been changed in 0.9 and currently causes it to attempt to "evict" a NPC unless the region is set to full public access. Since the NPC has no home location to send it to, the fall-back behaviour is to forcibly push them to the nearest parcel border.

    Fix #1: set your parcel to full public access

    Fix #2: in parcels that are set for group access only and are running a version of Opensim 0.9 built from commits made after Jan 2, 2016 there is now a flag that can be set for NPCs when they're created that will give them the same group as the rezzing object (in this case, the danceball). You will need to edit the master danceball script to have it set this flag in the creation call for both male and female NPCs and then ensure that your danceball is set to the parcel's group. It should stop evicting your NPCs after this.

    Fix #3: if you're using an earlier verison of 0.9 in a parcel with group access, or you use per-user parcel access, I am not aware of any fix for it other than to not use NPCs or to temporarily open the parcel to public access when the danceball is in use.
     
  • Danceball never finishes the initialization set when reset.

    Cause: Opensim 0.9 has changed the way Opensim works in a Windows environment and for regions where Opensim.ini [XEngine] section has AppDomainLoading set to true (which was the recommended setting for Windows under 0.8.x) this can result in a drastic reduction in script performance and speeds. Instead of the old ~5-10 second initialization times, this may result in the initialization taking considerably more than the default 30 seconds allowed for an event to process and results in the script silently aborting state_entry.

    Fix #1: As your region manager to change AppDomainLoading to false in Opensim.ini. This will cause Opensim to use a lot more memory than before, increasing as more scripts are run,  so you should also ask for your region to be given a regular shut down and restart to prevent excessive memory bloat. Note that the entire Opensim instance has to be shut down and restared to free up the memory...simply restarting the region will not do so.

    Fix #2: An alternative is to leave AppDomainLoading=true and to ask your region manager to change the event time limit instead. This can be done by setting the variable EventLimit (in the [XEngine section] to a much higher value. Try something like 120 or even 180 seconds and this should give the initialization enough time to complete under the new code and will still allow .NET to reclaim the memory again later. Unfortunately this won't make the initialization go back to the very short times you're used to under 0.8.2...it can take in excess of 2 minutes to reset depending on the hardware and software environment.

    Fix #3: A third alternative is to edit the script and completely remove all the error checking and fixing that I implemented as a way to help users be able to make changes to their system without it running into problems unless they really messed up the changes. The out-of-the-box set-up I supply with it will work perfectly without the checks and will initialize extremely quickly (<2 sec) but if you make any changes at all to it then you'll need to ensure that you precisely meet the expected data inputs or the entire system may cease to work or may throw assorted errors.

Paramour Multi-Animation Controller (PMAC)

This will experience ALL of the same issues that the Dancemaster system is subject to for positions and NPC evictions. The fixes are the same...redo all of your positions or edit the script to add a global z-offset to them all, and use one of the methods outlined above to allow NPCs not to be evicted. If you run your region under .NET you will probably need to switch to AppDomainLoading=false and do regular simulator restarts to control memory bloat in busy regions.

Paramour Polemaster Multi-Person Dance Pole

The dance pole system should work properly under 0.9 with the exception that:
  • all dancer positions are incorrect

    Cause: this due to the same changes that affect couples positions for the danceball

    Fix: for this item you can simply open the script and adjust the globalOffset vector in line 12 until you're dancing at the correct height again. The change will probably be approximately 0.15m on the (global) z-axis.

Paramour Private Dancer Floor Stage

This should work except:
  • all dancer positions are incorrect

    Cause: this due to the same changes that affect couples positions for the danceball

    Fix: for this item you can simply open the script and adjust the sitPos vector in line 80 until you're dancing at the correct height again. The change will probably be approximately 0.15m on the (global) z-axis.

Paramour  Table Dancer System

This should work except:
  • all dancer positions are incorrect

    Cause: this due to the same changes that affect couples positions for the danceball

    Fix: for this item you can simply open the script and adjust the pos vector in line 7 until you're dancing at the correct height again. The change will probably be approximately 0.15m on the (global) z-axis.

Paramour  Chair Dancer System

This should work except:
  • all dancer positions are incorrect

    Cause: this due to the same changes that affect couples positions for the danceball

    Fix: for this item you can simply open the script and adjust the vector in the sit target function in line 8 until you're dancing at the correct height again. The change will probably be approximately 0.15m on the (global) z-axis.

Paramour Line Dance Floor

This should work except:
  • all dancer positions are incorrect

    Cause: this due to the same changes that affect couples positions for the danceball

    Fix: you'll need to edit the object and adjust the position of the floor prim relative to the (invisible) root controller prim above it until you're dancing at the correct height. The change will probably be approximately 0.15m o n the (global) z-axis.

Paramour Rez & Pose Script or any other NPC Script

If your parcel isn't set to public access you will need to follow the instructions I supplied above for NPCs with the Dancemaster system to prevent having your NPCs evicted.

Why "Approximately 0.15m" for those Z-Axis Offsets?

Because I'm not sure exactly how or why the change was made or how the new calculations are being done in the code, and because there is no documentation for it, and because I wasn't given an answer when I asked, I can only say that most of my testing seems to suggest this value. I haven't tested it exhaustively for all possible avatar shapes/heights (which affect positions too) so the variance may be different for other users. I'm just suggesting 0.15m as a reasonable starting point that looked about right for the handful of items that I did my limited testing with, prior to deciding to revert my regions to 0.8.2.

Hey...Why Aren't You Doing the Fixing of this Stuff, Aine?

After reading all of that, you might be wondering why you should have to do all of that work instead of me doing it all for you, particularly because some of it involves hours and hours of redoing position data, not to mention a few cases of non-trivial script editing or adjusting of script values (which not everyone is comfortable doing).

There are a few reasons:
  1. My products work perfectly under 0.8.2 (and earlier) which is still the most recent "official" release of Opensim. That's what I have reverted to and will continue to use, at least for the foreseeable future. As such, I'm supporting what I should be expected to support (and I don't make support guarantees anyway).
     
  2. Development of 0.9 is currently occurring in such a rapid, hap-hazard way that I have absolutely zero interest in devoting what will likely be over 100 hours of my time to rewrite and redo everything, only to have yet another seemingly arbitrary change be made in master branch that forces me to do it all over again and again and again.

    If at some point Opensim appears to be relatively stable again and I have some reasonable expectation that the development team won't be further altering/breaking things; I might consider devoting the necessary time to provide an update version of each.  I will only do so if I'm able make changes that are compatible with and support the existing 0.8.x user base as well, though (unless, at the time, the vast majority of the Metaverse is no longer using 0.8.x).
     
  3. Some of the changes are undocumented and would require significant time devoted to testing to determine exactly how best to "fix" things for broad public use. You can skip that if you're doing a custom object for your own use, instead of trying to make the best possible one-size-fits-all product.
     
  4. Creating things and making them available to the public is my "recreation" activity. not my business, so when it isn't fun -- when it just feel like completely unnecessary extra work forced upon me at the whim of a development team that has very little consideration for existing content or content creators -- it's really hard to generate the necessary enthusiasm to spend all that time "fixing" things.

    Personally, I'll be staying on 0.8.2 for as long as I can and I may cease to make any new items I create available to the public except for things that aren't subject to the these differences/changes. If Opensim continues down the road it appears to be heading, I will probably switch to using Unreal 4 or Unity 5 as my environment instead.
     
  5. I'd feel a lot more guilty about it if I didn't give all of these things away for free.

I Need Support/Want To Complain

Because I will no longer be running 0.9, doing any testing of it, attending dev meetings, etc., I won't be able to offer any meaningful support for regions running under 0.9. The developers will be aware of which functions and Opensim features they have changed and should know how to fix the content that has been broken by those alterations so you could see if they've supplied any documentation for it or ask them directly. Failing that, perhaps your region manager will be able to assist you. If neither of those are able to help, I'd suggest reverting to 0.8.2 until such time as 0.9 is stable and supported.

If you -- like me -- feel that there is insufficient consideration being given to making changes that break existing content or are dismayed about the burden it places on content creators to now have to make two (or more!) versions of everything (including renting multiple regions to be able to test and develop for both) you should raise these concerns publicly and/or with the development team. Perhaps they'd be more receptive to these pleas if they realized that it's not just Aine bitching about something and it's actually a much, much larger user base that's being adversely affected and isn't very happy about it.

And if you think this entire post is just a thinly veiled rant...well, perhaps it is. But at least in addition to bitching I'm also identifying exactly which of my products are broken (so far...more may come), and giving the reason why, and indicating how best to probably go about fixing them.

Also keep in mind that I've only outlined the changes that affect the things I've been giving away...there are other changes to the code that (so far) detrimentally impact simulator performance (reverting some of Justin's OSCC2014 optimizations, etc) so this is only one element of it. It's too bad because there are some really nice features in 0.9 and ubOde too.

Edit

One thing I neglected to mention...lest you think this is just Aine pissed off because some changes broke her stuff, you should be aware that these exact same changes will break all existing MLP systems, all furniture/items that have sit targets or use position scripts, and all scripts that involve rezzing NPCs (eg. Ferd's excellent NPC controller system). It's not just the content I created that's being trashed...it's a very, very large percentage of commonly used objects.