llRezObject: Message parcel is full when it isn't?

Hi All,

I've created a simulation of Conway's Life, with each cell being rezzed with llRezObject and killed with llDie as appropriate.

I'm currently using an 8x8 grid, and have at max about 25 prims at any one time, on my land which has 101 prims left in it's allocation.

Somewhere around my 8th generation, I am getting a system message than my parcel's object allocation has been exceeded. Doing an 'about land' check shows the available objects around 80 still. The generations still seem to continue running, although I'm not sure if some prims are not being created when they should be.

Does anyone know why this message is being sent? Are prims not de-allocated immediately (or within a few seconds of) them llDie'ing?

Thanks. Russell.

I wonder if it's some kind of weird lag artifact. The system not keeping up with the fact that the prims are llDie()ing?

I suppose that's possible, but each generation takes about 5 - 7 seconds, so it's been about 45 seconds since the first objects died. After I get this message, it also tells me notifications are temporarily turned off for the sim as well, which doesn't help debugging.

Wonder if it's related to this. You could IM Andrew to see.

There is a lag in how the count of objects runs, it's about a minute to 90s from some not very detailed but very annoying experiences.

My most memorable, I rezzed a holovendor to discuss with a client, no problem. Tinkered with it a bit to fit their needs, still no problem. Took it into inventory, handed it over, they couldn't rez because the parcel was full! About a minute later, poof, there is was when they rezzed it.

It seems more likely to me you're hitting this barrier rather than the fence or anything else.

Sadly I don't know of any work around, I guess slower generation times would help, and rezzing the whole grid and texture changing, alpha'd out to present rather than rezzing and derezzing. Temp_on_rez might help too, since you will be turning them over anyway, and temp on rez doesn't count towards prim limits.

I get that message when I rez stuff out of my inventory randomly, once every 10 or so rezzes and I just repeat that rez and it usually works then. Just a slight unreliablility in the rez process!

Ok thanks guys, I messaged Andrew anyway, but yeah I think it's more likely what the others have said.

Guess I either live with the delays (as generating quicker would be even worse) or rewrite my code to use linked objects and alpha textures, because at the moment, my objects live independently

consider temp on rez objects also if you can be sure they won't last longer'n the autodie timeout.

I've run into this problem many times and have figured out what is going on. When you rez an object, SL immediately removes the number of prims from the number available in the parcel. However, when you remove an object, it can take up to a few minutes for the number available in the parcel to be adjusted.

Anyone can test this too; goto a parcel with a few hundred prims available, then find an object that has a few dozen or so prims in it. Rez it in world, take it back into inventory and repeat until you get the message. There are only two things I know of that you can do. One is to wait a few mins until SL adjusts the number available. The other is to goto the land tools and click on the Objects tab. This forces SL to update the number of prims on the parcel and you can immediately re-rez the object.

Temp-on-rez is probably the way to go. I noticed the same thing with
my gumball machine. As Kayla says, checking the number of objects
on the land with a right click seemed to make it realize deleted objects
had really been deleted.

I'd be interested in seeing your Game of Life simulator when you're
done. If you like, you can check out mine at Patagonia 15, 107. 9x9
was the biggest I could get before hitting link_message limits.

Interesting Alphazero. Yours runs faster than mine and is larger. My prims are on a 0.2m grid. I like your setup interface too. Mine is all code at the moment.

I did rewrite mine to have permanent prims and just toggle the alpha, and it definitely runs a lot faster, although by 8x8 grid still draws a little slow. I could unwrap some loops, but I suspect it may be the fact I have my grid rows in a list and the list processing is slowing things down.

Your emulation seems to be only using 2 neighbours as the live condition. I had trouble getting any patter to stay alive as a result. Mine uses 2 or 3 which I thought was the original Conway rules. I also tried your glider, and it died out as well.

I don't want to leave mine out running at the moment, as I dont want to crash the sim, so give me a yell in-game if you want to check it out.

OH btw, I like your toy dispenser. Unfortunately the flying bike I'm on has abducted me and I'm on an express ride out of the grid!

