Where is up-to-date Documentation

[arabellajones]

I keep finding documents such as this one:

Mesh/Mesh Server Weight

It starts with this message:

READ THIS FIRST
This is a preliminary design of an unimplemented cost algorithm. EVERYTHING is subject to change, and certainly will change, during the course of implementation.

It is all dated 15 April 2014, which isn't itself a problem. But if it is a stable version of the formula, currently used, why are you still using that warning?

There are other instances of this sort of apparent dud info. Take the web page on Avatar complexity, which is clearly headed with a warning that it only applies to a Release Candidate Viewer

Avatar Rendering Complexity

If web pages such as this do describe the current situation, why do they need these warnings? And if they don't describe the current situation, why not?

Can I trust anything Linden Lab say?

Oh, I know I am too disorganised to be paid as an editor, and I am not a good typist, but with writing of this quality, if you wanted to organise a piss-up in a brewery, the beer would end up in a different brewery.

 

[Nalates Urriah]

The Lindens are not good at keeping things up to date. If you look at the history of the first page you link to, you'll find the last Linden up ate was in 2012. A resident updated something in 2014. THe same is true with ACI. 

The Lindens that knew all the details have moved on to other projects. Costs have been modified. So, the page is out of date. No one really cares because most of us use the Preview Grid when uploading mesh and we can just click and see the LI cost or ACI.

ACI is changing... or is likely to change. The Lindens are still accpeting feedback on what would make for a better and more realistic calculation. So, there isn't much point in updating the ACI page. We don't know what the final calc will be.

All that matters to most of us is what things are considered in the calculation. There are lots of discussons about what the actual formula and values are. For the best discussions search through Drongle McMahon's posts. You may have to go back into history. But, Drongle has probably done the most testing and experiementing to find how to reduce Land Impact Cost.

I know it is tough on new people. But, it is mostly up to the community to update the wiki.It is also a matter of whether we want them writing in the Wiki or writting code. I prefer code.

[arabellajones]

If a project isn't documented, does anybody know what they're doing, users of programmers or managers?

[Whirly Fizzle]

As far as I'm aware, this page has current accurate info for the complexity calculation: http://wiki.secondlife.com/wiki/Mesh/Rendering_weight

[arabellajones]

Recent, and one of the better pages, but it would be worth making plain that Render Weight, Display Weight, and now Complexity are the same number. Picky? Well, what about search engines? Anyway, the word isn't anywhere in the page source.

[ChinRey]

---

Nalates Urriah wrote:

The Lindens that knew all the details have moved on to other projects.

---

Not only to other projects, they don't work at Linden Lab anymore. At least the person in charge of developing SL mesh doesn't, and his boss doesn't and his boss' boss doesn't. And LL's current CEO has publicly described the SL software as "stovepipe madness".

It's very easy for us to complain about LL's lack of documentation and I think we should complain because it is a serious issue and the ultimate reason for many of the problems we have in SL. But it's quite possible the current programmers at LL don't have better documentation themselves than we do and they're the ones who have to try to sort it all out.

In a very real sense we're blaming the cleanup crew for the mess. The Lindens today are accountable for it, no doubt about that, but let's remember that the people responsible are long gone. Last I heard they were busy messing up another virtual reaility. Maybe time to remove some old pedestals here...

[arabellajones]

I don't know if it is relevant, and some of these errors are plenty old enough, but I see that the Wiki has been locked down, for security reasons, for most of this month.

What I am seeing is rather fundamental ineptitude, not getting the documentation finished.

I'm not the Second Life equivalent of a Kremlin watcher, but I can't think of any well-known programmer-grade Lindens who have been around here as long as I have. If they don't even have internal documentation for the code that would be dreadful management, and I have heard a few stories from the days when Viewer 2 appeared.

And user-created content with poor documentation... It explains a lot.

[ChinRey]

---

arabellajones wrote:

If they don't even have internal documentation for the code that would be dreadful management,

---

It is indeed.

A while ago I mentioned the 3/4 face mesh LOD bug and the mesh/map bug to a friend who is fairly familiar with the viewer source code. It didn't take her long to identify the cause of the first of those bugs and when she brought it up with LL, Oz explanation why it was never fixed was that the person who wrote the code for SL mesh had quit shortyl afterwards. When my friend brought up the related map bug, Oz told her flatly that nobody at LL dared go near the map software. This is all according to my friend of course but she's not the kind of person who makes things up or exaggerates so I have no doubt that the story is true.

