Aishagain

This is yet another of these "now you see it, now you don't" bugs that have plagued SL for years. It seems to be having a bit of a resurgence of late and I suspect that no-one at LL (or anyone else really) has much of a clue as to how it could be fixed. That it may or may not disappear if the region on which the observe experiences this is restarted is mere happenstance. It's a legacy of the arcane and archaic archetecture of SecondLife.

So reading the above posts we have the situation of incomplete information being delivered too late. There is a term for this performance, it is NOT pretty, it is SNAFU.

From reading around this issue a bit it seems pretty conclusive from the fact that a "fresh" copy of the file shows the expected alpha activity. This bug that periodically sets texture alpha to "none" is a server side effect, not a rendering glitch in viewers. Like many non-reproducible bugs this harks back to issues that bubble up to the surface of region code at restarts and that are most likely on the "search me" list at LL. As Henri suggests on modifiable items changing the alpha value in edit might get you back to something resembling the original. On a no-mod item, one just has to rez a "new" one. If the item is no mod AND no copy....tough.

Feature request JIRA time then, Qie?

Looks like they noticed at last: https://status.secondlifegrid.net/incidents/cnyfnjh8gf71

Then your course of action is clear. For an account-specific issue like this you need to contact LL support, either by live chat if you are Premium or by ticket otherwise and use the "account problem" route. https://lindenlab.freshdesk.com/support/home

and I reiterate: by operating this you are forcing participants to use RLV (I assume this would also work using RLVa code). While participations is not forced the use of RLV is. I may be reading the ToS wrong but to me that is a Prima Facie breach of ToS. I hope I am wrong 'cos I'd hate to be a tinfoil-hatter and a spoilsport!

I think you really need to be aware that such a function, even if it WERE possible, would be very serious security risk and as such it is a Prima Facie ToS breach. It is also rather foolish. Yes, the intent is a bit of fun. Unfortunately the consequences might not be.

@Frionil Fang see https://jira.firestormviewer.org/browse/FIRE-31862. D'oh! You created it!! sorry *exits stage left muttering* Now that one is closed and a higher priority one is carrying the issue: https://jira.firestormviewer.org/browse/FIRE-31551

@Chic Aeon: like as not it isn't a bug but one or two oddities are turning up in 6.5.6, so I'd file a report on the FS JIRA, maybe not as a BUG but as a support request, someone's bound to help you sort this out.

Thanks Niran, I should know you wouldn't build a potato, looks very good, loverdag.

Umm...are you allowed to say such things in a forum rated "general"? Or is this predictive text striking again? 😁

I'm bound to say that given your comprehensive explanation of your viewer's operation, Niran, you have achieved something wholly undesirable for many. There is a point when you achieve "too much" and we reach a stage when "more is less". At this point is BD then a Viewer purely for photos excluding avatars unless they are bald?

*sigh* not THAT soon then. I confess to being rather disappointed that FS 6.5.6 did not incorporate the rendering improvements currently in the default LL viewer and no doubt some of the other TPVs. As I said, the gears of FS grind a little slower these days and despite their putting a brave face on things, it is becoming obvious that they are a bit underpowered in the developer area.

So...is Main Server being just bounced again or is 573176 to be promoted this week? Just thought I'd ask before I went to bed.

Is this another Caspervend issue or more extensive, I wonder?

My error, then, Henri. I assume the latest update to FS is therefore "in the works" and will be in our grubby hands as soon as it passes though the FS QA process. I am not privy to the ins and outs of viewer development, and my words were simply my way of suggesting that it "will be ready soon", now that it is out as a full release viewer. The gears of FS development grind a little slower than yours! 🙂

My guess is "soon" once LL release the relevant code to the TPVs. @Beq Janus?

I believe that the rendering hit that Linden water causes on viewers is one of the issues that is addressed by the recent performance enhanced default RC viewer ( don't quote me on this) because the Lindens are very much aware that anything other than opaque water settings halves (or worse) FPS on most, if not all viewers, irrespective of your GPU/CPU setup.

I guess I should assume that Main Server will get 573176 tomorrow and maybe the release notes for it will be revealed as well?

Also, though it is hardly unusual, the Scheduled Maintenance appears to have started 15 minutes early since several avatars that were rezzed happily 30 mins ago are now clouds after a TP. I assume that some regions were missed out on Wednesday's scheduled restarts, possibly if what LoganPryor said (above) was a general situation. Sometimes Linden Lab's internal communications seem more like Chinese Whispers than well coordinated functions.

@Beq Janus? FWIW my favourites are still accessible at login.

Give them a break! It takes a while to check on who should have fed the hamster, and why they didn't!

I was just scrolling back through some of the cooments and I saw this ^. What does this mean and is my FS logging in causing some region stress? I've never noticed it happening for me or my partner who uses the same (more or less) setup.

Wow "Grid Emergency". I've had several different login failure messages over the years but never THAT one! What CAN it mean?