Current Project: HUD7

Note ID# 684:

User:	Lulu	Submitted:	26/01/2016
	Miriam, could you tell me: which sim seems to cause this most frequently for you? (tp to this sim or relog)

Note ID# 686:

User:	Miriam Himanez	Submitted:	26/01/2016
	I don't know, I'm sorry. The bug can be provoked way easier by just relogging than teleporting. Mainly I chose your warehouse and the sim "Bay of Surreality", because both places are without lag and grant rezzing-rights. I dared to do just 1 stress-test so far, by teleporting to laggy and/or script-heavy places, shortly one after the other (not more than 2 minutes delay between 2 tps), ending up at the sim "Excipio Mihi" after the 5th or 6th tp with a damaged collar.

Note ID# 719:

User:	Lulu	Submitted:	16/02/2016
	Updated status to In Progress from New.

Note ID# 720:

User:	Lulu	Submitted:	16/02/2016
	This is a difficult one, because of SL instability during login and TP (i.e. TP-bug)... Three questions: 1) Can you tell whether your Gag/Cuffs etc. that triggered the message was actually OFF? i.e. maybe SL re-attached it so quickly it was back on even before the re-rez? 2) When you say your gear was damaged, how was it damaged? 3) Would it help if during login/TP, instead of re-rezzing right away, we just issue the message if the locked gear is not found, and leave it to you to re-wear manually? Then we check again after a minute, and if it's still not found, then we re-rez? What do you think?

Note ID# 723:

User:	Miriam Himanez	Submitted:	16/02/2016
	Indeed it's an old obstinate sl-bug standing behind it that kept affecting RLV-gear from other producers I've used already for a long time (RR, T&T) as well, causing frozen scripts, loss of locks and restrictions, unwanted detaches and so on. I try to answer your questions as good as I can: 1.) Most times there isn't any actual detach, I believe, because the HUD either doesn't send copies of the affected parts to the inventory or the ones being sent are just surplus and never worn, because the old parts are still worn. If old parts are detached and new copies worn instead, it's time for me to do a HUD-restart at least, which brings me to the next answer. 2.) As I said new copies worn indicate a malfunctioning HUD to me, but unluckily not inevitably. To check if there's a truly damage, I need to relog with all the gear worn on not shared attachment-points. If the HUD keeps sending messages of detached and re-rezzed gear then, it's definitely damaged, no matter wether it additionally sends copies of gear or not. So the malfunctions provoked by wearing gear on shared attachment-points become persistent. In most cases a HUD-restart is useless then and it's time to get a replacement. 3.) Yes, this definitely would be helpful. Actually I'd go even a step further: I'd surpress the message completely for this first minute because it's actually surplus within this timespan, I think. I've never ever needed to attach something manually, because anytime everything was at its place. A private warning to the sub would be useful instead but just explicitely in case the HUD actually sent copies of gear. (Just to avoid "secretely" sent copies messing up the inventory.) At the end I'd like to point at the fact once more, that this issue is a login-issue first of all. If one waits some minutes between 2 tps and doesn't forget to relog after several tps, it seem to occur just very rarely on tps.

Note ID# 724:

User:	Miriam Himanez	Submitted:	16/02/2016
	Addendum to answer 3: As a summary I'd suggest to surpress the messages on login for the first minute but keep them like they are now on teleports.

Note ID# 727:

User:	Miriam Himanez	Submitted:	18/02/2016
	Addendum 2 to answer 3: A big annoyance to me is the fact that always the Owner gets messaged without the sub having done something bad. An alternative could be leaving all the messages like they are now but sending them to the sub in private explicitely. I already mentioned that I actually never had to attach something manually because either there haven't been any detach at all or automatic re-attach has been triggered immediately (actually that fast that everything already was at it's place again when login has been finished). My alarm is always enabled and it was never triggered by this issue, which brought me to the idea just to message the Owner if the alarm gets triggered as well to make sure the sub actually deserves an Owner-message. (Of course without the message being surpressed if the alarm is disabled!)

Note ID# 729:

User:	Miriam Himanez	Submitted:	18/02/2016
	Please take a look at issue #173. I bet it's caused by the same sl-bug. I'm sorry for not reporting that one earlier, but I needed to watch the login-behaviour of the HUD for a longer timespan to be sure.

Note ID# 730:

User:	Miriam Himanez	Submitted:	19/02/2016
	The results of trying to provoke the bug by using the sl-viewer definitely point into the direction, that it has something to do with the viewer itself. I did 8 logins always making sure not to login on the same sim I've logged out before with having 3 parts of gear worn on a shared attachment point and Owner didn't receive any message at all. (Even not when doing the login at crowded places!) Owner was always online before sub logged in to be able to determine the exact moment for a possible message coming in. Afterwards I added 2 logins by using my preferred viewer Singularity again and Owner didn't receive any message either. I'm a bit confused now, I have to admit. Next login I will do tomorrow, using the sl-viewer again but under the same circumstance I received the last messages. (Logging in after several hours at the same place where I logged out before and logging in before Owner comes online.)

Note ID# 734:

User:	Miriam Himanez	Submitted:	21/02/2016	File attached:	Autofixing_bork.png
	Yay! Finally I've got something (at 22.43 SLT) after me unsuccessfully doing my best to provoke the bug again and again before. Two messages came up after a quick relog on the same sim I've stayed on before and they came up just for the sub. Owner received nothing, so I figure you changed something in the meantime. /Me looks at your question 3 on note #720. The Hud didn't send any copies and I have a clue now why I didn't manage to provoke the bug before. I'm wearing as many attachments as possible at the moment to set the HUD under stress on login and I did changings on some of them before relogging. Detached my gear as well for a short while. I was intentionally lazy on rewearing making sure to rewear a few cuffs and the gag after(!) rewearing the additional attachments. I received messages of detached cuffs and the gag but not of the collar. This absolutely makes sense to me because I made sure to rewear the collar before(!) rewearing the additional attachment. I will keep a very close look on this, when continuing my tests. Shortly after rewearing (before doing the relog) I received a message of a bork and the HUD autofixing it. Possibly this bork was caused by doing the rewearing in the wrong sequence as well.