What I know is true though, is that Ebbe Linden in a recent interview said that the SL code is a "stovepipe madness" caused by "too many chefs in the kitchen", and he more than indicated that was the main reason why they had decided to develop Sansar from scratch rather than try to upgrade the old SL software. It is quite extraordinary for a CEO to say something like that about his company's main product. I don't know if it was a thoughtless remark or a deliberate slip but in either case it can only mean that the situation was really, really, really bad when he took over.

[Perrie Juran]

---

ChinRey wrote:

---

arabellajones wrote:

If they don't even have internal documentation for the code that would be dreadful management,

---

It is indeed.

A while ago I mentioned the 3/4 face mesh LOD bug and the mesh/map bug to a friend who is fairly familiar with the viewer source code. It didn't take her long to identify the cause of the first of those bugs and when she brought it up with LL, Oz explanation why it was never fixed was that the person who wrote the code for SL mesh had quit shortyl afterwards. When my friend brought up the related map bug, Oz told her flatly that nobody at LL dared go near the map software. This is all according to my friend of course but she's not the kind of person who makes things up or exaggerates so I have no doubt that the story is true.

What I know is true though, is that Ebbe Linden in a recent interview said that the SL code is a "stovepipe madness" caused by "too many chefs in the kitchen", and he more than indicated that was the main reason why they had decided to develop Sansar from scratch rather than try to upgrade the old SL software. It is quite extraordinary for a CEO to say something like that about his company's main product. I don't know if it was a thoughtless remark or a deliberate slip but in either case it can only mean that the situation was really, really, really bad when he took over.

---

You have reminded me of this old bit of humor:

 

Top 20 things likely to be overheard if you had a Klingon Programmer:

1. Defensive programming? Never! Klingon programs are always on the offense. Yes, offensive programming is what we do best.
2. Specifications are for the weak and timid!
3. This machine is GAGH! I need dual Pentium processors if I am to do battle with this code!
4. You cannot really appreciate Dilbert unless you've read it in the original Klingon.
5. Indentation?! - I will show you how to indent when I indent your skull!
6. What is this talk of 'release'? Klingons do not make software 'releases'. Our software 'escapes' leaving a bloody trail of designers and quality assurance people in its wake.
7. Klingon function calls do not have 'parameters' - they have 'arguments' -- and they ALWAYS WIN THEM.
8. Debugging? Klingons do not debug. Our software does not coddle the weak. Bugs are good for building character in the user.
9. I have challenged the entire ISO-9000 quality assurance team to a Bat-Leth contest on the holodeck. They will not concern us again.
10. A TRUE Klingon Warrior does not comment his code!
11. By filing this bug report you have challenged the honor of my family. Prepare to die!
12. You question the worthiness of my code? I should kill you where you stand!
13. Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
14. Our competitors are without honor!
15. Python? That is for children. A Klingon Warrior uses only machine code, keyed in on the front panel switches in raw binary.
16. Klingon programs don't do accountancy. For that, you need a Ferengi.
17. Klingon multitasking systems do not support "time-sharing". When a Klingon program wants to run, it challenges the scheduler in hand-to-hand combat and owns the machine.
18. Perhaps it IS a good day to die! I say we ship it!
19. My program has just dumped Stova Core!
20. Behold, the keyboard of Kalis! The greatest Klingon code warrior that ever lived!

 

But seriously I sometimes think that it is a marvel that Second Life runs as well as it does.

It's easy to criticise or complain, and sometimes we disagree with the priorities they set, but we also know that any changes to the source code(s) can have a huge domino effect that can result in even bigger problems.  So it is not something you treat lightly.

[ChinRey]

---

Perrie Juran wrote:

You have reminded me of this old bit of humor:

---

 Thanks Perrie! I've been looking for that for a while. Read it long ago but then couldn't find it again.

 

---

Perrie Juran wrote:

But seriously I sometimes think that it is a marvel that Second Life runs as well as it does.

---

Oh yes. The LL programmers have shown an amazing ability to find brilliant solutions to problems that shouldn't have existed in the first place.

