Thursday, 28 January 2016

NOTICE: Getting help with any of my products

In the last few days I've had several dozen people contact me for help with their new danceball system and I've been unable to reply to them because they haven't identified who they were or what grid they were from.

When you need support on something I've made please follow this checklist:
  1. Did you read and try the solutions in the READ ME notecard? If you didn't please do that first since it answers almost all of the questions and provides most of the common solutions. If there isn't a read-me notecard in the product, open the script and look at the red commented text at the top instead...that's where I'll put instructions.
  2. Are you POSITIVE that OSSL is set up correctly for you in your region? If you're seeing a script error message popping up that mentions permissions as I've highlighted in the following, it means you DON'T have OSSL permissions set correctly and need to contact whoever administers your region's server. Here's a typical OSSL configuration/permission error message:
    System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> OpenSim.Region.ScriptEngine.Shared.ScriptException: OSSL Runtime Error: osGetNotecard permission denied.  Allowed threat level is VeryLow but function threat level is VeryHigh.?
    ...then a bunch of path details that will vary...
    The message might be a little different than this, but if the beginning part of it talks about permissions there's something wrong in your region's set-up and I CANNOT help you with that because it varies a little depending on your region's set-up.

    The details necessary to set OSSL correctly are in the READ ME notecard included inside the box and inside the danceball itself...give a copy of this to your server manager.
  3. If you're not seeing any script error messages, are you seeing any messages from the ball in chat? If so, they ought to be telling you what the ball thinks is wrong.
  4. AFTER CHECKING ALL OF THE ABOVE and making sure that it's really a problem that needs my direct help, please contact me either via IM or by sending me a notecard. To do either of these, you need to HTTP to RefugeGrid first, then send it. You can get here by doing a map search for "" and teleport to the destination that comes up on your map (or you can do so from my Shopping Region or from my Hedonism club, both of which are also in RefugeGrid).

    When you do so:

    • Tell me your name! Messages and notecards will very frequently arrive showing the sender as "unknown user" or "loading...." and any attempt I make to reply to you will fail. If I don't know who are are and what grid you're from, I can't help you. Yes, even IMs can arrive this way and, sadly, I'm not a psychic.
    • Tell me what grid you're from and ideally the HG entry address for your grid. The only way I can reliably reply to you is if I HGTP to your grid and I can't do that if I don't know where you're from or how to get there. With major grids I will probably know how to get there anyway, but it's still handy if you tell me so I don't have to go look it up. Even better, give me a landmark.
    • Be specific in telling me what problem you're experiencing. Saying "I have a problem" and supplying no details doesn't let me help you in a meaningful way. It also makes me think that you haven't read the READ ME notecard because it says exactly the same thing, which makes me assume that you haven't tried any of the solutions to common problems there, either. If you can't make the effort to help yourself first, why should you expect me to?
    • Even if I appear to be online, please understand that I might be afk and not able reply; or I may be HGed elsewhere an unable to reply; or I may be in the midst of something else and can't just drop what I'm doing to help you. If you aren't speaking to me face-to-face there's always a chance I won't receive it at all. If I haven't gotten back to you within a day or so, I might not even have received your message so try again, politely.
By doing the above you'll make it much easier to help you.

Thank you.

Monday, 25 January 2016

TUTORIAL: Singles NPC dancers for the Paramour Clubmaster 2.0 danceball

One of the new features of the Paramour Clubmaster v2.0 Danceball is the ability for NPCs to use its new group dance capability. This tutorial covers the basics for doing this.

The most likely use would be to make the danceball work as a group choreography controller for a troup of NPC dancers but there are tons of  other possible applications.

To do this, you need one or more external (separate) NPC handler scripts that are responsible for rezzing the NPC(s) and having them touch the ball. When an NPC touches it, it will immediately begin to play the current group dance. Having the NPC touch it again will stop the NPC from dancing and return it to its default SL standing animation.

If you're rezzing multiple NPCs and having them touch the ball, it will be close to impossible to arrange for them all to touch the ball simultaneously so as each one joins the group dance they'll be out of synch until the group's dance animation advances to the next one (by default it changes every 120 seconds) at which point they'll all be in synch.

