Jump to content

Sharie Criss

Resident
  • Posts

    162
  • Joined

  • Last visited

Reputation

81 Excellent

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. So we get the "new search" yet it still lacks BASIC search functionality such as the AND OR and NOT operators. Come on LL, that's a core requirement for ANY useful search engine. The removed metadata from place searching just makes it even more difficult to find interesting places. FAIL.
  2. FYI, you attributed a quote to me that I did not write, I was quoting someone else.
  3. This. This exactly. Can we get old search back please? Yes, it had it's issues, but this new search just doesn't provide the meta data needed to surf SL efficiently. Bring old search back, put this one back in development until they can add the features old search had back in. It's just not ready for prime time. New search reminds me of a every "rewrite this old code as new" project I've been involved with - every single time it takes longer than expected, is buggier than the old, and is feature incomplete. Project managers get fed up with the delays and just say "Ship It!" I suspect that's what has happened here.
  4. The Discord idea has been brought up before (years ago,) and the underlying problems of group chat have been well known by the Lab for over a decade. Small incremental fixes have been rolled out now and then, but the underlying design of Groups (not just chat) is fundamentally broken and the lab has been struggling to make it scale. We SHOULD be able to belong to Hundreds of groups, but as the permission system has to check all our groups every time we do a Land Permission thing (even as simple as the ability to run scripts in a parcel) the reality is that there is a finite limit to the number of groups that can be checked before the sim is spending all it's time doing permission checks and nothing else. [Side note: it's not just land, but that's the easiest to describe.] The inefficiencies in groups account for the limits to the number of roles in a group, the Lab shutting off the group list for large groups, and a plethora of other limitations - group chat is smack in the middle of that mess. Based on what the Lab has shared with us over the years here and there in forums, in-world meetings, etc., it's a monumental problem where the solution will affect EVERYTHING. I'm not shy of finding fault with LL, but in this case I believe they honestly have maxed out what they can do with the existing system and are probably trying to figure out how to move forward with a replacement that can be done by the small dev team they have without sacrificing all their other projects / plans. I know it sucks because it's not integrated into the viewer, but just putting that Discord link in your group description and telling everyone to use that instead really is the only near-term workaround that will probably be needed for a couple years. Discord isn't a panacea - even Discord has a limit of 100 "servers" (groups) you can belong to! If you belong to a lot of active "servers" it can be overwhelming to manage (IMHO significantly worse than SL groups in that regard.) Honestly, some of Discords features can be seen as a huge negative with the same people that do those big gestures in group chat now posting old meme pictures over and over and over and over under the misguided belief they are being clever.... Discord has shown ZERO interest in offering their technology as an integration so there would be a seriously steep uphill battle for LL to convince them to do so. The $$$ aren't there. I mean, Discord just turned down $12 Billion from Microsoft.....
  5. It is a problem to be sure. Rental issues are pretty easy to solve if you use a good rental system that supports bots to handle the group invites (Casper does, others may as well.) If you (anyone) rent land or manage some venue that has groups, it's good customer service to have some sort of bot invite system exactly because you can't be online all the time. The group limit means that there are some groups that you will constantly have to join and leave. If you are a creator and have stores at rental locations all over the grid, you know the pain. Casper's bot integration makes this pretty easy to do as long as there isn't a join fee. LL - if you are listening, we really need to be able to do group management through scripting directly without needing a bot. Also need a way to do an invite and waive the join fee. When you have limits on groups like this and so much of the permission / access systems are group based, we need more management flexibility.
  6. It appears that the llHTTPRequest / http_response() functionality is broken at the moment - I did not see any Grid Status announcement or forum thread on this problem. It appears to be impacting pretty much every vendor and operation of products and services that use web API's all over the grid (I haven't found anything using web API's working this morning.) As we don't know when LL will acknowledge given the weekend, I would encourage people to refrain from rezzing nocopy items and making purchases until we get the all clear. Better safe than sorry.
  7. If asset load time hadn't CLEARLY increased dramatically, Everywhere, including my own non-changing skybox, I could go with that explanation, but the issues are beyond that. Asset load times have always been an issue, but what we are taking about (mostly) is that it's worse now than it used to be when everything else is the same. If it was simply efficiencies in the server / viewer as you described, I would expect behavior to be different. Cached textures, once the UUID's are identified, should be immediately loaded from cache. They are not - they start gray, then slowly load and clarify as the textures are progressively loaded from low-rez to the final high-rez version. If the cache is being used properly, you would see the cache textures instantly load rather than progressively. Again, in my zooming example, the viewer shouldn't be dumping all that scene data prematurely (which I believe is called the Interest List) which forces it to be reloaded. Fix that and everything else gets better. Whatever the root cause of the recent slowness, it needs to be addressed. Then start working on resolving inefficiencies in the server / viewer that are long-time problems. In SL, it seems like age-old issues are swept under the carpet never to be addressed while working on the next whiz-bang feature. I would really like to see new feature rollout paused while important basic issues - some that span over 14 years - are fixed. Bottom line, I'm not saying you are wrong, clearly there are issues as assets have Always loaded slower than they should, but I do think the increase in load times is something else. Edit: Considering how much higher performing modern systems are, with super fast video cards, NVMe drives, modern CPU's, etc. than they used to be along with the viewer updating to 64bit, the increase in scene complexities is mostly compensated for on the client side with the exception of the viewer code itself which is still largely stuck in 2009 outside of cosmetic UI changes and additions for new features. It's time for the entire cache system to get a makeover. Checking for cached data and loading cached data should be a near instantaneous action on modern systems. I should not be waiting over a minute to load my 200 prim skybox in a nearly empty region and low draw distance.
  8. Assets are still loading very slowly. The issue has nothing to do with bandwidth, it's still slow on 1G symmetric fiber. Playing around with the bandwidth slider in the viewer including dropping it quite low is not effective (it's one of the support hints.) The annoying part is that the viewer cache system is just FUBARed completely, Zoom far away, let it load, hit Esc to reset view to close, wait wait wait while everything that had been rezzed (including your own avi) is now gray again and has to load all over as if you just TPed into the region. Even ancient old system library textures are affected. Time to dust off that old Squid caching proxy to do what the viewer cache should be doing... LL: You know, if you fix the viewer cache, that will drop your content delivery service costs to a fraction of current as right now, everyone is re-loading the same textures over and over and over and over and over.......
  9. 99.999% of all group chat: Person1: hi Person2: hello Person3: Hey Person4: tp me
  10. I wish I had an answer, I reported this bug YEARS ago, but it's not something that's easy to re-create. I've tried and have not been able to recreate it either. The absolute biggest problem is that these creators make all this stuff no-mod for no good reason basically screwing over their users - no-mod means no resetting scripts, not being able to set scripts running when they all go non-responsive... The ONLY option is to replace the broken items either unpacking your purchase again, getting a re-delivery, contacting the creator for replacement if no-copy. For copy items, after you unpack the originals, make a working copy that you use to leave the original pristine and working. Lastly, this is a server side problem - nothing you do as a user will have any impact on this bug. It has nothing to do with your viewer or your computer.
  11. So far, Teleports are not faster or more reliable going between uplifted (AWS) regions. It actually seems to be worse right now. Hopefully they will sort that out along with pretty horrible performance from the content servers delivering assets / textures. Akamai is great for web content delivery, but it seems to be not so great dealing with game assets. It doesn't help that the viewer's caching is just completely broken, where zooming far away, letting that load, and then resetting the camera to close and finding everything gray again having to wait for the textures to get reloaded.... That's just inexcusable when you have a large cache on a high-end NVMe drive. As I mentioned in other threads, I had high hopes too that moving from the OLD datacenter servers to the modern AWS would result in much less server side lag caused by lots of avatars in the region and significant scripts, but I'm not seeing any performance benefit at any level. It's as if they brought everything over using 2007-era computing resources ignoring Moore's law. With the size of the deployment, LL isn't paying retail prices here, but when I look at how much I pay for regions and what I can get for a VM at a hosting company like Digital Ocean (which has a simple pricing scheme unlike AWS) it leaves me scratching my head and frustrated that the performance is still just as crappy in this new supposedly "high end" environment. Continuing performance problems is that elephant in the room that LL doesn't appear to want to acknowledge.
  12. Well, apparently today TP's are failing much MUCH more often. In fact, it's about a 10% success rate for me. If that. To or from a busy sim fails 100% of the time. To or from completely empty sims such as Linden ocean fails 50% of the time. LL: It's time to stop blaming the user and fix your broken code.
  13. Based on what I am seeing with regions that have been uplifted, there is no measurable performance benefit for sims with lots of avatar activity / scripts. I had high hopes that going to a modern infrastructure would result in better performance (much like you would expect going from an old i5 CPU laptop with integrated graphics to a modern i7 desktop with a nvidia 2080TI.) Maybe the networking will be better allowing TPs to fail less often once the uplifting is complete, but if region performance is a significant factor in TP reliability it's not looking good.
  14. I had high hopes for at least some of the region performance issues to be addressed by uplifting regions to Amazon's servers and away from the old legacy servers. Unfortunately there appears to be absolutely NO difference at all from what I can see. With Moore's law, how can you possibly move to this new environment and not see an improvement? So in the grand scheme of things, where is resolving region performance issues? Are we doing the Ostrich move here and pretending it's not a problem that a social platform doesn't actually handle people having social events? We can't get more than about 20 people together in one region without serious issues and group chat is pretty much borked all the time now with everyone that uses group chat essentially being forced to move to Discord in order to actually have conversations. Does LL actually have a plan to address the elephant in the room? I recall one of the more active forum members had performed testing that showed even idle scripts were taking an unreasonably large amount of CPU - did that fell on deaf ears or.....? Handling scripts efficiently is critical - the current state prevents us from being able to develop interesting experiences that can bring more people to SL and keep the people here coming back.
  15. How long you wait for that progress bar is a huge factor here. I only wait for about 25% before hitting cancel. If it's not CLEARLY working within about 5 seconds I hit cancel and try the empty sim.
×
×
  • Create New...