Jump to content

NeoBokrug Elytis

Resident
  • Content Count

    132
  • Joined

  • Last visited

Posts posted by NeoBokrug Elytis

  1. I run The Wastelands, 10 regions big, a mix of Full Regions and Homesteads.  I like to keep my estate running nice, so I am a bit of a stats hawk.  Sometime last year things started to sometimes get bad enough to notice, and since then I have been doing casual research.  Here's what I know so far: @Oz Linden, @Whirly Fizzle

    "Top Scripts" in the region debug menu always reports HALF or less of what the Statistics menu says.  Even with "Spare Time" available, "Scripts Run" doesn't seem to use it.

    "Scripts Run" seems to be affected by a regions networking burden in addition to the obvious events per second (more scripts).  You will find that regions that have a exceptionally bad "Scripts Run" stat directly correlates to how much networking it's doing.  Could be object updates, or packets in/out, and especially noticeable when people teleport in/out. 

    Now, when regions come online they have been increasingly slow for all the "services" to fully start.  Specifically the dataserver() event is most noticeable right now, sometimes a few objects that I use to monitor the estate are slow to come online and take a few retries.

    I also run an Experience and during todays rolling restart someone tried to interact with an object that uses llRequestExperiencePermissions() and it returned an XP_ERROR_INVALID_EXPERIENCE despite that script being compiled for an experience for years.  It took probably 5 minutes for it to finally work properly without my intervention.

    As strange as it seems, I think networking for the regions is borked or throttled and is probably a bigger meta issue that just happens to affect "Scripts Run" as well.  I would probably look into the HTTP/UDP changes that have been made in the past year.

    • Thanks 4
  2. 4 hours ago, Qie Niangao said:

    But I've had this nagging thought: maybe it's not merely subjective and artifactual. Maybe sims' script-handling capacity has diminished. I doubt it, but I can't disprove it.

    Just for the record, I've noticed the same thing over the past two years... maybe?

    I think it has to do with all the logging of region "things" that LL has been adding over the years.  If you look at region release notes for the past two years, it's pretty much all "more internal logging".

    Scripts Executed is my go to stat now in determining region health.  Time Dilation and Physics usually say everything is just fine.  But when Scripts Executed gets below a certain threshold (65%), things that rely on scripts (pretty much everything), start to break down.

    • Like 2
  3. 13 hours ago, Sharie Criss said:

    I said resources.

    For the future, I guess maybe you should clarify then.  The subject of the sentence I quoted was the performance of servers and regions.  In that same sentence you said "resources to Sansar".  Any competent person would follow that sentence and come to the conclusion the resources you speak of are servers or regions.  There is not one single mention of money.  You should have said just said money instead of resources.

    In an online forum where the written word is everything to convey your argument, it's very important you convey your message correctly.

  4. On 8/6/2018 at 6:40 AM, Sharie Criss said:

    The biggest cause of this newer level of horrid performance is that LL reduced performance for regions by shoving more regions on a server so they could give resources to Sansar. 

    This is the dumbest thing I've read this month.

     

    • Like 3
    • Thanks 1
    • Haha 3
  5. Even a little bit of warning about the headers change would have gone a long way to ease a ton of frustration for everyone involved.

    I normally adapt rather well to LLs sudden LSL changes that break things simply because I am usually available for it.  And while it's not LLs problem personally, I actually had surgery a three days before this recent change.  Which means I had to find out about the change after the fact, drag myself to the computer when I should have been resting (because everything is broken), and make some quick fixes.

    Warnings about intentional and significant LSL changes such as this, SHOULD HAVE BEEN MADE CLEAR in advance, so we could at least have the opportunity to plan to make changes.  To me communication seems like an ongoing issue, whether or not the changes were intentional.

     

    • Like 1
  6. I think that it's only limited to the region pages.  If you do the same thing for a parcel page it works.  Additionally it's only they x and y portions of the vector that the client doesn't like being over 256.  I am pretty sure the z can go up to 4096 easily.

    31 minutes ago, Jo Yardley said:

    But the place pages teleporting doesn't seem to work very well in general, often when I click the visit button nothing happens at all, sometimes it opens another version of SL!

  7. Wow.  The JIRA was already closed with the reasoning: "Visit This Location is by design."

    So by design, the link is not supposed to work at all for region pages?

    This is why I hate filing JIRAs, because I spend my time writing them up with what I know, and someone who doesn't read, or try to understand the issue, closes it down.  Then I can't even comment on it to correct their misunderstanding because it's closed.

    [Edit to add...]

    ---  Since the JIRA issue is closed, I am explaining further and posting my fix here ---

    The SL viewer does not like URI location x, y, z, values greater than 256.  On a region page (not a parcel) ,the regions global coordinates are where the X and Y should be instead of local coordinates.  Since my regions global coordinates are 786x, 1038y, clicking Visit this Location will try to open another instance of the viewer because it doesn't understand what the URI wants to do, instead of opening the Place Profile window of the viewer.

    Possible fixes, one is tested and works:

    • For region pages only, default the x,y,z to 128,128,0.  Because it's a region destination it should be fine. (less desirable, but works)
    • Find the regions telehub/infohub coordinates with a back-end search, and put actual x,y,z coordinates in.

    I pray that a Linden sees this, and instructs someone to re-open the issue as it is a LEGITIMATE BUG.

     

    • Like 2
  8. Has there been any pricing point discussions?

    Will there be account requirements, for say accountability?  Am I correct to  assume Concierge level at least?

    If your experience gets shut down by TriggerFinger Linden, how does one go about getting it reinstated, speedy like?

    Hopefully things are going super smooth, and there's no discussion of limiting the LSL calls?

    I haven't had a single problem that I am aware of since my initial reports.  Other grid issues (rezzing / inventory) typically pop up before Experience Tools has issues.  THIS CONFUSES ME AND FILLS ME WITH FEAR OF THINGS JUST WORKING.

    CDN seems to have imprved things a lot server side.

  9. This is a bit tangental...

    As Frans Charming said, the KVP is what experience scripters REALLY want.  Glorified permissions are nice and all for an users end in the experience, but the utility of them is dwarfed by the KVP.  I've been migrating my http stuff to KVP, and it's everything I really needed 7 years ago.  Coding in pure LSL is far better than LSL->PHP->MySQL and back again; and so far much more reliable.

    One thing you may want to consider is not just Experience Keys, but perhaps an opt-in avatar based KVP system.  I know a lot of scripters that would pay to have their own personal KVP storeage.  Updating settings for a product or project on the fly is a killer feature, and they really don't need 128MB for it to work.  Heck they could probably get away with 2mb that would cover dozens of products.

    Another thing I would like to see is SETTING an experience key for the script.  That way if the previous paragraph ever comes into existence, you could sell scripted systems and experience toolkits to other people.  Then they could deploy their own experience or KVP storage much easier.

  10. Just a bit of an update:  We've created a tutorial area, not because our game is difficult, but because it has 7+ years of content and learning the basics on your own without reading the wiki is hard.  Adding even more ExpTools related content really warrants this.  I've already had a few compliments about it from people who have never been to the estate.

    Speaking of content we've also added a few daily quests that leverage ExpTools (find-specific-item, temp-attach item, carry-to-destination).  We've added a few "underground" areas that are enclosed instances -- which are really just cave entrances in walls that teleport people to a different location in the region.  We plan to add a few more if we can manage to free up prims.  Aside from the teleport noise and notice, it's pretty seamless!

    Our ExpHUD is no longer beta, and now mandatory to play the game.  I chose to centralize distribution of the game hud (temp-attached) at the major telehubs across the estate.  Centralized distribution has got more pros than cons, the primary con being that people don't like change.  But everyone is adapting at their own pace, and for the most part everyone really enjoys the exp-updates.  The biggest pro is that I can slap out updates as fast as I can make 'em.  I'm still working on porting over a lot of the more simple database logic that doesn't involve sorting records to exp-tools.  But I am torn between adding new content and porting over old code...

    Our only gripe so far is the Project Interesting bug where things don't update client side if there are changes that are out of view.  That's really killing us since our crates and objects de-spawn after a time.  People think they're clicking crates to loot, but the crate has already been gone a while, and it's disappearing because the client updated -- not because they got an item.  This bug which isn't related to ExpTools is really making a lot of people upset.

  11. This is an idea from my old wishlist of things I'd like to see in SL that would greatly enhance the immersion of a place. I know this is a bit of a stretch, and probably out of the current scope of the project but...

    Windlight is a seldom used, but powerful feature of Second Life.  Combined with experience keys it could have amazing potential to add a whole new level of immersion in Second Life.  I imagine controlling weather with fine-grain detail, vision impairments and enhancements, and gnarley and fast changing status effects.  The sky is (literally) the limit.  So I propose the following two functions that would at minimum require Experience Permissions to work.  The idea is that they change the viewers windlight setting for whatever avatar that has permissions, that this function is called for.

    llChangeWindlightSettings(key avatar, string json_or_xml, integer override);

    llChangeWindlightDayCycle(key avatar, string json_or_xml, integer override);

    Since changing windlight settings is a very powerful option to be done by a script, it should require permissions of some sort, and this is why experience keys would be needed,

    string json_or_xml could, and probably should instead be replaced with a nice sanitized list of windlight options.

    integer override should attempt to prevent the user from altering the current windlight setting, at least until a relog.  Though not required, it would be nice.

    Please discuss! :D

    JIRA BUG-7116

  12. For the most part, I have converted my Wastelands game into a BETA version (until EXP tools are finalized) that runs parallel to the legacy version.  I am still working on making new stuff specific to the experience tools, and minor updates as I find porting issues.

    A summary of the game is as follows:  

    1. Run around the 10 regions of my estate looking for crates.
    2. Loot the crates to get items, parts of things, trinkets, and food.
    3. Each piece of loot is tradeable to other avatars, or you can sell them for L$ -- or you know... eat the food to help stay alive.
    4. The items, trinkets and parts can be crafted at a crafting station into weapons or vanity items; which are also tradeable.
    5. Use the weapons to fight other people also looking for loot, or kill a buzzard or two for it's delicious meats.
    6. Got too much stuff, or don't have the parts you want?  Bring them to one of three trader NPCs to exchange them for different and sometimes unique things specific to that NPC.

    Mostly the HUD is used as a tool to RP on my estate.  But since neither RP or the HUD is mandatory, people pick and choose their level of involvement.  I also host Fight Night on Saturdays at 3pm PDT at our arena.  Our arena is as if Thunderdome met Robotwars, but with people instead of robots.

    Grab the BETA HUD here to start playing immediately:  http://maps.secondlife.com/secondlife/The%20Wastelands/137/156/67

    Full details about our game here: http://wiki.the-wastelands.org/Category:Games

  13. Now I don't use firestorm myself, and I know LL isn't responsible for Firestorm, but I had one friend come to test something...

    On the newest version of Firestorm, I had them come click to be prompted for the Experience, so I could see what the permissions dialog looked like.  To my surprize they weren't even presented with a pop-up, and were auto-opted in.  This could easily be a problem, if this isn't just a one-off case.  I have yet to test with other Firestorm users, which is why I am asking if other people could test for me/us.

    If it is still a problem, maybe someone with the proper contacts should let the FS people know?

    The most up to date Linden lab official viewer has a prompt that works just fine.

     

    p.s.  I finished porting over my Wastelands HUD / Game to a beta version for testing. come give it a whirl: http://maps.secondlife.com/secondlife/The%20Wastelands/136/156/67

×
×
  • Create New...