Jump to content

Whirly Fizzle

Advisor
  • Posts

    4,719
  • Joined

  • Last visited

Posts posted by Whirly Fizzle

  1. I didn't answer because I'm not 100% sure how this special box was created.

    But this is what I think happened.

    There was a bug at the beginning of December (now fixed) that caused certain objects to not get autoreturned because they behaved as if they were selcted/sat upon when they wern't - this bug is discussed briefly here

    Any objects that were "infected" by this bug will now (since the fix) exhibit behaviour like Anne-Marie's special box, in that they will die after crossing a region if they have no sitter.

    If you want an accurate answer for why this box was "special", compell yourself over to the deploy thread and ask Maestro :smileyindifferent:

     

  2. Ramona,

    If you can file a JIRA issue on the Firestorm JIRA, reproduce this crash and attach your crash logs to the JIRA issue, we can quickly see if you are having the crash I think you are having.

    This Page tells you how to file a Firestorm JIRA and where to find your crash logs.

    After you have reproduced this edit crash, grab the whole logs folder and zip it up, before you relaunch the viewer.

  3. It sounds like you are suffering from this crash

    FIRE-10910 - [bUG-3095] [MAINT-2876] [CRASH] Right click rigged mesh -> freeze/crash - Octree insertion failed, starting over from root!

    This crash affects all viewers and only happens with certain rigged high poly meshes.  It also usually only happens when you are up at 2000+m strangely. If you click anywhere inside that meshes octree, the viewer will freeze in an infinate loop & you'll have to force quit.

    I'm afraid theres no known workaround apart from to find which piece of rigged mesh you are wearing is the culpret and take it off.

     

  4. The viewer crashing intsead of failing gracefully when attempting to upload a corrupted dae is a known bug,

    FIRE-12763 - [bUG-4961] [MAINT-3661] Crash to desktop while attempting to upload a corrupted mesh after selecting file from open window - load_face_from_dom_triangles

    BUG-4961 - Viewer crashes when attempting to upload a corrupted dae instead of failing gracefully.

    Hopefully BUG-4961 will be visible one the JIRA has reopened. The Firestorm issue is the same bug though.


  5. Cassandra Kestrel wrote:

     

    Edit:  Now she's doing something else weird... one of her stations is rezzing a huge cube (not phantom) in the middle of the road and then sliding it over.  Over and over again.

    Annemarie cube_001.jpg


    That box was part of a bug repro set up for the Lindens to see. You probably also saw boxes owned by myself there testing this bug :smileywink:

    This particular bug that was being tested is now fixed on Bluesteel and LeTigre - "Fixed a bug in which certain objects had incorrect status when crossing between regions"

    So, nothing sinister, just bug hunting.

  6. I don't know if this has changed since (I havnt tested for a while), but a short while before christmas there was a change made that meant that if one of your avatars was added to an estate ban list, then your alts would also not be able to access that estate.

    Your actual banned avatar who's name was on the estate ban list would receive the standard "You are banned from this region" message when trying to access regions on that estate, whereas your alts would receive a "You do not have access to this region" message (as far as I can remember - the message didnt explicitly say you were banned for the alts anyway).

    I stumbled on this one by accident because I had an alt banned from my estate for testing something, and suddenly some of my other alts couldnt gain access to my region.

     

     


  7. Trinity Nizna wrote:

    Firestorm hasnt released their updated veiwer for fitted mesh yet.... 
     The next release of Firestorm will be out 
    around
     March 9th – possibly a little before, possibly after. Some of what should be in it includes:

     

     

    that what is says on they info page here link.. (read it over)

     


    This crash has nothing to do with fitted mesh.  Its an out of bounds crash caused by certain meshes and this crash existed before fitted mesh was on the grid. This crash was fixed in the materials code.

    So, if you update to Firestorm 4.5.1, which has the materials code, you will no longer crash with Iki's mesh.

  8. Yeah, I've been seeing this problem recently too and so have some friends. Its very sporadic but it happens regularly enough to be annoying :smileyfrustrated:

    The login screen just remains stuck forever showing "Logging in....".

    When I have had this happen, it appears to be account specific. I can hop on an alt and login with no problems at all but trying to log the affected avatar in on either Firestorm or the official Linden lab viewer or even the old Phoenix viewer or SL 1.23 viewer fails in the same way.

    The last time I had this happen I purged my cache and settings folders for both the official viewer and Firestorm, which did not help at all, though I am fairly sure this is a prolem at LL's end, it was worth a try.

    Each time its happened, its only lasted a couple of hours max.

    I suspect something is going wrong with the login server for certain accounts when this happens.

    If I look at my logs when its stuck at "Logging in....", the logs just sit there stuck at this line....

    INFO: newview/llxmlrpclistener.cpp(327) : Poller::Poller: login_to_simulator request sent to https://login.agni.lindenlab.com/cgi-bin/login.cgi

    If I run the viewer through a debugger and attempt to login the affected account, wait for it to get stuck at logging in and then break to get a stack, I get...

    0:000> kV
    ntdll!KiFastSystemCallRet
    kernel32!Sleep+0xf
    Firestorm_Beta!ms_sleep+0xd (FPO: [Non-Fpo]) (CONV: cdecl) [c:\fs\build_fs_windows_firestorm_4_5_1\build\indra\llcommon\lltimer.cpp @ 80]
    Firestorm_Beta!LLAppViewer::mainLoop+0xf38 (FPO: [Non-Fpo]) (CONV: thiscall) [c:\fs\build_fs_windows_firestorm_4_5_1\build\indra\newview\llappviewer.cpp @ 1651]
    Firestorm_Beta!WinMain+0x1f2 (FPO: [Non-Fpo]) (CONV: stdcall) [c:\fs\build_fs_windows_firestorm_4_5_1\build\indra\newview\llappviewerwin32.cpp @ 304]
    Firestorm_Beta!__tmainCRTStartup+0x150 (FPO: [Non-Fpo]) (CONV: cdecl) [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 547]
    kernel32!BaseThreadInitThunk+0x12
    ntdll!RtlInitializeExceptionChain+0x63
    ntdll!RtlInitializeExceptionChain+0x36


  9. Prokofy Neva wrote:

    Where do you find the chat logs and other avatar files for Second Life in Windows 8?

    You know that folder that is users/name/appdata/roaming etc.

     

    Can't find it for the life of me.

     

    I havnt seen the IM/Profile problem myself but web profiles are pretty futzed right now and have been since this post: http://status.secondlifegrid.net/2013/12/12/post2134/  which is still not resolved.


  10. JoannaVou wrote:

    I discovered that the blurriness is connected to my pofile photo. I was using the same photo I had in my SL profile as in the picture frame. When I changed my profile photo to another that I don't have framed the blurriness went away from the frame.


    Well done on finding that. It is indeed a bug and a very strange one.

    If you use a certain texture for a profile image or picks image or groups image, that texture can act very strangely when its used on inworld prims.

    Even weirder, if another avatar in range of you has a certain texture as their profile/group/picks image and you apply that texture to a prim inworld, you will see the same bug.

    This bug only affects V2/V3 based viewers.

    Here is one example repro that will show the bug easily on any V2/V3 based viewer:

     

    • For one of your groups, set the group texture to Plywood from the Library.
    • Rez a cube and texture it with the same plywood texture from the library.
    • Change texture repeats on the cube to be 4 horizontal and 4 vertical.
    • Observe the broken texture on the cube.
    • Login a different avatar to observe the cube - they will see the texture broken also as long as your first avatar is still nearby.
    • Change the groups texture to something different, log out both avatars and relog with one avatar and observe the cubes texture now looks correct.

    The blurry image that you saw inworld when using the same texture as you were using on your own profile is a little tricker to reproduce but it is basically the same bug as the above repro.

     

     

     

     

  11. I just did a quick check on the RC sandboxes and main channel sandboxes for return to last position, using the copy/paste object parameter feature and the align tool with Firestorm viewer and everything appears to be working as expected. My only fail was restoring to last position on the BlueSteel sandbox but this was because there is a parcel there at <0,0,0> where I do not have rez rights, so failure was expected.

  12. Maestro, unfortunately Viewer 3 does not have return to last position  or the copy/paste object position or the align feature. Those are TPV features only. I'll test these on Firestorm and JIRA if it appears serverside changes have caused some breakage there. I suspect there isnt a server problem or we would have heard much screaming in Firestorm support by now as those features are widely used.

  13. Do you have the ability to build at <0,0,0> on that region?  Return to last position will only work if you have the ability to rez at <0,0,0>. This is a server limitation.

    Can you reproduce the same problem on another viewer that has the copy/paste object position and the align feature? Can you reproduce it also on another region? That would help to narrow down if this is a region problem or something that changed in the server update or if its a specific issue with Singularity.

  14. Yes please :smileyhappy:

    If you are using a viewer that does not have your card added to the gpu table, it will not cause a crash, you just will not be able to enable shaders, so something else is wrong here.

    Your system information will give the viewer you are using, operating system, how your card is detected by the viewer and driver version so yes, please give that.  Then we can look if that viewer has your card added to the gpu table for a start.

    I suspect the login crash is because of the driver version tbh, but lets see  :)

     

×
×
  • Create New...