Hitomi Tiponi

Ayesha Askham wrote: I see the Google calendar has been ammened to show that there will be no Main Server roll on Tuesday 4th September (today for me). This, I assume, is due to Labor Day in the USA. Main Server residents will have to wait at least one more week to see SVC-8124 eradicated. I can only hope that the bug-fix will reach some of the RCs tomorrow (Wednesday). ----------------------------------------------------------------------------------------------------------- Come on Lindens - you only have one day's holiday yet you delay a whole week's worth of rollouts - pull your finger out and roll over the fix to the main grid.

Nalates Urriah wrote: I am not certain whether the flag is set when you move things at altitude, like in a skybox. Changing things in the navmesh at altitude does suggest a rebake - I know, I regularly do it in our 'village' at 3900.

I believe that moving or deleting objects in the navmesh will also affect it.

See http://wiki.secondlife.com/wiki/Pathfinding for a quick overview Also Havok's own site describes a lot about it and shows off it's capabilities - but remember that the advanced features (e.g. character steering, swimming, flying) are not currently being implemented in SL.

Most collars rez a leash when grabbed. OpenCollar is a good free collar to use - various styles available.

People keep telling you - this is an issue for you to talk to Google about - not LL, not people on these forums. Go and talk to them.

He was seen in SLU on 7th August - it's summer as well and I imagine he does get some holidays.

With the importance that the user community apparently attaches to SVC-8124 I am also surprised that it has not been given it's own seperate RC to be tested on rather than being rolled in with a large number of other fixes. Is there a reasoning behind this Oskar?

Theresa Tennyson wrote: 4) This seems to be caused by a glitch with diagonally touching regions, which are unusual in an important respect. If a series of regions are laid out as a checkerboard and only touching at the corners they're supposed to be invisible to each other. You can see swaths of private regions laid out like this on the map. If other regions fill in the blanks in the checkerboard, though, diagonally touching regions ARE supposed to be visible because they form part of a continuous area. Don't ask me why they work this way; don't ask me if this is a good idea. It probably isn't a good idea for English to have three hundred different ways to pronounce the letters "-ough" but that's how things ended up being built. There was a JIRA about diagonal visibility of sims that came up right before this issue popped up and that may have been the window the bug flew in through. The invisibility of diagonal regions in all ways was how it used to be. There now may be some interaction as you can walk up to about 10 metres into an adjacent region that is offline as part of the sim crossing changes (or you could last time I tried). I'm wondering if this change has caused more overlap.

See http://www.urbandictionary.com/define.php?term=goru goru = Sick, Twisted Hentai usually involving death, dismemberment or anything else sickening.

The SVC-8124 issue is one which we are working on fixing in the Magnum channel. __Oskar Thanks for that information Oskar.

Is this something to do with Groups and the permissions in them?

As someone who uses several machines and works on UI mods I monitor this closely. After incremental improvements in Viewer 2 (after it's extremely laggy/buggy start) there was a big fall back in performance for older machines with 2.8/3.0 (for mesh) which has never been fully recovered subsequently. Viewer 3.4 seems a bit all over the place from the limited amount I have used it, but that may be because pathfinding is still settling down, and I haven't explored the grid with it. For performance on older machines Viewer 1 and Viewer 1 based TPVs tend to still be the best option - I think that says a lot about Viewer 3.

I have great sympathy with what you say Ayesha. If, for example, LL were to say 'yes, this is a big issue and we are working hard on it, though it may take a couple of weeks' I imagine many would not be happy, but they would be a lot happier than they are now with their lack of communication or appreciation that it is a problem. With a system like pathfinding it was always going to be difficult to spot all problems on an RC rollout, the grid is such a diverse place. I do not think LL realised that as well as they should have - they do seem blinkered in looking at pure sim performance and down-time sometimes. If Apple or Microsoft were experiencing this they would be issuing statements and putting extra resources on the problem. Such organisations realise the importance of good PR (and can afford to make grand gestures) - LL is a very different beast.

Pandorah Ashdene wrote: My jaw just dropped to the floor. - I am seeing https://jira.secondlife.com/browse/SVC-8124 mentioned nowhere. Linden Lab are working on this and other Pathfinding/Havok 7 issues. These things take time to fix - and they are likely to need a week of testing on an RC after that. LL had the option to roll back pathfinding, but would probably only have done that if there was widespread content breakage or performance issues, as that would have caused it's own issues. Pathfinding, as expected, has brought with it many bugs that weren't exposed during testing - I am compiling details of one I have noticed. What is a fair criticism of LL is the lack of communication from them on progress on many issues, and the way they often hide the issues that have been reported without any apparent reason. Hopefully this, and other bugs that cause real grief, will be fixed soon.

You may find https://wiki.secondlife.com/wiki/Third_Party_Viewer_Directory useful as well.

As long as the speed is sufficient (greater than 0.8 Mbps seems to work and I often use a 1Mbps link) and it doesn't use a high latency system (e.g. satellite) you should be ok with any connection.

There are currently 10 User Interface files that contain this text string. It should not normally appear unless something has gone wrong. Often this is related to a failed connection with a LL server or service, and it sounds like you are experiencing this. Why, I do not know - but if it continues I suggest you log it in the JIRA to see if they can fix it for you.

Firstly make sure that your Windows updates are up-to-date and try Viewer 3.3.4. I have a friend who had the same problem for two moonths and suddenly it seems fixed.

Did you have a Windows update run just before this happenned? I'm guessing that SL used to be fine for you.

This sounds similar to http://community.secondlife.com/t5/Technical/Hej-I-have-installed-Viewer3-and-just-like-Firestorm-it-crashes/qaq-p/1610537 - I would suggest it might be related to your reinstalling the Operating System something in the latest Windows build may not like something in SL.

This isn't really an answer, more a follow-up question. Did it start happenning after a Windows Update, and do you have an Nvidia graphics card in your machine? I ask this because a friend has the same problem - still unresolved, but we suspect the Windows Update. And I agree with the others that full details of your machine would be helpful.

Sadlly Linden Lab are making the minimum of publicity about changes that are happenning, whether they be bugs or new features. It seems it is now company policy to make no comment other than at in-world user groups (occassionally), in the technical and rarely read Release Notes (most of the time) and in the difficult to search JIRAs (most of the time).

Is this only happenning with Viewer 3.3.3 as I have heard of others that are having this problem with more than one viewer? There are other 'project viewers' and a Beta Viewer you can try if you do not wish to try a TPV. That may indicate if it is Viewer 3.3.3 or something more general.

Today Widely Linden closed MAINT-1299 marking it as expected behaviour after several months. What this means - in English - is that invisprims are accepted as no longer rendering properly when shadows are enabled in the official viewer (and TPVs using the same rendering stream) and this will no longer be regarded as a bug. This has the biggest effect with many shoes and other items of clothing that took advantage of that as a feature some time back. More modern clothing should be using other methods, but older avatars (or avatars buying older content) may find that they don't look right when being viewed in a viewer with shadows enabled. Using invisiprims in this way may be inadvisable (but once was widespread), and with this LL is admiting it is happy breaking current content without publicising anything about it beyond the limited JIRA community. Hopefully this will help publicise this issue more widely.