Scripted Attachment and TP issues

Has anyone ever heard tell of the folllowing issue? Asking on behalf of a friend.

His customers are saying that they have problems tp'ing, usually into a busy sim, when they are wearing one of his scripted objects (usually a designer item, for which someone else has made the script for him.)

I tend to think it's just regular TP issues, and that they could be stark naked and they'd have the same TP issues.

It can absolutely make a difference, especially if there are multiple scripts or a lot of data to carry around. All that gets packed into a blob along with the basic prim data on sim exit, then has to be unpacked and rebuilt with state restored on the other side. A whole bunch of dumber prims can interfere with teleport success too, but script data tends to be meatier.

For something like a clothing item piled with resize scripts, a good plan (at least if it's copiable) is to give an option to delete the scripts once the buyer is satisifed that the item fits.

and of course they'll die in no script areas in most cases (take controls type scripts are an exception)

I've actually had this problem way back with objects that have open listens..I really don't know why that would make a difference, I haven't researched it or anything - my assumption would be that the listen would be inactive during a tp and reactivated with the state of the script when landing occurs. However, I did personally have that problem quite a bit with listening attachments.

I have noticed that lately there are more & more scripted "clothing" items appearing on the market. In fact I have one full suit of armour which when I took a close look at it, the different pieces had over 20 scripts running !

It's INSANE !!! So upon further investigation, these things had open listens and chatted to adjust sizing, colours etc... Normally I don't have issues but when wearing this I suffered issues. After deactivating all the scripts most problems were solved.

I believe in part, that scripter's need to seriously consider where & how the script is to be used, and I think most do when they know what the intended usage is. Lot of amateur coders out there though that cobble things together.... (BTW: I've been coding for over 20 years in numerous programming languages & platforms)

For instance, in a Linked Object (ie: Boots ), you can change colours / textures / sizes etc... by using llSetLinkPrimitiveParams. No receivers needed!

Sadly, some folks just grab any old script they come across and plug it into their product without understanding the consequences, most notably Bling, & Colour Changers. Many older "Listen" scripts also listen on PUBLIC_CHANNEL ( 0 ) for the Owner, but these have to filter EVERYTHING being heard on 0... Imagine in a club with 40 avatars chatting ! EEEKKKK

Well, I've certainly had my share of TP issues over the years. I just never thought to attribute them to any scripted c... er, coat, that's it! coat! attached to me. What telltale signs do you get that let you know that it is your scripted attachments that have interfered with your teleport, as opposed to general TP issues at that moment on the grid?

True, when I first started coding in LSL my clocks had 2 open listens all the time. After a while I sat down and did a complete rewrite, and they now have no open listens. I open a single listen on touch for the menu choices to be heard, then communicate with the other script with link messages. I think much of the 'bad scripting' out there is from newer coders not writing particularly tight code, as well as many builders using whatever they can find, and using it liberally without considering the consequences of splashing scripts all over the place.

I think a partial cause of this is that most residents of SecondLife don't know how to properly configure a script they got from someone else.

A common error I've seen is with new residents using the "Realistic Car" scripts.

Instead of putting the wheel scripts in the wheels, the main script in the root prim, etc., they just dump all the scripts into a random prim. Realizing that it doesn't work the way it should, they seek other scripts, which usually turn out the same as the first. What you end up with is a modge-podge of random scripts from different creators that sometimes aren't even meant for the same thing.

This is most prominent with vehicles, but I'm sure it happens with other common types of scripts, too.

If it's an attachment thing it will (usually) be reproducible, at least in that time period and with the same pair of sims. Unfortunately, this being SL, there aren't any expected error messages to finger it conclusively on the viewer side :/ That is: TP fails from sim A to sim B. dumping attachments lets the teleport succeed. Go back to sim A, try again after reattaching the same stuff, it fails again. Lather, rinse, repeat.

If the communications remains bogged down long enough, you may get lucky and have time to narrow it down to specific attachments by process of elimination; but even in good times, teleports will go noticeably faster with fewer/simpler attachments just because there is less stuff to scribble out, transmit between sims, and re-rez from scratch.

There is some JIRA chatter on this problem, a recent one is http://jira.secondlife.com/browse/VWR-12049 but there are lots of others that don't seem to get much coordinated attention.

I'm glad to see this being discussed. More Scripters and Residents need to be aware of the potential issues of excessive script wearing. I often have to diagnose this type of thing when customers complain my attachment stopped working, and it turns out it's due to some other excessively scripted item causing the issues on TP.

Please make resize scripts removable. I saw one system that removed them after 3 hours of wearing, no matter what, to get around the issue of consumers who don't realize they should be removed. I thought that was an excellent idea.

And please try to use llSetLinked* functions rather than putting a script per prim (like the 600 prim boots I bought one day. Needless to say I'll never wear them now that I know they have 600 scripts in them). Sure it's slower, but you're trading a few seconds for a host of issues elsewhere.

Something to think about.

wow earning that title with a vengeance eh?

do note, some prim setting are inaccessible via Link* functions (like particles), and reading those settings is impossible that way because there are no GetLink* functions (but you can save then as variables)

Yes, I think one thing LL could do to help scripters/creators out would be to expand the number of *Linked functions. But in the cases where they are available, I always give using them preference. I'm in fact retrofitting many of my older items to start using them via upcoming updates. The dark cloud of Script Limits looms on the horizon...