elleevelyn

am defo going to test this and try to work out what the nearness threshold is it also explains why we weren't always seeing the message edit add: my testing tells me that the nearness threshold is 96 meters from the device. 96 and beyond then no chat message or notification toast so thats pretty much the solution to not spam the neighbours with chat messages, place the device up in the sky so that is 96 or more meters away from neighbours builds and skyboxes and done well done! QIe

going back to this. It could be the viewer installation has been corrupted, meaning not working as intended have your friend uninstall every viewer they have on their computer. Then have them install the official Linden viewer and test with that using the default settings . Then if this works install whichever TPV is preferred and test again

it could be a connection issue for your friend see if your friend is able to login on at another location. Friend's house, internet cafe, etc. If the problems go away then is pretty much a connection issue

i don't know why either really. The message may be able to be suppressed in a TPV which I haven't tested for edit add: Looks like Eowyn above found a a partial solution for Firestorm, so that's good start i have tested this with Linden viewer but I can't find a setting to do the suppression. Maybe someone else can have a go at it, as would be useful if there was a way to suppress, which there may not be, at least in Linden Viewer test kit used scripts /* Test environment Linden Viewer: Second Life Release 7.1.2.7215179142 (64bit) - clean install with default settings Second Life Server 2023-11-07.6790647783 Group-owned land (Not tested on private owned land as I don't have at time of test) put the scripts below into 5 seperate objects */ // AddToLandPass // chat message: [Second Life: You have been granted access to this land] // also shows as a NotificationTipToast top right of screen default { state_entry() { llSetText("AddToLandPass", <1,1,1>, 1); } touch_start(integer total_number) { llAddToLandPassList(llDetectedKey(0), 0); } } // RemoveFromLandPass // chat message: [Second Life: Your access to this land has been revoked.] // also shows as a NotificationTipToast top right of screen default { state_entry() { llSetText("RemoveFromLandPass", <1,1,1>, 1); } touch_start(integer total_number) { llRemoveFromLandPassList(llDetectedKey(0)); } } // AddToLandBan // chat message: [Second Life: You have been banned indefinitely] // also shows as a NotificationTipToast top right of screen default { state_entry() { llSetText("AddToLandBan", <1,1,1>, 1); } touch_start(integer total_number) { llAddToLandBanList(llDetectedKey(0), 0); } } // RemoveFromLandBan // chat message: [Second Life: You have been removed from this land's ban list.] // also shows as a NotificationTipToast top right of screen // listen for message from Relay to RemoveFromLandBan // done this as we can't directly interact with object on land // we are banned from default { state_entry() { llSetText("RemoveFromLandBan", <1,1,1>, 1); llSay(0, (string)llGetKey()); llListen(-1234, "", NULL_KEY, ""); } listen(integer channel, string name, key id, string text) { llRemoveFromLandBanList((key)text); } } // Relay to RemoveFromLandBan // relay object placed on neighbour parcel // done this as we can't directly interact with object on land // we are banned from default { state_entry() { llSetText("Relay to RemoveFromLandBan", <1,1,1>, 1); } touch_start(integer total_number) { // RemoveFromLandBan uuid (key) hardcoded. Change to actual uiid for testing llRegionSayTo((key)"4d46ed50-6827-de7e-c886-f23b45ae0d0c", -1234, (string)llDetectedKey(0)); } }

i think it was a design choice when llAddToLandBanList and llAddToLandPassList were developed, probably from the thought that they are in some ways a complementary pairing llAddToLandPassList also give a notification message "You have been granted access to this land" granting access is done when the agent is not on the parcel. And it makes sense for the agent to get this message i think also if a JIRA was made requesting changes to llAddToLandBanList, Linden might consider nerfing the function's currently ability to add agents not on the parcel. Might not either tho, but I am pretty sure it would be come up in the discussion [add] Altho having said this it would be remiss of Linden to also not consider what the outcome of nerfing llAddToLandBanList in this way would be. The outcome would be the cementing in of instaboot scripted devices

yes is only necessary for the device to have an internal white list if there was an automated option to add the neighbours to our parcel whitelist. There is no LSL function to identify whether a agent is on the parcel white list or ban list automated option meaning a periodic scan of the neighbour parcels updating the internal whitelist as the neigbours change - adding/removing from the parcel whitelist appropriately. Then again tho if we do have to maintain an internal whitlelist then is no need to add them to the parcel whitelist. The script would just skip over them when doing the ban scan

