Wiki Wiki Wiki

As a person with no coding experience before LSL, I will strongly disagree with the above sentiments.

"BAD:
llSetColor(vector color, integer face);"
"ALTERNATIVE GOOD:
llSetColor(<fRed,fGreen,fBlue>,iPrimside);"
Let's switch that around. The first works just fine and the last is horrible.

There is no one in charge of the wiki and there never has been. Strife is not receiving a paycheck and nither are the other contributors. There is no editor, LL will never jump in there and do it and anyone is welcome to do it themselves. It is really bad form to pop in and state that you do not like how the wiki is but refuse to do it yourself. Where have you been the last 4 years? It wasn't helping people learn here in the forum or by contributing to the wiki. This would seem to indicate that you would not have helped with the wiki, no matter what format.

If the wiki is so bad and so unreadable how come there are so many just like me who have learned their very first scripting language using it and have gone on to learn others? When learning those other languages I wished several times that I had something as accessible and readable as ours.

Seconded.

Jesse, Eren has made efforts -- though I'm sure you're not saying he hasn't. I'm always leery of any posts that start off with "As a person..."

I third this statement, as I've said before. Part of coding is learning how to write readable code, then optimize if so desired. A new person is going to have lots of trouble, be asking questions, and under the ALTERNATIVE GOOD part, you will see a lot of:

llSetColor(<0.5, 0.653, 0.123>, ALL_SIDES);

where as, for a new person and easier to walkthrough code for new people AND experienced people (try walking through huge code sometime with no variable reference)

vector color = <0.5, 0.653, 0.123>;
llSetColor(color, ALL_SIDES);

is not only easier to read but easier to debug. By putting as your front instance of a function with llSetColor(<fRed, fGreen, fBlue>, iPrimside), that is how people will learn to code, instea of saying ANY vector can go into llSetColor. (which is a bad example since it's a restricted vector anyays).

For those that know calculus, you learn how to take limits first, then you learned the long form of a derivative, before you learned the short cuts. This is much the same, you are learning what types the specific function takes, and then narrowing it down.

Overall, it's all encouragement. If you want to learn to actually script, and how to read a script, you need to know the variable types available, and by having llSetColor(vector color, integer side), that not only tells the "techies" exactly what it does, but tells a new person, ok, I need a vector, and I need an integer. If the need to know what a vector is, click on the nice hyperlink right there for a vector.

Overall, the problem is llSetColor(<fRed, fGreen, fBlue, iPrimside) is not a reference at all, it's an example. So the real question is, do you want a function to display an example or the reference first?

Actually I am saying that he hasn't. Examples please? I don't see anything in the different libraries or a personal SL wiki page with examples. I haven't seen any posts helping someone new learn the basic concepts. And he has stated that he has not and will not help with the wiki. Even if the excuse could have been applied to the old wiki, it can't with the new wiki. It is one thing for a person who does not know how to script to come into the discussion and state that they wish the wiki was a little different. It is quite another for a person to come in and state that they have a background that could have made the new wiki much easier to use for new people, but they refused to help. The new wiki was a blank slate and people were begged to contribute.

And as to the leery part. He is stating his perspective as a person with a background in technical writing, correct? My perspective comes from a person with no previous experience. What is the difference?

Sigh. And that's the end of this thread, with the personal attacks now starting.

Calling my two posts personal attacks is an attack in itself, especially with the "Sigh" thrown in. Lets be clear, my posts are directed at anyone that wants to come in and say "I could have helped, but I refused". I like so many here worked hard at learning LSL. Yet so many of us have then gone on to help others learn also. Seeing ANYONE state that they are uniquely qualified to have made the process of learning LSL much easier for me, but they didn't is like a slap in the face.

@wiki stuff
my concern isn't bloat, it's the amount of work to apply all this user friendliness, I personally think it's a wonderful idea, if we can hash it out and get people to support a common style that achieves it. (prim parms page is actually being looked at for changes and reordering see Strife's previous post on it. that's just the beginning, I've hated it for awhile too, but didn't have the time to dedicate to it)

@remainder of wiki relevant stuff:
while I do agree that a singly managed and written scripting reference would be nice, the fact is we just don't have that. LL has put ~0% effort into the LSL Portal, past hosting it (and then only after it's original host was going down) and adding the <lsl> rewrite engine (which was essential just a plugin, granted a HIGHLY APPRECIATED one, with thanks to the Linden that wedged it in)...

