Whirly Fizzle

This isn't something Ive ever tried changing for a custom mouse button, but all the keybindings for the viewer are set in the viewer install folder.... \app_settings\keys.xml

Qie Niangao wrote: I'd given up on experience permissions so many times already that I'm still hoping they'll make an appearance in SL Classic before they turn pull the plug on this place. Experience tools are about to be released! LL stated at the TPV meeting that the beta was coming very soon and there were two of the experience tools Lindens there to answer questions. You can see the whole discussion about experience tools here - exp tools discussion starts at 7.10

There is a known problem on Mac which causes slplugins not to terminate when you logout. Often there will be stray slplugins left in a "not responding" state. If you relog without killing these old slplugins, it could cause your symptoms. So logout of the viewer, force kill all slplugins that are still showing in your activity monitor (or reboot the Mac) and see if this helps at all. JIRA issues reporting this problem: VWR-18250 - SLPlugin keeps running after closing the client BUG-3441 - SL plugin does not terminate properly and hogs CPU resources FIRE-8806 - SLPlugin does not terminate after quitting FS normally If this doesnt help then I suspect for some reason slplugin is crashing for some reason while the viewer is running. You should also make sure that slplugin is whitelisted in your Firewall and antivirus software.

Theresa, there haven't been any recent changes to the avatar baking backend. I would recommend filing a Jira about this baking issue, with attached viewer logs from a session where baking fails. Possibly related (?) issue at BUG-6269 where several users report map tiles suddenly failing to load. The secondlife.log attached to that issue shows some really weird network flakiness including... 2014-05-20T19:45:45Z INFO: LLCurl::completedRaw: Failed to deserialize LLSD. https://sim10335.agni.lindenlab.com:12043/cap/043e06a0-92ba-ee5e-6fe1-0de337f1b8ed [503]: Failed to request agent parameters 2014-05-20T19:45:45Z WARNING: errorWithContent: appearance update request failed, status: 503 reason: Failed to request agent parameters code: 0 error: "" 2014-05-20T19:45:45Z WARNING: onFailure: giving up after too many retries EDIT: Nevermind - he attached a log file that was over 2 weeks old. :smileyindifferent:

The OP filed a JIRA issue here: BUG-6068 - Beta Grid no longer allows fitted mesh.

Appears to be a problem with new accounts currently: BUG-5986 -Viewing own profile within viewer & my.secondlife.com of a newly created account continuely recieves 500 html error code

Hum... you closed that JIRA issue yourself.

BUG-5563 has been "Accepted" (look at the status and resolution) which means the Lindens have verified it is a bug and imported it to their internal JIRA. The best place to ask about updates for this bug is the Server Beta Usergroup: https://wiki.secondlife.com/wiki/Server_Beta_User_Group You can even add it to the agenda. Next meeting is this Thursday, April 24, 3PM SLT at Morris on Aditi.

It was a "bug", nothing is wrong at your end - see FIRE-13445 The 64bit installer has been fixed and replaced. Please download a fresh copy.

Yeah, deleting the logs folder seems to put behaviour back to the (expected?) very quick flash of the crash reporter on launch or close. That is, until *something* happens to get the viewer logs folder into a bad state again. I found one way to consistently make this happen, I'm sure there are others.

Something else is going very wrong with the crash reporting on the Breakpad builds. I suspect some of you were actually reporting what I am now seeing. I am now having multiple crash reports being sent in at viewer launch, viewer close and even while logged in, even though the viewer does not crash. I filed a bug report at BUG-5707

This problem was discussed again today at the server beta user group. The Lindens are aware of the problem and can reproduce it. They are having problems finding what is actually going wrong with the sync script though. So we need to be patient and wait for a fix.

I just checked on my older desktop system too and on that system I see the crash logger briefly appear when closing the viewer, not when launching it - go figure :smileywink: Second Life 3.7.5 (288464) Mar 26 2014 06:41:28 (Last)Release NotesCPU: Intel® Core2 Quad CPU Q8300 @ 2.50GHz (2493.75 MHz)Memory: 3326 MBOS Version: Microsoft Windows Vista 32-bit Service Pack 2 (Build 6002)Graphics Card Vendor: NVIDIA CorporationGraphics Card: GeForce GT 230/PCIe/SSE2Windows Graphics Driver Version: 9.18.0013.3523OpenGL Version: 3.3.0libcurl Version: libcurl/7.24.0 OpenSSL/0.9.8q zlib/1.2.5J2C Decoder Version: KDU v7.0Audio Driver Version: FMOD Ex 4.44.31Qt Webkit Version: 4.7.1 (version number hard-coded)Voice Server Version: Not ConnectedBuilt with MSVC version 1600

