Whirly Fizzle

I just had a dig through Firestorm support tickets & we had one filed on Jan 2nd this year from a user who had MSI true color installed & was seeing this problem. He didn't reply to my last questions though so not sure if he resolved his issue. The support ticket isn't public but here's a screenshot with names removed: https://gyazo.com/1cab4d988a49b7eb0f0c679bae1ba08a

I haven't seen anyone having this problem with MSI True Color before but your symptoms sound exactly the same as what happens when f.lux is running on the system - on exit of any SL viewer, the graphics driver crashes & you will get a corrupted display until computer reboot. JIRA issues for f.lux: Firestorm: FIRE-12561 - f.lux custom color profile will cause video driver to fail upon exit of firestorm LL Viewer: BUG-4782 - Crazy colors upon closing

Pamela Galli wrote: I would really love to know why these windows are affected and other alpha masked window textures and plants are not. Oh, I'm fairly sure that *any* alpha masked texture would be affected by the bug, as long as it's modify to at least the object owner. Are your windows mod to your customers?

I filed a new bug report for this at BUG-11333 - Alpha masked textures occasionally changing to alpha mode none without any interaction

Pamela, I have some "good" news. I reproduced your bug with the windows - only took 7 weeks lol. I have NO clue yet what caused it to happen but it happened right infront of my eyes. I was logged in on default LL release, Second Life 4.0.1 (310054) Jan 14 2016 18:17:17 (Second Life Release) & alone on the region. One minute the windows were all alpha masked as expected. I was camming around the region & suddenly I noticed all the windows were black. I verified my alt on Firestorm also saw them as black and when edited, the textures were all set to alpha mode none. Every single one of the windows had changed to alpha none.  Now to see if I can get it to happen again...

Qie Niangao wrote: Indeed, it's not working correctly at all -- the jellybabies appear and disappear seemingly at random, very often affecting avatars with complexities much lower than the selected threshold -- sometimes briefly, and often until the feature is overridden completely for that avatar (which, too, is temporary, the wording of the option notwithstanding). It's so very far from ready that I haven't bothered even trying to find a reportable pattern in its utter bugginess. The only reportable pattern I could find was the repro I filed in BUG-9962 , but that definitely doesn't cover all the cases of random frequent jelly or invisible avatars who should not be jelly or invisible. Blowed if I can find how to consistently reproduce it though, other then just using the viewer and you will see it happen easily. That does not make for an actionable bug report though. Qie Niangao wrote: Is there some chance this mess could go to production as-is? I asked about this at the Friday TPV meeting. Voice was broken for most of the meeting so the reply was in text. From the meeting transcript: [2016/01/29 12:33] Whirly Fizzle: Will the problem with QuickGraphics displaying jellies when you have max complexity set to no limit be fixd before it's released? [2016/01/29 12:34] Oz Linden: We're thinking about that, Whirly... [2016/01/29 12:34] Whirly Fizzle: Ok. I consider that to be a huge problem lol [2016/01/29 12:35] Oz Linden: The problem with those cases is that there are 2 more factors that go into making the avatar a colored impostor, and they're not obvious enough. [2016/01/29 12:35] Whirly Fizzle: Support will suffer [2016/01/29 12:35] Oz Linden: We will probably change the thresholds on those, and maybe make the response to them different somehow [2016/01/29 12:35] Whirly Fizzle: There has to be some way of disabling jellies totally for those who do not want to see them. [2016/01/29 12:35] Hope Dreier: Support always suffers. [2016/01/29 12:35] Oz Linden: Maybe [2016/01/29 12:35] Oz Linden: still tbd [2016/01/29 12:36] Oz Linden: but we won't make it the default viewer until we've done _something_ about that so that it happens much less often [2016/01/29 12:36] Whirly Fizzle: Ok cool [2016/01/29 12:37] katydid62 Resident: jelly babies would kind of ruin an overall "experience" if they showed up unwanted. [2016/01/29 12:37] Whirly Fizzle: It does. [2016/01/29 12:37] Cinder Roxley: babies ruin everything when they're unwanted, whirly. Video recording of the meeting:

Prokofy Neva wrote: This thing is back again in the viewer, and hugely annoying. I'm not someone who has a lot of bling and glam on, it changes constantly depending on whether or not I've attached something to myself, often something I'm testing like a tea cup, and I don't want this Too Much Information all the time in my face. I can't seem to find the place on the menu to turn it off -- if it exists. If you mean the visual complexity notifications as shown on this JIRA issue , as far as I can tell there is no way to turn these off. I agree they can be a bit spammy sometimes when you are trying lots of different outfits & attachments. It's worth filing a JIRA issue requesting a way to disable the visual complexity feedback. Prokofy Neva wrote: What's happening is that if someone has too much of this stuff, they are rendered as clay figures, colored grey or green. This is annoying too because usually I see them for a minute, then I don't, then they're back again. A busy sim like an event will be filled with these clay people. There is a bug in the Quick Graphics viewer that causes this to happen more then it should. The problem is that an avatars complexity will change depending on how far your camera is away from it. So in a busy scene where avatars are moving around a lot, they will often flicker very quickly between a normal state and the jelly baby state & it can be quite visually jarring. There is also no way to totally disable seeing jelly baby avatars currently. Even if you have Avatar Comlexity set to No Limit, you will still see jelly baby avatars. I filed a bug report for this problem at BUG-9962 - [Project QuickGraphics] Avatars often permanantly stuck as jellybabies even when Max complexity = No Limit I really hope LL fix this problem before Quick Graphics goes into release. I suspect there will be lots of complaints about it & personally I find it very annoying.

If you edit the listings on the Marketplace website and add a name to that blank name listings, you should then be able to delete them.

http://wiki.secondlife.com/wiki/Viewer_URI_Name_Space tells you how to do this. Example: secondlife:///app/agent/2e255955-e183-48c4-b9f9-1cd1b80db94e/pay When the above is posted into chat and the link clicked on, it will open up the pay resident floater for Whirly Fizzle.  You can customize the text of the link like this: [secondlife:///app/agent/2e255955-e183-48c4-b9f9-1cd1b80db94e/pay Text Goes Here] As the previous posters said though, I'd avoid using and clicking on those kinds of links, they are often used by scammers.

" Trixxie Nitely wrote:... the exact wording for error is # textures discarded due to insufficent memory 1 (number changed depending on how many it discards) You will see that message on Firestorm viewer shortly before an out of memory crash. You must be using the 32bit version of Firestorm if you are crashing from out of memory. It is unfortunately very easy to blow memory & crash on any 32bit viewer in busy places, especially if you are camming around a lot. If you switch over to using a 64bit viewer, you should never suffer from an out of memory crash again. This will not help you for the LL viewer because there is no 64bit viewer version yet (though LL are working on getting a 64bit viewer out) but Firestorm has a 64bit Mac viewer. Choose the "For SL & Opensim 64bit" at http://www.firestormviewer.org/mac/

Hmmm... you don't both happen to be using Webroot antivirus software do you? There have been a spate of reports over the last few days of corrupted mesh and texture loading and the one thing so far everyone has had in common is they are using Webroot antivirus software and the problem started after a recent Webroot definitions update. The viewer logs we have seen from those suffering from this problem on Firestorm show the usual nasty symptoms when firewall/antivirus software is not compatible with Pipelining in the viewer. Disabling Pipelining or disabling Webroot will fix this problem. It would be great if you could file a JIRA issue and attach your viewer logs after running a session where you reproduce this problem. The viewer logs will easily show if it is the usual problem of Antivirus/Firewall + Pipelining incompatibility. Once that's established, it can be investigated what's causing the problem on your system. Instructions on how to file a Firestorm JIRA issue and where to find the viewer logs: http://wiki.phoenixviewer.com/file_a_jira On the LL viewer, go to Help -> Report a bug, to file a JIRA issue. Where to find logs on the LL viewer: http://community.secondlife.com/t5/English-Knowledge-Base/How-to-report-a-bug/ta-p/733545#Section_.3