The approach for a basic external script is:
  • have a separate prim for the NPC with a touch activation
  • either supply that prim with the UUID of the danceball as a constant, or use a sensor event or other method to "look around" for the dancemaster ball and store its UUID. This is needed for the function that instructs the NPC to touch the ball
  • on touch, rez the NPC either by cloning the toucher or using a notecard from its inventory
  • have it touch the danceball
  • on subsequent touch of the NPC's prim, have the NPC touch the danceball again, then kill the NPC (or have it do something else if you want)
At its most basic, here is a script you can put in a prim as a sample

key npc=NULL_KEY;
key target="98c4f104-5ddb-4090-a6d9-8f1d4418656b";  // replace this with the key of your danceball
key user=NULL_KEY;
string emptyText="NPC singles dancer test\nTouch to rez a NPC clone\nof yourself to join the group dance\nTouch again to kill it";
    touch_start(integer num)
        if (npc==NULL_KEY) // no NPC currently rezzed
            // rez new NPC by cloning toucher
            npc=osNpcCreate("NPC","Dancer",llGetPos(),user,8);  // 8 = NPC Group owned
            // give it a moment to come into existence and start its basic stand animation
            // have it touch the dance ball
            llSetText("Currently in use by: "+llKey2Name(user),<0,1,0>,1);
        else if ((llDetectedKey(0)==user)||(llDetectedKey(0)==llGetOwner()))// kill the current NPC
            // have it touch the danceball first so the ball knows it wants to stop dancing (the ball will detect this within a couple minutes if you forget to do this)
            // then kill NPC and zero the key again, ready for re-use

MAJOR RELEASE: Paramour Clubmaster v2.0 Dance Machine

It gives me great pleasure to announce the official release of the new Paramour Clubmaster v2.0 updated version of the very popular club danceball system found in countless regions throughout the Metaverse.

This new version is the culmination of a couple months of work.....I spent most of December on updating the original danceball script to be as compatible with the changes made in Opensim 0.9 without breaking functionality for the many people (myself included) who use the official Opensim release. While I was at it, I added a number of new features that I'd been thinking about adding, or that people had requested and could be accommodated without impacting the key feature of being a single-script multi-purpose system ideally suited to a very high traffic club setting.

I began testing the new version at our RefugeGrid parties in January, and after squishing a few little bugs I'm happy to say that the last 5 tests (including last night's 48-person stress test) haven't uncovered any new bugs at all so with any luck it should work perfectly for almost all of you.

What's New in Version 2.0

