Jump to content

Whirly Fizzle

Advisor
  • Posts

    4,719
  • Joined

  • Last visited

Posts posted by Whirly Fizzle

  1. Tonky, you appear to be fixed now from details on your bug report but I just wanted to list the most common causes seen for people seeing grey avatars since serverside appearance.

     

    • You are connecting to SL using a cellular network. Lots of info on this problem over at http://community.secondlife.com/t5/Second-Life-Server/SSB-via-T-Mobile-cellphone/td-p/2086361
    • DNS issues - Usually there will be no sign of DNS type problems when you login (no DNS could not resolve host name at actual login, no disconnects on teleport etc) but viewer logs will show many "WARNING: LLTextureFetchWorker::onCompleted: CURL GET FAILED, status: 00000006 reason: Couldn't resolve host name". Switching over to Google public DNS will fix this one.
    • Your maximum bandwidth is set too high in the viewer preferences for your connection - see http://wiki.phoenixviewer.com/fs_speedtest
    • Disabling HTTP textures fixes some cases.
    • Ive seen a couple of cases where people had ramped up their MeshMaxConcurrentRequests setting in debug settings to some ridiculous number (default is 32) in an attempt to make mesh load faster. Lowering this debug back to 32 fixed the grey avatars issue.

     

  2. When you say crash, does the viewer just poof to desktop (crash) or do you get a message like "You have been disconnected from Secondlife" (disconnect, not a crash)?

    Are you wearing any new mesh on your avatar that coincided with this problem starting?

    Certain meshes will instantly crash you if you right click within their Octree.

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

     

     

  3. That bug was filed on Sept 13th 2013 and was verified and imported as MAINT-3166. None of us can see MAINT-3166 so we do not know what is going on with that issue now.

    The interesting part of the issue I already pasted - which was Maestro's steps on how to reproduce and a theory on what the cause was.

    The original report was for seeing avatars and vehicles "ghosted" at region borders frequently while sailing and flying around the Blake Sea regions and when you saw a ghosted vehicle/avatar, when you right clicked on it, both vehicle and avatar just disappeared.

    Hope that helps  :)

    Edit to add: Here is one I caught on video: http://www.screencast.com/t/reH2rvOPVD

  4. This sounds like another flavour of the issue reported at BUG-3872 - 'Ghost' avatars and vehicles sometimes appear to an observer at the sim border.

    Maestro gave reliable steps to reproduce this issue for the vehicles case as follows:

    I figured out how to reproduce this reliably; it requires special positioning of the avatars relative to the sim borders.

    You need 2 avatars, UserA and UserB, and also 2 adjacent regions, RegionC and RegionD.

    1. UserA: Set your viewer's draw distance to 64m
    2. UserA: Figure out the subscription and unsubscription distances for UserB
      • Find out how close you need to be to UserB (within a region) in order to see object updates from UserB (terse updates when he's moving). This is the subscription distance.
      • Find out how far you need to be from UserB (within a region) before the sim sends an KillObject message, indicating that UserB is no longer on your interest list. This is the unsubscription distance.
      • In my testing, I found that the subscription distance is about 106m, and the unsubscription distance is about 118m.
    3. UserA: position yourself in RegionC so that your distance to the border of RegionD is between your subscription and unsubscription distances, and have your avatar face RegionD
      • When RegionD is to the north of RegionC, I found that <128,145,21> in RegionC was a good place to stand
    4. UserB: Rez a Kart right near UserA, and sit on the Kart
    5. UserA: Open the minimap, and verify that the minimap does not indicate any connection to RegionD. Verify that you see UserB's dot at the correct place on the minimap, too.
    6. UserB: Drive the kart straight into RegionD
    7. UserA: note that UserB's agent dot moves right to the edge of RegionC, but does not move further
    8. UserB: Stand up, delete the Kart, then log out
    9. UserA: note that UserB's agent dot still appears on the map
    10. UserA: move toward RegionD, to to inspect UserB's apparent position
    11. UserA: note that you see UserB's ghost and the Kart at the sim border, rotating slowly
    12. UserA: Right click on UserB's ghost, and observe that he disappears
    13. UserA: Right click on the Kart, and observe that it disappears

    The expected behavior is:

    • UserA does not see a minimap dot for UserB, after UserB moves into RegionD (which UserA is not connected to)
    • UserA does not see a 'ghost' of the Kart or of UserB when approaching the sim border

    I spoke with Andrew about this, and we think the issue is that RegionC isn't sending the KillObject message to UserA because it assumes that RegionD will (as the vehicle and passenger are in RegionD). But RegionD can't send the message since it isn't connected to UserA. What should happen on region crossings is for the source region to check whether an observer is connected to the destination region, and immediately send a KillObject message for the crossing objects/agents to the observer is not connected to the destination.

  5. There are griefer objects that when rezzed on a region will set all scripts in your attachments to a not running state when entering the region.

    If the attachment scripts are mod, you can set the scripts back to running. If the scripts are no mod you are stuffed unless you have a copy of the attachment kept in inventory.

    Always keep backups of expensive scripted attachments, especially if the scripts are no mod.

  6. File a JIRA and be sure to include a full paste of your system information from Help -> About Secondlife (if you cannot get as far as the logion screen to get this information, grab the info from any viewer you can get to the login screen with) and be sure to attach a zip your viewer logs folder to the JIRA issue.

    THIS PAGE tells you how to find your Viewer 3 logs.

    Your logs should give a good indication of why you are crashing and then hopefully that can be fixed :smileyhappy:


  7. Monty Linden wrote:

    Please tell me 500 was a joke.  That would make me cry...

     

    lol Monty.

    Unfortunately the advice to set MeshMaxConcurrentRequests to 500 is pretty common. This is often seen in several "Help" notecards that do the rounds inworld.

    Just to make you cry some more :smileysad: ...

     

     

  8. You had some files locked that the installer couldn't replace. Simplest thing to do when that happens is to just reboot the computer and run the installer again.

    This does not happen that often but it's a known issue.

  9. Long shot, but another thing to check is that the sound isn't coming from slplugin.

    This doesnt happen very often and why it does sometimes happen is a complete mystery.

    Bring up your volume mixer and find slplugin in the list of applications (there will likely be more then one slplugin running)  and mute the volume on them all and see if the strange noise stops.

     


  10. Callak Skytower wrote:

     I was also going to post on my JIRA BUG-3143 ticket ....

    ....but since the ticket has been closed and later reopened by Whirly Fizzle with a message that it was accidentally closed, I cannot seem to post any further comments on it......

    EEeek!

    That wasn't me! :smileysurprised:

    Check the HISTORY on your issue to see who closed it, re-opened it then reclosed it.

    WorkingOnIt Linden closed it on 09/Jul/13 11:02 AM

    CommerceTeam Linden reopened it on Friday 4:03 PM with the comment "Accidentally closed."

    Then CommerceTeam Linden closed it Yesterday 5:22 PM

     


  11. Pamela Galli wrote:

    ...I notice that the actual texture is now in one tiny square in a corner...

    The textures appearing as a small square in the corner could be an openJPG problem (OpenJPG is the texture decoder used on some TPVs).

    Try clearing your texture cache first to rule out a local cache problem.

    Are you using a Singularity build that has Materials merged in?  If so, there are a few bugs which make certain textures appear black on materials viewers (specifically anything that has any glow and transparency).

    If none of the above is the case then check how those textures display on a viewer that uses KDU (Viewer 3, Firestorm or Exodus - probably best to use Viewer 3 for testing...)  and see if you see the same thing.

     

  12. You should do what you were advised to do on your JIRA issue.

    Your issue should clear up if your home region is restarted, which Linden Lab support can do for you.

    Create a Support ticket and choose "Land & Region" then "Report an offline region" and explain in the additional information why the region needs to be restarted. You can reference your JIRA issue in your support ticket.

    This problem should clear itself up during today's and tomorrow's rolling restarts anyway.

  13. Heya Sarah,

    You should file a bug report on the JIRA about this.

    Run a session on the latest release version of Viewer 3 while connected to your T-Mobile network.

    Login to a non-SSA region where there are other avatars, wait 10 minutes and then teleport to an SSA region where there are other avatars, stay there for 10 minutes or so and then teleport again to a non-SSA region where there are avatars and stay there for 10 minutes or so and then logout.

    Before relogging, grab your logs folder, zip up the logs folder and attach it to your JIRA issue using More Actions -> Attach files.

    Instructions on where to find your logs folder can be found HERE.

    Repeat the above process running a session on the same viewer with the same avatar while connected to your normal network which does not have these problems & also attach your logs from that session to the JIRA issue.

     

     


  14. StilettoSara wrote:

    I don't get this at all???

    When I right click on one object and choose edit, then the item just shows as transparent with lines around  the item......Next thing happening is that when I then grab the item by the tools, well then the object turns 100 % invisible? and "you" have to guess WHERE it ends up?

    Use CTRL+ALT+D to being up the Advanced menu in the top menu bar

    Advanced -> Highlighting & Visibility -> Hide selected -> Untick it  :smileywink:


  15. Theresa Tennyson wrote:

    ...or is the code just being deployed but not switched on?

    It looks like LeTigre will be using SSA as soon as it's rolled on Wednesday.

    "Client side baked textures are no longer shared with other connected agents, so the functionality was removed."

    This means that on LeTigre regions, people using non-SSA compatible viewers will show as unrezzed clouds to everyone using an SSA viewer and people on a non-SSA viewer will see everyone using an SSA viewer as a grey avatar.

    Anyone who has not updated to an SSA compatible viewer should do so ASAP.

    • Viewer 3 users - latest download can be found HERE
    • Phoenix Viewer users see HERE
    • Firestorm users should be on the 4.4.2 release, see HERE
    • Other third party viewer users, be sure to have updated to your viewer's SSA compatible release.

    As far as I am aware all the viewers listed in the top section of the TPV directory are SSA compatible apart from Imprudence, Dolphin and Exodus.

    CoolVL Viewer which is not listed on the TPV directory is SSA compatible.

    (Someone please correct me if I'm wrong about Imprudence, Dolphin and Exodus viewers not being SSA compatible).

×
×
  • Create New...