I have been having the same problem for a couple of months now. I submitted 3 bug reports with regards to this, but so far it hasn't been resolved. It would be nice if all of us keep sending bug reports and talking to the Lindens about this so that they could hopefuly fix this soon. It is quite frustrating especially when what you are trying to do relies on rezzing.

I haven't heard back on my PM to Andrew Linden yet. I was hoping that might shed some light on the topic.

I had the same speed issues with list processing. Even doing simple math is slow if
you're doing it a few hundred times. I ended up rewriting the whole thing to run in parallel.
There's a Master Control program which tells each cell via linked messages to either
update its value, or calculate the next.

When a cell gets a calculate message from the MCP, it tells its neighbors' if its alive or
dead. They figure out based on the number of alive messages if they should change
state, and do so on the update tick. Turns out to be waaaaaay faster that way.

I also added in a cutout, so it turns off after a few iterations. Don't want to be a lag-a-thon.



Ruht ro. If a glider is dying out something is screwy. Thanks for the report. It's using
the standard Conway rules, so something is clearly amiss.



Thanks! Yeah, that was my first (and so far, only) physics vehicle script. It needs a
small amount of refinement, you could say. Way too hard to control. The hatching egg
bit was what I was most interested in at the time.

A linden told me that rezzing on group land is buggy in SL. Consider changing away from group land if you can.

The issue is a lag in the object counter.

OMG! Not the MCP! We're all gonna be de-rezzed!!

I'm not sure I want to go to the trouble of a complete re-write for independent calculations. I do have a couple other speed improvement ideas, not sure if they'll work though.

And Iron Perth, thanks, I suspected that was the issue, but it must be all land, not just group, as I'm just on my little 512m of first land.

I can confirm this - I've seen it myself (even using temp_on_rez!) and the description seems exactly correct - when you call llDie() or when the object otherwise leaves the sim, it doesn't affect the land parcel object count until approximately 60 seconds later...

Well that's the other wierd part too. The displayed counter on "about land" seems to be showing correctly, but there must be another behind-the-scenes counter that the lag is occurring on.

Oh well nm, I understand well enough now, and can work with it.

Not exactly - when you view the About Land counter, it seems to force a refresh, and you can immediately rez / create the new prims.

If the problem is the new grey goo fence which is the subject of this thread, then you should see some script errors appear that say something about it.

If not that, then I suspect some errors in the parcel object accounting. I believe if you do a lot of rez and deletes on a parcel the object count can be temporarily out of sync and it may think it is too full. I'm currently working on a major overhaul of that part of the code that will make parcel object accounting much tighter, however the release of that work is weeks away.

In the meantime, you might be able to work around the problem by NOT creating/deleting so many objects... instead try recycling existing objects for re-use later. That is, change their size or location to make them hidden, or set them transparent. That would be much nicer to the simulator anyway... it takes fewer CPU cycles to move or resize an object than it is to delete it and create a new one.

Good advice... I never thought of that!

So this leads to the next obvious idea: would it be possible to optimize temp_on_rez and give it the ability to recycle the objects on the sim so that llRezObject simply works that way for temp_on_rez?

Are you asking if LL could automate llRezObject() to try to recycle temp_on_rez objects rather than let them be deleted? Probably not, at least not in the short term. Such an optimization would be rather low on my prioritized list of things to do. There are a lot of optimizations, clean-ups, and rewrites I'd do first.

Well, I won't be able to use the solution proposed. I have made a hologram vendor for furnitures since some of the lands, such as malls, do not have much prims available. In other words, I really need to be able to rez objects on the fly to be able to display each set of furniture at a time without going over the limit in prim count. Also, I can't use temp on rez cause it defeats the purpose of rezzing the furniture. Customers need to examine the furniture, try out the animations and any other features we offer with them. Is there any other solution to my case other than waiting for weeks? I have actually been waiting for months now since my first bug report on the issue.

On another note, I have gotten that rezzing error message even when manually dragging objects from my inventory and rezzing them into the world.


Troy