Things have been quiet. Over the last few weeks, as you may have noticed, I’ve been somewhat afk from SL.
An ill-conceived attempt at dieting put me in the hospital, and then the inevitable depression and isolation that followed had me looking for new fun and adventure, which I found in the form of being a child avatar. More anxiety as astronomical hospital bills began to arrive, and I started applying for financial assistance. I came up for air once or twice to make a couple of new holiday freebies, and then tinkered just a tiny bit, with the appearance HUD.
The appearance hud became.. bloatware. Or more accurately, it became a tangled disaster under the weight of the features I was trying to cram into it. Each new button I tried to add complicated an already overtaxed messaging protocol.. to the point that I had to tear it apart and rebuild even the syntax of the messages sent BY the HUD.
A new engine for the HUD was built on the ashes of the old.. and soon the HUD was doing things I’d never expected it to be able to do… with one catch. The example object wasn’t reacting to ANY of the messages, because now I had to rewrite the receiver script.
This had all been born out of a desire to gang together commands. So that a single button or message could contain multiple commands. A ‘reset’ button, for example, might include the factory defaults for textures, colors, alpha settings, even scaling and so on. With the press of one button, I wanted the POSSIBILITY of sending 5, 10, or however many messages of any kind.. and having the receiving object process those commands and execute them, in unison.
And there lay another problem in waiting. As each command had to be processed separately, and each prim in the linkset had to be checked each time a command was processed.. and then each tag in the prim’s description had to be checked.. well soon I had loops within loops within loops.. and in an 80 prim object, that could result in 320 prims having their descriptions read, if each prim had 3 tags in the description, that could be, well let’s just say.. a lot of things to look up and check.
The larger the object in terms of prims.. the more commands in a message.. the longer the wait, the ‘delay’ would be, from pressing a button on the HUD, to seeing the result completed.
And customers would (mis) interpret that delay, as ‘LAG’.
So I made the difficult decision to go with the “fly apart, fall together” approach.. that is to say, move/hide/recolor/retexture/whatever each prim, each face, as needed, as we come to it. Meaning that instead of having a 2 second delay between pressing a button, and seeing a color change.. you press the button, and the color change washes over the affected prims in the linkset, one at a time, like a very fast moving wave. It still takes the same amount of time to finish, but it looks like it’s doing something, instead of just ‘waiting’.
It’s the best option I’ve got at this point.. and it’s not a bad solution. Most products in SL these days, use this “washover” style effect for making changes. It can be a little disconcerting at first, especially with heavily primmed items. But for the most part, we’re talking about products with fewer than 100 prims.. and most of them, with only about 20 prims in a given prim group.. meaning that at any time, on any given command, only about 20% of the prims in the linkset will be being affected by the changes involved in that command.
So where does this leave the project at this point? Color change, texture change, and “simple alpha” changes are all working (a simple alpha change is, for example, the alpha change that shows or hides the straps on the Fetish Doll Hood).. whereas, an “exclusive alpha” change (not quite working just yet) is a change like the one that would change the shape of the base HOOD when you show or hide the straps. That function isn’t done yet… but it’s very close.
Functions that remain to be implemented at this point, include the aforementioned exclusive alpha function.. a passthrough message that allows me to send messages to a plugin script from the HUD (like messages to a particle generator, for example) .. a special ‘linked’ version of that passthrough message, so it can gather it’s value from the state of other controls on the HUD (partial examples for this are already finished as part of the ‘radio’ and ‘group toggle’ controls).
Also needed will be a set of resizer controls that will be built into the HUD’s receiver script (and the establishment of the token structure that will store the scale and position data for each prim).. as well as some controls for the rotation of the HUD itself (this is more about keeping things neat, as it creates the ability to have 4 ‘pages’ or ‘tabs’ on the HUD, letting me not overwhelm the user with a solid wall of buttons.
Following all of that, will be a need to revisit the locking scripts, and teach them how to find their new tokens, since I’ve changed the syntax for how those are written. Additionally, I’ll need to spend some time with the lock, adding the filtering that determines who can see what buttons on the lock dialogs.. and of course I’ll need to add those alarm messages if the thing gets unworn while locked. Lastly, I’ll need to actually add the unlock command, so the puzzle can actually successfully unlock the item.
As you can see, there’s still a huge pile left to be done.. and I haven’t been super fast lately. That said, I’m going to try and work through it a piece at a time, as much and as often as I can stand to.
