Whirly Fizzle

Take a look at this thread too: http://community.secondlife.com/t5/Second-Life-Server/High-Sim-Ping-from-UK/td-p/2212439

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!

Mordaken wrote: First mesh wasn't loading... My friends list does not load half the time I log. I can't teleport without crashing and a lot of things in game do not load. You list the classic symptoms of the "DNS bug" - see VWR-25426 The workaround is to switch over to using Google public DNS

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

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. UserA: Set your viewer's draw distance to 64m UserA: Figure out the subscription and unsubscription distances for UserBFind 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. 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 RegionDWhen RegionD is to the north of RegionC, I found that <128,145,21> in RegionC was a good place to stand UserB: Rez a Kart right near UserA, and sit on the Kart 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. UserB: Drive the kart straight into RegionD UserA: note that UserB's agent dot moves right to the edge of RegionC, but does not move further UserB: Stand up, delete the Kart, then log out UserA: note that UserB's agent dot still appears on the map UserA: move toward RegionD, to to inspect UserB's apparent position UserA: note that you see UserB's ghost and the Kart at the sim border, rotating slowly UserA: Right click on UserB's ghost, and observe that he disappears 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.

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.

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:

Take a look at Camera View Spinning In Mouselook Or When ALT Clicking On An Object

See FIRE-11143 - [sSA] Avatar textures are often blurry on SSA regions. for this bug. Unfortunately there isn't a publicly viewable LL JIRA about this. There is some info about this problem given by Nyx Linden on the above Firestorm JIRA though.

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: ... "change the MeshMaxConcurrentRequests from 16 to 500" "I set my value to 500..." Change that 32 ... to something really high: I walk with meshmaxconcurrentrequests at 1000 lol and I have no lag

This is a known bug and has been since around revision 276389. See CHUIBUG-210 Im really suprised this was released in one of the RCs that people with "willing to update" enabled could be force updated to this build but hey ho. :smileysurprised:

Is that a system skirt you are wearing in that image? If so, it could be FIRE-4082 This is fixed on more up to date versions of Viewer 3 and Firestorm. What viewer are you using? Are you wearing any mesh? SH-2340 can give that "invisiprim" look also. This issue is not fixed and probably never will be.

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.

Avatar cloth being broken in deferred rendering is a bug. Demo video HERE.

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.

Possibly you are seeing CHUIBUG-136 This bug affects both pre-CHUI and post CHUI viewers. I'm pretty certain it will affect all V3 based viewers - I have certainly seen it in Viewer 3 and Firestorm.

I think Engine Nine needs a restart. I can reproduce the same. I am unable to login directly to Engone Nine and if I teleport there, remove some attachments and relog, all my attachments I removed are back on again.

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

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.

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.

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.

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:

This is a known bug on the Materials viewer - see MATBUG-235 (With Advanced Lighting Model, some fullbright alpha textures are dark.) It's already fixed on the Materials nightly builds.

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

If you update to the 4.4.0 release of Firestorm, this problem should be fixed. It should be fixed on any up to date V3 based viewer actually, including official Viewer 3. Any viewer still using TC malloc (4.3.1 does) will give you this same problem. It isn't worth troubleshooting what software on your system is causing this with 4.3.1 because come July 9th, 4.3.1 wont be viable for SL anymore because of serverside appearance being switched on.