|
|
|
I believe the purpose is to show which objects cannot be returned. If so a show button might be nice also.
That seems odd. I can delete an item I own that someone is sitting on. So why shouldn't a land owner/sim owner be able to return anything they don't want on their land and sim, regardless of whether someone is sitting on it or not? Not arguing with you. I've seen a lot of strange stuff on SL that seemed to have no rhyme nor reason. The "selected / sat upon" just seems like one of 'em
You are correct, you can return sat upon objects, so no idea the purpose.
Harleen was close; it's to keep track of which objects won't be returned by autoreturn. I've noticed that the figure seems arbitrarily inflated on my land as well. I suspect that sometimes the sim loses track of when objects are no longer sat on or selected.
Here's a thread of folks who have also noticed this:
http://forums.secondlife.com/showthread.php?p=1915148 Does anyone know for a fact that this number being hugely inflated (as it is on my land as of yesterday) has no negative consequences? No this is not about what has been sat upon or selected but the system going wonky. Urbana Spes has for a couple of days been reporting that 4147 (number varies but always 4000+) of 8865 objects are selected or sat upon. There is no way that this is true. We are talking about a city rezzed by software that covers every last metre of the region. There is a tiny parcel used to send anyone loging into the region at 128,128,0 to be sent to the city (which is at 300m), that aprcel reports 8 out of 8 sat upon or selected. The third and final parcel is a dance club that reports 492 out of 515 sat on or selected. Regardless of the two smaller parcels there is no way that I or others have previously selected 4000+ objects in the city, especially as major redevelopment work would not be done with selects, but by re-running the sim rezzer software.
Negative consequences? YES!
Anyone renting land needing to track prim counts for one. Group owned, or any object that need to have a group tag to be rezzed on your rental property once its dumped into the "selected/sat upon" category and WILL NOT be counted anymore as a group object. The use of "selected/sat upon" is as it states and nothing more. This feature could be used for moving builds you know have a certain amount of objects or for pruning areas of a parcel of objects. If I need to move a house that I know has 83 prims and I check by viewing selected /sat upon, I'll know I have everything. Sometimes you all have had the experience of accidentally selecting a bunch of objects. It appears that these objects are not reverting to zero and I suggest the cause of the over abundance of that count. I had Kyle Linden reset a region to correct this. It seemed to work at first but now its starting to happen again. The problem with this bug is that objects that are dumped into the "selected sat upon category" are no longer being counted as group owned objects. That simple. Makes it difficult to count prims. Your selected sat upon should always zero unless you selected/ sat upon some objects BEFORE clicking on the about land settings. Once you exit about land and select about land< objects again it should revert to zero. What I am noticing is that certain regions or parcels within regions again are starting to stack up the selected sat upon objects area. It appears as though the "Primitive on parcel" count is correct, it's just the way the counts are grouped that is incorrect ("Owned by parcel Owner" and "Set to Group") are low and "selected/sat upon" is high. And selecting all items on your land and closing edit will either lower or raise the "sel;ected sat upon" count, so that kluge fix doesn't always work.
I can confirm that this is definitely not related to the system not released back statistics for what you have previously selected. Urbana Spes City is now stating that there are 6342 prims selected or sat on, there is no way that I have selected 2000 prims in the last two days.
I'm seeing this on my resi parcel with 1.19.1.4 as well.
Hi: This is affecting me too. Thanks for the workaround Eren. BTW, should this be in the viewer area of the jira? Wouldn't the info come from the Server end of things? Just asking.
Thanks to whomever fixes it! -Stimpy Appears fixed in Server 1.20.0.83683 sims.
This issue is not fixed and has not been resolved. Selected sat upon objects are accumulating and not being released. I curious as to why it was listed as "resolved".
It appeared fixed after the server update to 1.20.0.83683, but appears to have returned.
All one has to do on any parcel is bring up the object data in the about settings. You would be surprised to find out how many parcels have this data corrupted.
Possibly just a duplicate of
Our Sim also has this problem . Over 6000 prims are selected / sat upon according to the objects tab in the About Land.
No Beezle, not a duplicate of that very different issue. I get the selected/sat upon account rocketing even though it is highly unlikely that between reboots to give the figure before the reboot I just did, that 3170 prims failed to rez or de-rez. The selected/sat-upon number does go to zero with a reboot.
Plot 1 in my ROMA Subura sim has only 5 objects on it, as seen when I hit the count button on the land window. But the land records 35 prims on the plot, which is confusing the prim counting rental prim, giving prim overage notices to my renters.
Not sure if this is the appropriate entry for this – let me know and I can move this set of comments elsewhere.
I had 400+ Selected/Sat Upon prims in Yoonseul. and hadcollisions where the prims used to be. Additionally, the prim counts were off: Simulator Usage: 545/937 ( 392 free) This was cleared up with a region restart (ticket 4051-4691107) - howerver, as of today (April 15), I again have: Simulator primitive usage: 540 out of 937 (397 available) Second Life 1.20.1 (84760) Apr 15 2008 12:13:49 (Second Life Release Candidate) You are at 264556.1, 238099.9, 92.4 in Yoonseul located at sim3173.agni.lindenlab.com (216.82.20.162:13005) CPU: Intel Core 2 Series Processor (2999 MHz) = = = = This is possibly being fixed under http://jira.secondlife.com/browse/SVC-1910 "Assigning this to Kelly Linden, who was working on it Friday and will hopefully finish it soon. The current theory is that this is caused by a "selection bit leak" – objects are getting selected but not unselected. The best way to verify this is probably to pay attention to the "selected objects count" in the parcel object tallies. There is sanity code already in the SL simulator that tries to scan for lost selections but if this really is a selection bit leak then it would appear to not be working correctly, or else is not aggressive enough and waits too long. BTW, I think that when shift-drag-copying... the object that is moved and remains selected is the original, and the one that remains in place is the copy. You should be able to verify that by adding a script that does certain things on_rez()." – Andrew Linden Second Life 1.20.0 (84432) Apr 9 2008 03:59:09 (Second Life Release)
You are at 288949.6, 271072.1, 25.8 in Bristow located at sim5386.agni.lindenlab.com (8.2.33.133:12035) Second Life Server 1.20.0.83892 CPU: Intel Core 2 Series Processor (2000 MHz) 1) selected/sat upon and ghost prims at:
2) selected/sat upon: 60 3) selected/sat upon: 99 4) selected/sat upon: 95 I believe this is related to the rotating prim stoppage, re:
-s I believe this was caused by the 'selection bit leak' issue that was also breaking llTargetOmega objects - I think it should be fixed now with the currently deployed 1.21 Server
llTargetOmega being fixed as well? WOOHOO! Two birds with one stone (hopefully).
Thanks for letting us know, Kelly. : ) I confirm this is fixed, on a region that was erroneously reporting numbers of 5000+ selected or sat upon, it now says 1.
Second Life 1.20.5 (86279) Apr 30 2008 00:22:51 (Second Life Release Candidate)
You are at 288908.4, 266248.0, 67.6 in St Lion located at sim5930.agni.lindenlab.com (8.2.35.232:13002) CPU: Intel Core 2 Series Processor (2000 MHz) I have 8 ghost prims on my parcel this evening. Meredith: can you elaborate? Do you mean that there are 8 more objects in the parcel object counts than are actually on the parcel? Or that there are 8 objects that always show as selected? Or something else?
I don't think this is the jira item for ghost tasks - this was a jira item for the selected / sat upon count in the parcel properties window being wrong. What exactly are you reporting as a bug? Greeting Kelly. You're right, the ghost prim thing is a whole nuther bug, but I know what Meredith is speaking of.
Since Havok 4, I've noticed "ghost prims" regularly. These apparently are builds that were deleted by the builder... but for some reason their placemarkers (or something) still hangs around. The prims can't be seen (not event with ctrl alt T), they can't be selected, but you try to walk and you bump right into them. Sim has to be reset to get rid of them. hi eren, thank you for your elaboration and explanation. =)
hi, kelly, these are the detailed steps: 1) I rezz 8 prims on the ground Expected result:
Observed result:
then I cleared network cache and relog: 1) I checked the Object tab in About Land again Expected result:
Observed result:
This is very annoying we have to wait for LL to restart the sim every time. I am going to resolve this issue again, the bug Meredith is reporting is not the same bug. There are other issues open for Ghost Prims such as SVC-255. Please add your comments there, thank you.
Ugh, this thing hit me today but that "workaround" of placing all objects into the edit window is NOT resetting my value.
 This is NOT fixed!!! Can't you make that not included in the prim count until you can get it to maintain an accurate count?
