Why UUID Flipping is Bad

From Second Life Wiki
Revision as of 15:15, 27 October 2010 by Runitai Linden (talk | contribs) (Created page with '== Introduction == With sculpted prims, many residents took it upon themselves to create "animated" objects by using LSL to change the sculpt UUID thinking this is a supported me...')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Introduction

With sculpted prims, many residents took it upon themselves to create "animated" objects by using LSL to change the sculpt UUID thinking this is a supported method of creating animated objects inworld. In truth, Second Life does not currently provide any adequate means of animating objects beyond position/rotation/scale. This article aims to clear up some of the rumors and speculation around why UUID flipping is good or bad, and why UUID flipping is being throttled for mesh to prevent the creation of objects that animate in this way.

What UUID Flipping Actually Does

When you change a mesh UUID, it sets off a chain of events that stresses the entire Second Life content streaming system. From the back end on down to the viewer:

  • The simulator must fetch the new mesh asset from the asset server or load it from disk on its local cache, creating disk and network load for the host
  • The simulator must parse the mesh asset and update the current object cost, possibly causing the object to be returned for overflowing prim parcel limits.
  • Whether or not the object is physical or phantom, the simulator must construct some new physical proxy for the object based on its new size