|Anonymous | Login | Signup for a new account||2020-09-29 15:47 PDT|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006581||opensim||[REGION] OpenSim Core||public||2013-03-21 22:10||2019-02-06 11:28|
|Product Version||master (dev code)|
|Target Version||Fixed in Version||master (dev code)|
|Summary||0006581: Some attachments refuse to attach on login|
|Description||Some 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 Reproduce||I 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.
|Tags||No tags attached.|
|Git Revision or version number||r/22414|
|Run Mode||Standalone (Multiple Regions)|
|Environment||.NET / Windows64|
|Attached Files||mantis_6581_01.txt [^] (10,419 bytes) 2013-03-29 11:00 [Show Content]|
|Does this happen only if you are trying to use multi-attachments or with any single attachments on attachment points?|
|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.|
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.
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).
|Please try git master 23ae4c0a, I've fixed a number of things where were causing problems for me in v3 viewers.|
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.
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.
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.
|For anybody else reading, extra attachment debug logging is enabled with the command "debug attachments 1" in the OpenSimulator console.|
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 :)
@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 :-)
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 http://sldev.free.fr/forum/viewtopic.php?f=4&t=1201 [^]
|Have not seen this issue for a good while; Seems to be fixed|
|Marked as Resolved but never closed, can be reopened if needed.|
|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|