Wiki Wiki Wiki

most people have 3 types of rod cells in their eyes, the ones that respond to colors. tetras have four. it increases color distinction. think of it as seeing colors as a (rotation) instead of a (vector)

Haha ok, let me be more precise. For me personally, when I first started learning LSL the wiki was mainly a learning tool, however since then, it has primarily become a reference.

Unfortunately I doubt that there is a way that LL could have accumulated stats as to whether someone is reading a particular wiki page for reference or as a learning aid. Perhaps it would be instructive to start a poll in this forum?

no, but logic dictates that as you learn it you need it less and less for learning, and more and more as a reference (at least until you've used that function so much it's embedded in your mind.) I can't point to numbers on it, but my own wiki use follows this pattern.

OH! Well that makes me a mono-mat! You should see when i put on the plaid shirt with plaid shorts and think it all looks fine! People run for the tylenol in RL.

Yes I see what you mean. That be good as well.

The biggest drawback of a format like "llSetColor(<red,green,blue>,side);" is that it's not accurate. llSetColor really does take any arbitrary vector, and scripts can and do take advantage of this.

I was going to stay out of this further, but this I had to respond to.

Actually, it's quite accurate. No matter WHERE the vector information comes from or how coders may distort or abuse the vector concept, for all intents the llSetColor function still sees this as a concept of red, green and blue values.

Illustration: Your motorcycle is running at a speed of 60mph. You decide to turn that into a decimal and for a lark feed it as part of a vector into the llSetColor function so your bike changes colors with speed. Great! Fun thing. But llSetColor isn't processing SPEED... it's still processing RGB values regardless of their source.

Now I can already see some hard-core tech shooting back, "No, it's not processing red, green and blue. It's processing a VECTOR." Which would be why hard-core techs shouldn't write reference manuals. They're so focused on data they forget about the people who that data is intended for. ; )

(Which Void, is still my point on the 255/256 situation. You look at it from the standpoint of data. I look at it from the standpoint of the people using the data.)

As for the guy who nearly shouted IT'S STILL WRONG... LOL... man... chill out. I divide by 256 regularly and I don't believe anyone has yet died because of it. My code works too. LOL

Frankly, I don't care if someone wants to divide by 255. Go ahead! If they feel comfortable coming out with a figure of .49967 instead of .5, hey, more power to 'em. If they feel that the Wiki just HAS to use 255 because it's more "accurate" (regardless of the problems such causes coders in actual application), so be it. No skin off my nose. I'll just ignore 'em and continue to do it the way I know actually works in real life application.

I program for PRACTICAL applications. I've dealt all my life with techs who were so deeply focused on absolutes they'd nearly bust a vessel when someone recommended that non-absolutes might be better for the job. I've known guys with their heads buried so far in computer code they lost track of everyday reality. That's the point I was making guys: sometimes, absolute hard-core accuracy isn't the best available solution. If you don't personally get that or don't agree with it or even vehemently disagree... the sun will still rise and the world still rotate. And I'll still divide by 256, thank you very much.

Void, it really doesn't matter a rat's poot what status I hold in your eyes or whether I raise or drop a notch in your personal opinion for whatever reason. It's when people get emo and personal that discussions like this degrade into the contributors backing out and letting the ranters rant on.

Now as I said before, you folks go ahead do what you want to do; You'll pardon me if I don't waste any more hours here that could be spent on far more productive and beneficial activities. The LsL Wiki hasn't much improved over time-- people still regularly complain about it just like they did a year ago, two years ago... and I doubt that "yet another effort" to try to clean it up-- considering the debate I've seen here-- is actually going to have all that much influence on it now.

Feel free to keep the same format and add your examples and illustrations. I predict that a year from now people will still be validly complaining and have the SAME complaints about the LsL Wiki. You can't change and improve by insisting on remaining the same.

Now I really must get back to my projects. Spent waaaaay too much time on this forum. I keep promising myself to stop doing that. Forums tend to suck time away from far more useful activites. LOL

False. It doesn't matter what you think those numbers should mean, all that matters is what the function actually does. Values outside the narrow 0.0-1.0 range don't provide meaningful color values, they simply get clipped off by the viewer, but they still contain information in non-color uses.

Damn it, I go away for a day and people start talking about rewriting the documentation in Simple English... again. No, really, this is a bad idea for exactly the reason they haven't done this on the English Wikipedia (instead they gave simple English it's own Wikipedia fork and link to it like it were a translation).

