Strife Onizuka

Five years ago LL made changes to llPassTouches and llPassCollisions. They weren't well reported. Nobody noticed until last July. Previously llPass* took a boolean (TRUE or FALSE), now it takes: PASS_ALWAYS, PASS_IF_NOT_HANDLED and the (back in 2010) brand new PASS_NEVER. That's right folks, no need for dummy scripts anymore. See: http://wiki.secondlife.com/wiki/llPassTouches History: * http://jira.secondlife.com/browse/SVC-5923 * http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/1.40 P.S. I've updated the documentation.

Wiki Documentation Technical Description We use a number of mediawiki extensions to expand mediawikis template language into being a turing-complete programming language. LL has not kept these extensions up to date. Layout is managed and driven by templates. Some of the templates are more than just lightweight scripts, they are more like programs. We use templates to inject centralized content into articles. We use inline CSS to work around not being able to edit the site CSS. #6 is easy to fix, we could use the CSS extension or just allow certain admins to edit it. This is the low hanging fruit. #4 & #5 If we are to make use of the raw wikitext (as opposed to the rendered wikitext), we have to maintain it as it is now or we loose #5. The implementation can change but the interface needs to stay more or less the same. #5 A better solution to this might be Semantic MediaWiki (a fork of MediaWiki), this is something to look into. People really don't like that content is hidden away in templates, SMW *might* resolve some of this. #3 Like #5, people don't like having to learn template interfaces. They are non-obvious. This could be addressed by a wysiwyg, or wizard based editor. A wizard might necessitate using an entirely different wiki engine. It might be possible to work a wizard into the MediaWiki editor. This would be well worth the effort to implement. #2 Updating the extensions may break EVERYTHING. I'm not actually worried about this. It just means going through and fixing all the templates. Regardless of what we do, we will need to fix the templates. #1 Since it's interpreted and not compiled, it is SLOW. MediaWiki within the last few years added a new template language that *should* reduce this problem. LL never installed it. We would benefit from using it. This of course requires rewriting the templates to use it. So to summarize the options: If we stick with MediaWiki it won't be a smooth transition. Once we get an up to date version of MediaWiki working, things should work better. If we move to a different flavor of MediaWiki it might improve the editing experience. If we move to a different or custom wiki engine we could really improve the editing experience at the cost of having to write our own wiki engine, or adapt someone elses. If we choose an infrequently used Wiki engine or write our own we open ourselves up to being hacked. Web security is HARD to get right and sticking with a popular wiki engine means we will get security updates, etc without necessarily being hacked first. The same goes for wiki extensions. To summarize the summary: The transition will be bumpy. It may involve a bunch of work for whoever does it.I will look into the popular MediaWiki forks. I think we should probably wait until December before making a decission and then not do a move until January. I would really like it if LL just reopened the wik. o_O does linking to SLU get your post deleted automagically? WTF? That is NOT COOL!

What steps would be involved in the migration? 1) A server with CPU time and bandwidth to spare. 2) Someone to maintain it and install software. 3) For us to decide what we want. (See proposals) I'll post some proposals tomorrow. Basically there are a bunch of tradeoffs and maybe no good solutions, just ok solutions. There are a bunch of things behind the scenes we do poorly. If we go our own way, we could fix them.

Alexa was categorizing the issue into the hiarchy (mobile spell check sucks). It basically means a Linden spent about 10 seconds looking at and thinking about the issue. From the perspective of if this helps or hurts the prospects, it is neutral.

About a month ago LL locked down the wiki, locking the LSL Portal as a side effect, my understanding is that it was because of hacking. If the wiki isn't unlocked soon, we will need to consider if keeping the LSL Portal on the SecondLife Wiki is really serving the communities needs or not. With that in mind we should consider migrating the content elsewhere. This is the time to also discuss and put forward proposals redoing the layout/design goals. Fortunately we can take the content with us this time. This time around we can actually do this, the content is cc-by-sa. For those unfamiliar with the history, the lsl documentation has moved several times. This isn't the first time LL's wiki stewardship has left us high and dry.

I am going through withdrawal! There are Things that Need Doing. I haven't gone this long without being able to get a fix in years, maybe it's been a decade. If this keeps up much longer I may have to find something else to do.

