Life Camino

I don't know if this is the best forum for this question, and if someone else knows where it belongs, feel free to move it. But, I have this problem with strange "ghost prims" showing up in the bottom SW corner of my sim. They cannot be seen, not even while revealing transparency, and they act phantom, but they can be selected. And, you can see their shape and size, as well as other prim parameters. But, if you return them, whole link sets from over 1000 meters away get returned. These prims appear as single prims, but are somehow associated with other whole linksets elsewhere in the sim. The only common factor seems to be that all of the prims are megaprims from the 10m max prim size era. That is to say, these prims could be made by anyone, today, but not when they were created. So, they vary in size, but always larger than 10m on at least one axis. Restarting the region does not change anything. This would not be a big deal, except that I use that bottom corner of the sim near <0,0,0> as a server room and for rent boxes and these stray prims get in the way of being able to select other objects in that room. Anyone have any idea of what is going on here or how to correct it? Thanks.

Yes, Qie, I am trying to avoid using auto-return here. I have a sci-fi role play sim and some of the players want/need to have a tp pad in the region, even though they don't rent here. I don't mind accomodating that kind of thing, if I can. But, auto-return would not allow that. So, I am implementing my own configurable auto-return. I get your point about relying too much on scripted defenses. So, do you have any suggestions of how to defend against script lag attacks?

Thanks, for that bit of code, arton.

