NiranV Dean

I have seen people getting blocked on other Viewers (no names) and i have done the same in a single extreme case myself. I'm not sure how accepted it is by Linden Labs but i don't like the idea of excluding people from using a product they might want to use unless i absolutely deem it necessary and outright blocking people from accessing my Viewer for a bit of drama (or some complains) is quite an overkill which I'm sure would quickly find its way into the internet and just prove rumors I've seen going around of me apparently banning anyone who dares talking bad about me or my Viewer and i'd like to keep these rumors be just that, rumors. No, it is correct. You probably read the part for pre-Viewer 2.0.

Well that's what I'm saying, people are going out of their ways to cause problems, they are willingly doing so, this is malicious intend. Also i think you mean people are not enabling it and then complaining about it, because that's not the issue. The issue is people getting IMed because they have been camming around, they get directly attacked for doing what is completely normal in SL. The guide has been posted a couple posts back: http://wiki.secondlife.com/wiki/Show_Look_At Okay, explanation since you don't know what's happening here or what i'm actually complaining about, maybe others didn't understand this either: Lookat itself can be abused to see who is looking at what (or more specifically who), although it is hard at times because it does not show names, so you'd have to do some piecing together yourself. Firestorm (and a couple other Viewers) offer showing names on said lookat beacons, which makes it incredibly easy to see who is looking at who, this has caused lots of people mostly willingly, IM the person who is looking at them, often with malicious intend. They start insulting, attacking, harassing people for what is... well normal in SL, looking around. Personally i'd say man the f*** up and ignore it or give em hell but not everyone can or wants to do this. I'm notorious for going into public places where users have reported to be harassed by such people and camming on them, trying to get a reaction (so far unsuccessful every time) to show them what happens if they do this to someone who doesn't take up with your stupid *****. I'm a firm believer that these people need a good old slap in their face. I sadly can't however expect everyone to stand their ground and/or ignore it. That's why i've been trying in the past to request the removal of lookat names to put a stop to easy harassment. Today i'm offering a better solution than outright removal.

Is this sarcasm? The past has clearly proven that this hasn't worked out, especially not when its sharing its "Advanced" menu with many other often used options and when the menu is one of the very first things most people will immediately enable when starting to use a new viewer (or reconfiguring the same). Also the feature IS off by default in any Viewer. Also me doing this, especially alone doesn't solve the issue at hand, i'd just be locking out the maybe handful of people on my Viewer trying to abuse it (and i'm sure they are having a hard time without lookat names), i'd be cutting down a bush in a jungle. But thanks for your constructive criticism though. No seriously what is it with you guys hating on me so much? What have i done to you? I see a topic, i post my opinion and reasoning and go the lengths of offering a solution that includes as much of the good parts as possible while preventing as much of the bad as possible without straight up removing the feature (which in the past was my go-to request for lookat names). I'm the good guy trying to do good things but you just start attacking and insulting me and my Viewer for no reason, you are shooting your own foot here.

Step on the hatebrakes there. I don't treat people like they are too stupid to deal with, I wouldn't be offering personal help so freely if I did, neither would i be giving out said guide to do it themselves, let alone talk to them. I'm trying to find a compromise (despite hating compromises) that makes everyone happy, I'm trying to include what Firestorm told me (despite believing its utter bs) that they think its a tool to make sure people are looking at the right thing when they do their Firestorm Viewer lessons, I'm trying to let them continue using the ability to see beacons (and their names), thus retaining the usefulness of both features, while keeping it out of malicious hands. I'm not only concerned about those and you are right, they will find other things to whine about, as they always do but again that's no reason to simply ignore an issue that has been here for many years. While the way they may complain and the reasoning the have may not be good, the underlying message, that this feature (in combination with names) is causing unnecessary drama which could easily be shut down before it even begins is still there.

Well yes, i keep telling my users to ignore being watched too. Personally i do not care being watched. It should still not be full on supported, with how extremely restrictive LL is with abusive behavior of features i feel like this particular instance has always been glanced over at best.

A: Don't apply what they thought or did 2003, we are in 2022. Not everything they did back then had a reason or was good to begin with. A lot of things are kept simply because they can't be assed to change them. B: I link users to this article every single time because it is the only workaround available but not everyone can do the edits and doing so destroys lookat, which impacts your avatar head and eyetracking which i'm sure have been implemented for a reason in 2003. No it doesn't change the fact that it is a valid complain that has been amplified by a third party viewer implemented feature and could easily be solved.

