Wednesday, July 29, 2009

Dynamic Nightmares

Well. In order to please the customer more and make a few new poses for my cuffs (bringing the total up to nine) I made "Pony Hands". You know the pose, it's not over breast but it's wrists drawn up and chained to the elbows. I thought my system was ready for it, I was wrong.

It catastrophically crashed my scripts as the left side fought for control and the right side sat on it's proverbial behind ignoring me.

The issue stood thus: both the Left Wrist and Left Elbow cuffs were designed as the Sources, that is to say that the particle chain emitted from them and targeted the right side. Because of this when I tried to run Pony Hands and chain Left Wrist to Left Elbow it crashed (don't ask me why it just did) the Left Elbow cuff. The Right Elbow and Wrist cuffs did nothing because they had only been programed as targets, containing little more then scripts to get their UUID and having no knowledge of the commands needed to create particle chain.

Basically, I had to re-write the entire chain system so that all cuffs are Sources and Targets. What does this mean? It means LWrist to LElbow is now possible, as is RWrist to RElbow; it also mean you can do RElbow to LElbow if the direction of the chain matters to you.

Previously both LW>RW and RW>LW would draw a chain from LW to RW, now the second code will draw a chain from RW to LW. This is of course purely for visual continuity, we don't really need the chain between elbows going left to right and the wrist chain going right to left, it just looks odd.

To summarize:
  • The code found in the anims names now is strictly Source>Target
  • Any cuff may be Source and any cuff may be Target
  • You may still only have one Source but unlimited Targets (eg. You can't make RE the Source twice it will only take the last one. However you can make RE the Target for two chains)
And that's about it. I've averted issues with this one, goodness knows someone would have made themselves a nice anim that tried to use a more dynamic chain system then my cuffs previously supported and ended up crashing the scripts. Now they won't have that issue, all tests are (so far) all working as intended.

The only down side, this unexpected (major) issue ate up the day I'd intended to use to finish the Lockpick system.

Saturday, July 25, 2009

Last minute..

Seems of all the things I planned out for my cuffs I forgot one. LockGuard v2 compatibility! Well so I started adding in support for it when I came across an issue; how do I tell the cuffs what LG to call for?

Keep in mine the base design behind me cuffs, no pose is set, and they'll be a plugin that allows customers to make their own poses. How does the cuffs know which poses to use LG with?

I use a code of my own stored as part of the anim names to make chains from cuff to cuff but it's not designed to work with LG; seeing as I forgot about that at the time.

So I'm left with a choice:

a) Keep the system as is and forgo LG support
b) Totally replace my chain system and code support to work with LG which delays the cuffs release
c) do B but as an update instead of before release

Personally I'm leaning towards B, I know I know; delays suck! But A doesn't seem like a good choice and C has issues. If I do C then I'm stuck with people who have anims that don't contain the new code. What if I need a pose to attach to the ankles or a belt? There's no currently supported code for such actions and it may just be easier to redo the system now instead of having to update everyones anims.

Or I could stick basic support in, not any calls but anchor points at least so other products can chain to the cuffs but they won't attach to others. That shouldn't take to long and is better then nothing (A) but isn't the hassle of re-writing an entire system.

*shakes her head* I don't know. It needs more thought.

Thursday, July 23, 2009

So close you can lick it...

The Simplicity Cuffs are getting realllly close. The HUD is mostly done and a lot of the bugs have been evicted and moved into a hotel for later use; some were given a home under the "Unintended Feature" act.

There's some fine tuning to do with the HUD commands so that they stack in the right order and the RLV protocol. Where most HUDs will send the @detach=n command when in use (leaving it free to detach when just sitting there) mine will be different. Because of how you can turn it off from the cuffs themselves that will be the trigger to unlock the HUD which will be locked at all times otherwise. This allows for a bit less lag if you can believe it, with the foreknowledge that the HUD is locked in place we don't have to make it "ping" as often to let the cuffs know it's still there, because we just know it is thanks to the lock.

Still no set release date as goodness knows when a bug will move back in but I can estimate around a week or so till they're ready.

Here's hoping!

Friday, July 17, 2009

An Update on Products

AU-HUD:

Unfortunately this task is not moving forward so well, data storage is a massive issue and now comes the fact that it can't fulfill specific HUD commands. It isn't programmed to track things like Mouselook and there's no way to dynamically tell it to without presetting a command for such which while I could would mean others are using my defined parameters which may or may not be what they need.

I'm not giving up on it, it just wont be coming as soon as I'd hoped.

Simplicity Cuffs:

They are moving along, with the failure of the AU-HUD and the unique features these cuffs now require from a HUD I'm creating a new one for the cuffs themselves. Now of course this means another HUD slot gets eaten I know and I'm sorry. But not all is lost at least. Taking some data I gathered for use in the AU-HUD this Cuff HUD will be wearable on any HUD slot and still function normally.

