Using

I haven’t gotten to use the AO much. SL is messing up (Saturday 12/12). Moving animations into the HUD is being a pain. I got some duplicates because I put some in and some of them didn’t show up, I tried moving them in again then later found I had duplicates. Then I could not delete the duplicates. I would delete them, return the HUD to inventory, take it out of inventory and the duplicates would be back. I real pain. This isn’t a problem with NITRO, it is a problem with SL. Regardless of who causes the problem it is frustrating.

NITRO AO failing to properly show animation name.

I did get to use the AO a bit. It is easy enough to use when it works. The only behavior not intuitive is when changing the type of animation; walk, run, sit, etc. The animation name does not always quickly change. I often had to click an arrow to move to the next animation to see a change. I can’t tell if that is from SL messing up or the way the AO works.

I did have the AO apparently lockup. The FAQ’s say it can be reset like any other scripted item. In both FS and Linden SL viewers the script reset function was grayed out. I think that was an SL problem. But, Wednesday I got an update to v1.1 and this problem went away. But, I’m still having problems, which I’ll get to.

The dance feature of the HUD has all the features of my OWNS dance HUD without all the attaching and detaching and chat commands. I can click faster than I can try to remember and type a command.

Problems

I plan for it to be my primary AO. I will have one of my other AO’s based on a ZHAO in reserve for events and other places where I need minimum memory use. But, for now, NITRO is a toy I cannot rely on. I’m sending trouble-tickets, 3 so far.

AKEYO responds within 24 hours and often within an hour. But, the AKEYO_NitroAO_HUD (v 1.1) [script:~userManagement] Script run-time error Stack-Heap Collision errors are a pain. I am told wearing lots of scripts can cause that problem. Wearing 10 scripts using 590k of memory may be too much… Really!?! That would mean the majority of SL users would not be able to use this AO.

With the NITRO attached I am at 2,448kb, still under 3mb and I’m the only one in the region. So, I’ll assume there is a bug and I am not really memory limited.

Also, when using the Linden made viewer the animation names were not readable in the HUD (see above image). Seems one has to have Mesh Detail set to the right value. The FS viewer has it set to a high enough value by default. You have to change the Linden Viewer’s setting.

To make the change I was told to go into Preferences->Graphics->Advanced Settings and change the OBJECTS slider in the MESH section. Slowly slide it to the right while watching the NIRO HUD. You’ll see the animation name become readable.

This slider is changing the Debug Setting RenderVolumeLODFactor. If you make the change via the Debug Settings panel set the value to 1.4 or more. I prefer mine lower for a number of performance reasons. About 6 months ago I was writing about how this setting was becoming an issue. See: Second Life LoD Problems – Is Firestorm to Blame. It looks like AKEYO has been bitten by the Firestorm default value thing. Which, if so, goes to show how much of a problem it is.

I’m looking forward to playing more with this AO. But, for now it is basically unusable. I can’t get it working. I fear it is a combination of Linden Server issues and bugs in the AO. So, it may not be a quick fix.

More to come…

PS: After talking with Akeyo and running through basic troubleshooting they decided to refund my money. That is stand up. I greatly appreciate their help and their willingness to work with me.

I like their AO. But, I believe I tried to do too much with it. I had a ZHAO with sets of animations. I also had a dance HUD. Combining the animations from both was just too much for the Akeyo AO.

I ended up moving back to my ZHAO and Dance HUD.