Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006581opensim[REGION] OpenSim Corepublic2013-03-21 22:102019-02-06 11:28
Assigned Tomewtwo0641 
PlatformOSOS Version
Product Versionmaster (dev code) 
Target VersionFixed in Versionmaster (dev code) 
Summary0006581: Some attachments refuse to attach on login
DescriptionSome attachments refuse to attach on login and will refuse to attach manually via inventory. Relogging sometimes alleviates the issue as well as teleporting or crossing to another region. Sometimes it doesn't.
Steps To ReproduceI am unable to consistently reproduce this issue as it appears randomly but it happens fairly common enough to be able to run across it after a few login attempts and teleport/region cross attempts.

However one of the factors in my testing that I am noticing is that the presence of scripted attachments seems to make this happen more often than simply using all non scripted attachments. (I have been testing with 5 scripted attachments with a total of appx. 20 - 30 scripts or so) But I have observed this in cases where none of the attachments are scripted as well.
TagsNo tags attached.
Git Revision or version numberr/22414
Run Mode Standalone (Multiple Regions)
Physics EngineODE
Script Engine
Environment.NET / Windows64
Mono VersionNone
Attached Filestxt file icon mantis_6581_01.txt [^] (10,419 bytes) 2013-03-29 11:00 [Show Content]

- Relationships
related to 0006577closedmewtwo0641 Using an AO while crossing to another region results in stuck walk animations and general animation weirdness 
related to 0006579closedmewtwo0641 Attachments sometimes show up "floating" in world or are invisible 

-  Notes
justincc (administrator)
2013-03-25 15:05

Does this happen only if you are trying to use multi-attachments or with any single attachments on attachment points?
mewtwo0641 (reporter)
2013-03-25 20:51

From what I can tell, it does not seem to matter whether I'm using one attachment per point, multi attachments per point, using wear, or using add.
AdelleF (reporter)
2013-03-27 14:20

I can confirm this. This seems to have been introduced with the multi-attachment code recently introduced. That said, I am seeing this with only one attachment per attachment point. I have not tested with multiple attachments per point.

The attachments are pretty much the same attachments I have been using for months (hair etc.) They are not scripted and relatively low prim. It appears to affect attachments to the head (ears/nose/skull) more than others, but that could simply be that my avatar often wears attachments on these points more than others (jewellery etc.)

It seems pretty random as to when or what attachment points are affected. Most times I can log in OK. Other times it will affect only one or two of the attachments. Trying to attach the same again from inventory silently fails. The viewer doesn't attach them nor detach them. Replacing the attachment with a different one at the failed attachment point remedies this and then the old attachment can be worn again. Sometimes simply relogging will sort this and the attachments are attached OK.

From OpenSim.log
2013-03-27 21:02:50,416 DEBUG - OpenSim.Region.CoreModules.Framework.InventoryAccess.HGInventoryAccessModule [HGScene] RezObject itemID=9ccafbbe-0adf-47cd-a3ac-1136ef90639c fromTaskID=20b32db3-0fba-4ffe-b478-0046bc463470
2013-03-27 21:02:50,909 DEBUG - OpenSim.Framework.AvatarAppearance [AVATAR APPEARANCE]: Ignoring attempt to attach an already attached item 70ab6586-e96e-45d7-9b2c-08e0bcd5986a at point 142
2013-03-27 21:02:50,913 DEBUG - OpenSim.Region.CoreModules.Framework.InventoryAccess.HGInventoryAccessModule [HGScene] RezObject itemID=9ccafbbe-0adf-47cd-a3ac-1136ef90639c fromTaskID=20b32db3-0fba-4ffe-b478-0046bc463470
2013-03-27 21:02:55,852 DEBUG - OpenSim.Framework.AvatarAppearance [AVATAR APPEARANCE]: Ignoring attempt to attach an already attached item 9ccafbbe-0adf-47cd-a3ac-1136ef90639c at point 145

What I find particularly odd about the above log are the attachment point numbers (142 & 145).
justincc (administrator)
2013-03-28 19:40

Please try git master 23ae4c0a, I've fixed a number of things where were causing problems for me in v3 viewers.
mewtwo0641 (reporter)
2013-03-28 21:28

On git master current this seems to be working a bit better now with single attachments on single attach points if I use Replace Outfit from the context menu (Assuming that the folder to be replaced with or worn does not contain attachments that would go on a single point multiple times I suppose). I am still seeing the issue when using multiple attachments on a single point(s) or when using Add/Wear from the context menu (I have been testing with Add/Wear entire folders rather than individual attachments mostly).

A strange thing that I have noticed is; if I am seeing floating attachments and I cross over to a new region, my missing attachments will now be attached, but my floating attachments that were in the previous region will have followed me into the new region still afloat even though the viewer will have a copy of these attachments now attached to the avatar.
AdelleF (reporter)
2013-03-29 11:00
edited on: 2013-03-29 11:05

I'm afraid this is pretty much the same as before your fixes, Justin. Again just one attachment per point and seeing the same random effects. I turned on the attachment debugging you included and have attached the log here (mantis_6581_01.txt).

ETA: The failed attachment appeared to be the last attachment rezzed in the log, towards the end of log file.

justincc (administrator)
2013-03-29 16:38

AdelleF, thanks for posting the log with the attachment debugging turned on, that was very perceptive of you and gave me the information I needed.

