Overflowing the LI allocation of a parcel by the extreme LI expansion for PBR on prims returns random objects
tracked
Kathrine Jansma
Creating a prim with PBR textures and toying with the sliders in the build menus, its possible to vastly crank up the items LI to hundreds or thousands for a simple prim due to the weird LI accounting.
This may cause an overflow of the parcels LI budget and seemingly random objects from the parcel get returned to Lost+Found. This is extremly annoying.
Log In
Maestro Linden
updated the status to
tracked
Lucia Nightfire
I think any change that causes a prim accounting change should check for available prims before executing. If an overflow would be created, the change is blocked and an alert message is made. This is similar to how mesh linking is done.
Maestro Linden
Hi Kathrine Jansma, the parcel prim overflow return logic is a bit unintuitive, but I believe it works like this:
If a parcel is over its LI capacity, objects are returned based on which category they're in:
- Objects owned by "others" (i.e. random unaffiliated visitors) are returned first
- Objects set to the same group as the parcel are returned next
- Objects owned by the parcel owner are returned last
Within each of these categories, the 'youngest' objects are returned first. The age of an object on the parcel is reset to zero when:
- It is rezzed in the parcel
- It crosses into the parcel
- Its ownership changes (e.g. purchased with 'For Sale: Original' set)
The behavior you describe of a sudden LI increase in one object causing _other_ objects on the parcel to be returned could be "expected" if
either
of these conditions is met:A. The LI-increasing object is in a more privileged category (e.g. owned by parcel owner) than other objects on the parcel - the lower-tier objects will be returned first, even if they have been on the parcel for longer and have not updated their LI.
B. The LI-increasing object is in the same ownership tier as the objects being returned, but has been on the parcel for longer.
In order to know if your particular case is (A) and (B), we would need specifics about the objects' ownership info (relative to parcel's) and how long each object has been on the parcel.
That said, talking to Leviathan Linden, we think the algorithm could be updated to be made a bit more intuitive. Ideas are:
- If an object has been modified in such a way that its LI increases, reset its age to zero. This would put it first in line (within its ownership category) for return - would address case (B).
- Add a new category to the parcel overflow logic, for the most recently rezzed/entered/LI-increased object in the parcel, and return that object before any other objects in the parcel. This would somewhat/mostly address (A), for cases in which a single object 'blew up' the parcel LI. This idea is probably more controversial, since it could end up causing the parcel owner's youngest object to be returned instead of objects owned by other avatars.
These ideas are more feature work than bug fix, but I'm curious to hear feedback on them.
Kathrine Jansma
Maestro Linden Thanks for the explanation of the order of victims. I think my case was a matter of (A).
This sounds a bit similar to the Linux OOM Killer in principle.
I see a few issues with your proposed ideas:
- If i read it right, this would kind of "banish" the object overflowing the parcel back into inventory. This does fix the issue of not causing chaos in the same tier of objects. But the owner of the "banished" object now has a problem. He cannot rez the affected object on his parcel (and depening on the amount of LI explosion) also not in most sandboxes, as it would overflow or not fit. So he usually has no easy good action to fix/revert his accidental modifcation. That is undesirable. But better than today, as it does not disturb the regions other objects.
- This has similar issues of no clear way to sort out the modified object.
My pain point is really the different LI would overflow enforcement styles. If i try to rez a too big object, the rez fails because the parcel is full. Thats good behavior. But if i modify an existing object, so it gets too big for the parcel, it invokes chaos on the surroundings, instead of simply being blocked.
So technically i would prefer a kind of automatic undo of the object modification that overflowed the parcel. I assume thats technically tricky. I does sound like your GC/LI compactor runs asynchronously after the fact and has no access to modification details to rollback things.
Maestro Linden
Kathrine Jansma: Yeah, that is true about it potentially being awkward if an object suddenly gets returned to your inventory after having a highly inflated LI. I suppose that if the object is returned individually instead of as part of a coalesced object, one would always be able to wear it as an attachment and edit it back to a lower-LI state.
The idea of having an "edit rejected due to LI" response is promising too. I'm not sure how well it could be implemented for LI-impacting LSL operations, since existing scripts tend to assume a given
llSetPrimitiveParams
call (or similar) succeeded, but I think it would be possible to implement for build tool edits.I _think_ it would be possible to have an 'automatic undo' feature implemented solely in the viewer, since the updated LI shouldn't trigger an object return while the object is selected. Something like this:
- User edits object with build tool
- Viewer sends edit operation to simulator
- Simulator sends updated object info back to viewer, including new LI
- At this point, the object is still selected, so nothing is returned
- If the viewer sees that LI increased such that the parcel exceeds its prim capacity, and that objects will be returned once the object is deselected, it _reverts_ the change, and alerts the user.
Kathrine Jansma
Maestro Linden Good point, wear & edit would be a workaround i hadn't thought about. And some awkwardness for the creator of the mess seems more okay than causing chaos for other users. You break it, you fix it is fine.
I guess LSL operations are less likely to create such catastophic events in the first place. Sure there is some potential (and griefing potential) that it can happen, but lets assume people writing LSL know what they are doing and tested it. Unsuspecting users toying around with the build tools in the viewer are much less aware usually. So a viewer side fix for "oopsies" would be a good step into the right direction.
But even some decent error code for parcel LI overflow in LSL would not be outlandish to have. The current llGetParcelPrimCount()/llGetParcelMaxPrims() + llRezObject() chain already has a Silent error condition, that cannot be prevented (as it suffers from a TOCTOU race condition, e.g. the amount of prims free can change after the llGetParcelPrimCount() call, so a scripter has no safe way to prevent a rez from failing for parcel full.) An object modification may been seen in a similar light. A scripter that cares for failed/outside modifications could check the changed(CHANGED_TEXTURE | CHANGED_SHAPE) events to notice. Or create a new event change_denied (like experience_permission_denied) to receive blocked change requests.)
I'm not sure how the potential race conditions between Viewer sends update, selection & simulator computed object update and undo would work out. I assume there is room for breakage when the viewer drops the selection before the object update from the similator arrives. Thats easily in the realm of possible for 150ms latency network (e.g. Europe).
Bavid Dailey
Kathrine Jansmathat;s the essence, don't allow the overflow situation to come into existence, rather than trying clean upafterwards
Maestro Linden
updated the status to
under review
Bavid Dailey
this happened to me , took days to sort out.
I'd have expect6ed - and much preferred - if it said something like "operation cancelled due to exceeding prim allowance"