My selected/sat upon number has been 144 since FRIDAY and I can't use my in-world tools on 56 prims! Simulator primitive usage: 529 out of 585 (56 available) I tried selecting all object in the edit window, clearing cache, etc ... none of that is working for me. Second Life 1.20.8 (88152) May 22 2008 15:26:00 (Second Life Release Candidate)
You are at 288949.3, 271051.8, 478.5 in Bristow located at sim5386.agni.lindenlab.com (8.2.33.133:12035) CPU: Intel Core 2 Series Processor (2000 MHz) Simulator primitive usage: 802 out of 1406 (604 available) It seemed that they turned ghost when I was trying to delete them as a group. Second Life 1.19.1 (4) Apr 2 2008 11:59:37 (Second Life Release)
You are at 231398.4, 291802.9, 22.3 in Beachland located at sim2416.agni.lindenlab.com (216.82.17.167:13000) CPU: Intel Core 2 Series Processor (2000 MHz) Simulator primitive usage: 900 out of 937 (37 available) Still having problems with 143 Ghost prims This is not the Ghost Prim jira item. Please either find an issue about ghost prims or create one. Thanks.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Selected / Sat Upon reports incorrectly and confuses prim count
The two enclosed photos show a striking example of this bug. The first shows "Set to group" as 429 and "Selected/Sat Upon" as 1059.
The second photo was taken after the above trick was used, showing Selected/Sat Upon as 0 and a correct "Set to Group" of 1488.
IMO this confirms that it IS a bug, and not just a discrepency or misreading. Second Life appears to just be losing track of what is selected/sat upon.
And again, I question whether that figure is even warranted. What practical use does it have? None, I think.
Well... at least I WOULD upload photos if I could figure out how to get the photo uploader to work. Grrrr. Anyone ever heard of drag and drop or BROWZE? Grrrrr...