Please try git master 023faa2. If there are further logs to post, then please turn attachment debug information on again. With git master 023faa2, the 'ignoring attempt' calls are actually normal and will hopefully signal that we are ignoring viewer calls that we are already performing simulator-side.
justincc (administrator)
2013-03-29 16:39

For anybody else reading, extra attachment debug logging is enabled with the command "debug attachments 1" in the OpenSimulator console.
mewtwo0641 (reporter)
2013-03-30 03:32

This seems to be quite a bit better now. I've done a few quick tests on latest master on both Phoenix and Firestorm and attachments appear to be behaving better now in general.

One thing that my friend has noticed while helping me test is that on occasion attachments may have their position information slightly skewed and end up not in their proper positions resulting in having to reposition them. I have not been able to reproduce for myself however. I will keep a look out for this and see if it pops up again.

I didn't think to try the debug attachments command and post results here... Good call on that AdelleF :)
AdelleF (reporter)
2013-03-30 03:56

@mewtwo0641: I would suggest to your friend that he/she detaches all attachments, logs out, logs in, logs out again and logs in again. Then reattach attachments and try again. This should make sure that any attachments are 'flushed' from the relevant table in the database, for want of a better expression. If attachments are not attaching to their proper coords I suggest a new mantis is opened for that specific issue.

Tested 023faa2. In 10 out of 10 login attempts all attachments rezzed and attached properly. I reckon it is safe to assume this is resolved and this mantis can be closed.

Thanks Justin :-)
Clinton (reporter)
2013-08-07 05:20

I was going to create a new Mantis report on this but will post here. It may or may not be related. I was having trouble with attachments detaching after login. Using Cool VL Viewer, Henri Beauchamp added some Debug Tags to try and find the problem. I thought it might be Cool VL Viewer. He found that it was 2 server side bugs. Here is his explanation:

AHHhh !... Yes, I can now reproduce the bug, and it is indeed a server-side bug (in fact there are even two bugs !): for a start, there should not be any reattach message sent by the server to the viewer after a TP !!!... TPs don't attach or reattach objects on avatars... This is a protocol violation when compared to what happens (and always happened) in SL.

In such a case (the viewer properly diagnosing it as "same object reattached"; see the corresponding lines in the log), the viewer yet obeys the server and removes the object from the attachments list, then it waits for the addChild event from the server that normally always follows such an attach event to re-add the child object (the attachment is one of the avatar's child objects) at which point the object is re-added to the attachments list (and to avoid annoying flickering effects, the viewer doesn't de-render the attachments while it awaits for the server addChild event)... Problem: OpenSim doesn't send any addChild event after such a duplicate attach event (probably considering that since the object was already attached, it doesn't need to do it), which is another OpenSim bug.
The viewer then got missing attachments in its internal attachments list (causing the server and the viewer to disagree on what the avatar is actually wearing, and also causing rendered attachments to become 'phantom' ones for the viewer, which could well cause other issues as far as scripted attachments are concerned), and my outfit saving code properly removes the entries for these "removed" attachments...

I implemented a work-around for this server-side-double-bug, that seems to be solving the issue. This work around will be part of the next releases.

Complete thread is at [^]
mewtwo0641 (reporter)
2018-09-16 07:40

Have not seen this issue for a good while; Seems to be fixed
BillBlight (developer)
2019-02-06 11:28

Marked as Resolved but never closed, can be reopened if needed.

- Issue History
Date Modified Username Field Change
2013-03-21 22:10 mewtwo0641 New Issue
2013-03-21 22:12 mewtwo0641 Git Revision or version number => r/22414
2013-03-25 15:05 justincc Note Added: 0023694
2013-03-25 20:51 mewtwo0641 Note Added: 0023696
2013-03-27 14:20 AdelleF Note Added: 0023707
2013-03-28 19:39 justincc Relationship added related to 0006577
2013-03-28 19:40 justincc Note Added: 0023717
2013-03-28 21:28 mewtwo0641 Note Added: 0023720
2013-03-29 11:00 AdelleF Note Added: 0023723
2013-03-29 11:00 AdelleF File Added: mantis_6581_01.txt
2013-03-29 11:01 AdelleF Note Edited: 0023723 View Revisions
2013-03-29 11:01 AdelleF Note Edited: 0023723 View Revisions
2013-03-29 11:05 AdelleF Note Edited: 0023723 View Revisions
2013-03-29 16:38 justincc Note Added: 0023725
2013-03-29 16:39 justincc Note Added: 0023726
2013-03-30 03:32 mewtwo0641 Note Added: 0023731
2013-03-30 03:45 mewtwo0641 Relationship added related to 0006592
2013-03-30 03:49 mewtwo0641 Relationship added related to 0006579
2013-03-30 03:56 AdelleF Note Added: 0023734
2013-04-02 01:21 mewtwo0641 Relationship deleted related to 0006592
2013-08-07 05:20 Clinton Note Added: 0024255
2018-09-16 07:40 mewtwo0641 Note Added: 0032948
2018-09-16 07:40 mewtwo0641 Status new => resolved
2018-09-16 07:40 mewtwo0641 Fixed in Version => master (dev code)
2018-09-16 07:40 mewtwo0641 Resolution open => fixed
2018-09-16 07:40 mewtwo0641 Assigned To => mewtwo0641
2019-02-06 11:28 BillBlight Note Added: 0034370
2019-02-06 11:28 BillBlight Status resolved => closed

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker