Attachment misbehaves in the standard viewer only

I have spent the day getting very frustrated with a scripted attachment and could use the brilliance of your collective minds. My problem falls in the crack between this forum and the Scripting Tips forum, but I hope people see the post no matter where I put it.

I made a simple one-prim object that plays a random sequence of sound clips when it's worn. It looks like a rather ugly piece of jewelry, attached on the right shoulder. When anyone using the Emerald viewer wears it, it attaches where it is supposed to. Anyone else with the Emerald viewer sees it there too. No problem.

HOWEVER, anyone with the standard SL viewer sees it attached to the left thigh, and sees everyone else's attachment on the thigh too. Worse yet, people with the standard SL viewer can't detach the object because it isn't highlighted in inventory as being worn at all. Still, no matter who wears the object and no matter which viewer they use, the object plays its sound clips properly, as designed.

I have never encountered this sort of behavior, and I'm at my wits' end trying to fix it. This is part of the ambient sound environment for an exhibit that is supposed to be opening tomorrow, so it's more than a curious puzzle. Is this some very weird server borking, or is it a problem in the standard viewer, or is it something I can correct? If I can ..... how?

could this be a side effect of the extra attachment points that Emerald allows? standard viewer people can replace/add a file that allows them to see the extra attach points the same as in the standard viewer, but otherwise the behavior is different.

I thought about that, but the shoulder is a common attachment point in either viewer. And it's not just a matter of where it attaches. Why should someone with the standard viewer see MY object attached incorrectly? And why should HER object not even show in inventory as being worn, even though I can see it being worn correctly if I'm using Emerald? And why does the script work for ALL of us?

1. Someone with the standard viewer sees YOUR object in a different place because it doesn't understand the Emerald instructions for the set attach-point. It's a matter of "draw it WHERE???"

2. I'd imagine that inventory in the standard viewer is acting much the same way - just failing to recognise the Emerald settings.

3. YOU can see HER object fine because, obviously, Emerald does understand the Emerald settings.

4. The script works because it's unaffected by where the attachment is drawn.

I'm with Void but instead of making everyone else hack their computers ask someone with the standard viewer to 'attach to' a valid position. If they give it back to you like that everything should be fine for everyone, including those using Emerald.

I was going to suggest something along the lines of what Indeterminate said. I would submit there's no need to involve another person, though. Simply download the standard viewer yourself, use it to attach the object to a standard attachment point, and then you should be all set.

If after doing that, it no longer works properly in Emerald, then I'd suggest providing your customers with two versions of the object, each clearly labeled, "Works with ______ viewer only."

I'll give it a try and let you know. Dunno why I didn't think of doing that. .....

WooHoo!!! It works. As Chosen said, since I have both viewers I could do the exercise myself. I attached the object while I was using the standard viewer, detached it, and then logged out and back in with the Emerald viewer. It attaches correctly now with BOTH viewers.

I am SO happy. Thank you Void, Indeterminate, Chosen! You have made my day.

BTW, Chosen...... This is the project I talked to you about the other day. Your suggestion for handling the sound files was right on target. Thank you for THAT too.

One of the problems with the viewer being open sourced is that some people just can't live without the fact that the standard viewer doesn't do something, so they hack it until it does DESPITE the fact that the feature is not coded into other viewers (or the server for that matter). I'm beginning to see all sorts of oddball attachment oddities like this because alot of people are using emerald now (bad idea imho), and that's why we're beginning to see these issues.

If you're going to be a content creator, it's best to do all your content creation from the latest stable release of the standard LL viewer. It will avoid these sorts of situations all together.

Oddly, people seem fine with the fact that THEY can see their attachment where they want it, but don't seem much to care what other people see, as long as they think it's OK, then it's OK.

Glad to hear everything worked out, Rolig.

Yohan, I couldn't agree more with your post.

Yeah, maybe LL should setup some guidelines for viewer developers to follow, although I doubt that the hacks that force viewers to do things SL wasn't designed for would follow them. Perhaps LL should also force a pop up window on all non-LL viewers saying 'use at your own risk' or something along those lines to let people know that 3rd party viewers are non official LL software and subject to not working properly. I'm guessing the first words out of Live Help's mouth now-a-days is "what viewer are you using?" since they're probably starting to get peppered with help requests from unknowing users of 3rd party viewers.

