elleevelyn

is always interesting to think about urban design so continuing on with the complete derail of this thread 😸i think Belli urban homes are doable with 16 x 64 parcels - some houseboat parcels are this shape to begin: the front of house butted to the pavement with a backgarden. Is the butting of house to pavement that gives houses the urban feel a major design decision is whether they look like joined up terrace houses, or detached homes just a lot closer together than suburban homes on 32x32 parcels. Of the two designs, I think the detached homes would be the least chosen in a 16x64 parcel design. People who desire detached homes prefer to have as much space as possible between their house and the neighbours house, so go with a 32x32 parcel with terrace houses on 16x64 parcels then the home building would need be exactly 16 meters wide. The depth of the house can be variable depending on style. With 16m fixed width then for all styles, the house butts exactly to the facade on the parcel divider land on the sides the side divider land facade could be in various configurations: on the front and rear ends of the facade, sometimes a wall, sometimes a recess with a plant box, sometimes an alleyway between the houses. On each side of the facade, a wall butted up to the resident parcel boundaries. When not an alleyway then a roof on the facade to help make it look more joined up on the rear garden end, then a wall on the divider with an opening leading to the common back alleyway. with house styles - there would be no side windows or doors, only front and rear - the frontage could be fully 16 meters wide with the front door opening direct onto the pavement - the frontage could be recessed so is a front porch, stepping from the porch to the pavement - the house frontage could be 8 meters wide on one side with porch or no porch, and a 8 meter wide recess on the other for off-street car parking or front side garden as the resident decides to decorate - two storeys high - no variation on this. I probably forgo any kind of roof garden build as the parcel already has a relatively substantial back garden area with this terrace house setting then rather than open parkland, Mole corner store, Mole coffee kiosk, Mole urban walled garden, etc. These would typically be on street corners given the shape of the resident parcels a consideration is that these kinds of homes may be in least demand. With the old Linden Homes, am pretty sure the joined up quad homes were the least chosen. But I think the perceived shared courtyard of quad homes had a further impact on choice, which these Belli urban terrace houses wouldn't have, so a slight amelioration

other than the example pcode script nothing in here about the server is true if what is in a subsequent post is true reading thru what everyone has said and thinking more about how NAK occurs then my guess is the server design is something like this on every llGetNotecardLineSynch call if (notecard in cache) return line else { fetch notecard from datastore and cache if (fetch successful in X time) return line else return NAK } if this is true then NAK is the result of region server not being able to re/fetch and cache the notecard in a timely manner if so then a way to cater for NAK recovery while doing a sequential read can go something like // global string notecardName; integer notecardLine; key notecardQuery; // local call to get started notecardQuery = llGetNotecardLine(notecardName, notecardLine); dataserver(key query, string data) { if (query == notecardQuery) { // data should never be NAK at this moment ?? if (data != EOF) { ... do something with data ... integer continue = TRUE; do { data = llGetNotecardLineSynch(notecardName, ++notecardLine); if (data == NAK) { // is cache issue so revert to llGetNotecardLine for this line continue = FALSE; notecardQuery = llGetNotecardLine(notecardName, notecardLine); } else if (data != EOF) { ... do something with data ... } } while (data != EOF && continue); } } }

and getting our vehicle stuck in a banline and having to edit it off the banline (as is the current situation) is better than getting teleported home without any warning

on this part we can make a impulse engine with llMoveToTarget as the main engine component. With the rezzer (param) setting the distance for the vehicle to travel llMoveToTarget will try to push away physical objects and agents in its path ,as it slaves toward the target example pcode integer time_to_target; destroy() { ... destroy vehicle effects llDie(); } default { on_rez(integer param) { vector target = llGetPos(); target.x += param; llTarget(target, 1.0); llMoveToTarget(target, 0.4); llSetStatus(...); time_to_target = 60 + llGetUnixTime(); // give it for example 60 seconds to reach target } not_at_target() { if (llGetUnixTime() < time_to_target) { ... here as an effect we can llApplyRotationalImpulse/llSetAngularVelocity ... to slew/drift the vehicle as it slaves toward the target ... llApplyImpulse can also be used to give it an extra push forward } else // times up destroy(); } at_target(...) { destroy(); } collision_start(integer detected) { ... if detected is agent or physical then ... llApplyImpulse to give detected a hard shove } } https://wiki.secondlife.com/wiki/LlMoveToTarget

yes. Will need to pay attention to NAK . On NAK then retry that line. If retries continue to return NAK then at some point willl have to drop down to standard llGetNotecardLine and dataserver event

about detecting agents on the neighbouring region before they cross onto the device parcel llSensorRepeat can do this maybe the device could rez a sensor_repeat object which on sensor detection sends a message to the device to include the detected agent on the next region it could be designed so that the sensor will only activate when is positioned within say ?4? meters of the region boundary this said, sensors can be a bit unreliable sometimes, and only have a range of 96 meters. But still being able to pre-warn away agents most/some of the times, who are moving about near ground level is a friendly thing to do. For agents moving about at 3000 meters exploring skyboxes then I be less inclined to worry about them when they cross from the neighbour region

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