I wasn''t seeing this, so write a test script with Linden Viewer we only get this message when the agent is added to the parcel ban list using llAddToLandBanList the message is not received when we add the agent manually using the About Land \ Access dialog is a bit of a problem as the message doesn't say what parcel the agent has been banned from, When the neighbours keep getting this message every time they go home then some of them are going to file Support tickets, asking why every time they go home they are getting spammed by Second Life with a message telling them they have been banned indefinitely - banned from what ?

you keep saying in thread after thread what you want and why you want it - which is ok. Adding automated nice-to-have options doesn't change the way in which you would deploy the device. The automation suggestions if they were included would be disabled by default because they are options. They have to be enabled to work how does adding a person to the parcel Always allowed list (or internal whitelist) preventing that person from being banned from the parcel by this device, lead you to think that this is being nice to home-invading anti-privacy greifers. Is nuts to think like this

from what you saying it seems like you not saving the changes you make. On the webpage there is a Save Changes button. On the inworld dialog there is a Save button. You have to press the Save/Save Changes button after changing your tier contribution to 0 this link is a bit old but it does step thru the process for both webpage and inworld dialog (Firestorm) showing where the Save buttons are

responding with suggestions to OP's offer to consider suggestions, isn't complaining I made 2 suggestions in response to OP's offer to consider suggestions for other features. I will say them again 1) neighbour white list, not necessarily the same as friends white list. And it would be nice if this could be automated. scan using llGetParcelDetails. If the system isn't automated then people have to be added to the parcel white list (Always allowed) manually. What people ? the people not in our group who we are happy to not ban. To automate this the system has to maintain an internal whitelist because there is no LSL function that allows us to permanently place a person on the parcel's Always allowed white list. 2) automated On/Off switch triggered by presence of parcel owner and/or group and/or person on whitelist OP may not take either of these suggestions up. and is ok if OP does not. One reason for not doing this is that they are nice-to-haves. The same outcome can be achieved by the parcel owner doing this manually

