"Lost prims" after tp; "Interest List" errors; ONE WHOLE YEAR NOW LINDEN LABS

[Domitan Redenblack]

When is Linden Labs going to fix the "missing prims" problem? After you tp, many prims are "logically" there but not visible in viewers. 

 

If you right-click where the prim should be, or go to wireframe view then back, you can restore their visibility, but JEEZ why don't the fix it?

 

It used to work just fine.

 

[Theresa Tennyson]

---

Domitan Redenblack wrote:

When is Linden Labs going to fix the "missing prims" problem? After you tp, many prims are "logically" there but not visible in viewers. 

 

If you right-click where the prim should be, or go to wireframe view then back, you can restore their visibility, but JEEZ why don't the fix it?

 

It used to work just fine.

 

---

That's a viewer problem having to do with the cache and it's been fixed for months in the Viewer 3.

[Trin1]

It's a cache issue? How does that explain it happening in places you've never been before?

[Theresa Tennyson]

---

Trin1 wrote:

It's a cache issue? How does that explain it happening in places you've never been before?

---

I used to see that happen in new places too but usually only with the prim I was standing on when I arrived with a teleport. Anyway, I haven't seen it happening lately. Just curious - is anyone who's still seeing it using "progressive draw distance"? It always seemed to be caused by prims that were half in and half out of your field of view when you arrived at a location.

[Ayesha Askham]

Theresa

We have known for some weeks, thanks to Simon Linden's openness about the Interest List changes in server code, that the issue was only truly fixable viewer-side, but that code must surely have been made available to TPVs a while ago.  It still occurs on Firestorm 4.4.2, which is the latest codebase released, so I do not understand - are you really saying that this is fixed in Linden Lab's own viewer but that the code has not been released to TPV developers?  If so, that is a most disturbing scenario.

[Theresa Tennyson]

---

Ayesha Askham wrote:

Theresa

We have known for some weeks, thanks to Simon Linden's openness about the Interest List changes in server code, that the issue was only truly fixable viewer-side, but that code must surely have been made available to TPVs a while ago.  It still occurs on Firestorm 4.4.2, which is the latest codebase released, so I do not understand - are you really saying that this is fixed in Linden Lab's own viewer but that the code has not been released to TPV developers?  If so, that is a most disturbing scenario.

---

The code has been released and TPV's have it but they also have various additional rendering options like object blacklists, progressive draw distance, etc. that may not be completely compatible with the fix. That's why I was asking about progressive draw distance.

[Rolig Loon]

FWIW, until recently I had occasional problems with progressive draw distance sticking.  Either the draw distance would get stuck at 64m and fail to step up to my normal 128m after 20 seconds, or individual objects would fail to rez until I gave them a little kick.  That seems to have been solved with the Firestorm 4.4.2 code.  Progressive draw distance is working fine for me and objects in general are rezzing much faster.

[Trin1]

Unless progressive draw distance is on by default (which it isn' if I'm not mistakent) then I'm not using it.

[Rolig Loon]

No, it's off by default.  It's a nice option, though. Basically, what it does is to decrease your draw distance when you TP or log in to a sim, so that your viewer has fewer textures to download and rez at once.  It then increases up to whatever you have set your draw distance to download the rest.  You can set how long it takes before it steps from the short range to the long one.  Using PDD simply means that nearby things rez much faster than they would otherwise because they have been given first priority.

[Ayesha Askham]

Now the real state of play is this:

The definitive REAL fix for the Interest List bug is still in the early stages of closed testing by Linden Lab.  It is NOT in the Linden Viewer nor any of the TPVs.  An intermediate fix has been incorporated into both LLV3 and most, if not all, SSA capable TPVs, and that includes Firestorm 4.4.2.

That the bug is still occasionally visible is simply a consequence of the incomplete fix.  The full fix, which as a project viewer is still too crashy to be publically available, will work hand-in-hand with the simulator-code changes.

It is specious and not a little insulting :smileysurprised: to the Firestorm developers to suggest that any features that they incorporate in any way negatively affect the performance of the prim rezzing.  Any impact, as is reported above, is beneficial not negative.