http://simple.wikipedia.org/wiki/Simple_English#Simple_English

I'm not adverse to rewriting the wiki to remove unnecessary jargon but I am adverse to rewriting the wiki to remove necessary critical terminology. The reader should be able to describe the functionality with the correct terminology after reading, otherwise they cannot communicate efficiently with their peers or be able to write useful bug reports. If the terminology has been stripped and watered down... need I say more? We are in the education business, we should be educating.

But that brings us to main facet of the problem: Where do we put all this beginner information? How do we include it in such a way that is easy for beginners to find and easy for advanced users to ignore? This is the issue that is what is really in contention. This is what the fighting has been all about. The current answer to this question is as follows:
A) Newbie information goes in the Newbie Notes section. This section has been largely unused... I think two articles make use of it.
B) General information and usages go in the Notes section, examples in Examples, useful snippets and wrappers in Snippets, bugs and feature suggestions in Issues (for JIRA).
C) Function specification goes in Specification, Descriptions and Caveats (soon to be renamed if everyone likes it).

The sections are currently ordered: (if my memory serves me)
*Description
*Newbie Notes
*Constants
*Specification
*Caveats
*Examples
*Notes
*See Also
*Deep Notes
**History
**Issues
**Footnotes

The idea behind the current sections is to make finding information easy. Do you want to know what will cause the function to fail? Look in Caveats. Do you want to see an example of the function in use? See Examples. Do you want to read about the function? See Notes. Do you want to know every detail of the implementation? See Specification. Do you want to to know everything trivial and unimportant? See Deep Notes. Are you a beginner to LSL? See Newbie Notes. This layout is by no means perfect but it does try to address the main documentation usecases.

I am open to any suggestion but for it to be implemented it needs to work with all usecases.

-----

Eren has had some really insightful criticisms of the wiki unfortunately historically most solutions he has put forth haven't stood up to criticism.

-----

Eren, this isn't the first thread on this issue, I post one about every five months. I have been trying for years to get feedback but I can't force people to participate in these threads.

LOL whatever Strife. You ask for feedback and when we provide it, all we get in return is condescending attitude. Did you just ignore the folks back there that agreed with my suggestions? Regardless of your personal opinion and the opnionated claims of a handful of others, I've been writing professional manuals long enough to know those suggestions are based on tried-and-true industry standards and hold merit.

Is it any wonder more people don't respond to your forums or contribute to the LsL Wiki? Why should they even waste their time? I surely should not have.

Done. Outta here.

I'm still reading through the thread... (i'm on post 57)

The reason the format is at the top in a header is this...
First there was the keyword. Then not wanting to waist good whitespace we put variable names to give the usage. But the problem is if you are checking the usage, you don't just want to know what the variable's name is, you also want to know it's type... so it became the definition. Next came the floating text, last to be added was the prefix of the type of the keyword (Function, Event, Constant). Now it being in a header makes it easy to find.

While on the topic of how things came about... the design of the parameter description table:
During initial layouts, I found when scanning the text it was difficult to pick out the variable names from the types from the descriptions. The problem was the greatest with the descriptions, so I put everything in a table so that you could scan them vertically. If you are reading the parameter description table you already know the keyword definition, the two important pieces of information are the names and the descriptions, everything else can be a distraction. But if you are reading about the parameters it helps to know what the type of the parameter is. So it needs to be there but it can't be a distraction... so the type and the separator were made gray.

----

Eren, I posted this thread because I get very little feedback on the wiki, unsolicited or not. I always worry that I am out of touch with the peoples needs; I can't fathom how you can be so sure of what the people need. Consequently the point of this thread is to find out what the the people need and want. So when the people comment, please don't marginalize them and dismiss their comments. It's counter productive and when you do it, I'm left asking my self the question "How does he know what the people need?"

