Parcel full, something has changed?

I have an object that autonomously travels between my various plots, using llSetPos. This worked perfectly before the last update.

This is the first time I have tried it since the recent updates, and I am getting objects returned to me. Upon investigation, the parcels that return the objects are full, that cannot accept any more prims.

It is too coincidental that five of my routes suddenly encounter full parcels, whereas before the update they were all clear, so something must have changed during the last update?


Is the problem that I am just traversing the full parcel, or is it because of the 10m limit on llSetPos that I am actually momentarily stopping on that parcel?

Is this a bug that needs reporting, or was I just taking advantage of a quirk, that no longer exists?

Odd that you should say that - I've just been bombarded with trams being returned, when they went into a parcel that didn't have enough prims to support them. It normally takes a little while for that to happen, enough to get through the space.

I wonder if the delay for returning objects over the prim count hasn't been reduced. That could be quite serious for vehicles, particularly on the mainland. Hm.

I had another similar reply in world, so that makes three of us whose scripts no longer work due to the update.

The "Parcel Full" object returning seems to be implementing immediately whereas before there used to be a delay.

I have officially reported this as a bug.

It is going to be a pain to work around this "new feature", having to check if each step is possible, and trying to find an alternative route.

This is just a theory, but some people were making vendors on small plots that only allow 16 prims or so, and using scripts that create objects above it for sale and derez them before they count towards prims on the land, allowing to a point as many prims as you want.

LL has since added the "Temporary" field on objects, and when they did that, they may have decided to make non-temp objects not be allowed to rez if the prim count is > then prims allowed.

Just a guess...

I think the rules for temp on rez have been changed, something like Vick suggests. I use (in a few places) holovendors with temp on rez, ONE in my sig line being an obvious one.

Someone's just set up 6 holovendors recently (that's 36 static prims) but the land usage for his objects shows up at about 180 - that would be ~24 for each model, which since he's selling cars seems reasonable. It's just not what I was expecting, but it's what I see.

Another undocumented change perhaps?

I can verify that temp_on_rez did change but it changed with 1.10.1 (or 1.10.2) weeks ago. When I first started on my "exploding windows" the tempory pieces didn't count towards my prim limit (I did extensive tests to verify) and then suddenly with that update I started getting notice that the parcel was full.

I spoke to live help (sorry don't remember who) and they verified that it changed.

-Ham

But, what's the point of temp on rez if it does in fact count towards your limit?

Hmmmm... Interesting. I shall have to run some tests of my own on this later.

I know of a few people who are suddenly getting objects returned since the last update, myself included. I hadn't thought about the possibility of some change in Temp_on_rez policy, and now that it's been mentioned, a little light's just appeared over my head.

I too have a temp_on_rez vendor, and it would make sense that things would get returned upon rez were the temp_on_rez items counting toward the entire parcel prim count.

Problem is, my shop's only on a 512m2 plot of land. I'm pretty much screwed if I can't temp_on_rez some of my higher prim creations for potential customers to view in 3D before purchase

Geoff.

I'm pretty sure the way it works is that the "Primitives on Parcel" count does not include temp-on-rez prims. I use many holo-vendors at my store and the prims-on-parcel count is 329 prim. However, if I add up the prims from the "Object Ower" list the count is 472 prims. So the prim owner list does count the temp-on-rez prims, but those prims do not count against your prim total for the parcel.

Did some more digging...

from the wiki...

http://secondlife.com/badgeo/wakka.php?wakka=TemporaryOnRez


Also this /139/94/109335/1.html

...makes me think that I don't have all my facts correct and I need to revist my own tests.

Thanks,

-Ham

Providing your goal is to get an object from point A to point B, without an avatar seated - you might try using warpPos() instead.

It may get around this parcel full issue you're experiencing, as using this method appears to 'warp' directly to the destination.

Not to mention, its lightning fast

ok i have holovendors that are only 3 prims where do u get 36 ?
and as far as im aware vehicles cant be more than 30 prims anyway.

but what i want to know is why i can res as many prims as i want in a 20m by 40m sand box
is there away to sandbox your property ?
and why dont i lose attachments when i walk onto a full parcel?
is it not counting those prims ?

The holovendors in use are 6 prims each, and 6 X 6 = 36.
6 cars at ~24 prims each is 144 more prims.
Total 180.

In fact there is a limit on a sandbox, but essentially a sandbox is a large (often sim sized) single parcel with lots of prims (15,000 in the case of a whole sim). I wouldn't suggest you go to overwhelm it, but it can be done. Your hypothetical 20 X 40 plot is 800sqm so would get 160ish elsewhere, but in a sandbox the prims aren't divided up between parcels. You can (Anshe used to, may still do) make a sandbox for yourself. She put up a whole sim as a sandbox and let people use it.

Your attachments aren't rezzed prims essentially. Or rather they're not counted against the prims in a parcel or sim. I don't think anyone's ever actually answered this in full, but I'm guessing the avatar limits per sim and the prim limits per sim have a juggle between them so the attachments on the avatars are counted against their processing power to try and give a decent experience.

Hmm. I hope the 'llSetPrimitiveParams()' warping works. Otherwise we may have to resort to rezzing a temporary object to save permanent object state, re-rez the permanent object, and restore the state once the temp object gets to its destination. And maybe a TCP like protocol in case the temporary object doesn't last long enough to get there....