just a fyi on Linden system message re. banning it happens in only one situation as far as I remember. We are on a parcel and while present the land owner changes the parcel to No Access. We get a system dialog message which says (paraphrasing as I can't remember the exact wording) "You no longer have access to this parcell. You have 15 seconds to leave before you will be ejected" and thats what happens if we don't leave. We get ejected after 15 seconds

you might be addressing the wrong person. I have not made any complaint about this type of device moving on tho i get that you have a very firm view of what you want - completely locked down parcel only accessible to you and those on your whitelist or group. Is ok to want this and to have it. Out-of-the-box this system does this. And is nothing wrong with it doing this however people not you, can view privacy for themselves in different ways. Like for example I only care about privacy when I am on my posestand in my changing room. With this system I could do this for my changing room parcel if it could detect me - tun on when I am present, turn off when I am not. At the moment I do this manually but sometimes I forget to turn off. For me I would like to automate this being neighbour friendly. people who try to enter my changing room, aren't typically the neighbours, they are rando flybers. I dunno if you ever been caught up in donut war with your neighbours. Like you start it by ban the neighbours, the neighbours retaliate and ban you. You look at the minimap. Your little parcel surrounded on on all sides by a sea of red - a donut blocked on all sides now this again may not be any worry to someone who likes donuts for sure we could say that we can add our neighbours manually to the orb whitelist. My suggestion is can this be automated please neither of these breaks the operation of the system. They are optional extras, use them or not as suits

keeping it friendly Me > Youse kehehe 😸

maybe a neighbour-friendly option. Orb adds neighbour parcel owners and parcel group to the orb neighbours whitelist. The scan could be done on a timed schedule in addition to manually. ?? Neighbours whitelist not necessarily being the same as Friends whitlelist ?? maybe also a automated Turn on when I am at home. Turn off when I am not at home. (I meaning all agents on orb friends whitlelist)

i like that you making an effort to help address this perennial issue

only Linden can answer this fully however it depends on what question Linden are asked to give an answer too like if we had a paid supporters group for our charity , can we give a free L$ prize to only one member of our group ? where Linden may struggle is with the language used to solicit the donation. Like a big sign: Donate to our charity and go in the draw to win L$100,000. Linden probably say umm! nah.If only because they don't want Support Linden getting overrun by ARs going OMG! gambling !! so suppose it went like this donate to the board, get a token of appreciation (like teddy bear or something). Also get a dialog which says: "Would you like to join our charity donor supporters group for free. Benefits include regular charity activity updates, periodic gift products from our sponsors, participation in our annual L$100,000 cash giveaway, invites to inworld charity soirees and other cool stuff. [Yes] [No] click Yes and go on the supporters (subscribers) list. click No to decline going on the list. Ignore the dialog and the answer is No. People can opt-out of becoming a member of the charity supporters group by clicking [No], they just happy to make a donation and done strictly speaking there is a language misdirection here. The offer to join the donor supporters group is conditional on making a donation. However, it can't be otherwise. Donors are donors, non-donors are not donors. And the offer to be on the donor supporters list can be declined the comparative to giving gifts/benefits i(ncluding L$ to selected group members as part of a larger benefit bundle ) is inworld store groups with paid memberships who do this how Linden might view all this I dunno, only Linden can answer

if we are ok with using a string function truncating to two fractional digits, then the simplest is float f = 123.456789; string message = (string)f; string trunc = llDeleteSubString(message, -4, -1); // when we are unsurethe string message is in LSL cast format (6 fractional digits) from HTTP for example, then double cast: from string to float to string string trunc = llDeleteSubString((string)((float)message), -4, -1);

Coffee Pancake talked about this when Catznip minimap was being developed back in the day paraphrasing Coffee as best I remember, banline info is sent to the viewer only when the agent is within 16 meters of the banline. So the minimap, Catznip and other TPV, can only be updated to show banlines at the same time as they can be shown as inworld tape. This is unlike other parcel info that can be obtained by the viewer within draw distance. The wish is banline info to be available to the viewer at the same time as other parcel info

when we have decided to use two (or other) fractional digits of precision truncating the string then we are flooring the value. We are doing this to save space in linksetdata comparing to the string truncating method // encode (floor math method) integer parsedNumber = (integer)((float)message * 100.0); integer existingNumber = (integer)llLinksetDataRead(aeD); integer domTotal = existingNumber + parsedNumber; llLinksetDataWrite(aeD, (string)domTotal); // decode (floor math method) // Debugging owner says float domFloat = (float)llLinksetDataRead(aeD) * 0.01; // * 0.01 is the same as / 100.0 just a bit faster llOwnerSay("ShadowCave: " + (string)domFloat); pros/cons - both methods result in the same precision - floor math method doesn't encode decimal point saving 1 char - saving 3 chars for value 0 - floor math method doesn't use string functions to encode, uses 1 multiplication operator. floor math method encoding is a bit faster - floor math method decoding uses 1 multiplication operator. floor method decoding is a bit slower

yes the Belli public roads/spaces autoreturn is set to 1 minute. Which is pretty quick compared to mainland where is typically 5 minutes

in Linden Viewer 7.1.2 look in folder Library \ Textures \ Materials

if we on a vehicle then we can enter a parcel with Object Entry = Off. Should we get ejected by an orb then our vehicle is not returned by Object Entry being off. Our vehicle will stay on the parcel til Parcel auto-return kicks in Object Entry is provided to stop unattended objects from entering a parcel, like bullets, robocars, etc

yes thats correct with menu: Show Banlines on Proximity we see the banline tape when we are within 16meters of the parcel boundary. This distance has always been the case since forever Linden have recent-ish added Show Banlines on Collision - means we don't see the banline tape til we crash into them. This option suits people who have neighbour parcels with access restricted there is no option Show Banlines within Draw Distance. This would suit travelers, has been asked for a number of times down the years, but Linden have not provided this yet nor has there been any firm Linden commitment to do so i just want to add on here about the ban box. When we talking about privacy for ourselves when we at home then the ban box is the best way to achieve this combined with Parcel Visibility. Is pre-emptive unlike an orb. Unwanted visitors are prevented from entering the ban box. And with parcel visibility when we are inside the ban box then anyone over the ban box can't see our avatar either

the ban box for no access or group only access is upto 50 meters above the terrain. Other people, not the owner or not in group, can flyover the ban box without restriction we only see banline tape above 50 meters when we are explicitly on the parcel ban list

this is true of many orbs which are focused only agent intruders a orb that returns the intruder's objects gives more flexibility in parcel settings. For example return all objects of agents not on orb whitelist