Jump to content

Lucia Nightfire

Resident
  • Posts

    3,476
  • Joined

Posts posted by Lucia Nightfire

  1. So now it's metaverses we all need and not a metaverse? Got it.

    Capitalism, patents and brand/IP rights/protection won't allow for a true metaverse anyway.

    All this metaverse slanging that tech companies are doing now is to gage interest and to signal to those with less money to throw around that, "We got this. Don't even try it.".

    All the while, no one is going to come up with anything remotely like the pie in the sky everyone is dreaming of.

    Until the day full-dive is actually a thing, it's all an absolute waste of time.

     

    P.S. Full-dive without RW-to-IW observed time ratioing will be a bummer to. I want to overclock my brain and live pseudo forever while acquiring the knowledge of a god and all the time to do it in. IDC if I lose my humanity/identity/compassion in the process. Yeah...

    • Haha 1
  2. 2 hours ago, LoneWolfiNTj said:

    Ok, I'm seeing now that I very much need to do that, yes. After experimenting, I just learned two very interesting things!

    1. The teleporter in front of my house was interacting with the teleporter inside my house! Apparently, Experience permission requests, grants, and denials are broadcast over all devices with the same Experience baked into them. So doing fresh double-checks of what avatar is where when an event happens is vital.
    2. The permissions were NOT being requested twice! The later "denial" was not so much a "denial" as a "revocation"! Still more reason to ignore all such events unless (agent_id == llAvatarOnSitTarget())

    I suppose as I gain more experience with Experiences I'll be caught by-surprise by these things less often.

    There is no "broadcasting". Scripts that contain experience permissions (0x62000) automatically monitor when the perms holder either blocks the experience or enters land that does not have a land scope experience allowed and removes all perms.

    1 hour ago, Quistess Alpha said:

    This just occured to me, but one cool thing about experience permissions is that they only need ot be requested once per avatar. As an alternative to requesting experience permissions, llAgentInExperience() can be used to test if the avatar has already granted permissions, roughly:

    safe_teleport(key ID, /*landmark stuff*/)
    {	// write landmark stuff to global variables.
      if(llAgentInExperience(ID))
      {	// do the teleport.
      }else
      {	llRequestExperiencePermissions(ID);
      }
    }

    Edit: actually, not tested Hmm. . .

    FYI, llAgentInExperience() can return false negatives while the target is over land that does not have the land scope experience allowed.

    • Like 2
  3. 3 hours ago, LoneWolfiNTj said:

    So I investigated what was triggering that, and it was the "experience_permission_denied" event. And, strangely, the "Reason" number was "17", meaning "experience not permitted on land". The "agent_id" gave a UUID which turned out to be the avatar key of my friend who had used the teleporter two minutes earlier.

    Unanswered experience permission requests remain active in the background for any one agent up to 5 minutes.

    You need to tailor your work flow to only handle one user at a time and ignore denied events from anyone other than the person of interest.

    What you encountered is the opposite of someone granting permissions after someone else steps in and has a request made and granted. https://jira.secondlife.com/browse/BUG-228162

    In that scenario, we really need a dedicated error code.

  4. first, check an attachment with llGetAttachedList() + llGetObjectDetails () + OBJECT_GROUP (alternatively, make sure object isn't temp attached if NULL_KEY is returned)

    then, check the wearer with llGetObjectDetails () + OBJECT_GROUP_TAG (make sure all group role titles are unique and no one else can/will change them)

    http://wiki.secondlife.com/wiki/LlGetObjectDetails

    http://wiki.secondlife.com/wiki/LlGetAttachedList

    • Like 3
  5. On 9/24/2021 at 3:09 AM, Jaylinbridges said:

    If you add at least one name (any resident) to your parcel ban list, then you can not see another avatar when you are over 50 meters away and both avatars are on the SAME parcel.  This was tested only on a Bellisseria 1024 sqm parcel.  On larger parcels the visibility distance increases.  I think this is a long term bug (or undocumented feature).  But someone can hover like 51 meters higher than you with parcel privacy turned on, and you cannot see them and they cannot see you, if there is at least one banned name in the parcel ban list.  

    For example, if my Alt is at 21 meters elevation, on the ground, then he will turn invisible when I fly to a height of 72 meters above him on the parcel.

     

     

     

    Yet, another dated bug LL won't prioritize fixing. https://jira.secondlife.com/browse/BUG-37601

    The parcel privacy ceiling no longer works on full region estates, too. https://jira.secondlife.com/browse/BUG-230749

    • Sad 1
  6. 2 hours ago, Bree Giffen said:

    Did you know that Windows has peer to peer network sharing turned on by default? That means when someone in your area is downloading a Microsoft update, your computer might be uploading it’s data to that other computer?  I turned that “feature” off.

    *Windows 10 and up

  7. On 9/20/2021 at 11:08 PM, Mazidox Linden said:

    Second Life Server

    We'll be rolling last week's RC roll, version 563375 to all remaining channels and simhosts this week.

    Second Life RC

    No new roll for RC this week, but keep your eyes on the Server Technology forum for some news about upcoming releases!

    Region Restarts

    After Grid Poking Bot nearly gained sentience earlier today our engineers will be handling region restarts manually until we've had a chance to check the bot's code and make sure it's set to "friendly helper" 🙂

    What's with all the regions restarting ATM?

    OK, not "all", but I indirectly monitor thousands of regions and I'm seeing dozens restarting ATM, plus many of them are "stuck" showing "starting" via dataserver events.

    OK, got word it is "minor grid maintenance" and won't result in an incident report...

  8. 9 hours ago, LoneWolfiNTj said:

    I have a skybox with an interesting feature: if you sit on the roof, you instantly end up standing on the floor of the skybox 25m below; and if you sit on the floor, you instantly end up standing on the roof; and no permissions are asked either way.

    Until tonight, I had no clue how that was done, because the perms on the scripts in my skybox are "no modify" so I can't read the scripts. But tonight it hit me like a thunderbolt: It's being done using llSitTarget() trickery! On sitting, the person is translated by some <x,y,z> vector to a new location then unsat with llUnSit().

    So I wondered if this is confined to a single region. No it is not! I created the following script:

    // No-Permissions-Teleport.lsl
    default
    {
        state_entry()
        {
            llSitTarget(<1234.5, -2345.6, 0.0>, llEuler2Rot(<0.0, 0.0, PI>));
        }
        changed(integer what_changed)
        {
            if (what_changed & CHANGED_LINK)
            {
                key ava_key = llAvatarOnSitTarget();
                if (NULL_KEY != ava_key)
                {
                    llUnSit(ava_key);
                }
            }
        }
    }

    Then I went to a sandbox, rezzed a slab 10m x 10m x 10cm, 100m in the air, flew up, stood on the slab, then sat on it. Boom, I was in a different region altogether! Unbelievable! Check out the attached image; the red circle is where I started, and the "you are here" icon is where I ended up.

    So, one can do no-permissions teleporting this way. I'm not sure what the limitations are, or if there are any. I'm tempted to try translations of 100km just to see if it actually works. If it can transport me 2 regions away (as it did), I'm pretty sure it can transport me anywhere in SL. I'll experiment with that.

    No-Permissions-Teleport.png

    Not to be a downer, but you discovered something that some people have been using for years. 😉

     

    4 hours ago, Wulfie Reanimator said:

    FYI, an avatar that is sitting on an object can be moved up to 2000 meters away from the root using functions like llSetLinkPrimitiveParamsFast and PRIM_POS_LOCAL.

    *1000 (you made me check that again to see if LL changed anything recently, but they didn't)

    • Like 1
    • Thanks 1
  9. 5 hours ago, Sid Nagy said:

    Cut them some slack.
    Afteral we are talking about a LL implementation.
    "NEVER the first time right" is part of their TAO, no?

    "We'll add it in a follow-up!" is also part their tao now which, at this point, has been either one broken promise after another or just straight up lies.

    • Like 3
  10. 2 hours ago, Innula Zenovka said:

    Yes, but that's a very specific use case, I think.   Not many people run animatronic knocking shops or whatever on their land, after all, and if they do, I'd have thought the rezzers could solve the problem, should it arise, by checking who on the parcel owns what before they try to rez a playmate, and if someone's seated on something that doesn't belong to the landowner that's too high an LI to allow this, simply have the script unsit and send them home,  which should also trigger object return shortly afterwards.     Would something like that not work?

    I simply do not want to add the overhead to each rezzer, one for rezzing characters, furniture, bits, animation preloaders, adjusting helpers.

    I'm already splitting scripts big time with everything as it is. To check who is sitting on something and where, I would have to use a dedicated llGetAgentList() script per rezzer or involve back and forth to a central service.

    I can't depend on an unsit magically causing a vehicle to die especially if the owner selects it or might have it already selected.

    Vehicles sometimes enter regions without a sitter as they've already crashed to desktop or got unsat in an adjacent region.

    I simply have a dedicated central single-scripted host that, at the bare minimum, checks for changes in llGetParcelPrimCount() that, upon change, checks where the land impact is coming from and if it is not owned by me, moves to the parcel, executes a prim return then moves back to its origin.

    I simply do not want to add overhead anywhere to accommodate vehicles.

    If vehicles weren't able to override the no-object entry flag, 99.9% of vehicle user's ire would be on just banlines and not security orbs.

    • Thanks 2
  11. 1 hour ago, Innula Zenovka said:

    Yes, but if they're not using it for the 10 seconds or however long it takes me to drive across their parcel,  what's the harm?   If there's a problem, surely it results in my vehicle not being able to enter their parcel rather than in their objects being returned from the parcel?

     

    That still depends on the land owner's needs/reasoning.

    For me, I've had idiots stop on my land with their 500+ land impact (once it turned physical) car doing who knows what, maybe take a selfie or to look at the surroundings.

    My land has a specific use case and that is to rez one or more high land impact animesh "playmates" on demand per clientele, anywhere from 75 to over 400 land impact each.

    I also offer private rooms at various altitudes on individual privacy parcels.

    So when I get people entering private parcels or when I get an influx of land impact that I do not own, people get sent home and objects get returned.

    • Like 1
    • Thanks 1
  12. 1 hour ago, Innula Zenovka said:

    So initially the LI comes out of what's available on my land, but then it comes out of the region LI when I drive off.

    There are two pools that are being used, the parcel pool (parcel owner available prims grid-wide) and the region pool (ignoring region object bonus).

    Driving off the parcel, just means someone else is now eating the land impact, that is, if you entered a different land owner's parcel.

    Also, as long as the land impact doesn't go over their available prims, else, others are eating that overage in a distributed ratio region wide.

  13. 1 hour ago, Qie Niangao said:

    Once all bugs and other griefing vectors are fixed, some desperate ne'er-do-well might resort to vehicle abuse. Do let's hasten to prevent that at all cost, lest fun be had in the meantime.

    Fillers and overfillers have been a thing in "Combat HUDs" for years.

    It's why I even added it to my NPV from the days(over 5 years ago) I use to hang out in the weapons testing sandbox to block idiots from filling it with spam or attacks.

    I've filed this feature request and this feature request to deter that behavior, but LL hasn't bothered implementing any protocol.

  14. I got something wrong in that previous list.

    It's 10% region overflow of non-temp legacy prims or mesh that blocks non-temp legacy prim and mesh rezzing in the reigon.

    It's 10% region temp prim overflow that blocks temp legacy prim or mesh rezzing, but not non-temp legacy prim rezzing.

    Also, this rate might also apply to the grid-wide parcel owner level as well.

    • Thanks 1
  15. 1 hour ago, Innula Zenovka said:

    Are you sure about this?

    One of my alts has just rezzed a car on their plot on Bellisseria:

    1ae7d98747592a7149f96e4dc095fc14.png

    This is the resulting LI

     

    I can come to your parcel, rez and sit on my NPV and block all rezzing on your land or in the region if you want. Send me a tp lure. 😉

  16. 1 hour ago, Innula Zenovka said:

    I may be mistaken, but doesn't the vehicle's LI (and that of any of its passengers, come to that) come out of the region's "spare" LI that's allocated to, but not currently in use by, individual parcels?    That is, the same pool of spare LI than temp-on-rez objects use?

    If the region is literally full, vehicles can't enter it, of course, but otherwise I don't see how LI matters.     I might not want vehicles crossing my land, or even one of their wheels temporarily impinging on it, for all sorts of reasons, but I don't think LI needs to be one of them.

    Only if the vehicle is temp on rez, contains 0 mesh and the land impact does not go over 10% of the region's max prims.

    Mesh, even when set to temp, does not use temp prim accounting.

    Mesh "Prim" physics shapes can balloon land impact when a linkset is turned physical.

    The presence of sitters or selectors prevents autoreturn or overflow return.

    Non-temp land impact that exceeds a parcel's maximum prim allowance begins to "take away" available prims from other parcels at a proportion based on % of parcel size versus region max prims.

    Temp prim land impact that overflows a region's max prim allowance by 10% will block rezzing of temp, non-temp or mesh content anywhere in the region.

    Region-wide temp prim overflow can instantly cause all temp non-mesh objects in the region to die.

    And, yes, when a region's max prims have been overflowed, no vehicles or objects can enter.

    TL;DR - If a vehicle contains mesh or is non-temp, a parcel owner is eating the land impact.

    • Thanks 2
  17. 10 hours ago, connorboy26 said:

    It's not a very busy sim

    If someone has scripted terraforming running or pathfinding breedables/critters running around or just lots of physical objects floating around or updating child link positions/rotations or any physical objects colliding with other objects, either of which, having complex physics shapes, this can cause region physics memory to creep up over time.

    Maybe take a look around to see if any of this is going on.

    A "busy" region doesn't have to have agents.

    • Thanks 1
×
×
  • Create New...