Note ID# 736:

User:	Lulu	Submitted:	21/02/2016
	Hey Miriam, thanks for the updates. I'm putting together a special beta for you to test. It will have an improved delayed timer to test the gear worn multiple times before triggering the "SL-TP-bug" message. There probably will be a re-rez on this trigger. Your Owner should not be informed till after the second trigger, which is about 30-60secs later. Hopefully this is a smarter system.

Note ID# 737:

User:	Lulu	Submitted:	21/02/2016
	My best guess at this time is that it's an asset server issue - simply, the attachments are not fully retrieved, and so the detection fails. Regardless, it should not IM your Owner till the second trigger. This beta will hopefully even eliminate the first "SL-TP-bug" message plus re-rez.

Note ID# 738:

User:	Miriam Himanez	Submitted:	22/02/2016	File attached:	Tip-message_being_repeated.png
	I'm finished with my first login-tests done in sl-viewer, Firestorm and Singularity using the new Beta and having 8 parts of gear worn on shared attachment points. Any gear was attached before the additional attachments. There haven't been any messages of detach or re-rezz, neither to myself nor to Owner so far. I recognized one conspicuousness although: The HUD tends to repeat one of it's normal login-messages (Just this specific message, not the other ones; so it can't be just caused by lag! ---> Please view attached file.) and some sound as well but just on the first login on the particular place. There wasn't any repetition when I logged in there a second time not long afterwards to doublecheck. I monitored time and location where the most repetitions occured: Leords (Monday 22.02. 14:48 SLT) - 8 repetitions Excipio Mihi (Monday 22.02. 15:20 SLT) - 3 repetitions Priasmin (Monday 22.02. 15:56 SLT) - 9 repetitions Next tests I will do with some parts of gear attached after the additional attachments. Then it'll get really interesing.

Note ID# 739:

User:	Miriam Himanez	Submitted:	23/02/2016
	Today I did 3 logins using sl-viewer with the 8 additional attachments already being worn before attaching the gear. As I expected the HUD sent gear (all 8 parts on the first and second login, some parts even worn) but didn't notify Owner mistakenly. Sub received messages of course. On the third login 2 parts of gear actually got detached triggering the alarm and notifying Owner. The HUD tried to rezz the activation code, which failed due to no rezz-permission on the parcel. The 2 parts of gear are still missing. I'm going to send a detailed protocol.

Note ID# 747:

User:	Miriam Himanez	Submitted:	25/02/2016
	Wearing the new Beta 2 now I did login-tests using Firestorm today. Very good news is, that I didn't receive any wrong messages of detach anymore. Bad news is, that on some logins actual detaches occured followed by a crash. The TIP-messages still tend to be repeated multiple times as well. I have another protocol ready.

Note ID# 751:

User:	Lulu	Submitted:	03/03/2016
	Hey Miriam, How are the tests going? Is the beta HUD now performing as expected in the light of existing SL issues? If so, let me know and I'll mark this as fixed.

Note ID# 756:

User:	Miriam Himanez	Submitted:	03/03/2016
	Hi Lulu. 🙂 I continuously ran tests until the end of the weekend. Needed to do a break in the last two days unfortunately and ran a last serie today. None of the tests brought any new experiences, so I definitely suggest to mark this issue as fixed. I'd like to add a little summary: 1.) This issue doesn't seem to appear at all if gear isn't worn on shared attachment points. 2.) If shared attachment points are used it doesn't seem to appear either if all gear is worn before additional attachments are added. 3.) If shared attachment points are used and gear is added to already occupied attachments points this issue can appear on logins from time to time and possibly very rarely on teleports as well. So everything what follows now refers to point 3 explicitely. On the average I managed to trigger the issue 1 time when having done 10-12 logins under extreme conditions. With "extreme" I mean having the maximum of possible attachments worn with 7 or 8 parts of gear worn on shared attachment points. (All of them added to already worn attachments of course!) Using the Beta 3 "wrong" Owner-messages never appeared again, so just the 1:10-risk of an actual detach followed by the need to rewear gear manually has been left on login. Now I'd like to point you on issue #176, because it seems to be directly triggered if point 3 applies. (Even without any previous detach on login!). I recognized a light tendency to Stack-Heap-collisions as well. (Which had been autofixed by the HUD in all cases except of 1!). Anyhow after a restart of the Main HUD (After ending the conditions under point 3 of course!) everything was well again at any time. At the end I have a suggestion: Explain this SL-bug as easy to understand as possible on your Helpdesk-page, giving the users some advice like: Point 1: You're on the safe side. Point 2: You're safe as well. Point 3: Try to avoid this condition or be prepared to possibly experience some difficulties from time to time and restart your Main HUD after having left the condition of point 3 as soon as possible to be completely safe again.

Note ID# 757:

User:	Lulu	Submitted:	04/03/2016
	Updated status to Completed from In Progress. Assigned to Lulu.

Note ID# 758:

User:	Lulu	Submitted:	04/03/2016
	Thanks for the series of stress-tests, and its' a good idea to add a link to a help page that explains things in greater detail. Your findings will be very helpful in this case. I'll have to think about which bits to include as too much info would confuse non-technical people.