Hello. I'm Strife Onizuka, LSL Portal editor and scriptor. This being the start of the second quarter I come to you today to announce a new project I am spearheading, it's goal is to make the documentation more accessible to a larger portion of the SL community. Long have we struggled with how to make the documentation more accessible. One of the most common complaints is that is simply too technical and we are hearing this more often than you would believe from one of SL's more traditional content creators: descriptive writers. So I am proud to announce that after many sleepless nights we have come up with a way to address this. As the core problem is that the documentation relies upon very specific, technical language we have come up with a way to bring more mundane verbiage into the documentation. To achieve this end we are announcing the LSL Portal Poetry Project! The goal of the the LPPP (or LP³ as I like to think of it), is to provide poetry for every LSL Event, Function and Constant. More specifically, the form of poetry we have chosen is Haiku. Screen realistate being at a premium haiku requires the minimum amount of space while packing the greatest metaphorical punch. To illustrate, here is the haiku for llParticleSystem: Cherry blossom sprites alight upon fickle breezes to fall through the ground.For myself I had to had to have this haiku explained to me. It's writer explained that the literary expert will be able to extract with great ease the following incites: Particles in SecondLife are traditional 2D sprites often seen in may games.That SecondLife not only has wind, which is a bit capricious, it has a full blown weather simulator.That the particle system has no notion of clipping; particles will go through solid objects, including the ground.The writer has a tabby that likes to sleep on the keyboard.As always the LSL Portal needs volunteers. To give you an idea of what we need, some articles already have poems. You can find a list of them here: Articles with haiku If you would like to help with this project, here are a list of LSL articles in need of haiku: Articles in need of haiku If writing haiku isn't where your strength lies (it sure isn't mine) maybe consider writing examples or just generally expanding on what has already been written: LSL Articles in need of an example For those interested, the runner up to Haiku was Limerick but we had trouble rhyming anything with llSetLinkPrimitiveParamsFast.

Hello. I'm Strife Onizuka, LSL Portal editor and scriptor. This being the start of the second quarter I come to you today to announce a new project I am spearheading, it's goal is to make the documentation more accessible to a larger portion of the SL community. Long have we struggled with how to make the documentation more accessible. One of the most common complaints is that is simply too technical and we are hearing this more often than you would believe from one of SL's more traditional content creators: descriptive writers. So I am proud to announce that after many sleepless nights we have come up with a way to address this. As the core problem is that the documentation relies upon very specific, technical language we have come up with a way to bring more mundane verbiage into the documentation. To achieve this end we are announcing the LSL Portal Poetry Project! The goal of the the LPPP (or LP³ as I like to think of it), is to provide poetry for every LSL Event, Function and Constant. More specifically, the form of poetry we have chosen is Haiku. Screen realistate being at a premium haiku requires the minimum amount of space while packing the greatest metaphorical punch. To illustrate, here is the haiku for llParticleSystem: Cherry blossom sprites alight upon fickle breezes to fall through the ground.For myself I had to had to have this haiku explained to me. It's writer explained that the literary expert will be able to extract with great ease the following incites: Particles in SecondLife are traditional 2D sprites often seen in may games.That SecondLife not only has wind, which is a bit capricious, it has a full blown weather simulator.That the particle system has no notion of clipping; particles will go through solid objects, including the ground.The writer has a tabby that likes to sleep on the keyboard.As always the LSL Portal needs volunteers. To give you an idea of what we need, some articles already have poems. You can find a list of them here: Articles with haiku If you would like to help with this project, here are a list of LSL articles in need of haiku: Articles in need of haiku If writing haiku isn't where your strength lies (it sure isn't mine) maybe consider writing examples or just generally expanding on what has already been written: LSL Articles in need of an example For those interested, the runner up to Haiku was Limerick but we had trouble rhyming anything with llSetLinkPrimitiveParamsFast.

