Cool VL Viewer forum

This may be coincidental, but since upgrading to Cool VL Viewer 1.25.0 (30), I'm finding that double-clicking attachments sometimes (but not always) leads to their being attached to the wrong attachment point, rather than the last place they were attached to. It doesn't happen with all attachments, but results for any given attachment appear to be consistent. (That is, if a given attachment is affected, it always ends up at the same incorrect point, even after it's been attached to another location.) For affected attachments, this happens whether the attachment is double-clicked, or I right-click it and select "Wear" or "Add"; the only way to get it to go to the right place is to right-click it, select "Attach to," and select the attachment point manually.

Is this a server issue that just happened to hit at the same time, or is it somehow related to the client?

(I generally change outfits on a LeTigre sim, which may or may not be relevant.)

I never encountered this bug, but it is indeed a server-side issue: "Wear" makes the viewer ask to the server to attach the object on its default attachment point, and it's the server which replies and orders to the viewer to rez the attachment on the corresponding point...

This bug was present in some former "Magnum" server releases (see this JIRA issue): perhaps it crept in Le Tigre too...

Your best bet is to first reproduce the bug with one of LL's official viewers (try v1.23, since it's still "supported" by LL and will not clutter your inventory with the stupid new system folders like v2 would), then report the bug to LL (if you report it straight away, mentioning the use of a TPV, they will dismiss your report, even though it's a server side bug).

Good to know; I'll check to see if the replication method on that JIRA applies in this case too...

Thanks!

Hello,
i use the Cool viewer for long time, because i love it.
But, Samantha are right, attachment going wrong sincs Coolviewer Ver. 1.25.0.29, the Coolviewer 1.25.0.25 are ok.
I think i know the problem, because i have examined a bit.
The Coolviewer 1.25.0.29 and all the newer ones looks in to the name of the attached thing and if find for example Top in this name,
then it will attach automaticly to Top, this a Hud place.
So if a prim bra have name red top for example, it will be attached automaticly to Top in Hud place.
This very unfortunatly, but, i think because version 1.25.0.25 work correctly, must be a change you have made in the next versions.
I would very happy if you can change this and make work like the Version 1.25.0.25, this version do not look to fitting names as attachment points.
Hope this can help you vor the next udates, thank you for this realy good viewer, i love it, specialy the new version 1.26.0.1, but only without this bug .

Hi Rieko

Hello again,
i add the importand information, that seems that the bug are in RLV (Restrained Live).
If i switch RLV off attachments will work nice.
If i switch RLV on, then the bug appiers.

Hi Rieko

Yes, the behaviour you are reporting is not relating to the bug Samantha was telling about (and that was a server side bug, since resolved).

The behaviour you describe is not a bug either, it's a feature of RestrainedLove which tries to figure out what is the default attachment point for an object from its name when you attempt to "Wear" it.

This is done because there is alas no way for the viewer to know what is the default attachment point for an object (this info is only stored in the asset server and the latter only transmits it to the sim server): normally, when you "Wear" an object, the viewer simply sends a request to the server to rez and attach the object on the default attachment point; the server in turns replies to the viewer telling on which point the object was attached (with the possibility that other, previously attached objects were kicked from that point as a result), and the viewer must comply.
Since RestrainedLove must attempt to avoid kicking "locked" attachments, it tries and guesses what is the attachment point to use from the object name, and when it finds the name of an attachment point in that name and only if the corresponding point is free of any locked attachment, then it sends an "Attach To" command for that object and point instead of a "Wear" command to the server.

What may have changed however, is that older RestrainedLove versions were only doing that check for objects the #RLV folder, and that it now works for the whole inventory.

This said, it is true that this feature is sometime annoying, because some attachment points got very simple and very common names that could be part of an object name while not referring to an attachment point ("top" and "bottom", for example, are such simple and common names that are far from specific to attachment point names).
I am currently testing a modified algorithm that only retains attachment names when they are enclosed between parenthesis (which is already the convention used by RestrainedLove when it adds the attachment point name to the names of attached objects held in the #RLV folder).

This should avoid conflicts in most cases. If all goes well, this change will be part of the next Cool VL Viewer releases.

The new attachment determination policy has been implemented in today's releases (v1.25.0.37 and v1.26.0.3).