But that doesn't change the fact that those problems shouldn't have existed in the first place. I used to read a lot here about how brilliant certain prominent early Linden programmers were. Haven't heard much of that recently and maybe it's jsut as well because they weren't. Even without Ebbe's and (apparently) Oz' recent admissions, it's quite easy to see that the core of the SL code has serious issues. What Linden Lab originally made, was the digital equivalent of some boy's hobby room project, assembled from random bits and pieces and held together with paper clips and rubber bands. There's a long way from that to a professional product and judging by what I've seen of High Fidelity, they are still at the hobbyroom level.

[Pamela Galli]

Chinrey, what is the 3/4 face mesh LOD bug and the mesh map bug?

In this very forum Charlar promised the mesh documentation I whined about all the time -- and then was let go.

I am sure if we forum merchants wrote the history of the marketplace and commerce team, it would be mostly new information to those working on it.

[ChinRey]

---

Pamela Galli wrote:

Chinrey, what is the 3/4 face mesh LOD bug and the mesh map bug?

---

When LL added mesh to SL, they didn't write rendering code optimizes for mesh, instead they did quick-and-dirty modifications of code for various prim shapes. So, as far as the viewer is concerned, a one face mesh is a ditrorted sphere, a two face mesh a distorted hemisphere and so on. Unfortunately, they forgot to update the map software so on the big map meshes are represented by the prims they are based on rather than anything resembling their actual shape. They also overlooked the fact that cylinders have considerably lower LOD than other prim shapes and three and four face meshes are based om cylinders.

 

---

Pamela Galli wrote:

I am sure if we forum merchants wrote the history of the marketplace and commerce team, it would be mostly new information to those working on it.

---

Yes, probably. That would explain a lot.

Of course, with MP there is also the language barrier. For some weird reason the MP software is written in a completely different programming language than everything else at LL.

Imagine an English author being told to write his next novel in German even though he doesn't speak a word German. That's the challenge the Lindens who wrote that code to start with had to face.

Then imagine an editor who doesn't speak a word German ether, being told to proofread that novel. That's the challenge the current MP programmer(s) has to take on. It's a miracle it works at all really.

[arabellajones]

The flaws I pointed out are relatively minor, more library management than actual programming.

And if the Marketplace code was written in a different language, so what? You hire programmers who know the language. There are people still working in COBOL for instance. That skill isn't as common as it was, but they're out there.

But what I am hearing suggests that I would be a fool to have any great confidence in Project Sansar, because it looks like a rather poor competence in the higher management.

[ChinRey]

---

arabellajones wrote:

And if the Marketplace code was written in a different language, so what? You hire programmers who know the language.

---

That would have been the sensible thing to do, yes. But not LL's way. They just threw their C++ programmers into the deep end of Ruby.

 

---

arabellajones wrote:

But what I am hearing suggests that I would be a fool to have any great confidence in Project Sansar, because it looks like a rather poor competence in the higher management.

---

Not necessarily. The current LL leadership seems to be of a completely different caliber.

[arabellajones]

It's always easier to fire things of the right calibre...

(Sorry...)

Programmers are not things.

Neither are users.

I am not a mushroom either.

 

[Theresa Tennyson]

---

arabellajones wrote:

I don't know if it is relevant, and some of these errors are plenty old enough, but I see that the Wiki has been locked down, for security reasons, for most of this month.

What I am seeing is rather fundamental ineptitude, not getting the documentation finished.

I'm not the Second Life equivalent of a Kremlin watcher,

but I can't think of any well-known programmer-grade Lindens who have been around here as long as I have. If they don't even have internal documentation for the code that would be dreadful management, and I have heard a few stories from the days when Viewer 2 appeared.

And user-created content with poor documentation... It explains a lot.

---

You're also not very self-aware.

[arton Rotaru]

---

ChinRey wrote:

---

When LL added mesh to SL, they didn't write rendering code optimizes for mesh, instead they did quick-and-dirty modifications of code for various prim shapes. So, as far as the viewer is concerned, a one face mesh is a ditrorted sphere, a two face mesh a distorted hemisphere and so on.

---

FWIW, tying prim shapes to mesh has been done deliberately. The reason was simply to prevent non mesh viewers from crashing when a mesh came in view. Because these viewers didn't know what to do with mesh assets. So they got something to render they knew, instead of crashing.

Thinking of how hesitant users were to update their viewer of choice at that time (much more hesitant than they are today), it was probably a wise decision after all.