What we DO have are a volunteer staff, made up numerous individuals, who get no direct benefit from the time they put into it. just pure hobbyist passion.

and this is why we use talk pages to discuss changes, so that everyone can get a general consensus, and go from there as a group effort. Most SL wiki editors are fairly flexible when it comes to following the consensus because they know everyone's a volunteer.

However, I don't see it as productive limit who can contribute to a volunteer community maintained resource, or to suggest that extremely prolific volunteers abandon their efforts. USEFUL is to talk with everyone involved and get a majority consensus, so that volunteer efforts can be coordinated and consistent.

now if LL at some point chooses to refine or change the format to something that is directly manged and written by a specific group, that'll be up to them. in the meantime what we've got is a wiki. anything different would have to be built from the ground up, with the hope that LL might host it instead... and I don't see too many volunteer to do that for free.

noteworthy, but skippable
I was writing to my audience (ie you) Whom I assume can understand tech speak =)

and yet if they do, they'll wonder why they are getting weird errors, because colors don't go to 256, they go to 255. even in sl (open the color picker if you like). then they get frustrated because there's errors and impossible colors, or colors that don't match any other program... 128 / 256 is meaningless you might as well say 75 / 150, because there is no color 256 it doesn't exist. and .5 as a float doesn't represent the color value 128 it actually represents 127.5 and heaven's know how that's interpreted by the graphics card.

code that doesn't produce errors is much less masochistic than code that does. better to be right the first time, and have to explain why, then to have it wrong, with no explanation of the errors. this frustrates new users.

wrong answers from scripts are NOT user friendly. now if someone wants to use it for a simple "in my head" calculation of color, that's fine, it's convenient and useful. but programatically, we need accurate information for the wiki because it's a programming reference (the approximate SHOULD be listed, as a note of convenience).

as a small for instance, someone had mislabeled ~ as the one's complement operator, when it is actually a TWO's complement operator. now as someone that knows the difference, I thought it useless for my purposes until I found it was just mislabeled after which it was VERY useful. a person that didn't know might look up what that means, and then wonder why it was giving results that didn't match the expectation. incorrect information that leads to unexpected results is bad for everyone (it STILL needs a proper user friendly description, I'm getting there)

actually I was referring to the internal code, they shot themselves in the foot on that one, since the rendering is where it mas to be converted internally (by the viewer) (and I don't think it was Corey that designed the prim property specs, so I can't pin any blame there)

Rather than our debating what might be helpful to the great unwashed masses of neophytes and dabblers, I posted a poll over in the group of non-scripters who hit me the most to squeeze in a script for them: builders.

http://forums.secondlife.com/poll.php?do=showresults&pollid=2879

So far, the option with the most votes is: "I like it just how it is, but more examples please." Mind you, early days yet, just 5 votes in. And my allowing for multi-choice picks is leading to some people picking conflicting options, but never mind :}

If you had read my past posts Jesse, you'd already have an answer to these questions. As it stands, looks to me like all you're wanting to do is pick a fight... drama in which I have no interest. So you'll excuse my ignoring further such rants.

I'm not going to try to guess what Eren has or hasn't done vis-a-vis the wiki or helping others. because we don't know what other names are being operated under. I can say that there are very few content edits in the wiki under that name, but that's not a telling feature.

I must have missed him saying he refused to help, I surely can't find that. however it really doesn't matter, as he pointed out, and Strife stated in the beginning, this is a FEEDBACK thread, the more ideas the better. popular ones will likely be discussed in depth as how or if they can be implemented by the editors. lack of discussion or interest in working on it generally means it'll default to whoever wants to work on it.

Strife is actually no more in charge or the wiki than any other editor. the general consensus has been to defer to Strife as the one who actually puts in the time to do all these things. as such Strife is essentially the community nominated lead editor, and while I haven't always agreed, my respect for that kind of volunteer effort means my disagreements stay on discussion pages unless/until there is a more universal consensus (which Strife has generally either agreed with directly, or conformed to from community respect). should some one else desire to put in the time, I'm sure they'd receive similar deference.

