elleevelyn

i think a get lucky ISAM strategy can be viable under light/moderate server load. A safe method can be something like // data handler function handleData(string data) { if (data != EOF) { ... do something with this notecardLine of data ... } } // a prior call to set up the cache llGetNumberOfNotecardLines(); // under light/moderate load then more times than not this // will result in something other than NAK string data = llGetNotecardLineSync(notecardName, notecardLine); if (data != NAK) handleData(data); else notecardQuery = llGetNotecardLine(notecardName, notecardLine); dataserver(key query, string data) { if (query == notecardQuery) handleData(data); }

yes you onto it it just shows in a horrible way what is needed when we don't use the dataserver event in combination with llGetNotecardLineSync(). Is in the not-the-same-as-the-last algorithm class. Example of: // thrash it until nextnumber is not equal to thisnumber. // How likely is it that they will always be equal ? // Not likely, until the one time it is float thisnumber = llFrand(1.0); float nextnumber; do { nextnumber = llFrand(1.0); } while (nextnumber == thisnumber);

just because I can and I got nothing better to do😸 @OhWellDoItAgain; string data; integer continue; do { llGetNotecardLinesCount(); data = llGetNotecardLineSync(notecardName, notecardLine); if (data == NAK) { // thrash it upto 10,000 times but yanno :) continue = ++continue % 10000; } else continue = FALSE; } while (continue); if (data == NAK) { jump OhWellDoItAgain; }

is some nuances that have to be catered for. Like Rider Linden had to change Damage to be a property of the prim (from being a script property) when he developed llRezObjectWithParams. This was to save server time in identifying objects deliivering/receiving damage without having to interrogate the script(s) within. And I think Linden would want to save time in the same way with the vehicle object for this purpose

you are channeling Crusher Collins now !! (google new zealand politician) Ms Collins is total ruthless when it comes to hooligan car drivers :😲

based on llGetObjectDetails then I think vehicle type is a property of the script, is not a property of the prim. So I think vehicle for this purpose would be any prim sat on

about carparking at my inworld shop (if I had one, which I never) Big sign: "Free parking for paying customers. Please pay the parking meter L$10 for 1 hour. You can park for as many hours as you want ok. When you buy something in my shop then I refund your parking fee. if you don't pay the parking fee then your vehicle be towed away by Return-To--Lost&Found Towing Services. Thankyou and happy shopping !!" 😻

the times have gotten shorter since LDPW took over the upkeep back in the day when Governor Linden was responsible then the times were all over the place, including in some places Auto-return = 0 the issue with the longer times was vehicle abandonment and lost prims, You be going down the highway and then can't go any further because next Parcel Full due to abandoned vehicles and random prims lost by builders on the region

on mainland roads they are mostly either 5 or 10 minutes

just on this each object does have its own Auto-return timer. Instantiated when the object is rezzed or enters with or without agent sitting so maybe thats a way to for this to work. Parcel setting option: Start Auto-return timer when object is not sat on edit: so forpublic right-of-ways on mainland which are typically Auto return = 5 minutes. Stand and timer starts. Sit and timer stops. Stand again and timer starts over.

i actual gave this some thought would have to be a parcel setting that owner can set or not as they prefer something like option: Pause Auto-return while object owner on parcel a issue could be one or more persons filling up all the available LI (Parcel full) blocking other people on vehicles from entering the parcel. Can see this happening for example on Blake Sea where people are playing war games. So public parcels probably not have this enabled can see it enabled on some private owned parcels where car parks or boat marinas are provided, airports also

yeah that ^^ maybe not make your alt too gorgeous or might end up crash your boat into the dock because too much ogle 😺

pretty much yes. The more I look at this then I can only see issues trying to deal with NAK in a custom loop yes can do retry but what do we do when the retry constantly returns NAK ? Working with the assumption tnat this won't happen is basically gambling. And I am myself not into writing gambling code for a data retrieval program. If we break out of the retry loop then what ? Do we save the line numbers we missed and go back and get them later ? If try to mitigate with llSleep then how long do we sleep it for ? If we do sleep it then none of the other events are going to fire while the script is sleeping is all super messy are custom loops

i had a quick play with the script. It detects me ok when I am within sensor range. It doesn't detect me when I am in a corner of the box where the sensor being a sphere, doesn't reach when working with sensing agent presence inside a box then the sensor sphere is best to encompass the entire box, which we can do by setting the sensor range (radius) to half the diagonal of the box. And then checking for agent position inside the box, so that any agent detected outside the box is excluded some longhand example functions which show a way this can be done (assumes script is in the box prim) float getBoxHalfDiagonal() { // return half the box diagonal vector pos = llGetPos(); vector scale = llGetScale() * 0.5; vector topcorner = pos + scale; vector bottomcorner = pos - scale; return llVecDist(topcorner, bottomcorner) * 0.5; } integer isInBox(vector position) { // is position inside the box ? vector pos = llGetPos(); vector scale = llGetScale() * 0.5; vector topcorner = pos + scale; vector bottomcorner = pos - scale; return (position.x <= topcorner.x) & (position.x >= bottomcorner.x) & (position.y <= topcorner.y) & (position.y >= bottomcorner.y) & (position.z <= topcorner.z) & (position.z >= bottomcorner.z); } default { ... set sensor range to getBoxHalfDiagonal sensor(integer detected) { integer yes = isInBox(llDetectedPos(...)); } }

Linden Viewer: Preferences \ Notifications \ When my friends log in or out with TPV then should be similar

reading the feedback from those doing testing then unless there is further changes from Linden in how the cache works, for a one-time sequential read/write into LinksetData then I be going with this code. Which is a more tidy version of what I posted earlier when the cache is available then use it, when it isn't then continue getting data with standard llGetNotecardLine and dataserver event // global string notecardName; integer notecardLine; key notecardQuery; state default { state_entry() { notecardQuery = llGetNotecardLine(notecardName, notecardLine); } dataserver(key query, string data) { if (query == notecardQuery) { while (data != EOF) { ... write data to LinksetData ... data = llGetNotecardLineSync(notecardName, ++notecardLine); if (data == NAK) { notecardQuery = llGetNotecardLine(notecardName, notecardLine); return; } } } } }

looks like Qie was pretty spot on with Pattern 1 in how this is going to work for sequential reads

is not on Main Server release, nor on Le Tigre. if is on anything on Main Grid then be on Magnum, otherwise Beta Grid. With a Premium account then should be able to access region: "Magnum Sandbox A" and check not sure if is even on Magnum tho as Signal Linden said on 13 January 2024 is "In Progress" https://feedback.secondlife.com/scripting-features/p/add-llgetnotecardlinefast the LSL wiki entry went up on 17 January also just read the following exchange on there. maybe primer1 will come by here and shed more light so if this holds true then at least we know how the caching is triggered

yes this makes sense both for the /* -- maybe and /* -- but not edit add: altho if it didn't wait for some X time when fetching the notecard to cache then wouldn't it always NAK on the very 1st llGetNotecardLineSync call ? I can't actually test this as i can't go to a Linden Magnum sandbox and I dunno where elsewhere there might be a Magnum region

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