NeoBokrug Elytis
-
Posts
160 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by NeoBokrug Elytis
-
-
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.
-
4
-
-
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.
-
2
-
-
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.
-
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.
-
3
-
1
-
3
-
-
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.
-
1
-
-
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!
-
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.
-
2
-
Oh, I didn't see it on the JIRA.
-
1
-
-
Found a bug for you. Bring me to the betas next time.
-
Why doesn't Second Life have gift cards? I go to the stores and I see gift cards for just about every game or service imaginable. These gift cards could simply be for premium membership time, or better; un-cash-out-able account credit.
The gift cards are more than just an alternate way to bring money into SL, but also a way to advertise the platform.
-
Just for clarifications sake:
A regular Experience Key requires a region to have the ExpKey as a Trusted Experience?
And a Grid Scope Key does not? It can work on Mainland?
-
Title sort of sums it all up -- but the grid was havin' some weekend issues, and my experience had a lot of XP_ERROR_STORAGE_EXCEPTION issues as well.
Just loggin' it here to get some eyeballs on it.
-
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.
-
I just assume that it goes to the black hole known as "WorkingOnIt Linden"
-
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.
-
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.
-
Just walk away.
Give me the scripts, the experience keys, the parcels, and the whole region, and I'll spare your lives.
Just walk away. I will give you safe passage in The Wastelands.
Just walk away and there will be an end to the horror.
I await your answer. You have one full day to decide.
p.s. More keys pls.
-
Thank you. It is done!
-
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
-
Are there any plans to take them out of chiclets if they're part of an experience?
-
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:
- Run around the 10 regions of my estate looking for crates.
- Loot the crates to get items, parts of things, trinkets, and food.
- 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.
- The items, trinkets and parts can be crafted at a crafting station into weapons or vanity items; which are also tradeable.
- Use the weapons to fight other people also looking for loot, or kill a buzzard or two for it's delicious meats.
- 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
-
Good. Thanks for testing! It must have been a viewer setting in FS or something then.
-
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
-
I'm actually pretty giddy about the HTTP-IN fix. It's kind of been a pain in the butt, but I am glad it's being fixed faster than normal. I have a question though, is it at all related to dataserver() not responding as well? I haven't filed a bug about it, but occasionally dataserver() doesn't give a reply, and I have found that it is near when http-in URLs are dropped that it starts behaving like that.
@WolfBaginski: Less snark, more constructive feedback.
Facebook
Instagram
Twitter
YouTube
Flickr
Is LL putting more sims on fewer servers?
in Second Life Server
Posted
Additionally, I forgot to mention that regions sometimes degrade in performance for no describable reason. The region had only been online a few days (Tuesday to Saturday), but by that time it got bad Case in point: My main region "The Wastelands" had only 33% scripts executed one day. It took TWO restarts to clear it back up to 100% -- but the restarts fixed it nonetheless. This happens more often than I'd like to admit on all of my regions.
Just last week I had one region drop down to 50%, and it was because someone had rezzed a collection of objects that were pounding the viewer with minor object updates; a steady stream of 0.5mb for each av in view. In total these objects also used about 1.5ms of script time (I know, a lot), but relatively speaking a small fraction of the total script time in the region. As soon as these objects were removed, UDP data to the viewer more than halved, and scripts executed jumped back up to 75-80%. That's my basis for script execution being related to a network problem.
Over a month ago I used the SALT HUD to request some mega prims for something I'm working on. At the time it seemed like it was broken, and I assumed it was because it's old. However, just two days ago I got two inventory offers for the prims I requested way back when. Now maybe all the delivery nodes were all offline, or maybe the tubes at LLs end need to be flushed out with lottery balls.
@Qie Niangao I've seen it occasionally in the dataserver() event after a restart, but that's why I usually wait a little bit to do anything. I've been pushing that timer back further and further as time goes on. However this instance of XP_ERROR_INVALID_EXPERIENCE was specifically with llRequestExperiencePermissions and it lasted for about 5 minutes before things suddenly worked in the region. What's baffling is, that the player got a game HUD from a neighboring region and walked into the problem region (where upon more checks were made) and the HUD spat out the same error. That shows that communications with experiences (and in general) is lagged until the region catches up.
I really think this is a big networking problem that's been quietly growing for years.