@"as a person who..."
a relevant point, being that LSL was Jesse's first scripting language. negating that downplays what new users experience, which I'd think would be anathema to a discussion of user friendliness.

tl;dr?
Ideas are useful here, regardless of previous contribution, and ALL relevant input should be welcome. can we please get back to that?

Looks like more talk of insults than insults..

Y'all aren't silly enough to spam Strifes thread, are you?

Void, I agree with your entire post in principle and concept. Yes, a lot of work has gone into the LsL Wiki. Yes, it's volunteer based. Yes, Linden Lab has put about 0% effort into something they should have hired professionals to write in the first place. Ane correct, they're not likely to lift one finger or pay one dime to update the Wiki format.

That doesn't mean it can't be done better, even if it's found necessary to put it together, from scratch, elsewhere. Mind you, I'm not saying we should do that. I am saying that the techs need to get their heads out of their tails and realize the people in general don't like the LsL Wiki, don't understand the LsL Wiki-- and stop insisting on doing it their way because they're techs and they like it just fine.

If all they want to do is leave the Wiki the way it is... then why even post this forum? Reminds me of the Lindens blogging and asking people's opinions... then ignoring those opinions and doing what they want anyway. ; )

BTW Void, thanks for standing up for me. You're right, I never said I refused to help. It's obvious from my lengthy posts here that I'm trying to help. There's aways someone who's willing to bring drama and trolling into any forum... and twisting the facts usually comes as part of their game. Nothing new. They have their opinions and anyone who disagrees with them is automatically wrong and singled out as their personal target. Nothing new. LOL

Forgive my own attitude here. I enjoy a good-natured jab or barb and humor, but when a thread starts degrading into personal areas (so what have YOU done anyway?), I grow tired quickly.

Jesse, if you want to see what I TRIED to do on the Wiki, check out the Newbie Notes under llSetColor. That was my creation. What happened to that idea after that? The amount of effort and hassle and head pounding that was required to accomplish even that one post made me not want to spend time in further such effort. I was new to the Wiki and instead of helping out an enthusiastic contributor, all I got was looked down on and everything I posted completely changed by others. No one needs that kind of frustration when volunteering to help.



Ahem... what "weird errors"? Can't think of any right off hand... and I've been scripting for a time now. Consider please:

Black: 0 / 256 = 0
Dark: 64/256 = .25
Medium: 128/256 = .5
Light: 192 / 256 = .75
White: 255 / 256 = .996

So in every instance except pure white, the answer comes out acceptably precise, and even 255 won't result in an "error". If they want absolute, pure white down to the 1,000th decimal level. then they can code it in there prior to the conversion:
if(value==255){value = 256;}
or...
if(value => .996){value=1;}

BUT, case in point, I wasn't speaking in my example of people coding mathematical values of color changing into their program. I was speaking of doing direct color conversions by hand to plug into their programs. In such instance, dividing by 255 will yield far more "glitchy" results than 256... across the entire spectrum... at least as far as coders are concerned. yes, dividing by 256 will have a technical logical error in the ten thousanth decimal place. That really doesn't matter when setting the llSetColor statement.

IF you're talking math, then consider:

if(colorvalue==.5) will come out wrong if you divide by 255.
It will come out accurate if divided by 256.
Trying to say "if(colorvalue==.49967)" is going to create a whole kettle of worms.

I'm not saying you're wrong. I'm not saying I'm right. I'm just pointing out two differnt logic concepts in handling the situation. Frankly, I think that coding .25, .5 and .75 is far easier than coding .24799, .49672 and .74938... especially since the human eye and computer monitors can't really tell the diffrence.

Your method is deep-tech correct. My method is user friendly. Either one will work. I like 256 better for most purposes.

But your point is valid: folks should probably be informed of the advantages and disadvantages of using both methods. Myself, I've always used 256 and have never had any color coding problems at all; I just allow for the 1,000th place error in the case of solid white.

Lazink:

If you personally believe that:
vector color = <0.5, 0.653, 0.123>;
llSetColor(color, ALL_SIDES);

is preferrable to:

llSetColor(<0.5, 0.653, 0.123>, ALL_SIDES);

