|
I think a simple solution would be to have rez requests include the
prim count, if the rez request is accepted, the prim count is increased
before the object event starts to actually be rezzed. Doing it like this, it would be somthing like this. 1. Sim receives rez request for an coalesced object with 9000 prims 2. It confirms the parcel where the object will be rezzed has 10000 prims avaiable 3. The sim adds 9000 prims to the count of prims used by the parcel assigned to the object that is being loaded 4. The asset server is slow to serve the actual prims 5. The sim gets a rez request for a object with 500 prims 6. The sim confirms that the parcel has 1000 prims still avaiable 7. The sim adds 500 prims to the coutn of prims used by the parcel 8. The asset server is still crawling 9. The sim gets a rez request for an object with 1000 prims 10. The sim verifies that the parcel only got 500 prims avaiable 11. The rez request is denied and fails 12. The asset server finally delivers the whole 9000 prim object 13. Some misterious condition results in the delivery of the 500 prims object being interrupted and not finishing. 14. The rez request for the 500 prims object fails. 15. The sim remvoes 500 prims from the count of the parcel since the object isn't there anymore. Basicly the rez request is only accepted if there are enough prims avaiable, and once a rez request is accepted the prim count for the object is already reserved regardless of how many prims of the object have actually been rezzzed already. A scripted object that repeatedly rezzes an object with enough prims to clog a parcel, DOSing by filling the queue after a few repeats would probably trigger the grey goo fence anyway, so there shouldn't be much concern, and since the prims are already being counted a parcel manager should be able to see who is cloging their parcel. On a slightly unrelated topic. You've probably noted that I mentioned an object with a huge number of prims, way beyond what is currently allowed, here is somthing from a pjira entry on the topic of the supposed problems with rezzing big number of prims: Dante Linden added a comment - 22/Jun/09 05:52 PM Here's the KB article I mentioned:
https://support.secondlife.com/ics/support/default.asp?deptID=4417&task=knowledge&questionID=6425 Tigro, addressing the root cause of the issue would require changing old and fundamental pieces of the simulator: the pieces that manage object rezzing. The only somewhat-recent related changes I'm aware of have been a rez limit and now the prim limit, both of which are mentioned in that KB article. so
if it is just due to concern of physical objects breaking apart while
rezzing, only apply the limit to coalesced objects that contain at
least one physical object, or even better, simply don't simulate any
physics for a coalesced object until it is all rezzed
also,
with so many issues, people are already used to have to do workarounds
and avoid certain things, taking a field together with a physical ball
would be avoided, either turn the ball non-phys, or have the field rez
a new ball if no ball is around
edit:also, what happened to being in build mode to rez physical objects you don't wanna get loose? Isn't that common sense? And sim crossing, if your chair isn't linked to the rest of the boat, you're asking to have it move separatedly, usually even when the avatar is sitting in an object there is already the risk the avatar itself will be separated from the rest of the object during sim crossing. And anyone that has walked across a sim border over prims, unless only with builds that are made with the workaround to avoid the issue, knows that when crossing sim borders physics and collisions don't work well the
explanations on that knowledge base entry seems to suggest this is just
a bunch of solutions to problems that didn't exist causing real
problems
get rid of the freezing sim, and get rid of the prim count limit, that should result in having less problems than what we have now, if you add up all problems that will be created by removing those non-features, subtract all problems that are caused by having them present, and combine with the problems that exist with or without them being present, the result is less problems than what we have now, I believe you won't even have to weight each individual problem solved by not having those two non-features to notice a clear benefit in not having them ---- if you wanna read the rest of the comments go to http://jira.secondlife.com/browse/SVC-4207 ps:sorry if the links get kinda messy, I just pasted straight fromt he page, I'm not sure if the links will get mangled with formating conversions and stuff Dale Mahalko escreveu: On Wed, Jul 8, 2009 at 8:37 PM, Argent Stonecutter<[email protected]> wrote: |
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
