Jump to content

Whirly Fizzle

Advisor
  • Posts

    4,719
  • Joined

  • Last visited

Posts posted by Whirly Fizzle


  1. Kurenai Ishnoo wrote:

     

    Ever since I put on another outfit without changing any
    thing, my client was getting bugged. I would see my eyes trough my cheeks (I use a mesh avi) while others saw me fine. Relogging didn't help.


    Did you change your outfit using the latest release of the Linden Lab viewer?

    There is a nasty bug on that viewer which will distort your avatar when you add or remove any rigged mesh with joint offsets. If this happens, a relog will fix it - see BUG-6197 and BUG-6439

    If this happened when changing outfit on Firestorm, then it isnt the above bug, Firestorm didnt pick this bug up yet.

    Regarding the wonky right click behaviour - are you playing in full screen mode? On Firestorm there is  aknown peoblem on Mac when in fullscreen when using the pie menu and right clicking. You can either disable fullscreen mode or switch to using the context menu.

    Your right click symptoms and the mouselook symptoms could also be caused by having a non default DPI set for your monitor. Are you using a Retina monitor?

    Regarding the crashing - are you crashing whenever basic shaders are enabled in graphics preferences?

    Best thing to do for the crash is to file a JIRA issue and give your crash logs.

    Linden Lab JIRA: How to report a bug - Second Life

    Firestorm JIRA: file_a_jira [Phoenix Firestorm Project - Wiki]

    Can you paste all your system information from Help -> About Secondlife or Help -> About Firestorm.


  2. 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

     

  3. 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.


  4. 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:

  5. 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.

  6. 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

  7. 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

     

     

  8. 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

     

     

     

  9. 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.

  10. 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>);        }    }}

     

  11. 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.

  12. 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?

     

  13. 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:

    Pf1oEC0.png

     

    Observed: Avatar B will not see the rings on Avatar A's chest because they are inside the avatar body.

     

    XNNTKi4.png

×
×
  • Create New...