Oh and giving mass in Latin is coming back in some places... some people like the old traditions (personally, I'm not Catholic).

Because Strife, the first job I ever got out of college was conducting computer clasees... back in 1980. I have worked ever since in one form or another in the public computer education process, corporate consulting, professional tech manual authoring, computer programming, and even sales. My entire career has been about figuring out what people in general want and need-- and how to best provide it for them. I have been told throughout my career that I write exceptionally easy to understand and informative tech manuals... and I have written for a prominent computer magazine.

In addition, I spend several hours a day on SL, 7 days a week, and I regularly hear comments from people who try to use the LsL Wiki and wind up bashing their heads against that very user-unfriendly wall. I hear the complaints from experienced, full-time professional programmers who can't make head nor tails of the LsL Wiki.

If you are concerned you're out of touch with what the general populace needs-- you probably are. If you WERE in touch, you'd know it. I'm out here on the front lines, working with large groups, scripting for large projects, helping people with their scripting problems... and I hear their feedback on a daily basis.

That Strife, is how I know what people need. Add to that the people back in these posts that said "What Eren says is right on"... and I have to wonder how you DON'T know what people want and need. With all respect: maybe it's because of being too convinced that what you're doing now just HAS to be the best way... and failing to give due consideration to alternate concepts, no matter how valid and rational they may be. Maybe it's because of hanging around too much with like-minded techs instead of listening to the vast majority of the scripting or wannabe scripting populace who are less tech-oriented.

I'm just answering a question that you found necessary to state twice, that I read before I logged out of the forum. As I said, done and outta here. I'm sure you can continue on without our help and feedback. If I don't know what I'm talking about.. no sense wasting any more of my time here. I can be spending these hours on far more beneficial things than messing further with the still-user-unfriendly LsL Wiki.

(still reading, now at post #77)
Chaz, you should review his wiki contributions if you haven't already. There is a good reason why none of his edits have remained as he intended them. I don't want to dredge up this stuff though, it is Off Topic and distracting.

LOL Strife, then why DID you dredge this stuff up?

Let me ask you a question: based on your history on the forums, when are you going to stop being "critical" of other people and their ideas... and start trying to work with them instead? People don't contribute to the LsL Wiki because they get tired of being treated like second-class citizens and having their ideas summarily rejected, time after time.

I was new to the Wiki when I first contributed. A little GUIDANCE would have gone a long way. Instead, all I got was attitude... with the result that I lost interest in assisting you further. You want to know why more people don't try to assist you with the Wiki? That might be why.

So again... do the work yourself. People in general dislike the LsL Wiki and find it confusing, unfriendly and uninformative. I suspect that will still be the general opinion a year from now.

Just on the style thing using color like has been done already:

llSetColor(vector color, ...)
llSetColor(<red, green, blue>, ...)

When I read these, the first way tells me more immediately about what I dont know than the second way.

vector ??? whats a vector ??? click on word and get explanation of this. ok kool I got that. ok now what ??? Read the following explanation of how to use a vector to make colors using this function. ok.

If is the second way then I dont know what a vector is, unless is explained to me that the writer is using <red, green, blue> to represent a vector. And when they dont explain this, then they assuming I already know what a vector is.

I just find is easier when learning something new, if teachers not make these kinds of assumptions about me. Im a bit of an idiot really when I dont know what I dont know. Is really hard to learn stuff sometimes when others assume I do know and also assume that Im not an idiot.

I'm not sure I understand, could you give an example?

Man pages on the whole I despise, I'm sure there are good Man pages out there... I just haven't found them. So often they lack examples and a detailed explanation... and when you do an internet search all you find are copies of the same Man page. And they almost never describe the edge cases. There just isn't enough diversity in Linux documentation. I hate to say this, but the fracturing of the wiki community may have been a good thing: it has given the users choices. I vowed long ago to never let the LSL Portal content be as bad as Man pages (I'm sorry if parts of it are, I'm working on it).

Oh and llAxis2Rot, never had a use for it. I'm pretty sure I know how to use it, just no real idea why you would want to.

----

The debate over the requirement for accuracy is too important to be decided in this thread; especially since it would require changing the mission statement or the roles of the mission and goal statements. The mission is what we do, the goal is what we try to achieve.

https://wiki.secondlife.com/wiki/LSL_Portal_Guidelines#About_The_LSL_Portal

----

When it comes to technical writing, there is a big difference between writing books and hypertext.

I've have read all sorts of programing manuals over the years. And you will find in them bookmarks, lots of them. Usually odd bits of random paper, movie ticket stubs, wrappers, receipts, anything that is to hand. And the important thing is, I don't have to put them at the start of a topic, I can put them in the middle of a topic, anywhere I want. But with digitized documentation, it can only easily be bookmarked at the topic start... or if you are lucky and have the foresight, via a link in the articles Table Of Contents. Additionally if you want to highlight or annotate sections of the documentation, you need special software. Digital documentation is not the same as printed documentation, different rules apply.

To aid the reader, digital documentation needs to be tight and contain sufficient headings. The headings help people find their way. It needs lots of embedded links and tooltips where appropriate to aid the reader finding out what terms mean (to not do so is not embracing the strengths of the medium).

A book can be accessed randomly or in a linear fashion (flipping through the pages vs reading front to back), a website (unless specifically designed) cannot be read in a linear fashion. The author of a book can assume that the reader of the book has read the pages before the page they are currently reading, this allows them to build on the knowledge of preceding pages. Since the website has no hints of being linear the author cannot assume the level of knowledge of their readers.

Authoring digital content is different.

Solutions to inexperience of readers on websites:
1) dumb down every article
2) include newbie information in every article
3) make it clear to the reader where they can find the prerequisite information