Here's a very quick summary of what's new:
  • Group Dance: you can now set one of the singles dance styles as the group dance, and your guests can simply touch the danceball, pick "GROUP" from the menu, and they'll join the dance. Everyone using group will be using the same animation and kept in synch (synch updates every 2 minutes so when they first join they'll be out of synch for the first minute or two).
  • Expanded Singles Dances: version 2.0 of the dance ball now allows for an unlimited number of different singles dance styles, and the system comes with more than 500 singles dance animations (more than 300 new ones added since v1.x) and works the same way it always has. You'll find that the singles styles menu now has three pages to it...
    • the ones on the first page are general purpose/club dances
    • the ones on the second page are a little more flirty or burlesque or special focus
    • the two on the last page are more...explicit
    As was the case with the previous version, you can add or remove any of these fairly simply.
  • Couples Dance Global Offset: there is now a setting in the main script that allows you to assign a global z-axis offset that will be applied to all couples dances, correcting for the change to sit targets made in the latest developer code. This allows you to adjust the height of all couples dancers to get their feet positioned more or less correctly on the floor. People using Opensim 0.8.x can use the default 0.0 offset. People running under Opensim 0.9 will need to experiment with adjusting this value. I suggest a good approximate starting point of -0.15 which seemed about right in my tests. Obviously this is subject to any further changes made by the developers.
  • Easier NPC Handling: In the versoion 1.x system you had to manually edit the script to add and remove NPCs from the danceball. Many people found this a bit intimidating so I have reworked the way NPCs are handled. Now, you simply have to start their notecard names with a specific special text string (.NPCM for male, .NPCF for female) and the dancemaster system automatically builds the lists for you during initialization. That means you can now just add a correctly-named appearance notecard, or delete and existing card, then reset the script and it's all done automatically for you!

    You can also change those special strings with a simple edit to the basic user settings in the script. This allows you to have multiple different sets of NPCs in your danceball, named for for different occasions, then simply assign the set you want you use in the script and reset.

    For example, in my own I have a set of .NPCM/.NPCF cards for daily use; then another set that all have names starting with .LingerieM or change between them I just make a quick edit to the setting in the script and they're ready to dance!
  • Faster Initialization: I have now made all of the detailed error-checking and contents analysis of the old system an option set in the script. It's off by default because I have carefully ensured that my setup is correct, so this greatly reduces the time taken for the system to reset (under 2 seconds and usually under 1 second). If you make any edits you can enabled error-checking and let it double-check your work, then switch it back off again once you've made any corrections.

    People using the new 0.9 development code under .NET may experience issues where initialization with error-checking will hang and never complete because for some systems it appears to take 100+ seconds to execute on the same set of instructions that used to take <10 seconds under 0.8.x and the default Opensim limit to an event's procession time is 30 seconds. I've included a detailed work-around to let you use this...see the included READ ME notecard for details.
  • Custom NPCs: The new version 2.0 now allows you to include an optional configuration notecard with a list of one or more user UUIDs and their preferred NPC dance partner. When someone picks NPC Couples and sits, if they're in that list they will always be given their preferred NPC as their partner but they can always use the NEW M or NEW F option to dance with different ones.

    One additional "perk" to this is that you can assign any valid NPC appearance notecard name (that's in the ball's inventory) as a person's preferred partner, even if it doesn't conform to the special naming convention introduced above. This means I can have it set up to give me a NPC as my partner that nobody else can get.

    The version I supply of the danceball includes a sample configuration notecard to get you started and you can simply leave it in there or edit it as desired. You can delete it too, without any issues.
  • Extended NPC Support: I've added the provision for NPCs that are rezzed and controlled by other (external) scripts to be able to touch the danceball at which point they will join the group dance. Commanding the NPC to touch the ball again will have it stop dancing. Those commands are all ones to be handled by an external script such as Ferd's excellent NPC controller system.
  • New NPCs: The new system comes with all of the old version's NPCs, as well as a number of new NPCs that I've made and even more that were very kindly donated by various people from around the Metaverse. Some of these will probably not display correctly for people who are residents of smaller grids that have never encountered those assets before but you can simply delete any that don't work for you and add your own.
  • Parcel Group Permission Compatibility: Opensim 0.9 has made major changes to the way that parcel access permissions are handled which will break version 1.x  of my ball if the parcel is set to group access. NPCs will be evicted and poseballs may refuse to rez for couples in general.

    I have applied a fix for this to change the method used for NPC rezzing while still keeping my system fully compatible with Opensim 0.8.x simulators. NPCs shouldn't be evicted any longer from 0.9 parcels unless there are further code changes. If you're running with group parcel access or script permissions limits, please be sure to set the main danceball's group to match the allowed group, too.
  • New Danceball and Poseball Objects: I made a new version of the mesh for both the main danceball and the poseball to reduce their poly count and make them easier to spot from a distance. They're now only a single prim (instead of each being 2) to reduce the LI for grids that use LI.
  • Script Improvements: I also made a small number of further refinements to the script in both the main danceball and in the poseball that make them even more efficient than before. In my testing it uses about 10% fewer resources than the v1.x system under the same circumstances.

    I added a few new attempts to "trap" the occasional case where asynchronous handling of scripts by the region would cause it to generate an OSSL error message. It is still possible that you'll see the occasional one, depending on your region's server and how busy your party is, but hopefully they'll be less common that was the case with version 1.x. I can't completely eliminate this, though...that would require major surgery to the Opensim code itself and the error message doesn't cause the system to stop working.
  • Bug Fixes: The 1.3 version had two very small semi-bugs in it that didn't actually affect performance at all but I fixed them anyway in case they causes issues at some point in future Opensim releases. I fixed a case where regions that don't recompile scripts on start-up would still purge any stranded poseballs (although it should be impossible to strand a poseball unless the entire region crashes during operation) and a case where a list look-up was type-casted incorrectly (which still worked but might not if casting handling is changed in the main code).