So you are saying i should just continue ignoring the complains of my users and users that won't use my Viewer because they feel unsafe using it due to a missing "hide lookat" feature that is a poor excuse to solve a self-inflicted issue?

A tiny number? You have no idea how many complains i get, on average one every day. Thats just roughly 3000 over the past 10 years i've been making BD. Pretty sure a lot of other people have been complaining everywhere too. And how does this not warranty this system to be implemented? This debug feature is supposed to be used for debugging, average users have no use for this feature instead its being abused to stir up drama left and right. Keep it locked behind checks and everyone who truly needs it will continue to be able to use it while everyone else who doesn't won't.

Coming back to the topic. I don't think normal users should be allowed to see lookat/pointat beacons. They should be locked behind godmode, something that any developer can easily circumvent but the average user can't. This would limit the potential drama to only those capable of getting past the godmode check, which only Lindens, developers or self compilers can do. I'd go as far as hardcoding the UUID's into this so only select people can use it (gods and devs only). Obviously that would only work if everyone does.

Impossible. Everyone knows i'm the only one who hates wearing pants.

A check that goes through all objects on the SIM and checks whether they are there would A not help, B that's basically the cache (which we see not working in this case) and C would unnecessarily add more work ontop of what the Viewer already does, further impacting performance in one of the slowest parts of the Viewer. Objects that vanish in this manner cannot be right clicked, they are completely gone and do not exist to the Viewer, thus the Viewer cannot search for them and find them. If the Viewer is never told that there is an object there then said potential object is never being tracked. You can't request said specific object either because you'd first have to know it exists, the only solution is a full on interest list request which would give you everything on the region again, essentially what you do when teleporting away and back.

Taking snapshots in SL has always been a bit weird due to how the shaders work that produce these effects. Almost all shaders do not scale their properties with screen resolution, the properties (settings) are all fixed and set by you the user, this means that you are taking a snapshot with a 8K resolution with settings meant for 1080p. If you are taking a snapshot at any resolution different from that of your window you will have to use the preview (Black Dragon has a big preview button that pops out the preview and allows you to scale it bigger) to see how the final image looks like. Your picture shows that the preview already shows that Depth of Field will be weaker, that is because the preview shows you how the actual final image will look like (in Black Dragon at least). The explanation for this weird shader behavior is quite simple, think of this example: You draw a circle, the circle according to your settings should have a 100x100 pixel size. Regardless of your chosen resolution, said circle will always be 100x100 pixel, 100 pixel on a 1000 pixel image is 10% thus quite huge. 100 pixel on a 10000 pixel image is just 1% thus 10 times smaller. This means you will have to pre-emptively compensate for the resolution you are going for, a rule of thumb is usually multiplying certain settings by the amount of times your chosen resolution is bigger. 2000x1000 to 4000x2000 = ~2x and so on. Black Dragon also offers an Autoscale Rendering option which does exactly that to help with this, it is by far not perfect and is only meant as a quick and dirty help in case you can't be bothered to due it manually (or don't know how).

I'm getting a constant amount of reports every day (including today) this issue certainly is not hiding. I do not know the exact reproduction steps (if there are any) i just know that after switching Viewers it happens. I did switch to Alchemy and the LL Viewer, but only on my alt account (because i was using my main to talk to an user who needed help). I have not yet tested switching with my main both in cached and uncached regions. But whatever it is i doubt that even reproducing would help fixing it since it's not a Viewer side issue.

That would be a far spread general internet issue then. Why would it happen to basically everyone... that sounds like a failure of cataclysmic proportions

I wouldn't rule out cache corruptions just because you use different caches for different viewers, thats the default so thats a given. In fact this all the more screams cache corruption, the malformed interest list is being written into cache, writing possibly bogus or missing data which results in the same cached (vanishing objects) visuals over and over with 100% reproducibility. But i assume the actual bogus data comes from the AWS service which was taken partly down for a bit a while ago, they might broke something really hard there.