Currently the wiki employs the second method. Eren advocates the first method to the extreme of making the documentation inaccurate.
I am more than willing to try the third method in conjunction to the second method. If it works for books it could work for us. Just need a way to work it into the layout.

Newbie content tends to meander and is a pain to distill technical information from; it is buried in paragraphs. I hate having to drudge through articles on the LSLWiki. Haven't they heard of bulleted lists?

----

color debate
Read the source, serializing colors rounds them to the nearest increment of 1/255.

----

If I could get just 0.1% of the wiki users to comment in this thread, I'd be happy. And the documentation can't be that bad... or they would be trying to burn me alive.

----

As to reworking content, I volunteer to rewrite the templates to whatever layout design the community agrees on even if I don't like the new design. But I won't be silent during the debate and I will point out the flaws in any plan. That said there is a hitch, if the template variables don't mesh, someone else is going to need to do the work of fixing all of the articles. But it gets worse, if the layout demands individual article work to be done the person to do that work must be found before I push through the changes to the templates. I will not leave the community with broken documentation for any amount of time.

In other words, unless someone commits to doing the leg work during the transition, don't break the template system with the new design. Keep in mind it's about 850 articles at this point. It's a big time investment.

My vote is for the current layout (and for more examples and illustrations). To do anything except give the syntax first - llSetColor( vector color, integer face ) - is madness. This is the same text that is given in the hover-text in the LSL editor; it immediately tells someone what the function parameters are and what the return type is and it is the minimum one needs to know in order to use a function.

Sure this will confuse an absolute newb but an absolute newb is going to be confused even by llSetColour(<red, green, blue>, prim_side). In learning any new language there are some basics that have to be understood before any kind of reference becomes understandable. Who has recently looked at a Teach Yourself Sanskrit or Arabic or Russian book? Immediately you are confronted with a heap of symbols you don't even know the sound of. Even Teach Yourself Portuguese begins with a list of pronunciations for various characters and combinations of characters.

Initially the wiki will be obscure for anyone, even for programmers experienced in other languages, because the concepts are different and the environment in which the scripts run is quite different. It is hardly surprising that there are plenty who will complain. But what is to be done? If it is an introduction to LSL scripting then it will not succeed in the valuable role of LSL reference; it can't possibly because a reference needs to be concise and accurate while a teaching manual needs to be clear and simple to understand, describing things in plain English and elucidating technical terms.

Do we really want to encourage people to script who cannot be bothered to understand scripting in depth? Doesn't that just lead to a ton of inefficient, inelegant, resource-hogging scripts? I really think the wiki should be intended as a reference first and foremost and that it should be something that beginners graduate to using rather than something that encourages people to think they know how to script because they can copy examples out of the wiki. Perhaps what is lacking is an alternate means of learning LSL and that should be addressed rather than attempting to include that mandate in the LSL reference wiki.

It is not that there are a load of tech-heads who are stuck in their arcane tradition of seeing things expressed in a formal manner: there are good reasons for using the formal syntax descriptions and those who have bothered to become familiar with the format and terms used find them concise, informative and useful. Sure it takes time to become familiar with the terms but it also takes time to become familiar with any new subject. I would be very disappointed if the current format is changed; not because I consider myself part of the technical elite but simply because it is an extremely efficient layout for reference once you understand the terms.