Perrie Juran wrote: I'm not sure if this comment was aimed at me because I was really the one to say something. I've gotten burned a couple of times when making a case for something based on statements in other parts of the Wiki. One of the times was on an important policy issue. It was but at the same time it wasn't. I've heard others say similar things in the past and it's taken me some time to figure out just where I stand on all this and I felt the community at large would like to know. I've seen people get burned (very badly) for making bad edits to LL Official content. For the love of King Philip, if you ever want to edit something LL Official on the wiki, discuss it on the talk page first. The LL Official namespace Lindens do not mess around (I don't think they entirely get the wiki concept). I do get that some folks are no better at documentation writting than I am but I haven't let that stop me. I am mostly interested in technical content. I spend alomst no time on the Notes or Examples sections, you can put as much non-technical content as you want in those sections (within reason, no War and Peace please). If you think the documentation needs a new section or subsection we can discuss it on the wiki on my talk page(just click the "+" tab).

I am not offended at all by any dispariging remarks made about the quality of the documentation. There are a lot of things I could do to improve the wiki. They would take a lot of time and effort. Alas I am a volunteer with limited time and being unpaid, limited motivation to tackle the hard projects. My current project is a category system for similar parameters (since parameter restrictions essentially describe what in other languages would be a derived type), which has the advanatage of dragging me through just about every function article. As I go through I make small changes. Actually we are The Official documentation for LSL. Sort of like Hilton is the official hotel of the Olympics, that doesn't mean Hilton speaks for the Olympic Comity. How did we become official? We asked. Why did we ask? We figured that LL would be more likely to contribute if we were the official documentation. We were right. Official? Yes. Definiative? No. Accurate? Not always. It wouldn't be our continuing mission to be accurate if we had already acheived it. To summarize: The documenation sucks. So come help us fix it.

Hi, I'm Strife Onizuka and I volunteer my time on the LSL Portal, the official documentation of LSL. We are currently trying to decide if we should be using PUBLIC_CHANNEL or Zero as the value for chat functions. We have a poll over at: http://www.sluniverse.com/php/vb/scripting/91061-wiki-public_channel-vs-zero.html Basically would you prefer to have all (every last one) of the examples say: llSay(0, msg); or llSay(PUBLIC_CHANNEL, msg); Many of the veteran users already know this but it's been a while since I've proselytized. The LSL Portal, the Official documentation of LSL... is open to all users to edit. That is right, if you don't like the wording, if you know something that isn't documented, or you think an article needs a better example, you can edit the documentation. Please edit the documentation. If you don't feel comfortable editing a page or just want to leave tips, advice or questions, click on the discussion tab for the article and leave a note there and someone will try to integrate it into the article.

Qie Niangao wrote: Ela Talaj wrote: It seems logical to firstly specify what a method returns (type) and then secondly what the returned value means in the content of the method. But as I understand it, the function signature will still look the same, and does exactly that: Function integer llGetAttached( ); It's the text below, describing the method's return value that's affected. Returns the attach_point (an integer) the object is attached to or zero if it is not attached. At least, that's how llGetAttached() currently looks. Strife, I'm probably misunderstanding, but it seems to me that you're going to extra work here, defining a mapping of a nonce term (the parameter name) to a convention (a subtype name). If the parameter name isn't the same as the subtype name, is there a reason not to just change the parameter name to match? Or, hmmm... yeah: there could be a function that takes two arguments of exactly the same subtype, and they would have to be distinguised by different parameter names. Still, it's kind of ugly to repeat the same word, once as a parameter and once as a subtype, when the names do match. I'm not going to touch the signature. There is nothing to be gained by changing that (... further, it has changed over the years, like the bug Icon on the end, do people like the bug icon? do they find it useful? I do wonder about these things). You understand correctly. As you point out, a function may have multiple parameters of the same type. Or due to convention some functions use agent as the parameter name, and others use avatar. I've really tried to reduce the use of "agent" but it's hard (there is no good reason in the documentation to have both terms floating about, it just confuses things). I'm with you about repeating the words. I really don't want to waste screen space with whitespace or worse, empty words (no added meaning). I really wanted the table to look reminiscent of variable declarations. Thowing the subtype in there with the type and the name breaks that. I really don't want to change that and I'm willing to throw the parameter category project under the bus to make that happen (the ideas overlap but not 100%). Maybe the solution is to put the parameter project in Deep Notes. I think that is the best solution. I think thats what I'll do. As to the return text, I'm worried that subtype forking is going to result in user unfriendly names... I'm contemplating nice names for the names but I don't want to do that lest it be abused. Argg. I'll burn that bridge when I get there. Did I ever say, I'm bad at naming things? Despite my apparent negativity, I'm really positive about this project and where it is going. Your input and everone elses is keeping me on the right track.

I've completed the initial phase of the project, though I've run into a little problem. Following the theme, I've done llGetAttached & llAttachToAvatar to showcase the feature. Please also take a look at the subtype category page: Category:LSL_Integer/attach_point Nothing is final at this point, especially not the Template:LSL_Subtype_Category or the content in the category page. ---- I couldn't figure out a good looking way to do both parameter categories and subtype categories (in the parameter table), so I've got subtype categories usurping the link for parameter names. I'm at this point viewing parameter categories as Version 1.0 of this project and something that should be killed off (it's not something that was ever fully rolled out). But I still want to give parameter subtypes more visibility within the table, you get the link to the subtype but you don't get to see the subtype name right now. Any ideas on how to change the parameter table layout to make the subtype more visible? Subscript for the subtype next to the type? integer(attach_point) attach_point - where you want to attach it. Or maybe at the start of the description? integer attach_point - attach_point: where you want to attach it.

Hi, Strife here, I maintain and improve LSL Documentation in my free time. I'm contemplating a change in the wording of the documentation. Additions to the documentation I would roll out with little or no input from the community but this being a change, and a change to the "return text" I wanted to run it past the community y first. The "return text" is the sentence in the description that describes what the function returns along with the return type. The sentence is know for it's awkward wording and the third word being the return type. An example would be: "Returns an integer that is the attach point the object is attached to or zero if not attached." I want to change this to: "Returns the attach_point (an integer) that the object is attached to or zero if not attached." So why do I want to change this? Organization. One of my projects has been to categorize articles together that share common parameters. This lead to the epiphany that these parameters are really subtypes of the major type and that is how the functions should be categorized. The issue is that it only categorizes functions which take parameters but doesn't categorize functions that return those subtypes. This project solves that problem by allowing the wiki editor to supply a subtype for a function's return value. Parameter names will be interpreted as subtypes by default. The only hang up is that this is a core feature of the documentation that has been in place since it was written. The main reason for the weird wording is so that the return type is always in the same place, the third word, so it's easy to find. This would maintain this while allowing for more flexibility in the sentence structure. I'd appreciate everyone's input on this. If you have questions, I'll try to answer those too. About me and how you can help improve the documentation: When it comes to SL I mostly work on the documentation on the Wiki (do not IM me inworld). I see my job there as an editor and librarian. Most of what I do is to make sure that knowledge that is poured into one articles finds it's way into related articles in the appropriate places. I also import knowledge to the wiki and I source it from scripts, the forums, wiki articles, and bug reports (Jira). The fastest way to get knowledge into a wiki article when you don't know how to add it is post it to the target article's discussion (talk) page and if we can figure out how to post it, we will. If you have questions don't hesitate to ask. We value our contributors and editors; we welcome you to join us.

Thank you all for the responses, they are helping. RE Dora Gustafson I like the idea of a comment section (I wish the templates were shockingly simple but I think to implement this it could be made really simple). RE Kimm Paulino For an experienced user the rating will be nothing more than a confirmation of what they alread know. The rating system is a bootstarp, it gives you a flavor for the article before you read it, and will link you to an explanation (maybe even an introduction) to the topic. RE Ela Talaj I won't deny it. Fish out of water, thats me, but I think I'm past the gasping phase. This isn't something that happened over night, more like a fish evolving legs. If you know any technical writers who will work for free, please have them submit a proposal (rewrite llSetTextureAnim lets say). Here are the LSL Portal requirements and things to look out for: We have an ever changing language which is not nicely versioned (nor the changes completely documented). The documentation is only useful if it is relevant, it must incorporate bugs and gotchas as they evolve. It has to be technically complete, it is the official documentation after all. The users want a quick reference and a detailed reference. The users are new and old users. It has to be accessible. We have requirements that seem to compete with each other! The hardest requirement I have found is accessibility.