It will also be using a dynamic creation filter, what this means is that when the HUD is created it will attach to any slot you define and not just whatever slot is set by default. This should hopefully alleviate some of the annoyance that HUDs bring.

HUD use on the cuffs is also optional. There will be a toggle in the options accessible to the wearer only and only available when the cuffs are unlocked that will deactivate the HUD. The options will still appear in the menus (their controls explained later in this post) but the HUD won't respond and won't be persistent (the cuffs won't care if you take the HUD off). When active all pending HUD commands are sent and the cuffs will want the HUD on at all times.

"Pose Settings" are a different approach to RLV and HUD control. Unlike other cuffs you may see in the market the Simplicity Cuffs don't have all inclusive restrictions. For starters the RLV restrictions are kept to a "realistic" limit. That is to say that the cuffs won't be able to block speech or flight or anything of that sort. They can block rez/edit, show inv and fartouch; logical things that you'd be unable to do when cuffed. Besides RLV there's three (3) HUD controls, Block, Idle Block and Mouselook.

These six (6) options don't function like you'll see in other cuffs. The settings are inclusive with each individual pose. Long and short, if you have three poses in your cuffs "Wrists Front", "Wrists Back", and "BoxTie" you can set the cuffs to automatically apply certain restrictions and settings for each pose. Set "Wrists Front" to block FarTouch, "Wrists Back" to block ShowInv and Block, and "BoxTie" to Idle Block. This would mean then that if you lock the cuffs into Wrists Front that FarTouch will be restricted, shifting it then to Wrists Back would unblock Fartouch but restrict ShowInv and activate the HUD Block. You get the idea?

It's pretty neat :)

So anyway, about the only thing left to do on the cuffs is create the HUD and do a lot of testing. I don't have any predictions of when they will be ready for market but it's getting close.

Wednesday, July 8, 2009

Technical Difficulties

Don't you just love hearing that. "We're sorry we are experiencing technical difficulties at this present moment and cannot provide our service"

Well, tada... hi my video card died so no SecondLife, no anything really until I can replace it which should hopefully only be a day or so... hopefully.

*hugs* to all my friends I hope you come read this so that you at least know why I'm not haven't been logging in.

** UPDATE **

Things were a bit hectic but we've at least partially resolved the issue. From just video messing up the audio went too and with it the fear that it was the motherboard that was screwed. Thankfully we got our heads on straight and decided to try swapping back to the old RAM (these issues occurred when we tried to double our RAM) and; while tragically 1 gig of RAM isn't working/being detected, things are at least in working order.

Time to head to the store and bitch about the faulty RAM they sold us!

So, I am back in action I do have the ability to log into SL but it may be really slow going with only 1 gig of RAM *eek*

** UPDATE **

Soooo, new RAM from the store, same issue when we plug in it. Now during all this it's been my brother who's put the RAM in. As he did with this new RAM that screwed up just the same today. After he left I took a peek and noticed he was putting this new RAM into two different slots.

The motherboard we have has 4 slots for RAM, two are yellow two are black, the old RAM was being put in the yellow, the new ones were in the black. So I took the RAM outa the black and put em in the yellow and voila they work with only one issue: one of the yellow slots is fried (hence why I only had 1gig of RAM before).

This of course concludes that it is in fact the motherboard and not the RAM and, had my brother been consistent with the slots he was putting it in, we would have known this before we exchange the RAM.

Anyway. For the time being things are alright, I'm back up to 2gigs of RAM (which is what I had before all this kerfuffle) which I can live with until such time as we can get a new motherboard and get all 4 gigs.

Thursday, July 2, 2009

We've Moved!!

The main showroom previously found in Balazic Isle South has now moved to it's new location in Orchid Farm.

http://slurl.com/secondlife/Orchid%20Farm/144/144/1005/

I apologize for any inconvenience this may have caused people as the vendors flickered on and off. The move is complete and the server should be stable...

Wednesday, July 1, 2009

The Master Swo...er Key

Just as a heads up to prospective customers when relating to my newer products (Simplicity Cuffs and Muzzle Gag currently) that use the Hybrid Key/Owner system they do not have Safewords like my Owner system items do (Chastity Belt, Slave Harness). Instead they use a Master Key which borrows its concept from Marine Kelley's Real Key with a few differences.

1) The key is NO COPY

2) It is found in the box with the product, it is not given or generated by the product

3) You only get ONE, don't lose it and if you give it away be sure to trust that person (in the case of losing it you can get a replacement but try not to alright)

4) You don't create your own password to remember, wearing both product and key you Set Key (option in key menu) to generate a random code unique to the product

5) Once Set you can Use or Reset, Use will unlock your product and return the keys to whomever used the Master Key

6) Reset will clear it's special code and communication with the product will fail, resetting the product will cause this failure also. Be sure to Set your key again in such cases

7) The key can only be Set while the product is Unlocked