Very well known issue currently. Been getting daily reports of this. It seems to be triggered by relogging from one Viewer to another (whichever comes last seems to permanently corrupt the cache for some reason). I can only assume this is due to the Viewer requesting a new list of objects when switching Viewers as opposed to just updating what is already cached, for some reason this new list is corrupted (or gets corrupted somewhere between the server and until everything is writting into the cache). Hence why it doesn't happen to the first Viewer as this one was most likely the one to TP in whereas the other one is just requesting what is there. Couple this with a quick relog (from one Viewer to another) this might be causing faulty messages or a faulty login, SL in general has a lot of issues with doing quick relogs (doing too many too fast can result in your login session completely breaking, to the point you get disconnected shortly after again).

And who's going to take all these little images of a million of objects? Not to mention the texture memory usage again... oof.

absolutely not left, that is a massive amount of wasted space, not to mention the viewer cant preview items as it doesnt know what they look like until rezzed, not to mention the abyssmal performance of one of the already slowest windows when having to render a bunch of objects with hundreds and thousands of polygons again

Are you sure you want a grid inventory with 40k-100k items and thousands of subfolders in your main folder? This would so quickly get out of hand...

Well BD had it as button too but i got rid of it due to the styling change that didn't have any more space for it. It's now in a menu again (which technically allows it to have a shortcut) but unlike LL Viewer its in a known menu style that we see being used in the main UI. I still don't see much reason for it being a button. Both are one click (did you know you can click and hold the menu and let go while Close All Folders is selected?), its also at the very top too so the first thing being selected. If people don't really check the menus or buttons (especially if there aren't many) then i don't know.

The UI only has so much space, cramming more options into an already overly crammed window like the tools floater for instance doesn't seem like a good idea. That's why they started using these gear menu buttons. The tools floater hasn't been touched since forever and neither of the Viewers because there is hardly much to change about it and all Viewers do have these options in the Tools/Build menu. The inventory however still has some space for some commonly used buttons at the bottom, although i wouldn't count collapse all folders as a commonly used function, common would be creating a new item.

Fix your Second Life in 3 easy steps. 1. 2. 3. Clearly you didn't look hard enough (or at all). 1 has been an option since CHUI was implemented many years ago, 3 was always an option ever since there was building and 2 has been added quite a while ago too. None of these options are hard to find, 1 and 2 are directly inside the very window you are looking to change, 3 is in the usual build menu that everyone loves so much.

i've recently had a lot of these reports from my users, roughly a week or two it started cropping up. A lot of people report certain animeshes (specifically pets) and pose stands to vanish, sometimes entire places. Despite all kinds of things we tried and even using their settings i could not reproduce the issue nor diagnose whats happening. Idk why its happening all of the sudden but all of these cases seem to be about the sane type of objects and most of them have in common that they swapped from Firestorm to my Viewer beforehand. Idk what to think of this nor what to make of this but i know SL had a lot if issues recently and there was also the Amazon server outages. I'll keep investigating and the only thing i can still think of is straight up cache corruption, but cache clear did not help either...

I don't see ARC as a meaning to tell what your current lag cause is but rather a global guide to what is bad rendering wise, how much hardware has an impact on this "theoretical" impact can be somewhat easily estimated depending on our hardware. LL's biggest mistake with ARC was to try and test it against a wide variety of hardware when hardware really does not matter, these tests simply pollute the actual baseline information that we need. Complexity should be based on a generic complexity score that certain features have according to what they do and how much time they actually eat in a vacuum. For instance, it is no secret that alpha blended surfaces are one of the single worst offenders when it comes to core rendering parts, more so in SL, according to that alpha can be punished. We know projectors will quickly absolutely destroy your performance even without shadows (due to the way they work in rendering), simple conclusion is we punish using them. It is only really a question of how much feature A should be punished compared to B. I think i have ARC in a decent place where i can say that its generally a good guideline on what to avoid and so far it did a good job at doing what LL failed at doing with their ARC which only begs the question now how close are my estimates to actual timed rendering, is that avatar that has slightly more ARC really slower to render than the other one? Is that avatar with half as much ARC roughly half as much of a time waste in rendering? That's what's important to me.

I'd be very interested to see how these ART numbers compare against my own performance breakdown floater values, particularly how accurate the overall ARC is i'm dishing out at what i consider bad avatars and how much ART and ARC match. Will this floater become an official implementation or is it going to be a Firestorm-only thing? Also is it using the third party telemetry/performance libs or is it taking these with the internal implementation we had for years?