skyboxes

Hi guys.....anyone able to offer a suggestion.....
I have a skybox over my land. If i rez a box and sit on it...i can adjust the z co-ords to take me up. No problem.
Today...i rezzed a box to take a friend up...and when ever she sat, I was subsequently unable to change the co-ords to send her. Even me sitting first made no difference...as soon as she sat, the figures reverted and refused to shift.
Any help gratefully received!!
Vix

She may be wearing a scripted object that prevents it.
I've found my Fran watch prevents it...

cool....I'll try that suggestion....many thanks! x

if they're wearing anything with a timer every time the timer fires the coordinates selected in the edit window will reset and unhighlight if you were trying ot change them at the time.

ah...which is exactly whats happening......thanks all.

And I SOOOO hate that! That bug has really gotta be fixed. Everyone that sees it, report it.

its noe the timer itself, its the object update (moving the face of the watch) that does it.

Objects are treated as basically 'whole' entities, if any piece of a link set changes, such as a watch dial, changes... the entire link set is re-sent to the client as an update, superceding all other data that the client has that hasn also been sent to the sever already.

When an avatar sits on an object they technically become part of the link set of an object, so any time the avatar has an object update, the entire object resends all its data back to the client

This is also why sitting on a spinning object, while wearing a watch, or anything else that pushes updates out, will constantly reset the spin of the object, or re-set certain particle effects etc.

The only real way to fix it is to setup guidelines as to which updates force an entire link set to update, and which updates will only force the child of a link to update. I'm not sure how LL specifically handles that but it could be abit of a pain. and prolly take awhile.. tho i think it really should be done as theres really no good way we could get 'around' this problem on our own

OMG.

This is a bug, right? Please don't tell me that it's meant to work like that by design.

Because if that is what is happening, then it would explain totally why my prefilled cache re-access tests involving repeated teleports between two fixed telehubs (with no avs present other than my own) are showing 15 seconds of object reloads after just 1 minute of absence from a zone. In a sensible design, one would expect just one round-trip time's worth of client-server traffic, enough to inform the client that nothing has changed since the last visit and that therefore everything in the cache can be reused. What I see is about one hunded to one thousand times slower than it should be, depending on one's RTT.

A Linden who I can very reliably say is extremely well informed did suggest to me that this was script-related traffic, but without giving details. I'm still trying to construct some tests to check out what he said.

If what you describe is the way it was designed to be then we have before us two things: (i) an appallingly bad bit of design, and (ii) a golden opportunity to improve massively the perceived responsiveness of SL. Scripts are ubiquituous in SL. If their internal state changes virally contaminate every prim in their link set, then you might as well hard-code a MEGA_BIG_LAG_HERE(10000000000) directly into the implementation.

Eltee, the info you gave sounds extremely authoritative. Is it so, or just a well-informed guess? Because if things are as you describe, we need a massive campaign to get this addressed and corrected.

you misunderstood me

wat is happening is not that the script has a state change, causing a huge reload.. its that the script is changing the state of an object, causing a huge reload

aka turning the dial on a watch face

or updating a particle emitter

or changing somethings' color

or changing something's transparency.

ANYTHING that updates the properties of an object, causes the entire link set the object is part of to be pushed to the client.

In fact one of the most lag-inducing scripts i've seen of late is a 'fading' photo holder that fades between two images... each and every single one of the 100 steps of the fade causes the entire object's state to tbe re-sent to the client, theres two of them, cyclcing once every 3 seconds... so this thing is attempting to send approximately 4000 individual updates per minute, per avatar, for every single avatar within range of it.

The amount of lag this is causing the sim, and everyone in it, is pretty crippling

Yep Eltee, that's exatly how I interpreted what you said the first time.

The problem can be split into three parts, with corresponding questions:

1. First of all, any event that triggers an event handler in the script can result in one or more changes in object properties, and the list of these is very extensive. The question is, which changes mark the object as "dirty" from the point of view of caching, requiring an object reload? Do mere global script variable changes mark it as dirty? We can probably assume that changing position, size or texture marks it as dirty, but how about changing its state to phantom? Or emitting a particle, which changes internal timers only? If the answer isn't "any change at all" then we need to know exactly which changes are on the dirty list and which aren't.

1. Secondly, there is a sort of "prim contamination" going on as you described, in which a prim dirtied by a script contaminates all the other prims that are members of the link set because they are regarded as a unit, not only from the point of view of moving together but also for the purpose of caching (and that's diabolically bad). No questions here, because you seem confident that this is what is happening.

1. And thirdly, having contaminated all its link set members, it appears that there is no finesse associated with object reloading, so that every darn parameter and attribute of every darn prim in the link set is downloaded again regardless of what's changed, and regardless of whether any specific prim has suffered any change or not. The question here is, does this really happen for all the properties of each prim in the set?

It's the worst-case combination of these answers that I dread, because it would definitely explain totally the horrendous effect I've observed on cache retrieval times. A factor of 100 or 1000 is not merely "suboptimal". It demands a completely different word altogether, one not allowed in PG zones.