Where Do I Get It?

The complete system is available, boxed, from my shopping region. Simply HGTP to RefugeGrid and take the local portal to Paramour Shopping; or you can HGTP there directly using:
  • Shopping
You'll find it in the middle of the three pyramid-shaped buildings in the region, along with the rest of my club items and animations.
 If you want to test it out and see it in action first, you'll find it above the center of the dance floor in my Hedonism club region in RefugeGrid. I host parties there every Sunday at 5pm-9pm grid time but you can drop by any time to play with it.

The system is supplied under Creative Commons Attribution-Non-Commercial-ShareAlike 4.0 International license which means you're free to share it or make it available for others to pick up from your own regions, provided you don't charge for it and it continues to credit me as the creator.

Whether you pick up a copy from me, or from anyone else, please be very patient to allow the transfer to complete if you are HGed to another grid. There are more than 700 animations plus assorted other contents, plus the objects themselves, so depending on how busy the servers are this can take several minutes at least to deliver if nobody else on your grid already has a copy. Just wait for this to complete rather than clicking to "buy" again since that will only just slow down the transfer even further. For most users, the box will be added to your "My Suitcase > Objects" folder once it has been delivered.

The danceball and READ ME notecard are inside the box.

If you want to put a copy of it out on your region for other people to take, please do this using the boxed version...that way people will get the proper complete system. Note that I would advise against doing this in a region on a residential server or that is otherwise very busy as it's the region itself that has to handle the asset transfer which can impact on other things happening in the area.

What Does It Cost?

All products I create are completely free...just come and pick up a copy.

Seth (and I as a resident) do, however, incur costs to maintain the grid, shopping region and my testing/development regions so if you feel inspired to make a small contribution to help with this we'd both be extremely appreciative. I want to stress that this is completely voluntary but of course every little bit helps. You'll find a sign in the region with a link for secure Paypal donation to RefugeGrid if you feel so inclined.

How Do I Set It Up?

The cryptically named "READ ME" notecard in the box and inside the danceball itself contains complete instructions on how to get it up and running.

If you're new to the system you may need to ask your region admin to adjust a few settings but, increasingly, regions are preconfigured by providers to let it work perfectly straight out of the box.

If you're running a region with an existing version 1.x of the ball there are no changes to the script that require anything special and it should work perfectly.

If you've just updated to the experimental Opensim 0.9 build you will need to make additional changes (all details are in the notecard).

If you have an existing system with custom NPCs in it, you can take those NPCs out of your old ball, rename them to match the new naming conventions, then drop them into the new ball and reset the script. It will pick them up automatically when it initializes.

If you have an existing system with custom dance animations in it, they can be added to the new system in exactly the same way it worked when you added them to the old system.

How Do I Get Help?

If you have any questions or encounter any problems, please take the time to first re-read the READ ME will answer many of the most common ones.

If you still need help, you can contact me via a comment here (G+) or in-world you can come to and see if I'm online and able to take your IM. If not, please send me a notecard via IM that details your question/problem and please include your name and the HG address of your grid so I will know who it comes from and where I need to go to be able to reply to you. Inter-grid communications are extremely buggy so if you don't hear back from me in a day or two it's safe to assume that I haven't received your message and please try again.

For issues directly relating to the Opensim 0.9 development branch I may or may not be able to help you and may refer you directly to the Opensim developers for support since they will be more aware of the functionalities that they've broken/changed and what fixes/work-arounds might be possible. Until such time as 0.9 has been tested, fixed, and reached some measure of stability I highly recommend using for most club/production environments.

If you discover any bugs with the system, particularly ones that you're able to reproduce, please get in touch with me and let me know. I take great pride in releasing as bug-free a product as I possibly can and am very happy to fix anything that I'm responsible for breaking. For bugs or broken functionality resulting from changes to Opensim, please file a Mantis report with the developers.

Friday, 8 January 2016

Sneak Peek: Paramour Clubmaster v2.0