LL really opened a can of worms by open sourcing the client. It seemed like a good idea at the time, but now it's hard to say. Sure, there's alot of neat things that 3rd party devs have come up with, but others make me wonder sometimes. The texture preview in Emerald for example. While it's a nice idea, I'm guessing that it's probably pretty hard on the asset servers to fill out hundreds of previews when people browse using it. One would think that perhaps LL should come up with a texture previewer themselves, and modify the asset servers to feed thumbnails rather than the full texture so the hit isn't so hard. While a texture previewer is nice, without the ability of the asset servers to feed thumbs, it's a bad idea that can clog up and slow down SL. Certainly something I would consider if I were modding the viewer source, and would likely reject without access to thumbs, but that's just me. Seems to me that most coders in SL either LSL or client devs don't take that sort of stuff into consideration when coding. I'm no Void Singer sitting off in a corner counting cpu ticks, but I do at least consider the overall picture when coding, and try to make my code as tight and efficient as possible, and not be such a resource hog. (Void that was said lovingly and with the utmost respect!!!).

/me looks up from her counting: huh, what's that? I gained a reputation without looking?

I do wish that was a feature they'd left out (although it'd be nice if it found it's way into the next forced viewer update).... it's just too buggy between viewer versions..

I couldn't agree more, Johan, now that I've bumped up against this myself. I guess I have been lucky in the months since I started using Emerald, but it simply hadn't occurred to me that there was a problem with attachments. As I was trying to solve this problem yesterday, I was focused on everything else that it could have been. Too close to the issue to see it for what it was, I suppose. I imagine a lot of content creators will be just as slow to pick up on other hidden challenges posed by open sourcing. I am just grateful for the early wake-up call. Thanks again to everyone.

Of course i agree, that having too many unnoticed derivations from the "standards" (huh? standards?) might not be good, but it is not bad either. I call that evolution (to some extent).

Also if the SL viewer would have remained closed source, then would we have been able to gain all that knowledge about how things work together in SL? Wouldn't we instead sit here, constantly mourning about the bad lindens, who are not able to bring us a stable viewer ?

Well either Emerald is a consequence of the fact, that LL fails to create the "fail proof client" or LL has open sourced the viewer in order to let people create things like Emerald, which in turn is good for LL due to unpayed development, unpayed testing, unpayed creativity...

Wichever reason was behind opening the viewer, i have the feeling that it was the better way to go. And people should be aware that they are operating on their own risk, when they decide to use and or support a third party tool.

BTW: I think, that allowing additional attachment points was a very bad idea! Hopefully the Emeralds will learn from that ... The builders do (here at least...) ... And evolution theory predecits, that bad development will die out ...

Yep, I even said in the original post that it seemed like a good idea at the time. I think at the time, Cory Linden likened himself as the Tim Berners-Lee of the "3D Internet", and pushed Philip to open source the viewer thinking that the wider development would produce newer, better features. I don't really think it was so much them thinking that they'd get free development and creativity although I suppose that thought might have crossed their mind, and, they certainly accept bug fixes and new ideas for sure. The whole open sourcing issue comes up in the now infamous Hitler Explains Second Life video.... lol,

http://www.youtube.com/watch?v=Gy9hQDT6fhI

actually at the time of the open sourcing there was a system in place to submit patches to the standard viewer, both for correcting bugs, and for creating new features... but LL found themselves unable to keep up with even that moderate flood, between QA testing and all the new ideas... so I can see both things being a push towards the open source, but I think that leveraging open source testing really sealed the deal for them.

and for that part it has helped leaps and bounds in trapping and fixing quite a few problems... and many of the new creative features work just fine... but much of the creativity is now to a point where introducing those features produces incompatibilities with the basic standard...

I don't lament the open sourcing so much as the level of initial exposure that revealed so much unvetted communications with the server... but then LL had already been in the habit of exposing the wrong things, while hiding the right ones.