then we'll just have to respectfully disagree. To me, that's a case of making the program more complex, using up preciously limited coding space, and causing the system one more coding step and an additional variable tracking in the process.

If that value is used repeatedly throughout the program your coding example may have merit. If that value is repeatedly mathematically assigned throughout the program, your coding example has merit. Otherwise, it would just be an unnecessary step.

I was discussing direct assigning of a color value in the function; you're discussing prior assigning of a variable value with apparent intention to change throughout the program. I don't see what that has to do with describing the syntax of the llSetColor function in the LsL Wiki.

Not trying to pick a fight here. I am extremely passionate about helping people learn thou. I have never been very good with words or instructions, preferring always to teach by example. This is why I post scripts and snippets, they speak much better then I ever could. This being said, if I personally felt that 99% of the scripters hated the wiki then that would have had my full attention instead. If my edits were overwritten and I could do a better job then I would have started my own wiki. There was pleanty of opportunity for that on 3 occasions. When LL pulled the wiki, when the wiki was so very hard to reach for months and when the new wiki was created. Everyone would have been more then glad to jump in and help.

I believe that there will be good come from this conversation. But since I will not be editing myself and concentrating my efforts elsewhere I had not joined in the conversation. Maybe I misread the posts but I do not think so. To me someone was stating that all of the conversation here is worth nothing and that no matter what we decide the wiki will never change. I dispute that notion and any attempt to portray the work and the countless, thankless hours that people like Strife, Talarus and others have sacrificed as "despised" by the majority.

The wiki works, myself and many others are proof of that and can be made better. All it takes is people doing it instead of saying it is hopeless. This is what my "rant" is about, it is not about attacking one person, only the ideas presented.

Now as to the wiki itself and what i feel would be most helpful; That is simple, "a picture is worth a thousand words", example scripts, example scripts, example scripts. A concise, clear example can be posted by anyone and I can not imagine it being edited out.

EDIT: Footnote There is still respect even in disagreement between people that do help others. Chaz and I had the opportunity to chat a little tonight. We may not agree on everything but he and anyone else that has stepped up to help others in whatever fashion they can will always be held in very high regard by me.

A personal observation here:

What I'm seeing above is a number of people who are saying "Yeah, the Wiki definitely needs a change of format"... and on the other side those who are saying "No it doesn't. I like it just the way it is."

The major difference in this, is that one side is saying "This is really difficult to understand. It needs to be simplified." Whereas the other side is saying, "I like it perfectly fine and if you find it difficult to understand, tough."

The reality is that under the format I and others are suggesting, almost everyone will be able to use and understand the Wiki. But under the current format, people will still be complaining about the Wiki from here on out.

So you people choose. I've made my point, I have other things to deal with on SL

(Yes Jessee... I do have more things on my slate than volunteering to do Linden Lab's work for it free of charge... and no Sindy, I'm not going to get dragged into standard who's-trolling-who debate .

I appreciate your position Jesse. I agree in principle. But I also have seen first hand how the LsL Wiki operates and I (along with thousands of other people) simply don't like it. I'm not insulting the efforts of others (in fact, I believe I've applauded them). I'm just giving my opinion and feedback on the current (and long-continuing) state of the LsL Wiki.

So you folks argue it out from here on out. The points are made; you can take 'em or leave 'em. Then let's see what kind of condition the Wiki is in a year from now. I know what kind of condition it was in last year when I first made my suggestions on the JIRA. It's in no better condition now than it was then. So you folks battle it out. I have spaceships to build and script. Have fun.

It's unfortunate that you see it that way, what I've seen in all of this is that you have some people who are asking for dramatic changes, in format and everything, while others are saying that the format works, but the examples and explanations are often confusing and written in "techie" speak.

I will admit, I fall under the latter. I find the quick reference at the top with the proper syntax of LSL fine, and a quick explanation of each function variable. I do think better examples can be written, and "dumbed" down, but I don't think a drastic change in function heading is called for at all.

As to my example, I wasn't going for optimization at all. I was going for what would be easiest for a cs101 student to understand and debug. As I said in my post, trying to debug, or run through code that has stuff embedded in functions when it doesn't have to be is time consuming and a headache, hell look at some of Void's stuff, he uses little tricks that take a while to wrap one's head around, without his comments (which I know he hates doing, as we all do) one gets lost easy.

hahahaha Fortunately Strife does not wiki like he scripts. Took me a year before I could read one of his.
Now I have to force myself to comment. I try instead to make sure the variables are named in such a manner as to be self explanatory. When it comes to reading code here now, I find myself sending some of the more verbose ones through a whitespace stripper just so I can see the code itself.

Jesse meet Eren.... Eren meet Jesse.....

Intelligent, caring and damn fine people both of you :}

/me gets more ice for another top-up :}