I've spent the last ten days or so working on an updated version of my widely used club danceball system since I'm still being flooded with support requests from people trying to use it with 0.9.

Since ensuring compatibility with both the new code changes as well as regions running under 0.8.x involved some significant rewrites in places, I thought while I was at it I might as well go ahead and make any other changes to it that seemed useful to me or had been requested.

We did the first beta-test of the new system on Wednesday with a dozen people, encountering only one small corner-case bug, and I'll continue to put it through its paces for the next few weeks at my Sunday Hedonism dances to hopefully find and purge any remaining bugs and ensure that it works under both old and new code versions.

Barring discovery of any major new bugs, the final system should be ready for public consumption by the end of the month or early in February.

If there are any bugs with the existing version that you're aware of and haven't reported to me, or if there are any feasible new feature requests, I would be open to considering them if you get in touch with me in the next week or two.

Here's a sneak peek at the change log so far, although this is subject to change between now and the actual time of release if I discover issues with it:

Change Log Paramour Clubmaster Dance Machine 2.0



There is now a new "GROUP" option available in the initial dialog that you can choose for dancing.

The danceball owner can specify any one of the singles styles to be the group dance style (it's a setting at the top of the script in the BASIC USER SETTINGS section) or, if left blank, the first singles dance style will be assigned automatically. Unfortunately this selection can only be made in the danceball's can't change it during use (you'd have to do it the "old 1.x way" where you choose singles dance when you join, then agree up which style you should all pick).

Anyone who touches the danceball and picks "GROUP" will play that dance style and be kept in perfect synch with everyone else who's using it (the synch doesn't happen until the next time the dance advances so they'll be out of synch for the first minute or two). The group will cycle through the animations assigned to that style in much the same way singles dances work. Touching the danceball again stops you from dancing.

A NPC who touches the danceball is automatically added to the group dance, allowing you to use external scripts to rez a NPC and have it touch the danceball and start dancing whereas in the past this wasn't possible. Having the NPC touch the danceball again will stop it from dancing but not kill have to have your NPC controller script do that if you want to remove the NPC. You can just kill the NPC with your external script at any time and the danceball will detect it the next time the group dance changes.

