|
|
|
[
Permlink
| « Hide
]
Simon Nolan added a comment - 03/Apr/07 12:14 PM
Seems that this problem occurs most frequently for me when teleporting to a busy sim. Could this indicate a possible problem in interaction between the viewer and the grid? Occasionally only one shoe will render incorrectly--usually not all attachments are affected, only some, including HUD attachments. Attaching and reattaching will fix the problem, except when the "pending attachment " message occurs. That message seems to further point to a problem between the viewer and the grid (maybe the asset server?).
Just want to add, that this happens with the Windows client too. Not always on a teleport though, it has happened to me several times when crossing adjoining sim boundries (walking or flying) (I have land on a corner so im always crossing the border)
This is the notorious "hair in butt" bug... we hope to fix this soon. Will link it up internally.
Does anyone here have a solid repro for this? Now, we've been trying to find our own, involving many-primmed objects and poor network performance (lots of packet loss). At latest, it seems like if you have this problem and wait a few minutes, your attachments should eventually "slide' back to the expected positions. Is anyone else finding this to be the case?
Otherwise, a relog is the workaround, but it's confusing, because you might think your attachment positioning is futzed and make it worse by trying to adjust them more. Further details appreciated. From my experiences, I've noticed that generally, the victim doesn't actually see it. Only others around.
Though occasionally, it's the other way around, and only the one affected will see it. Almost never does this happen in a situation where it's universally visible. At least to me. Also, I've never seen it fix itself naturally. But detaching and reattaching seems to work. We need a better repro for this.
Not sure if this is helpful or not. This only started happening to me recently (last two weeks). Until today this happened only during teleports, but earlier I was afk for a few minutes, and when I came back I had one shoe no longer visible (but still showing as attached) and the other one attached to my rear. Unfortunately no one is around when this happens to me so I don't know if others can see it or not. It is not happening consistently to me. So far it has been my shoes only. Detaching and reattaching solves the issue.
Lately, If out shopping, exploring, clubbing, or visiting, I go bald and barefoot and unadorned.
Please do find a fix for this. This situation has been the norm for me for quite some time. It has never gone away or gotten better. Clothing and jewelry attachments shift, but HUDs like MystiTool, or LC Helper, disappear entirely, even though they show as still attached. I must Detach and Re-Attach them in order to get any clickability use---VERY inconvenient. I thought maybe it was frequent TP-ing that was doing it, and felt very lucky if I could go to 4 or 5 places and keep my stuff on, but sometimes it happens after only one TP. Oh, and I am on Windows, Not Mac.
This happens to me a LOT and has for months -usually affects hair but often shoes and other attachments as well. Mostly seen by me - not sure what others see.
The problem would be one of the things that degrades my SL experience the most and makes Teleporting between regions a real pain (you know where). Have also recently been getting HUD attachments disappearing from the screen as well. This issue has been driving me mad for months (as was said). I wish I could remember what patch started it, I think it was several patches ago. It happens to me upon teleport, i always see it, and to my knowledge nobody else ever has. Also affects HUD objects (could be unrelated?) and like Alphabet I have to reattach my mystitool and my AO all the time. I am on windows client. I just cleared cache, hopefully this will help.
Whilst this never used to happen to me, and I used to laugh at my PC using boss, it has started to happen on my iMac G5 since about four updates ago. It doesn't matter how busy the sim is, seems pretty random, but only after a while inworld. 1.15 is slightly better in that they are all up my ass: hair, shoes jewellery, with 1.14 they could be off to one side.
However prior to 1.14, HUDs would only move a bit onscreen, since then they usually move offscreen, necessitating a shift into Edit mode and command zooming to get the outside screen area to show and moving into the screen area. I noticed that Torley Linden chimed into this one on the 4 April - here it is 30 April and still no resolution to this. We've gone through at least 2 disastrous updates since then.
The problem still exists - is still intermittent - is stil completely unpredictable (other than the predictability of it happening on the majority of tps to some extent) - is still also unpredictable as to which items will attempt sodomy (although the default seems to be hair and at least 1 shoe - still removes jewellery to external to the body, while hair and shoes are up but. I"ve also found that simply Detatching them and re-attaching them restores them to the correct position - though I"ve started to see where they re-attach to the up-bum position on occassions where packet loss it high. And that seems to be the only common thread. At times when packet loss is bouncing through the top of my screen, it's more likely to happen. But packet loss isn't necessarily linked to the number of people on the grid, as it's often worse in my evening (Australian) when online numbers are well below 20 or 25k. Sighs and removes yet another item from rear end .... Again, we'd love to fix this, but we need a solid reproduction to make it happen reliably after teleports/region crossings. "It happens once in awhile" sadly hasn't helped us get much closer to a cause because it's difficult to catch.
If you can find a solid repro, that'd be a great help. Comment it here and email torley at lindenlab dot com to get my attention. Yes, this is happening to me also. I teleport, and I arrive at my destination with my tie and shoes stuck in my crotch area. VERY annoying.
This happens alot to my AV when I am: on a Mac Pro - have a high packet loose of <10% and bandwith showing low - after a TP.
Sorry, no solid repro here either, but I have seen it on two sims (Elibia School, Le Resort) only so far and only maybe once in one or two days. But here are a few details how it happens here (Windows Version, seen it from day one that is Feb. 2007).
I see this often, but I cannot reproduce it easily.. it seems to happen almost randomly.
What I have observed...
It certainly is a time based factor, the longer you are on, the more likely, like tp failures etc. Perhaps connected with the memory leaks still extant.
As for HUDs, they are actually moved off screen. I forget the keyboard shortcut, but if you go into Edit mode, you can zoom back the screen area, see them and move them on to the visible portion, as I find detaching and reattaching doesn't always work for HUDs. Good news Torley that there is a fix for this coming, but please be very very careful this fix does not break something else One thing that I've noticed since the last patch is that occasionally I'll see all my attachments gather at the centre of my avatar, then over the course of a few seconds shoot out to their correct positions. This suggests to me that, after a teleport, all attachments are sticking to one point and then moving to the correct attachment point. Is this what the code does?
My experience:
-It doesn't always include all attachments. I had not seen this issue personally in a little while, but am seeing it start to occur with frequency again with the 1.15.1 (3) release.
I have not seen it in a long time also, but if returning, it may have more to do with the network delays over the last days (I seem to remember it mostly from time when the system was under heavy stress (packet loss, etc.)). One important thing to know would be, if people around you see you correctly when it happens. An easy way to reproduce this is teleport from sim to sim in areas you know are busy. Eventually you will have all your stuff in your anal canal.
Recently I have been having attachments simply fall off onto the floor and stay there even though I am moving around. Since the last viewer update a few days ago, this now happens on every single teleport for me. It's now 100% reproducible. I never experienced this problem before this. Using 1.16.0(6) on a MacBook Pro.
Does this happen for anyone else 100% like Emma? And Emma, do you have another computer you can log into and see if it happens there, too?
I have this issue happening a lot to me. Teleporting to most places. Doesn't seem to matter if it's busy or not (though I have suspected if it is affected by sim performance in general).
My hair nearly always ends up in my crotch region, as do most other attachments. HUD attachments will generally disappear completely if they are affected. Even editing/zooming out of the HUD doesn't show them. They are still reported as being attached though in my inventory. I also have the same issue when attaching objects quite frequently too. They seem to get stuck in an intermediate state between being attached and not, and not being positioned. Example: Attaching hair
If the issue occurs the object will appear, in the middle/crotch area of my avatar. It does now show as attached in the inventory, nor the edit -> detach object menu. I can still cmd+click and select "Wear" (as it has not apparently attached), but this does nothing. The only way to detach the object is to right click on the object itself and select Detach. This allows the "Wear" option to work again, and nearly always works again the second time. (Only once or twice has it happened twice in a row) Otherwise the attachment attaches as normal. I have never experienced the attachments righting their own positions after some minutes. Been there half an hour or more with it sat in my nether regions sometimes. Logging out and back in fixes it. It seems no other people can see it, so I'd say it's a local issue. I've seen it happen to other people before, but they have said they can't see it on themselves when I told them. Again, local issue? I have also seen the wierd thing where someone's attachment will seem to fall off and stay still while they move around. On an extremely rare occasion if I've zoomed my camera in on something far away and then panned back out to see myself, one or two of my attachments have been in my crotch again. As if the positional data for the attachment was being re-requested (I don't know how it all works) and it was being reported wrongly to my client. I've always referred to this crotch location as "zero position", e.g. That's where the attachments all start out without any coordinates/rotations given. Is that apt? I am running OS X 10.4.9, PowerPC G5 I have not seen this bug been reproduced on any Windows-based clients I've tried on the same local network. Everything seems to attach as normal. Whee, the "pubic hair" bug is back :-/
Just wanted to add that I am now seeing this bug again after it very noticeably vanished entirely during the previous release. That is, it happened frequently in 1.14.XX, stopped happening entirely in 1.15, and is now back in 1.16 (I have observed the same with
I'm agree with Veronica. The bug also appeared on the First Look viewer. I experienced it yesterday when teleporting on a parcel with 20+ people on it.
I usually refer to this problem as "asstachment."
1) The behavior isn't always easy to reproduce. As far as I can tell, it is a viewer problem. 2) Most "asstachment" issues are not visible to all people. In fact, it usually the avatar's player that notices the problem while nobody else does. It most often occurs with prim hair and shoes. Other attachments often simply detach themselves (this usually happens with earrings for yours truly). 3) It appears to occur in impacted sims - usually popular places or places with lots of prims that have to be drawn onto a computer. Just guessing, I would say that the viewer chokes on having to do too much and "forgets" where the attachment goes. Instead, the items are drawn into the avatar's centerpoint ... which on most avatars is around the region of the hips/crotch or slightly lower. Possibly related to this is teleporting and finding that one prim shoe has become detached. If I check inventory, I can 'wear' the shoe to re-attach it. It's like someone had clicked on the shoe to detach it when I did the teleport. Odd...
I've had the above problem (seemingly detached) happen to me too, but that feels like somewhat-unrelated lag - after a few seconds, the object spontaneously switches to 'attached' again.
From what I can tell from observing this glitch last night, the error occurs client-side. I was talking with a person A, who was changing her hair often as we stayed in one spot in a basically empty, lag-free sim. Persons A and B didn't see her hair appear attached at Person A's crotch, although I did. Shortly after Person A reattached her hair and resumed changing attachments (she was showing off her inventory, which explains all of the attachment changes), Person B noticed an error with attachment placement on Person A while I didn't see any errors. I haven't cleared my cache for about a week. All three of us are scattered around the US.
It seems like the issue is with the viewer missing a packet or some small bit of information when onjects are being rezzed to attach points. The error doesn't discriminate between the user's av and the other avs in the user's view. If you want a reproduction, keep three viewers open and switch attachments on each of the avs for about 30 minutes. Make sure you have at least ten different attachments per attach point (I'd recommend focusing on the head, since people seem to report that most often). Also, I'd recommend testing on each quarter of the day (6am, noon, 6pm, midnight) to troubleshoot against network errors that could be causing it. I hope this helps. Sorry for the double post, but I'm on Windows XP, and Person B has Mac OSX (not sure which subversion, but I suspect 10.4). That makes the issue cross-platform.
can't add a solid repro, only some observation: especially when using a slow connection (I am on mobile dialup again this week), I observe that after teleport all attachments go to the center of my avatar and the center of the screen. Then there seem to come "position updates" that move those attachments and hud elements to their position. This is quite reliably reproduceable: my connection is only 300kbit, and this happens after allmost every teleport. I somehow have the nagging feeling that the asstachments (I love that word) happen when those position updates somehow get lost - for example in a combination of low bandwidth and high packet loss.
Which brings me to something I allways wanted for some time: an equivalent of the "rebake textures" for the attachments "reposition all attachments". Because there are other weird cases where attachements go astray and it can usually be fixed by a "replace outfit" from inventory to one other outfit and back - a shortcut menu option would help lots to get around that irritating bugling. I am running Windows XP and I'm having the same problems. This ''asstachment'' happens mostly when I teleport but has sometimes happened as I logged on. It is quite aggrivating having to go unattach and reattach everything so that your avatar looks normal. I myself don't really like the hair/sunglasses/shoes in the crotch look...lol.
I agree with Barney, a ''reposition all attachments'' shortcut would be wonderful and make things so much easier. I do hope this gets resolved soon, it hasn't been happening to me for very long being new to SL, but I'm sure all those having to deal with it for so long are even more frustrated. how about this one. why don't you find out how old fixed defects mysteriously return? it has to do with the programmers period. not gonna harp on this but you need a butt kicking development manager with the authority to terminate resources regardless of who they are and who they know.
Linux viewer here, constantly getting boots or hair attached mid backside after a tp. It's a random issue, so can't provide a solid reproduction of circumstances. Only that it's happening more often in the 1.18 viewer.
I see this issue in the 1.18.0.6 rev on XP Sp2 AMD X2. Have uploaded 2 screen caps.
It appears to be refresh rate related which I REPRO via changing bandwidth rate slider. A sim crossing in a loaded region is the worst case. The HUD does not recover other than a detach -reattach. I first saw the issue a few revs back but is more pronounced in 1.18.0.6. The open source viewer (Nickolaz 18) is more stable but still exhibits the HUD loss. For what it's worth, switching my ISP from DSL (ATT) to Cable (Comcast) appears to have "resolved" this issue. I don't know if it's the higher bandwidth, or if it's a latency issue, or packet loss, or number of hops, or all of the above. I haven't noticed any packet loss with Cable compared to DSL which I saw packet loss almost all the time. My DSL was 3Mbps down/384kbps up, and Cable is 6Mbps/384kbps (although I seem to be getting much higher speeds than that).
Maybe some of you can compare Internet providers and see if there's a common thread here. Linden engineers are probably sitting behind a T1 or DS3. All I had to do to reproduce this issue was to zone into a laggy area. It actually happened to me several times over the last week or so. I zone, and when I rerezz, my hair, my jewlery, and sometimes my shoes are stuck to my butt, rather than being where they were before. It's happened to my friend, Hope, too. It's gotten to the point where now I stop after I rezz, and check to see if my hair is on my head or on my butt. Incredibly annoying.
Repo is difficult because it is often related to another issue, that of lag-related involuntary flying or walking huge distances, while the network is having co-lo problems this is the time to try for a repo:
1. Log into a medium to high lag sim, preferably on a lower spec computer to maximise the chance of the involuntary distance travelling bug [Nolidae] This has happened to me in Nolidae 5 times in the last two days, during heavy grid problems, and I was not trying to create a repo for this bug report. Something similar to this happens to me quite frequently. Most often, when I TP to the welcome area, my Prim hair appears to be attached to to my rump.
Ignore my comment on not being able to fly on Nolidae Mountain as it is too high, it must have been the lag on that day.
Mercia This is still happening; it's infuriating. Seems to happen most after a teleport or when crossing sim lines. Hair and shoes are the biggest offenders, invariably appearing suddenly on my butt.
Reporting a new variant of the "hair in butt" bug, repro may not be reliable, but some of the novel features may suggest a possible line of inquiry.
Current version: 1.18.3.5 release candidate. Bug first observed in Botany Bay, sim4076.agni.lindenlab.com (63.210.156.234:13004), 58 agents in region (presumed high lag conditions). Similarities with previous versions of the bug: prim attachments position at agent target in center of avatar (when shown with Client > Character > Display Agent Target, attachments align to white axes, not blue axes, as verified with AO controlled poses). In my personal experience at least, attachments usually remain there indefinitely and do not eventually move to their correct positions (personal record time more than 15 hours; spontaneous repositioning to correct position observed only 4 times out of a total of several hundred occasions, and only after region crossings, not teleport). Novel features of this version of the bug, never seen before 1.18.3.5: whereas in previous versions the bug happened exclusively after teleports and laggy region border crossings, the bug now happens when attaching the object from inventory. Effect takes place both when attaching by click and drag to avatar and when attaching with right click > Wear AND EVEN right click > Attach to > (desired attachment point)!!! Moreover, NONE of the previous workarounds can be used reliably anymore. Detaching and reattaching the object repositions it to the central agent target, not the desired attachment point (previously reattaching fixed the problem). Attaching another object to replace the centered object likewise forces the new attachment to the center. EVEN RELOGGING NOT ALWAYS RESOLVES THE ISSUE. It often correctly positions some attachments but not others. HIGHLY SUGGESTIVE OBSERVATION: while attempting to replace the misaligned attachment by attaching another object in the same position, a dialog box pops up warning that there is already something attached there, and double checking if I really want to replace it. Previously SL never checked for this, but simply silently replaced the old attachment with the new one (barring occasional eternally pending attachment bugs). Though I have been unable to confirm this on a quick skim of release notes, this suggests to me that the dialog box in question is a new feature introduced with this release. This in turn suggests that the novel characteristics of the bug are correlated with the changes involved in the addition of this feature. I hope this correlation may provide a clue as to the nature of this bug. Update as I proofread before sending this comment: a possible variant of this bug I just observed is that an alternative failure mode is that when attaching a replacement as described above, the aforementioned dialog box does NOT show up, but the new attachment rezzes at an offset position several meters away from the avatar, thus producing the doubly surreal spectacle of a bald avatar with hair up its butt being followed like a faithful pet by a disembodied hairdo floating several meters behind. The two attachments can be separately selected and detached--that is, detaching the one will not detach the other, even though they are reported as attached at the same point. SL 1.18.3.5, OSX 10.4.10, G5 2GHz 2GB, Cable moden access through Airport router
Same "asstachment" problem here. Seen this many, many times. Many times. Prim hair (attached on mouth) ends up on the butt. The hair will not return to head on it's own. I have to detach..Strangely, thought it's on the butt, if I use the Pie Menu to detach, I have to detach from Head>Mouth, where it was supposed to be. Also, the problem does not appear to be visible to other users-the few I've asked...only in my client, I think. I can sort of reproduce thiis..usually in about 5 minutes, if I try. Flying as fast as I can (up arrow), in one direction, crossing sim boarders, perhaps doing quick reversal(down arrow) or turn after border crossing. Often associated with "Can't Stop Flying" ( Of course, a good repro would be wonderful. Meanwhile, would it be useful to report it the moment it happens? That is, suppose the next time it happens, I were to contact Torley or WorkingOnIt immediately, and, if they could, they snoop in the sim suing a debugger or some-such to collect information.
No flames please, just a suggestion. Ah this is perfect! This is exactly the issue I have been having. For me it started after I downloaded and installed the latest update 1.18.3 (5) several weeks ago. I have been able to reproduce this issue on a regular basis after logging in and teleporting at least 2-3 times. Then somone will say hey your head is missing or something. The items to me appear to be there and I will often look fine in the first 1 or 2 places I'm in but after at least 2 teleports particularly in higher lag areas it will happen. I think I get it more often because I normally wear a full prim av as my main form. Contact me and I'd be happy to help you reproduce it. This is really driving me crazy. The only thing I have been able to do that fixes it is to reselect my clothing folder with the av in it and select add to outfit and it seems to replace the several missing parts. This fixes the problem at least 60% of the time. I hope this helps.
I call it the "all attachements in the butt" bug...
It used to happen a lot with pre-1.17 versions, but i was "almost" cured in the v1.18 series (including v1.18.3.5RC), Interestingly, and in a probably directly related way, when a TP fails, detaching all your attachements allows to TP successfully (i.e. the less attachements on your AV and the more likely your TP will succeed). I yet I'm pretty new the SL and this has been happening to my Av for a while. and its driving me nuts. attachments expecailly hair, jewelry and shoes attached to my butt, groin and pelvis. Recently, my objects have been reacttach have actually inside the Av's pelvis or butt ( only visible by moving the camera to see inside the Av or because my butt is sparkling). My jewelry use to move a feet in front of me, now it's attaching to my av's lower areas too. Today, was a first when I had a mop stick though my hip.
This seems to occured mostly when I transport and it doesn't matter how many people are there. the chances seems to increase of this happening when I'm wearing alot of attachments ( ex. I'm wearing all the jewelry on my ears, neck and arms) The chances increase when I'm sitting down or dancing or doing any animations- though it doesn't help if I stop the animation before transport. This issue also occurs sometime when I come out of water or have been flying around. and my computer is a Ibook g4, btw @Sicily and others presently affected often by this: can you please provide more details about your Internet connection?
For example, are you on wireless? A low-bandwidth connection (e.g., 512 kbps downstream – your ISP can provide more details)? Do you have high packet loss? Log into Second Life, do things as normal for an hour or so, and let me know what it says in Help menu > About Second Life next to "Packets Lost". We need to establish more commonality between those experiencing this problem. So far, Residents I've talked to have had high packet loss, e.g., "5252/38071 (13.8%)". It is
I encountered this problem with 3 different ISPs and ADSL links, on two different computers and locations:
My (averaged) packet loss is well below 5% (usually around 1-2%), and I do have my QoS set properly to avoid queuing packets in the modems (and by the way, I gave SL traffic the highest priority too). I have this "hair in the butt" (also "wings on the flank" and "necklace in the air") problem since the beginning.... last June... I had it with all possible combinaions of bandwith.... and media... office LAN, wireless, UMTS. Really annoying.... Only thing i can add is the feeling that it could be really related to the busy status of the arriving SIM.
This is one example where the mantra "we need a solid, step-by-step reproduction" just doesn't work.
Anyone that uses SL fairly regularly will have had this happen to them. So in effect the solid reproduction would be: "Use the main grid for several hours every day." If this kind of thing simply doesn't happen within LL because everyone is on a direct connection to the servers or something, then you can modify that to "Use the main grid via a standard ADSL connection for several hours every day." If you add to that the points above you'd be wise to try wearing full prim hair, a decent prim pair of boots / shoes and maybe some jewellery, and make a point of TP'ng or flying in to some high traffic sims while you're in-world. There are also plenty of user provided clues above on where someone might want to start looking for problems and discarding them. I know tech problems are a pain in the neck when they don't have a "solid, step-by-step reproduction", but many tech tasks involve solving precisely those kinds of problems. PS. I may be totally embarrassed by the amount of work already put in to SL-29362 if I knew what it added up to, but I don't, and afaik I can't find out. I'm currently working on this (made some fairly decent progress already). If you are using my viewer and if you see this problem and if you want to help out with details, please email me (nicholaz at blueflash dot cc). @Fluf: I agree "step-by-step repro" isn't always qualifiable – but it's worth a shot to reasonably rule it out. I used to have this bug a lot, currently I haven't seen it (and I use SL regularly), but I know it's still out there based on complaints I keep hearing.
@Nicholaz: Your help is very much appreciated; I've let our devs know you're investigating this. I would like to propose that a feature similar to "Rebake" be added to the client - to create a command for "Reattach ALL CURRENT Attachments". The same way that the rebake issues are tricky, this problem with the crotch attached attachments is going to continue. Can we at least have a decent work around for it in the meantime?
I'm fairly confident that I will be able to fix it near the root of the problem. If not I'll take a shot at a re-attach.
the problem is also happening (very frequently) in the Windlight First viewer...
as for a solid repro, I cant help much, but it usually happens to me when I tp to GOL 4 (Sensual Elements) but I have to say.. the "attachment pending" issue, that sometimes happens afterwards , is even more frustrating.. as it forces me to relog all the time.. I like the ideia of the re-attach feature (at least for the time being or if the problem re-surfaces in the future...) I have a High Speed Cable connection and I typically get about 7600down/1156up on average and I test regularly. I have noticed a drop off in the instances of the attachments going to center and as a reminder I routinely wear a full prim av. However it does still happen and is very annoying when it does. I typically have low packet loss even when it happens but I will watch it closely. Someone previously suggested a command similar to rebake textures to force the system to unattach and then reattach all attachments. This in the interum could make it more tolerable. Right now the only way to fix it when it happens is a log out. Sure you can put your attachments back on but if you want to change av's then you're out of luck.
I am oh so happy to report that Nicholaz appears to have beaten this one into submission, running the BE-v0b client the problem seems to be vanquished!
@Torley (in defence of Fluff and in favour of reading earlier posts), see my repo on comment date 9th August, this is for me now and always, an issue to do with heavy lag and region crossing. I have had flexi-hair dissapear in lag without crossing a region, but I have only ever had a hairy butt or got booted up the bottom when region crossing.
This is reported fixed by users of my viewer. Patch is attached. There are basically two attachment problems, both resulting from the way BOOL LLViewerJointAttachment::addObject handles situations where an attachment already exists. Sometimes an existing object is attached again (exactly same pointer/object) but left in the center of the avatar, because it isn't routed through setupDrawable(), thus becoming child of avatar but not linked to a joint. Sometimes new objects are sent as replacements for old (packet order comes into play here, I have seen removeChilds(old) after addAttachment(new)) leaving ass-tachments or copies of attachments hovering losely around the avatar. That's cool, thanks for the diagnosis. During your investigation did you come up with any good repro recipes which I can give to QA?
Nope, no good way to QA that because you need packet loss to repro. The whole thing was done through turns and turns of user logs and special compiles, adding more and more logging over time to get an idea of the state of the objects. I still have logs, which might convince a developer who is willing to invest efforts, but I doubt it will do anything for a QA guy looking at it from it from the outside. The only place I ever saw it myself was at Ahern Welcome Area when it's busy. But it's extremely tedious to locate the situation in that buzzing place. Once I knew what to look for, I made a special version and added extra code to notify me when it happened and for which avatar and then hopped around accidentally stumbled over it at Ahern. But that was during times last week when you had grid problems anyway, I normally don't have packet loss, but got some of it there ... but only had the 2nd form (hovering copies, differing object pointers) for other avatars, not for my own. Nothing consistent. I do have users who say they are having it consistently (and one who was able to prove it because he sent me a log of it within an hour when I needed it) and who say it's fixed now and I trust them. Not sure if that's any good for your QA though. /me points to his earlier comment.
Some bugs in SL do not have reproducible scenarios. The only way to test Nicholaz's work is to roll it out and see if the users are happy. If QA are going to shoot down potential bug fixes because they can't easily reproduce the initial bug, then QA is a barrier to fixing bugs in SL not a benefit, and we will be stuck with many many bugs that don't have "good repro recipes" for a long long time. Even if your work isn't the silver bullet Nicholaz, many thanks for trying so hard. I hope it's not a wasted effort. @tofu: bottom line: go to Ahern with a high prim avatar and walk in circles in the central area at busy times. I get consistent packet loss there. Look for ass-tachments (e.g. if you can recover from "walking through" ground) or hovering attachment-copies on other avatars. That's the closest to a repro I can get.
@fluf: Thanks for the vote of confidence, but the effort won't be wasted either way Have QA tried using something, like NISTnet for example, to test on simulated lossy WAN links?
Not specifically something I have experience of, but would seem a fairly obvious step when developing such a widely distributed application, to observe how performance degrades in a worst case situation. Hi Nicholaz,
How does this patch look? The fix is to the same site as your patch, but attempts to use existing code to properly perform the implicit detachment from the occupied slot. I've tested the ass-tachment case with it - it's fine - but have never been able to repro the floating-attachments case; as you say that you find the floating-attachments case easiest to repro, perhaps you could try this out. Thanks! Still happens in some of the cases (see double-attachments.png) But your version just detaches it from the joint (a normal detachment comes from deep down from killObject through avatar's removeChild through avatar's detachObject. into joint's removeObject). That's why I was going for the kill (in case the detach packet gets lost entirely). And when the object pointers are same (in the typical ass-tachments), the existing one (which equals new) is not properly attached alredy, i.e. the object->mDrawable->mXform's parent isn't the joints xform. This is the first thing that setupDrawable does, and I'd expect an existing attachment to have it linked/parented that way. I don't know why, maybe it's somehow reinitialized when it comes in again, but it did look fresh from what I saw it, that's why I did not try a removal first in that case. Applied internally - thanks for the reports and the fix!
Sweet!
Merry Christmas  Go on ... roll it out in the next release candidate .. you know you want to! This issue has been bulk changed to fix pending.
The Same thing has been happening to me.
This seems to happen to me when I teleport, it randomly happens, all my attachments end up in the middle of my av. Hardware Overview: Machine Name: iMac GeForce FX 5200: Chipset Model: GeForce FX 5200 The issue seems resoved if you use the Nicholaz viewer. http://nicholaz-beresford.blogspot.com/
 What I do not understand is how it is possible that one person CAN resolve the issue while a complete company with dozens of people working on the viewer cannot. Anyway I know who to nominate for the first SL Nobell Price Thanks Nicholaz for this fix and others. And even more for giving back the "old" user interface
AMD Geode NX 1750, 1 Gig ram, NVidia GeForce NX7600GS 256MB This is still happening to me with the 1.19 79185 Windlight viewer. But for the first time, it's happening when I fly across sim borders.
 Yep.
Despite the long list of bug fixes and enhancements in 1.19, for some reason this one didn't make it in to the release. It's now pretty much the only reason I stay on a non-official patched 1.18 viewer rather than go back to trying the WindLight and RC releases. Shrugs .. Gives the Labs one less source of crash reports I guess. Well there's a surprise. 1.19.0.4 makes it to the official client stage without this one being fixed???
The patch here works guys and doesn't appear to cause any stability problems. Wonder how long it'll take for 1.19.1.x to become a replacement official viewer and what the odds are this one will be fixed? /me shrugs and sticks with a patched up viewer instead. It's definitely in 1.19.1.
Just a hypothetical but if the object is dropped to the ground and the message gets lost then the user tries to attach another attachment to that position wouldn't it result in the object not appearing to be dropped? That is since the object is getting killed.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Attachments sometimes move to the centre of the body after region cross/teleport