Let me suggest this approach, because it has worked well for me in the past: Use a script to record the position and rotation of the cars relative to the rezzer and then use an on_rez event to trigger the car to move to that relative position when it is rezzed. I use a positioning script to do the job: integer crate_channel=-14200;integer crate_listen_handle;integer count;vector rez_pos;vector my_pos;vector owner_pos;vector offset;rotation my_rot;rotation owner_rot;default{ state_entry() { string crate_name = llGetObjectName(); if (!~llSubStringIndex(crate_name, "VEHICLE")) { crate_name = "VEHICLE " + crate_name; } // crate_name = llGetSubString(crate_name, 0, 28); llSetObjectName(crate_name); owner_pos = llList2Vector(llGetObjectDetails(llGetOwner(), [OBJECT_POS]), 0); my_pos = llGetPos(); my_rot = llGetRot(); offset = my_pos - owner_pos; llMessageLinked(LINK_THIS, TRUE, "AVRS_MENU", ""); } on_rez(integer start_param) { if (start_param > 0) { llSetLinkAlpha(LINK_SET, 0.0, ALL_SIDES); llMessageLinked(LINK_THIS, FALSE, "AVRS_MENU", ""); crate_listen_handle = llListen(crate_channel,"","",""); owner_pos = llList2Vector(llGetObjectDetails(llGetOwner(), [OBJECT_POS]), 0); owner_rot = llList2Rot(llGetObjectDetails(llGetOwner(), [OBJECT_ROT]), 0); llSetRot(my_rot * owner_rot); llSetRegionPos(owner_pos + offset*owner_rot); } else if (start_param == 0) { state default; } } listen(integer channel, string name, key id, string message) { if (channel == crate_channel && llGetOwnerKey(id) == llGetOwner()) { if (message == "CLEAR_VEHICLE") { llMessageLinked(LINK_THIS, 0, "AVRS_CLEAR", ""); llMessageLinked(LINK_SET, 0, "POOFER",NULL_KEY); llSleep(2.0); llDie(); } if (~llSubStringIndex(message, "POOF_START::")) { llMessageLinked(LINK_THIS, 0, message, id); } if (~llSubStringIndex(message, "POOF_END::")) { llMessageLinked(LINK_THIS, 0, message, id); llMessageLinked(LINK_SET, 0, "POOFER",NULL_KEY); llSleep(2.0); llSetLinkAlpha(LINK_SET, 1.0, ALL_SIDES); llMessageLinked(LINK_THIS, 0, "AVRS_REZ", ""); llMessageLinked(LINK_THIS, TRUE, "AVRS_MENU", ""); } } } } I use the script, above, to position vehicles relative to my avatar when the vehicles are rezzed from a HUD. It also works with Horizons scene crates and can trigger an on-rez poofer effect. You may not need all that; but, I hope this helps.

Thanks, Rolig. The system is scripted so that it can detect CasperLet rent boxes and automatically add residents to the access list, along with additional tenants that the renters may have added to share their prim allowance. It also supports a non-resident prim limit that is definable in the configuration notecard for the system. Every five seconds, the system scans the region for prims by owner and filters out staff, residents, and renters, and considers only prim usage by non-residents. If a non-resident exceeds the established non-resident prim limit, their prims are returned to them along with a warning about not exceeding the limit. If they exceed the limit, again, their objects are returned and they are banned from the parcel automatically. Additionally, periodically (definable), the system does an "Auto-Clean" of the sim of non-resident prims. If the non-resident prim owner is still on the land at the time of the cleaning and they are under the limit, their prims are left undisturbed. If they are not present on the parcel at the time of auto-cleaning, their prims are returned to them along with a warning not to leave prims unattended in the region. If they violate the usage policy, again, they are automatically banned. The system also supports a non-resident prim limit minimum, below which their non-resident prims will be left undisturbed. For example, if you want to allow non-residents to keep a teleport pad or server, or some small low impact object on the sim, despite their not being a resident, you can specify a minimum number of prims that will be ignored by auto-clean. I'm trying to keep the sim as open and friendly to outsiders as possible, while protecting my residents, renters, and role players against attack and preventing griefers from using all the resources in the region. It is a delicate balancing act I am trying to achieve, here. So, any advice that might help me achieve my goals would be greatly appreciated.

Thanks, Rolig. So, do you have any suggestions of what I might monitor to detect griefing avatars/objects that are stalling a region?

I'm working on a new security system to protect my sim from griefing and I want to be able to detect griefing levels of script time; but, I don't have a feel for what that level might be. So, can anyone tell me how much script time is generally considered so excessive as to constitute griefing? The recent attacks have involved avatars rezzing all the available prims in the region, launching particle attacks to crash video cards, and using scripts that cripple the region - including the security system. So, I really need to be able to detect and eliminate this particular type of threat. The sim is open to the public, has renters, role players, and visitors all the time, so I can't just restrict access. I've got to detect misbehavior. Any advice you can offer would be appreciated. Thanks.

It seems to me, that adding the used memory to the available memory should result in a total that is 64k (in a mono script). But, it doesn't. I have a script that reports 3946 bytes of free memory, but when I substitute the llGetUsedMemory command for the llGetFreeMemory command I get 41674 bytes of memory used. Why don't these two numbers add up to 64k? Thanks, for any insight you can offer into this discrepancy.

If I add someone to the Land Pass List using llAddToLandPassList is that the same thing as adding them to the Allowed Residents list?

I think I may have gathered insight into what may be causing the problem. The requests stop when it tries to process group owned objects. That is to say, when it gets to the key of the Group Name that is the owner of prims in the region, it stops. I think what is happening is that I am issuing a llRequestAgentData request, but passing a group key, rather than an avatar key to the function, resulting in it not returning anything, and stopping the loop from continuing to bump ahead to the next records in the list. But, I don't know how to detect that so I can intercept it and filter it out. EDIT: I figured out how to retrieve the land group key and then delete it and its prim count from the list before passing the keys to the dataserver for agent names. So, that solved the problem. The script is now processing all of the records in the list.

Thanks, Rolig, but I added a llSleep(0.5) before each and every dataserver request and it plods along much more slowly, but only up to 74. I still can't get it to process the entire list up to the 92 records it has in it. Any other suggestions?

I'm working on a security relay that is accessed remotely by a HUD and one of the functions I am trying to implement is to be able to get a parcel prim count by owners report. Getting that and passing it to the user's screen is not a problem. But, I am also trying to build a list of full agent names to be used in a menu to allow returning of objects by owner. This, of course, requires the dataserver to retrieve the DATA_NAME information. I'm using this bit of code to initiate the parcel prim count by owners report: prim_owners = llGetParcelPrimOwners( llGetPos() ); gListLength= llGetListLength(prim_owners); if (!gListLength) { llRegionSayTo(user, 0, "[ERROR]\n Couldn't get Parcel Prim Owners"); } else { // Produce a copy of the list suitable for sorting by count, i.e. count then key integer x; for ( ; x < gListLength; x += 2) { gListCountsAndOwners += llList2Integer(prim_owners, x+1); gListCountsAndOwners += llList2String(prim_owners, x); } // Sort the list in descending order of prim count gListCountsAndOwners = llListSort(gListCountsAndOwners, 2, FALSE); // Lookup each owner's name. Start at the beginning of our sorted list gListLength= llGetListLength(gListCountsAndOwners); integer i; for (;i< gListLength;i++) { string current_name = llList2String(gListCountsAndOwners, i+1); string current_count = llList2String(gListCountsAndOwners, i); llRegionSayTo(user, 0, "secondlife:///app/agent/" + (string)current_name + "/displayname" + "\t" + current_count); i++; } gDataserverID = llRequestAgentData( llList2String(gListCountsAndOwners, 1), DATA_NAME ); } In the dataserver event I am using this bit of code in an attempt to store the names in another list: dataserver(key query_id, string data) { if ( query_id == gDataserverID ) { llOwnerSay(data + " added to gListNamesAndCounts..."); // llOwnerSay("gListLength = " + (string)gListLength); // llOwnerSay("gIndex = " + (string)gIndex); gListNamesAndCounts += data; gListNamesAndCounts += llList2String(gListCountsAndOwners, gIndex); // process the count as a string if (gIndex >= gListLength) { prim_list(); } gIndex += 2; // bump through the strided list if (gIndex < gListLength ) { // lookup name of next owner in our list gDataserverID = llRequestAgentData( llList2String(gListCountsAndOwners, gIndex +1) , DATA_NAME ); } } The problem I am running into is that the dataserver never processes all of the requests. I have a list length of 92 - a key and a count for 46 prim owners in the region. But, the process stops when gIndex reaches 74. It never gets bumped all the way to 92, which would trigger the prim_list() function. So, what is going on, here? Why would it stop at 74 records and not make it all the way to 92? Thanks, for any insight you can offer into this issue.

I'm working on a security relay and I want to be able to both ban an avatar and return their objects in the same step. There are no examples provided for the command, so I was wondering if someone could tell me how this command should be used for my purposes. The security relay is to be deeded to a group on group owned land, so I need the relay to always have the permissions it needs without having to ask every time. And, once the relay is deeded to a group, I need to be able to reset the script and grant permissions. Thanks.

That depends on whether you have the following: * - Modify rights to the script for the raffle board. and/or * - The ability to capture the winners UUID. If you have either of those, you can write a script that will give the inventory item to the winner - assuming there is only one prize in inventory to be given. If there is more than one prize, you will need a way to know which prize to give.

Look up message boards on the Marketplace and filter for full perm. I came across this one for L$1 https://marketplace.secondlife.com/p/Blue-Running-Light-scrolling-message-board-Display/2459425