Just when this irritating bug will finally be squashed is open to speculation, but since it was very important to lower the load on connected devices with the advent of more and more hand-held devices, I think it will be sooner rather than later.:smileywink:

ETA: Perrie's post (next page) gives Andrew Linden's original explanation of the viewer-sim dialogue and how it has changed.

[Perrie Juran]

---

Ayesha Askham wrote:

Theresa

We have known for some weeks, thanks to Simon Linden's openness about the Interest List changes in server code, that the issue was only truly fixable viewer-side, but that code must surely have been made available to TPVs a while ago.  It still occurs on Firestorm 4.4.2, which is the latest codebase released, so I do not understand - are you really saying that this is fixed in Linden Lab's own viewer but that the code has not been released to TPV developers?  If so, that is a most disturbing scenario.

---

For reference, Andrew Linden's original explanation:

 

"But why is the client suddenly having a problem it didn't have two months ago? "

What has changed is that the server is now treating much more content as "cacheable".  The server's definition of cacheable used to be something like:  "is static and does not have a script".  The new definition of cacheable is: "has not changed position or appearance in the last couple minutes".

The viewer bug must exist inside the code that retrieves object data from cache and is more noticeable now because the viewer-side object cache tends to be bigger.  I've brought the problem to the attention of one of the developers who is working on some viewer-side changes that will compliment the next server-side interestlist changes (*), so we hope to figure it out soon.

(*) The server will soon support two hints from the viewer:

(1) "I don't have an object cache file for this region at all" --> the server will then be able to bypass some of the initial "cache probe" messages of the protocol which looks something like this:

Viewer: Hello, I would like to connect.

Server:  You are connected.

Server: Do you have cache for object 123 whose version is 456?

Viewer: No, I do not have cache for object 123.

Server: Here is the data for object 123.

Under the new system: when visiting a region for the first time the conversation will look more like this:

Viewer: Hello, I would like to connect, and BTW I can tell you right now that I have no cache.

Server: You are connected.

Server: Here is the data for object 123.

 

(2) "I'm willing to cache ALL object data in the region, including stuff that is too far away or too small to see" --> the server will eventually stream all cacheable data to the viewer, including sky boxes far above.  It sends the non-visible data with a delay so that if you're flying through the region on a jetpack and leave soon after arriving you won't get the extra data, and once it starts sending the non-visible objects it will be in a lazy fashion -- lower bandwidth than when sending what is in front of you.

 

http://community.secondlife.com/t5/Second-Life-Server/Deploys-for-the-week-of-2013-04-01/td-p/1954059/highlight/true/page/2

Whatever fix was deployed after this was included in FS.

I still see isolated incidents of Prims not rezzing.  But nothing on the level of what was occurring last April.

 

[Theresa Tennyson]

---

Ayesha Askham wrote:

It is specious and not a little insulting  to the Firestorm developers to suggest that any features that they incorporate in any way negatively affect the performance of the prim rezzing.  Any impact, as is reported above, is beneficial not negative.

 

---

I wasn't aware that the Firestorm developers were infallible beings working in a sphere of pure light cupped in the hands of God. That may come as news to at least some of them too.

I no longer seem to have missing prim problems that I notice and I use Viewer 3, others do and use Firestorm. It would be logical to wonder if any differences in the viewers might be the cause of this.

[Cincia Singh]

Given the slow pace of updates to Firestorm compared to the updates to the LL viewer it's no surprise fixes don't come along as quickly.

[Ayesha Askham]

@Theresa

I never said Firestorm devs were infallible but they DO test their updates thoroughly to ensure that they do NOT have a negative impact on the user experience.

The fact is that while the missing prim issue is NOT fixed yet, it is much less severe.  I know of at least one other Linden Viewer user that is having this issue still, albeit reduced.

@Cincia

So Firestorm updates come along slowly do they?  I cannot say I have noticed.  But I do notice that when they come, they work.  Firestorm updates as soon as it is allowed to by the release of code by Linden Lab, if that slows them it is hardly their fault now, is it?