The beta grid syncing is still broken. Currently LL support are handling the syncing manually on a case by case basis, so what you need to do each time you require a sync of password &/or inventory onto beta grid is to file a support ticket to request a sync - https://support.secondlife.com/create-case/

I strongly suspect this has nothing to do with your griefer. There is a bug on the latest version of the LL viewer and any TPV that has already released with the CEF feature that causes the web profiles in the viewer to prompt for a login and you will indeed see a lock icon on the profiles when this happens. For details see: BUG-10415 - [Valhalla] profiles and marketplace are asking for a login each session Within the viewer profile window, click the lock symbol & if you tick "Remember me on this computer" and login, then this should work around the bug unless you purge the CEF cache or switch to a different account.

Does this help? Text and User Interface too small after a recent Windows 10 update

That symptom is pretty much always a problem with the region & seems to happen to regions which have not been restarted for >2 weeks. Restarting the region will fix it. All regions should be rolling this week so it should be fixed by Wednesday afternoon at the latest. For details see BUG-7557 - Online Friends are not showing when login (Once again) If this is indeed the problem then anyone on any viewer logging into the affected region will see the same problem.

Coby Foden wrote: Whirly Fizzle wrote: There is a JIRA issue filed for the bug at BUG-4643 - Depth of field doesn't scale with resolution of snapshots "Permission violation" on that bug report page. Not available for everybody to view? Gah! Yes sorry, that issue was filed while the JIRA was mutilated by Rodvik grrrr. Here are 2 other public JIRA issues reporting the same bug: LL: VWR-26497 - Lose DOF when taking snapshot Firestorm: FIRE-13989 - [bUG-4643] [ MAINT-3549] Depth of field doesn't scale with resolution of snapshots.

Ahhh that's expected behaviour. DOF has never been active when freeze frame is enabled. It's the same behaviour as the LL viewer & always has been. I think the OP is probably having a different problem.

Are you saving your snapshots at a larger size then your window size? If so, the DOF effect on the saved snapshots will be less pronounced. The larger size you save your image, the less effect you will see from DOF. This isn't a new problem, it's been this way ever since DOF was added as a feature and the LL viewer also has this bug. There is a JIRA issue filed for the bug at BUG-4643 - Depth of field doesn't scale with resolution of snapshots

Possibly Kali?

Oz Linden wrote: We are trying to find and if possible fix any bugs related to the Bento features. If you can find a good quality report (meaning one with usable instructions to reproduce it), please add a pointer here; if not, please try to create one. There is also the long standing SH-2550 - First frame of uploaded animations is triplicated which Medhue has already brought up in this thread.

Oz Linden wrote: Gael Streeter wrote: This is a very very old known bug : When importing a BVH animation into SL, the SL viewer performs an "optimization" of the animation (to reduce its load). But this "optimization" algorythm has bugs and induces very big problems of "phantom moves" (I call it like that) when the animation has very small moves between keyframes : the fine moves are replaced by big and long incoherent moves. We are trying to find and if possible fix any bugs related to the Bento features. If you can find a good quality report (meaning one with usable instructions to reproduce it), please add a pointer here; if not, please try to create one. Extra points for including an animation file that demonstrates the problem. It may also be that we should implement checks in the viewer to alert the author that an animation does not use an appropriate frame rate, but let's see some actual examples before we draw any conclusions. I believe this bug is caused by the same optimization issue - it has a repro bvh and a video showing the problem BUG-5146 - Animation skipping frames 5146 is probably the same bug as VWR-2461 - Preserve subtle movements when uploading animations

Naiman Broome wrote: no because are still showed ... apart that I noticed the problem to disappear if I uncheck the object object occlusion in developers rendering menu , but I have to relog then ... What can t be ? Looks like a bug to me . Yep, it's a bug & you already nailed the cause. See BUG-5144 - Underwater objects are invisible at certain camera angles unless object-object occlusion is disabled.

Can you post an image of it here?

Hmm do you maybe have "Always Run" enabled? BUG-10467 - If "Always Run" is enabled, camming is broken when sitting down.

See BUG-11128 - Sim Traffic counter has not changed in 5 days