Let's encourage quality in scripting rather than quantity. Let's encourage people to become technically competent rather than dumb things down, with the result that those who are concerned to write efficient scripts will continue to have a most valuable reference and those who have yet to become familiar with the language will be encouraged to learn it in depth - to actually understand what they are writing, what is happening in terms of resources and side-effects, to understand why things work when they do and know where to look when they don't.

Let's face it: someone who can't be bothered to become familiar enough with vectors not to be thrown by the formal expression for llSetColor() is going to run into huge problems debugging their script or even in developing the logic to write it in the first place. Surely we can be permitted to assume a certain level of knowledge from those using the wiki, otherwise where do we draw the line?

You want me to implement it without thinking? And when push comes to shove, who will the community blame? The Sword of Damocles hangs not over your head. If the community is to be happy, critical thinking is required. Nastiness isn't, for which I apologize.

The newbie experience in retrospect is lacking. We pretty much throw people into the deep end without warning. We don't tell them that in the public space they have no personal space or property. You may own the edit, but the content is the communities. It's a tough pill to swallow all at once. I'll work on a template to include in user talk pages to introduce them to the wiki.

It's not that your idea doesn't have good bits, it does, I'm just getting the wrong type of noise from the community. I personally would be more receptive if you didn't introduce devils into the details. Does a feature proposal need a debate about 255/256? Does the syntax of llSetColor really need to done with this feature proposal? Pushing too much too hard IMO. People get bogged down in the details.

I think we might do better if we stay high-level for now. It might be a good time to attempt to refocus this thread on Strife's original questions.



And, reminder that in order to gauge if laypeople and dabblers (whatever the right expression is) have any thoughts, I posted a poll for that group of stakeholders over in the builders' forum, to which there are 19 responders so far: /8/9f/318692/1.html

@Prajna: You eloquently argue a difficult view. I don't agree but being able to serve the reference niche has always been a high priority. If the official documentation isn't a reference what will be?

(And yes, the LSL Portal is the official documentation)

My goal is to try and be both, a reference and newbie material. Reference first though... I'm not so good at writing newbie material.

that comment was directed at proposed user friendliness ideas... it's actuaully in place in the current format, I'm just saying we need to preserve that as core info if any format changes are applied. it's probably one of the most frequent lookups I do, to see if a function takes relative or region coordinates, or if they are different for my usage.