I have the same on a any viewer with the google breakpad changes. I also thought this was an "expected" change with breakpad. I do not see the crash logger window when I close the viewer but I see it very briefly (for less then half a second) flash onscreen when I launch any breakpad build. When launching Second Life 3.7.5 (288464) Mar 26 2014 06:41:28 (Second Life Release) , SecondLifeViewer.exe *32 and win_crash_logger.exe *32 are launched Task manager -> processes. Pre-Breakpad builds do not launch win_crash_logger unless a c rash report is being sent in. Also on launch, a new folder is created in C:\Users\Whirly\AppData\Roaming\SecondLife\logs named dump-f3fe84aa-833e-49b3-5a59-b2ec81f32c61 containing a file named static_debug_info.log. After logout this dump-f3fe84aa-833e-49b3-5a59-b2ec81f32c61 folder is removed from the logs folder. A new dump-<different random letters and numbers> folder is created each launch. Is this expected or not Oz? Testing system: Second Life 3.7.5 (288464) Mar 26 2014 06:41:28 (Second Life Release)Release NotesCPU: Intel® Core i7-4770K CPU @ 3.50GHz (3491.96 MHz)Memory: 16268 MBOS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601)Graphics Card Vendor: NVIDIA CorporationGraphics Card: GeForce GTX 750/PCIe/SSE2Windows Graphics Driver Version: 9.18.0013.3750OpenGL Version: 4.4.0libcurl Version: libcurl/7.24.0 OpenSSL/0.9.8q zlib/1.2.5J2C Decoder Version: KDU v7.0Audio Driver Version: FMOD Ex 4.44.31Qt Webkit Version: 4.7.1 (version number hard-coded)Voice Server Version: Not ConnectedBuilt with MSVC version 1600

This problem still isn't fixed. I changed password again and (~30 hours later) logged into Aditi on the official viewer and my new password would not work for Aditi, I had to use my old password. Also my inventory had not been updated. https://jira.secondlife.com/browse/BUG-5563

Take a peek at BUG-5563 - My Password and Inventory don't update on Beta Grid (aditi). Simon did say at todays server beta usergroup that he thought Maestro had fixed this bug. I havnt tested again to see if it is fixed though.

I tested on Second Life 3.7.4 (288138) Mar 15 2014 16:28:23 (Second Life Release) with the Lost Mine HUD and it is working fine for me. I get the request from the HUD to allow teleport and once accepted, my teleports automatically happened. I made sure I had received offline inventory offers and tested again and this time the "allow teleport" popup did not appear on the screen but disappeared into the notification chiclet straight away. It was easy to miss it. After opening the past notifications and allowing teleport the HUD was working properly. If you think there is a different bug happening from BUG-5550 though, you should file a JIRA issue.

Looks like LL just dropped a fix for this: https://bitbucket.org/lindenlab/viewer-bear/commits/10f4f43e6e1e5ec8075d61d40e27c77a195357e1 MAINT-535 FIXED The teleport SLAPP is changed to UNTRUSTED_THROTTLE. Confirmation dialog for teleporting via slapp is added.

Oh another thought. Does the HUD print teleport links into chat of the form secondlife:///app/teleport/Promethium/71/6/22 ? These will not work anymore on the most recent official viewer release. See BUG-5536 - Issue with clicking SL teleport uri's being blocked

Hmmm. Which HUD are you using? This is the script I was testing with: key teleportee; default{ state_entry() { llSay(0, "Touch to teleport"); } touch_start(integer total_num) { teleportee = llDetectedKey(0); llRequestPermissions(teleportee, PERMISSION_TELEPORT); } run_time_permissions(integer perm) { if(PERMISSION_TELEPORT & perm) { llTeleportAgent(teleportee, "", <109.0, 98.0, 23.5>, <13.0, 12.0, 23.5>); } }}

I just tested on Second Life 3.7.4 (288138) Mar 15 2014 16:28:23 (Second Life Release) on Windows and it is working for me BUT if you had any offline inventory offers waiting when you logged in you will not see the popup asking for permission to teleport. The dialog will disappear straight into the notification chiclet. This is a known bug - see BUG-5550 - Instant message toasts and certain kinds of popups (ex. group invites) fail to display if an offline inventory offer was received before logging in.

I think your problem may be caused by this: MAINT-1841 Use NVAPI to force NVIDIA GPU power management mode to prefer max performance http://hg.secondlife.com/viewer-release/commits/6a2054a7cf5b83220f6f0342af51b3d0d0ae25cd After installing and running an SL viewer, this applies a setting to the nvidia control panel (NVCP) to set "power management mode" to prefer maximum performance...this setting locks the core clocks at max. The issue is that changes to the NVCP do not take effect till a system restart is done..this is somehow bugging out the driver or the control panel to think SL is running soon as computer restarts and the settings take effect. To fix: Open the NVCP after a restart. -> Manage 3d settings > Program Settings > Power management Mode > and select Adaptive. Does this help?

After testing this today, it appears its a viewer bug affecting everyone on a fitted mesh capable viewer. Male avatars on a fitted mesh viewer will see their own chest shape and chest region attachments correctly. Anyone on a fitted mesh viewer will see all male avatars (apart from themselves) with a "deformed" chest shape and any attachments covering the chest area in the wrong position. This affects standard prim attachments, sculpts, unrigged and rigged mesh. It does not matter what viewer the male avatar being observed is on. If the observers are on a fitted mesh viewer, they will see this bug. Simple Repro: Login Avatar A and Avatar B on Second Life 3.7.4 (288138) Mar 15 2014 16:28:23 (Second Life Release) - this is the current default official release. Change Avatar A into the default male from Develop -> Avatar -> Character Tests -> Test Male. Take off Avatar A's jacket. Avatar A rez a ring and resize it to approx <0.010,0.038, 0.038> and take 2 copies of ring into inventory. Attach both rings to chest attach point and edit into position so that one ring is around each nipple and flush to the avatar mesh like so: Observed: Avatar B will not see the rings on Avatar A's chest because they are inside the avatar body.

msvcr80.dll wasnt needed when testing this but lets see if just adding that one file works first.