To further reinforce what Lazink said, one would assume that the majority of page views are for reference rather than tutorial, in other words most of the time people are refreshing their memory and require precise and accurate information as quickly as possible. Tutorial and anecdotal material belongs further down where it does not obscure the reference material.


The two alternate examples you give, make little sense to me.
Your first example provides the argument types but no information as to what the arguments do. Your second example gives meaning but no type, and please spare us from the horror of polish notation by proposing fRed, iSide etc.
Furthermore, even an experienced coder approaching LSL for the first time never mind a raw beginner, would be completely thrown by the < and > in the arguments list.

Not only is
llSetColor(vector color, integer face)
precise, it is the only one of the three alternatives that accurately specifies that the function takes a vector. By not actually specifying this in the examples you gave, you completely obscure this useful concept.


Actually it does matter completely, programming is about being precise; so knowingly imparting incorrect information is wrong. 256 may be close enough most of the time, but it is nevertheless WRONG.

Whoops. I just gotta challenge that assumption even if the speak is literate enough to use the word "one." (grin) The Internet is so full of assumptions and guesses, I always reckon that the last thing it needs is anymore. Why not ask LL for stats instead of guessing? (then we can guess from stats, hehe.)

Reference first please, then the technical description (for the codies who know what they doing and just need a quick lookup) And then commented examples and textual descriptions that help to explain it all to us less knowledgeable people.

I just like to say that I am very happy with the people who do provided the code example scripts. They all pretty much follow the same written style, naming and spacing and stuff like that. Is very good and it makes them much easier to understand and learn from. Thanks =)

@thread stuff

I don't think this is what's happening though, else there'd be no point in this thread existing. Strife is tech oriented true, but it's been lack of specific feedback, not ignoring of it, that has put the wiki where it is: a marvel of organization, but very tech oriented)

@color conversion

1.0 * 256 = 256 <-- try to get that color somewhere, is it ultraviolet? =)

conversion outward matters A LOT in color matching. come to that it matters a lot on the inward conversion too. accuracy definitely counts in those.

this occurred to me as being your point while writing my previous post. I made the point of distinction because you used it as example code to portray in a function page. but it's why I noted it at the end because it IS useful shorthand.

less convenient to write? harder to mentally calculate? most likely. glitchy? uhm, no.


actually it's a ~4 thousandths, which translates into a a complete number jump of +1 on outward conversion.

but programatically you never have to deal with fractions anyways, since the computer is doing all of it for you. you just plug in the upper limit and poof: divide down to get the SL float range, multiply up to get the common color. (#/255.0) is good shorthand too, more accurate AND doesn't give you any oddness on reconversion.

and in all truth, color numbers are indexes, not ranges (at least as handled by computers for display )
extreme mathematical illustration:
["0", "1"]
encode index to float [0.0, 1.0]
0 / 2 = 0
1 / 2 = .5 ??
decode index from a float [0.0, 1.0]
0 * 2 = 0
.5 * 2 = 1
1 * 2 = 2 (bad)
now try it with 1 as your range...

Footnote: I completely agree that it's good shorthand, however as a tetrachomat I can generally see the difference (darker ranges are harder than lighter ones). and the color picker on the computer can too. =)

@personal
I stand up for any fact, and having known Jesse a while, I guessed a statement may have been misread (or I missed it)... however, on a personal note, you dropped yourself a notch in my eyes by using that to take a free shot back. tres non chic IMO. no response required on this part.

What does "tetrachomat" mean? Sorry, I'm limited to 9 RL languages :}

again I whole heartedly agree. however I AM satisfied if it just amounts to the heading despription as is currently done. frame of reference would be nice to have almost immediately after for things that operate in world or relative modes. (which covers almost all of the core info for most functions, making reference lookups fast.