I'll assume that's on use as a display color with values limited to the 0-1 range when being displayed? or is it actually being doctored in the save (in which case I KNOW it isn't being range limited there)... definitely important to know if I decide to use color space to store other arbitrary vectors =)

I'll address this one, as I started the conversation there. it was meant as a side discussion, and only as referred to in the context of accuracy for use in an example article. my apologies if it's taken away from the thrust of the debate.

@re focusing on the main topic:
I do think that we could incorporate some friendliness with a minimum of change, just by including a more human readable example as a simplified description, but am concerned about how much work that might be (perhaps just a new field or two that can be filled in along the way).

I'm not actually convinced that following too close to Wikipedia style on technical topics is as useful to us as a community, I understand why they did it, but they are strictly an informational guide, whereas we are for a large part, an educational community, so it behooves us to bootstrap the inexperienced. I'm completely open to debate, there's a fine line between reference manual and teaching manual here that we need to explore.

being that the lsl portal doesn't fall under the same structure and support as most of the SL wiki, it's definitely something we need to consider, especially in light of available editor manhours.

It is serialized in the process of being sent over the network. Not before or after. It was a pain to find in the code. The actual conversion is done in the code for an implicit typecast that handles converting a llColor4 into a llColor4U. The only reason I had any hint it was in a typecast was that they mentioned a typecast in the comment but the code didn't have one explicitly.

I did want to back up Void on the 255 / 256 thing. It started out as a side comment on his part and turned in to what I considered an interesting debate. The downside is that it drew focus away from the primary issue... and for that I apologize as he did. But I felt he remained respectful throughout and I found the points made on both sides valid and interesting.

In the end, I came to the personal conclusion that we both tended to arrive at about halfway through... that to best serve all users, both methods would need to be presented, with applicable caveats in each. 255 is more technically accurate, 256 is more user-friendly. Like most things in this universe, there are pros and cons to each. So off-topic somewhat, yeah. But I'm glad Void and I had that discussion. It was lively and interesting and presented a truism of coding (as well as life itself): there's often more than one valid way of doing something.

And Strife... we're good. I think you just came across a little to strongly in your first return message-- but hey, we've all done that here at one point or another, me included. We all tend to be passionate about this subject.

I understand and sympathize with your stated position on the LsL Wiki. Whatever the community agrees upon as a majority is how the Wiki should be presented. And yes, before any vast changes would be made, people would be needed who are willing to spend the time in making those changes. I will admit I have neither the time nor desire to take on such a project (primarily because Linden Lab should have paid a professional to do it right in the first place... and I'm long past volunteering to do their work for them for free). So you're one-up on me in that department. I devote my volunteer time elsehwere on SL, to the direct support of specific groups. We all play our part both in VR and RL.

So under the current situation I'll simply say this: no, people aren't tarring and feathering you... nor should anyone do so. But there IS a whole lot of grumbling over the difficulty and indecipherability of the current WIKI. The format IS user-unfriendly, regardless of whatever advantages it may have. No, the ideas I presented are not out-of-line or improper; they are used in professional technical manuals world wide and have been for decades. Like I said in the last post... there's often more than one valid way of doing somthing. Your approach is technical. My approach is user-friendly. Guess whose approach in the long run would receive the fewest complaints?

I'll take the disgrutled complaints of a few stubborn techs over the complaints of thousands of frustrated end-users any day. And frankly, under my suggestions even the techs would get used to it and quickly adapt. So just saying that despite the (pardon) opinionated statements of a few people here, the method I've presentd is not insane, not ridiculous, IS industry-standard, is widely used and has been for a very long time. Sorry some folks here prefer deep-tech over usability, but that's their personal preference. Agree or disagree, I respect their right to opinion.

IF you're going to continue under the current format, then I would make the same recommendation others have made:

* Simplify the syntax as much as possible under the current concept and use terms people readily understand

* Organize the system a whole lot better (the clunky and obtuse llSetPrimitiveParams page is a prime example)

* Provide more meaningful data definitions ("the third string in the object parameters list" is not meaningful)

* Provide simplifed and valid examples, and trim the "garbage" from those examples... relegating the escoteric stuff to an external page. We don't need to know how to create and dump a data list in order to be able to send a linked message. That should be handled under list creation and dumping, yes?

* I very much agree with your statement Strife, that something needs to be done to reduce the front-end opacity of the LsL Wiki. It's semi-organized yes, but has zero flow. A first-time (or even long time) visitor is faced with a warehouse of largely arbitrarily-placed infomration without a visible starting place, without logical and immediately perceptible order or path. It's currently kind of a "shotgun effect" page that needs t be more transparent and understandable. It needs to become a "Welcome Island" with logical, perceptible order and flow. For new scripters, currently its downright intimidating.

* I would strongly recommend, as one user mentioned to me today, that you Strife take a back seat position of technical consultant and bring in a writer to do the writing. That is not an insult-- just the opposite. It is acknowledging your signifcant (and frankly amazing) skills as a tech and using those skills where they are best suited. Again: never let a tech write a tech manual. ;D I know of course, finding a qualified writer who's willing to spend the time might be a nigh-impossibility, but it's just a suggestion. Nothing more than feedback.

* At the risk of sounding personal (and forgive me if it does) when new people come to the LsL Wiki all enthusiastic and fired up to help, a little friendly guidance serves a lot better than "supreme coder syndrome". A little less judgemental... more friendy attitude and a humble, guding hand can go a long way toward keeping those enthusiastic volunteers enthusiastic. Remember that just like any newb, they're going to make mistakes, they won't have the whole picture, they'll need to be brought up to speed. Don't be condescending or poo-poo their ideas just because such are not 100% accurate. Remeber that not everyone enjoys the genius of Strife (and I mean that in all sincerity... I wish I had even half your brain power). Rather than being "critical"... be helpful. And remember... that this particular LsLWiki newb was responsible for creation of the concept of "Newbie Notes"-- despite your disagreement with my general manual-writing methods. There's something to be gained from everyone Strife, regardless of their proficiency and expertise (or lack thereof). So don't look down on newbs, even if they make mistakes and "don't get it". Encourage them and guide them instead.

Primarily, above all... KEEP IT SIMPLE. If there is one overwhelming fault of the LsL Wiki... it's never using one small word when twelve big ones will do. It seriously needs to have someone go through the whole thing and turn the technobabble into (yes) plain-english, sensible writing.

That's all I got.