Issues during login
Issue #106
resolved
Frequently worn attached items fail to re-attach during login. Subjectively it seems to happen when there is a lot of mesh to load. Scripted items, as well, seem to fail to attach more often. RLV seems to give up attaching items too soon.
Comments (11)
-
repo owner
-
On a related point, I wonder if RLV can be made smart enough that even if it would be prevented (eg addoutfit=n) wearing of a skin/shape/eyes/hair will always succeed if no such item is already worn. I suspect some cloud situations are happening because rlv restrictions are coming into effect before items that should be worn upon rezzing actually try to attach - and the situation (avatar is a cloud) cannot then be fixed without getting the rlv restriction concerned lifted (or relogging and hope things arrive faster next time)
-
repo owner
Normally the RLV always allows wearing a body part if the avatar is a cloud, so it more or less addresses this issue already.
-
I had a case last night that went like this... first login, avatar had wrong shape but wasn't a cloud (wrong height was reported as well as looking different). Correct shape wasn't worn. Relogged and became a cloud. Shape still not worn. Tried to attach the shape but couldn't. Lifted addoutfit restriction, tried again, it succeeded. So, in this situation the detect-a-cloud-av didn't pick it up. This was with Kokua 3.8.4 (RLV 2.9.14).
-
additional information: just had another glitched login and amongst the messages was a 'you've detached your collar...' meaning that it was worn briefly and then got pushed off, presumably because its attach point had become locked before the collar landed there. It seems like RLV restrictions are coming into effect before the avatar is done rezzing and wearing their attached-at-login items
-
and confirmed - addoutfit:shape prevents a cloud from wearing a shape (that glitched login actually detached almost everything...)
-
reporter
I haven't had the problem with Firestorm. My AV has quite a few RLV attachments and my connection is modest (2Mb). My computer is a good one. GTX780M graphics 4Gb Have it set to 1,232 Mb for texture memory. I'll try reducing it to 1,024. The problem is worst with slow rezzes and laggy sims.It doesn't seem to occur in a relog, just your first login of the day. My character is a doll so I do have a lot of locks if my clothing is locked. My shape is often locked too. But it's not clear to me that it has to do with how many things are locked. I think it would be resolved if RLV could just have a few minutes of exceptions for things that were worn at logoff.
-
Just had a variation on the above scenario - av logged in seeing themselves as a cloud, but normal to others. Inventory said no shape being worn. Unable to wear shape. Relogged. Still seeing self as a cloud. Unable to wear shape until two addoutfit restrictions had been lifted (one was a general addoutfit, the other a specific addoutfit:shape). This was with Kokua 3.8.4 (RLV 2.9.14). I'm now certain that the code mentioned above to allow wearing a body part when a cloud isn't working right.
-
repo owner
I think I found the reason for the bug described at the top (because shapes not worn during login with @addoutfit is another issue, one I thought I fixed with a blanked fix saying "if we're a cloud, allow to wear anything"), and I'm a bit surprised to see that it doesn't work... The code is very simple there. If we're a cloud, no outfit restriction is taken into account.
Anyway... The reason for the bug described here seems to be a short timeout for attachments and wearables in general. If they don't arrive within the next 30 seconds, their attachment request is simply discarded. But many people need more than 30 seconds to log on !
So I have increased the timeout to one hour. After a few days of testing, I have no sudden detach on login, nor missing shapes, nor even detached items on TP (which was another pet peeve of mine).
So I'm gonna mark this as solved (until the next time it happens, if ever), if the addoutfit problem arises again, please open another bug for it.
Please note that this bug was introduced in RLV 2.9.14 after the merge with the official code base. The culprit was MAX_ATTACHMENT_REQUEST_LIFETIME (30 seconds initially) in llattachmentsmgr.cpp, and was a fairly recent addition. It was added 7 months ago but merged to the release branch only recently. Therefore it should not be in RLV 2.9.13 and below.
-
Many thanks for investigating it. I can't say for sure it was OK with 2.9.13 and below but it's certainly become much more of an irritation lately (ie since Kokua 3.8.4 / RLV 2.9.14 became my standard viewer). I'll keep a watch on this when Kokua-next / RLV 2.9.15 comes out.
-
repo owner
- changed status to resolved
- Log in to comment
Yes I'm aware of this bug... but is it an RLV bug or does the SL viewer do that too ? I heard that Firestorm had the same issue. In any case, it annoys me as well, some of my attachments are missing when I log on sometimes (not always), regardless of whether they are locked or not. I'll look into this.