I found some very interesting information on Keiki Lemieux’s blog this morning : Keiki posted some repro steps (discovered by Nock Forager) for consistently reproducing the "Inventory Item permanently disappears when detached" bug that I posted about before and which can be found in JIRA as issue VWR-6610.
The really frustrating part is that, as I reviewed the posted reproduction steps, I realized that I too have been bitten by this bug literally dozens of times. When I am working on a sword, I have to detach and re-attach it by necessity any time I edit certain scripts that contain physics calls like llMoveToTarget. This is less of a problem in Havok 4, but the previous simulator code would not allow such calls to work until the object was re-attached after an edit, so I wouldn’t be able to test the changes until that was done.
So it turns out that my typical process of creating a ‘backup copy’ first, then dropping and re-wearing the sword is actually related to the same damned bug. I’ve learned to identify the symptoms of this, which typically is demonstrated by the fact that when I attach the sword it does not show up as "worn" in the inventory window (which I leave open when working for the purposes of keeping various backup versions), in fact it doesn’t show up at all, which is not normal behavior.
When I noticed this in the past, and knew from experience that the sword would be forever lost on the next detach, I would rename the sword (while it was still in my hand) to something like "lost fucking sword" or something else unique and crude so that when I filed a bug report and included the name, the guys at "The Lab" should be able to easily identify it’s orphaned record in the database. Fat lot of good it seems to have done filing those bug reports, because nearly two years later the bug still exists and seems in fact to be much more prevalent.
So once again, if you’ve been bitten by this bug, I encourage you to go visit the JIRA listing and vote and leave your comments.
Popularity: 30% [?]
Share This
I’ve been reading a very disturbing thread on the SL Forums (registration required) that points to a new type of inventory loss bug : VWR-6610 - Detaching a HUD could lead to the permanent loss of the detached item.
There are multiple ways to detach a HUD, of course, but far and away the most common ‘accidental’ detachment comes from the Second Life® viewer’s damned stupid user interface design. When you click the ‘Release Keys’ button, it blows off every attachment that has scripted access to your movement key. This could include nearly all animation overrides, C:SI swords, most in-world weapons of just about any flavor, and even the key display HUD that I created for Aimee.
And it makes me wonder, just why the hell is it necessary to do that? Why is it necessary to have a button taking up valuable screen real-estate, and even sometimes (depending on what viewer version you are using) intentionally placed as if to encourage accidentally pressing it? If the devs over at The Lab deem it to be such an indispensable feature, even though it’s almost certainly very rarely used once a person finds out how horrible the results are, couldn’t they at the very least place it in the Tools menu alongside the nearly-useless ‘Stop Animations’ item?
/rant off
Please note that the JIRA issue mentioned, while it gave me a chance to rant about something that irritates the crap out of me, is not limited to problems encountered using the ‘Release Keys’ button : It would appear that under some (unknown) set of circumstances, detaching a HUD by any means could result in the permanent loss of that HUD and all of its contents, which may include very expensive animations.
Popularity: 48% [?]
Share This
This is promising news : Kelly Linden reported that he expects the fix to the C:SI kick bug to be deployed in the near future (or now, depending on the order of the rolling update, I guess), and has marked the Jira issue as [Resolved] and [Fixed] and deployed in the latest server-side code rollout V1.21 :
kelly linden - 29/Apr/08 11:31 AM
This issue should be fixed in the current simulator version (1.21)
I’m not able to verify this at the moment (durned work making me work), but I’d love it if anyone could verify this and let me know 
[UPDATE]
False alarm 
Kelly Linden said…
Resolution: (was: Fixed)
Status: Fix Pending (was: Resolved)
Arg, oops!! This is NOT fixed in 1.21, but will be in 1.22 (the next version we release, I hope).
Sorry Robby! This got caught in some pjira clean up I was doing. I thought I re-read all the issues to only get the ones fixed in 1.21, but not well enough I guess.
Popularity: 39% [?]
Share This
Hot on the heels of yesterday’s announcement that Kelly Linden had been working on a fix for SVC-1648 ("The Kick Bug"), and my reply to his request for feedback on the proposed fix, he left the following comment :
Kelly Linden said…
Ok, I’m gonna move on then and consider this ‘fixed internally’. I’ll try and remember to update here when this code gets put on the beta grid to get more feedback, but watch the blog posts for it in case I forget.
This will *not* be in the next release (1.21, planned for this week hopefully), but should I hope be in the next server update after that.
This is great. It will still require an update on all C:SI weapons to fully restore the kick functionality, as we will have to increase push power a bit to compensate for the reduced push in Havok 4, but I’m sure a great many people will be happy to hear this news.
I would have reported on this yesterday, which is when Kelly Linden actually replied, but I seem to have been taken off of the watch list and even though I’ve re-added myself I no longer receive any JIRA updates. I must have annoyed someone over at "The Lab"
Popularity: 24% [?]
Share This
Latest Comments