[Darien Caldwell]

---

Ayesha Askham wrote:

It is specious and not a little insulting :smileysurprised: to the Firestorm developers to suggest that any features that they incorporate in any way negatively affect the performance of the prim rezzing.  Any impact, as is reported above, is beneficial not negative.

 

---

 

Wow. Someone's drinking the Koolaid. Do you really believe FS is incapaoble of making any mistakes? I seem to recall recently the released a viewer that was spamming LL's servers with debug info. Oops!

Firestorm has just as much culpability for any bugs they introduce, as LL does. And it does happen. No code is perfect, and I am sure the FS devs would agree heartily.

As for the Missing Prim issue, I can say with the latest LL viewers, the problem is greatly reduced. I can't say how it is for FS. But if they are still having serious issues with that viewer, it doesn't take a genius to understand something must be wrong there.

[Rolig Loon]

Yeah, none of the viewers is perfect.  They're all dealing with a complex code and any changes are likely to have unexpected consequences.  Historically, Firestorm has been more cautious about releasing upgrades until they have tested in-house to identify the most obvious problems.  Linden Lab's approach -- equally valid but different -- has been to release code more quickly and let its users serve as the bug-finding team.  Whichever approach they use, there has been a healthy, continuing dialog between developers in each of the houses within the past year or so. It doesn't seem to me that there's as much competition between them as there appears to be among users.

FWIW, I have been using Firestorm through all of its versions for a couple of years.  The missing prim problem has all but vanished in 4.4.2, as far as I can see.  In the past two weeks, I have maybe had a half dozen times when one failed to rez for me.  Compared to 4.4.0, which everyone agrees was rushed to release too quickly because SSA was on the near horizon, 4.4.2 is lovely.  I don't know how well V3 works, because I don't have it loaded on this machine.  It's difficult to make valid comparisons with the way any viewer works on someone else's machine, so I'm not going there either.

[Domitan Redenblack]

---

Rolig Loon wrote: 

 In the past two weeks, I have maybe had a half dozen times when one failed to rez for me.

---

I especially see sculpties not rezzing in my own sim, and in most others. I have Firestorm QuickPreferences tick box tool to allow me to switch Alpha Mask Rendering off then back on, which forces all prims to appear. Some places it is as few as 2-3 objects, some places it's 20+ still with 4.4.2 FS.

[Qie Niangao]

---

Domitan Redenblack wrote:

 some places it's 20+ still with 4.4.2 FS.

---

Okay, I've not seen anything like that with the LL viewer in weeks, maybe months. If this is really the most critical issue for you at present, you owe it to yourself to try the LL viewer long enough to tell whether there's still a problem worth worrying about, or if it will just magically disappear the next time Firestorm pulls in the LL rendering changes (which have been happening rapidly, as the Materials features mature--and which will have their own problems until those features are mature).

Longer term, expect more viewer changes that take better advantage of Andrew's server-side interestlist changes. I expect those also will first appear in Linden viewers before they get merged into TPVs, by which time they'll likely be more stable than when first introduced in a Linden viewer. That's just how it works now; it's silly to get all religious about viewer-specific differences in performance and stability.

 

[Ayesha Askham]

Good Grief

Do any of you actually read more than one post?

Of course the FS devs take responsibility for bugs that are introduced.  Where do I suggest that they don't?

Yes Domitan it does seem that Firestorm is more prone to not rendering sculpties properly, more so than the Linden Viewer, I suspect.  But the main reason that I think most folk see more issues reported with Firestorm is that by and large (excluding Darien I'd imagine) they (users of the Linden Viewer) do not use such high graphic settings*. 

*That opinion is purely hearsay gleaned from talking to other users.

Please folks read more than one post before venting! :smileywink:

Edit was to make sense of what I posted!  (Note to self: proof read your post properly)

 

PS  Yes Darien the blunder in FS 4.4.1 of not deleting code that LL had asked them to put into the viewer during testing was a bad one, but they 'fessed up sharpish and sorted it within a few days.  It'd be nice if all Linden whoopsies were fixed as quickly.