The triple advantage of this new feature is:
  • no need to coordinate which singles dance style you should all select to dance as a group...just pick "GROUP" and you'll join
  • greatly expanded NPC support and flexibility (particularly in conjunction with Ferd's excellent NPC controller)
  • from a load standpoint, the danceball is able to cycle through group dances slightly more efficiently than individually selected singles dance styles, so there will be a tiny reduction in sim load abd script memory use for each dancer who uses the GROUP option instead of picking their own singles style (while still leaving that as an option)


In version 1.x of the danceball, changing NPCs involved adding/removing their appearance notecards from the ball, then also manually editing the appropriate list in the Advanced User Settings section to match them. Many users with limited scripting experience found this an intimidating task so...

With version 2.x, I have changed the way this works. NPC lists are now built during the ball initialization based on a specified naming prefix (by default, ".NPCM" for a male NPC and ".NPCF" for a female one but you can change this if you like) so all you have to do is name your notecards correctly and reset the main will take care of the rest. You can also expand the use of this feature by having a number of different NPC notecard sets with different prefixes for different occasions. To swap sets, all you need to do is edit the Advanced user settings to indicate which prefix notecards to load.

More details on this feature are in a separate section below.


You can (optionally) include a notecard in inventory that specifies a specific NPC to initially rez for a specific user. When that user picks NPC COUPLES and sits, if their UUID is in the list it will rez whatever NPC is specified in the notecard. Note that this NPC can be *any* valid appearance card, even if its name doesn't conform to the new auto-list-building feature above. This would allow you to set up a custom NPC that only that specific user can dance with.

To make this work without unduly expanding the script size, this NPC is only rezzed when you first sit down (and it doesn't matter which ball you pick to sit will rez your NPC to whichever one you don't occupy) and then after that the NEW M and NEW F buttons in the Options menu will continue to work as before, allowing you to change to a different NPC if you want. You would have to stand up and start over again to get your specific, custom NPC rezzed for you again.

Anyone not in the custom list will have the danceball work exactly as normal.

More details on this feature are in a separate section below.


This new feature is intended to allow the danceball to accomodate the changes made to sit target positions in Opensim 0.9 while remaining compatible with regions running under 0.8.x as well.

Added a zGlobal offset value to the basic setup values which allows you to easily adjust the couples dance positions.  The default value of 0.0001 is suitable for any region running under Opensim 0.8.x. People using Opensim 0.9 will need to determine the best value for your various Opensim.ini settings -- please consult any Opensim documentation available for your version or, if you're unable to find any and if you see couples floating above the ground, I'd suggest starting with an offset value of -0.15 and tweak from there since this appears to be the approximate (undocumented) change made to sit targets in the newer code.

This z-offset value is sent to the poseballs which apply it as a direct offset to the ball's sit target to avoid having to do extensive ongoing position calculations during actual danceball operation...the calculation is only done once at the time the avatar/NPC sits. This method is a little clumsy but at least allows you to easily adapt the danceball to whatever version of Opensim you're using and will add flexibility to handle any other changes of this nature if/when they occur to the code.

The value is set in the BASIC USER VARIABLES section at the very top of the script.


The main danceball mesh object has been remade as a single mesh instead of linkset. It is approximate the same poly counnt as the old one but was uploaded with higher LOD values and simplified physics shape (even though it's set phantom by default). The couples poseball object has been remade as a single mesh with lower poly count, and uploaded with higher LOD values and simplified physics shape (even though it, too, is phantom by default). This should make it easier to spot both objects from greater distances and/or with lower viewer LOD settings and reduces the LI for grids where LI is used.

Other Main Danceball Script Changes

  • Changed the initializing and live handling of singles dances to now allow for a (virtually) unlimited number of different styles to be defined for it and presented in navigable dialog pages. Note that having a very large number of them will result in a (small) increase in the script's memory usage. It's still not possible to allow selecting a specific dance animation to play (it would require a level of dialog/menu tracking that would drastically increase the memory footprint when the danceball is in use) but I'm hoping people will enjoy the increased flexibility and ability to customize. For much the same reason, it wasn't practical to make this sort of change to the couples dances (nor do I think there are enough additional ones out there in the Metaverse to require it since there are already two empty style slots available which can accomodate 18 more dances).
  • The basic user settings now has a "errorCheck" variable (TRUE/FALSE) that determines whether to run extened error checking and has a large impact on initialization speed. Due to Opensim 0.9 code changes, disabling error checking may be required for some regions unless you greatly increase the value of the EventLimit variable in Opensim.ini [XEngine].
    • TRUE will do a full error-check on start-up, strips strings, confirms animation names, confirms inventory, warns about excess animations, etc (old behaviour from 1.x but slower)
    • FALSE is now the default value and does only minimal critical error checking and assumes everything is correctly configured and string-stripped (much faster but if you edit your notecards incorrectly the errors won't be detected and fixed)
    If you're using the danceball version I supply, without content edits, you can safely leave this at its default FALSE value.
  • Because NPC lists are now build from inventory, added an option to randomize the order after building the lists. This is only done once, at start-up, after which the order will remain the same until the main script is reset.
  • Added a QUIT button to the couples options menu (except for owner when in edit mode) to allow you to quit from there as well as from the styles menu (or by standing up).
  • Added a script global integer constant "osNpcObjectGroup" with value of 8 which is used as a switch to the NPC creation method, allowing the NPC feature to be used in a region running Opensim 0.9 with group perms but also won't break functionality under 0.8.x. I used a global defined variable rather than the new constant OS_NPC_OBJECT_GROUP in order to allow the script to compile in regions running code earlier than Jan 4, 2016.

    Please note that there are additional changes to NPC configuration and functions that may require adjusting your Opensim.ini and osslenable.ini to enable the necessary functions. Consult any available Opensim documentation.

    Any region running a version of Opensim 0.9 with a commit date prior to January 4, 2016 will need to be set to allow full public access to allow NPCs to work (or upgraded to a more recent version or reverted to 0.8.x). IMPORTANT!!!! AT THE TIME OF THIS WRITING, FOR THIS TO WORK IN OPENSIM 0.9 PARCELS YOU NEED TO SET THE DANCEBALL GROUP TO MATCH THE ALLOWED PARCEL GROUP!!!
    If you run Opensim 0.8.x you don't need to worry about this at all since NPCs aren't evicted from group parcels.
  • Added new presence checking to a variety of places to try to catch occasions where asynchronous script handling can result in OSSL error messages being thrown as a result of trying to send issue a command to a non-existent NPC or poseball. This can't completely eliminate the chance of it happening but should make it a much rarer occurrence. The function calls are isolated and an error won't prevent the danceball from continuing to work properly for all other users. This error-catching does add a very slight amount of overhead during use, but not to an objectionable degree.

    The most common action that can still generate an error message is to select COUPLES NPC and sit, then stand rapidly after the NPC has rezzed and before selecting a style or dance. There is no way I can stop this from happening due to the way NPC agent entry is handled so you may need to advise a user not to do this if they're chronic about triggering it (most often it's because they aren't aware that they can use the OPTIONS menu to change to a different partner so they keep having the ball rez new ones until they get the one they want which is hard on sim resources and should be discouraged anyway...please help your newbie guests!)
  • BUGFIX: Fixed an incorrect casting assignment when pulling pos and rot values from a list as string instead of vector (it still worked fine under Opensim 0.8.x because it wasn't used until recast in a function call but could result in compile errors in the future -- and it needed to be corrected anyway).

Couples Poseball Script Changes

  • Made a couple small script tweaks for efficiency
  • Made sure that a poseball doesn't try to unsit a non-existent user which can occasionally happen due to asynch handling of operations
  • In regions that don't recompile scripts on start-up, a stranded poseball will now also be destroyed
  • This script now expects to be given a zGlobal offset value from the main script and adjusts sit target position based on this value (see above). This is only done when the user first sits (all other positions are based on the poseball location rather than avi location) thus doesn't add to the sim load when in use.

Danceball Contents Changes

The main danceball and its poseball have changed as per all of the above, plus...
  • attempted to ensure compatibility with the known Opensim 0.9 changes to date in addition to 0.8x (but I cannot guarantee that it will remain compatible with future code changes)
  • the script inside the poseball has changed and poseballs from versions 1.x ARE NOT COMPATIBLE with version 2.x or visa versa
  • the NPC notecards supplied with the danceball have been renamed to comply with the new naming rules but the actual NPCs are the same.
  • the couples dances are unchanged from v1.3
  • added a huge number of new singles dances more than doubling the previous number (now more than 500 different singles)!!!
  • because of this, a number of the (in my opinion) less-good singles dances from previous versions have been removed...mostly due to either because of tilted stance or poor looping
  • removed a few duplicates (even though they had different UUIDs) although I'm sure there are still more...wish there were a way to compare them at a file level...
  • renamed some of the dances that were in the v1.x ball to help group them a little better in inventory
  • re-arranged, renamed and split up some of the old dance categories since the number of them isn't limited any longer


Version 1.x of the clubmaster system required the user to manually enter the names of all the NPC notecards into the script which many novice users found confusing.

With version 2.x this is now handled a bit differently. Instead of having to manually supply a list, the initialization now looks at the notecard name and matches it to a supplied gender prefix that is set in the Advanced User Variables section at the top of the script. By default, a male NPC must have a name that begins with ".NPCM" and a female must have a name that begins with ".NPCF" but you can change this to anything else you want, making it easy to have multiple custom sets of NPCs in the ball for different events and simply changing the prefix filter to load the set you want.


If you've already made a set of custom NPCs for your v1.x danceball you can easily transplant them to your new v2.x system as follows:
  1. Select your old danceball in edit mode and go to the inventory tab
  2. Copy your NPC notecards into a folder in your own personal inventory
  3. While they're still in your own inventory, rename the male ones to begin with ".NPCM" (not including the quotation marks but including the dot at the start) and the female ones to begin with ".NPCF"
  4. Drop these renamed cards into your new v2.x danceball
  5. Press the "reset scripts" button to have the danceball reinitialize and pick up the changes


You can now easily add a new NPC by using any of the normal NPC appearance notecard creation utilities (you can get one free from my shop in RefugeGrid) which will hand you the notecard. Rename this card to begin with either .NPCM or .NPCF and drop it into the danceball's inventory. Then reset the script. You no longer have to edit the lists in the script itself.


You can now easily remove a NPC from the danceball by opening its inventory, deleting the appearance notecard, and then resetting the script. You no longer have to edit the lists in the script itself.


This is a new feature to v2 of the danceball and allows you to include an extra notecard in the danceball's inventory where you can set up a specific NPC to always be rezzed as the partner for someone. The NPC's appearance notecard has to be in inventory too, of course, but it doesn't have to use the naming convention of the normal NPC notecard prefix so this even allows you to have a specific NPC that is reserved for only a single user's use.

The matchmaker notecard can be any name you want (assuming it doesn't conflict with anything else) and needs to be specified in the BASIC USER VARIABLES section at the top of the script. When the danceball initializes, if it finds that notecard it will read in the contents.

Each line of the notecard needs to be in the format:
which is:
  • the UUID of the user you want to assign a custom NPC to
  • followed immediately by the pipe symbol (|) ...DO NO add any spaces between the end of the UUID and the pipe symbol
  • then followed immediately by the exact NPC appearance notecard name...DO NOT add a space between the pipe symbol and the notecard name...the name can be any valid appearance notecard even if it doesn't have the prefix that your normal "public" NPC notecards are using.

Let's pretend that my UUID is "12345678-90ab-cdef-1234-567890abcdef" and that when I use the NPC partners I always want the one with the appearance notecard called "Aine's Partner". My matchmaker notecard would therefore include the line:
12345678-90ab-cdef-1234-567890abcdef|Aine's Partner

Now, whenever I use NPCs it won't matter which of the two poseballs I sit on...that NPC will always be the one that is rezzed for me to dance with even though its notecard name doesn't have the prefix I've assigned for the normal male and female NPC cards. If I want to change to use one of the other NPCs instead, I can go into the OPTIONS sub-menu of the dialog and pick "NEW M" or "NEW F" to replace my NPC with the next one from the "public" list, but after that it would only give me access to the ones in the regular public list on future swaps. To get my own custom partner back I'd need to stand up and start again.

Whenever you add or alter this notecard you will need to reset the main script to have it pick up these changes so it's something you'd set up ahead of time and probably limit to only yourself and perhaps a few regular guests.

The only error-checking done is to ensure that the specified notecard actually exists in inventory during initialization. You'll be notified it it isn't and it will be ignored (using the "public" NPCs instead). If a user's UUID is listed twice, it will rez the NPC associated with the first instance of it in the notecard. If you delete the NPC notecard without resetting the script, this WILL NOT be detected at time of rez and could cause issues so always be sure to reset the master script any time you make any inventory changes (preferably with error-checking enabled, too).

I had originally hoped to provide a more automated and flexible method for doing this (and even letting users select and store their own, in real time) instead of the owner having to manually edit the  notecard. Unfortunately it resulted in too much additional complexity and performance degradation to the danceball for this to be practical. In future, if I can come up with an efficient method for doing so I'll consider adding it.

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


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's a very, very large percentage of commonly used objects.

Friday, 1 January 2016

FYI: Opensim dev master and NPCs

Just a head's up for anyone running Opensim dev master branch...

It seems that something has been changed recently in the development branch that has broken anything that rezzes/uses NPCs. The version I tested was OpenSim Dev 7831d21 committed 2015-12-27 running with ubOde phsics. Any time a NPC is rezzed it immediately starts to drift toward the edge of the region where it gets stuck. It ignore sit commands but it will respond to a kill command, so you are able to get rid of it.

This change breaks my Clubmaster danceball (for NPC couples), my rez & pose utility, and anything else that rezzes NPCs.

Just thought you might like to be aware of that if you were considering updating a region to use it.


After some investigation, the issue appears to be tied to the new way that 0.9 handles access permissions. If the region and parcel are both set to allow full public access NPCs should still work. Anything other than that (group access or UUID-restricted access) will likely break them.