User:Strife Onizuka/Talkpage Archive 01

DialogMenus Tutorial Piece

Moved to Talk:DialogMenus#DialogMenus_Tutorial_Piece.

Hello from Chaz Longstaff

Hi Strife, Chaz Longstaff here. (Wednesday, 15 July 2008.)

First of all, I want to thank you Strife for all you have done to date on the official wiki. Without you, it wouldn't be here at all. Your knowledge, skill and commitment (plus diplomatic skills and courtesy, noted by many) are a bonanza to LSL.

>> At first your edits were naive

If you mean geared toward beginners, then I take that as an immeasurable compliment :} If you mean in terms of how to use your template, yep, I'm figuring it out piece by piece as I go. As for editing, I don't mind being edited; I've written professionally all my life up here in Canada and so am used to it. When you write something, you have to be willing to let it go and let a second-pair of eyes give it a once over.

>> the quality of your edits and contributions have been constantly improving

Ah yes, I'm slowly getting the hang of your template. Its construct wasn't apparent at first. No fault of yours: anything like this anywhere in life just takes a while and a bit of effort to figure out, but if you're going to join any project, it's common decency to first understand how people have done things to date and to catch up with the procedures. I'm making the effort and grokking more of it now.

>> I would love to dialog (on the wiki preferably).

Where is the dialogue place? Is it here? https://wiki.secondlife.com/wiki/Talk:LSL_Portal_Guidelines

Just wanted to give you a heads-up that my emphasis would be on accessibility and relevance for beginners and learners. What would motivate me is adding to the LSL wiki how-to-do's, step-by-step, in readily-understood common-use language, so that even LSL dabblers can tackle in-world some scripting basics. I've just passed the initial 1 1/2 year learning hump, so I want to get down what puzzled me at the start, while it is still clear in my mind, before I become an older-hand and take all the basics for granted.

I don't think you'll object to that, though. I read here https://jira.secondlife.com/browse/WEB-658 that you feel that both (a) basic information (presented in accessible, plain old-fashioned English using good old Anglo-Saxon root words) and (b) more esoteric, complex concepts expressed in a technical vocabulary can and should have a place in the LSL wiki.

I realize that some techies may look down on "plain English", but I was taught to see it as a strength, not a weakness.

So, you don't mind my jumping in? I know you want help, and want to make the "official" wiki more than an often-disregarded cousin to other LSL wikis on the Internet (or whatever analogy is appropriate.) But it must be hard, because it is your baby, to have others come in and just "do stuff", especially adding a focus that is different from the one you have brought to bear on it so far.

Given that you not only left but added (some good stuff, thanks!) to my entry on chat, for instance, I think you're okay with that kind of approach being added onto what's there already. Just to be clear, though, if you'd rather I didn't, now's the time to sing out, and I'll happily bow out with no hard feelings and focus on other projects.

p.s. everything you've edited on my postings has been great, and muchly appreciated! Thank you for taking the time to review them!

p.p.s. I see there is a project to port the LSL wiki to other languages. I speak 7 human languages, but I think I'll see how I get on with the English-language version first before enquiring further about the others.

Chaz Longstaff 08:41, 15 July 2008 (PDT)

I want you to continue to contribute. Not just because it's easier to fix someone else's edits, but because you produce good meaty content. I have no interest in having the wiki all to my self, my goal is to have the content being the best it can be and you seem to share that. You explain things in such a way that they make sense but without going overboard on wordiness, or hide related caveats. Plain English is a hard balance, I tend to lean towards concise & technical but that doesn't make me right. I find it much easier to add content after someone has made edits to an article, it's easier to see what's needed. Some people take offense to the activity but wiki's are about the content not the contributers; I'm glad you aren't upset by it. I welcome you to review my content and make changes, we all need a second set of eyeballs.

If I thought your contributions were crap I would remove them; I have no compunction with removing bad content. If I make changes to an edit it means I agree with what I don't change; if the changes were minor then I just felt the wording wasn't quite right. If I don't make changes at all it means I agree or I haven't seen it yet (or worst case scenario that I haven't gotten to it yet).

I think it's great you are targeting newbies. I've been coding in LSL so long (4 1/2 years?) that I don't remember what it was like to be a newbie (I knew how to program to start with so I wasn't really ever an LSL newbie), so I'm not that good at writing content targeted for them. I keep an eye on the SL forums and try to add content to the documentation to answer questions that crop up there but that don't really address the issue pro-actively. We need people who can write content for that audience.

I'm sorry to say that WEB-65 isn't me at my best, I don't get along well with Eren; I'm glad you were able to distill anything useful from it and weren't confused by it (which incidentally also raises my opinion of you). Finding and keeping the balance is hard; you seem to be doing a good job of it.

To some things up, I not only don't mind, I'm excited that you have jumping in. I want you to continue.

p.s. There are a lot of variables you can use with the LSL Function template. They aren't all listed in the article source (and the order they are defined in doesn't matter), if there is one missing (from the article source) you can just add it; the unused ones listed are for convenience. There is also a Newbie Notes section you might be interested in, it's for writing tutorials for newbies, it allows for a short synopses to be inserted into the appropriate articles.

-- Strife Onizuka 12:48, 15 July 2008 (PDT)

LlListRandomize and the use of random vs pseudo random

Since you seem to have written and/or formatted a lot of the documentation on this I figure you'd be the best choice to answer this question. For LlListRandomize should all uses of random be replaced with pseudo random as appears to be the case with llFrand's mentioning of random number generation or should it be left as it is currently referencing random which is less accurate in my opinion. Gordon Wendt 13:31, 8 June 2008 (PDT)

I've moved the conversation to Talk:LlListRandomize. -- Strife Onizuka 13:54, 8 June 2008 (PDT)

Typo in geometric function?

Since it appears the code came from you, I am just putting a pointer here to comments I've added:

Talk:Geometric#Typo in Box and Ray, Intersection Distance, or is it correct?

Scalar Tardis 22:51, 15 June 2008 (PDT)

Endorsed Group Entry & Other Stuffz

Heya Strife!
Since you're one of the owners of the LSL portal translation group, I'd like to ask you to consider joining the endorsed group program. It would/could at least raise some attention to the project and therefor might attract new contributors. Problem: The group would need at least 25 members. But that should be managable somehow...
Besides that I'd like to ask you to add it to Volunteer Groups#Other Volunteer Groups and maybe add info about how to join the group in the group charter.
Might also want to add your point of view here.
Greetz =) Zai Lynch^{(talk|contribs)} 22:18, 26 June 2008 (PDT)

LSL Library

Heyas Strife!
I just used to clean the Special:DoubleRedirects and the LSL Library is confusing me there... It's listed as it would link to Float, what it's not doing. Is it because the page still got content besides the redirect? And should the talkpage be moved too? I'm just confused atm but I'm sure you'll know the answers.
Greetz, --Zai Lynch^{(talk|contribs)} 22:55, 11 July 2008 (PDT)

I'd say either leave the talk page or merge it with the category talk page. The Float stuff is because of theU other content on the page yes. Oh and good job cleaning up the double redirects, i looked at that recently and was like "this is more work then i want to do." -- Strife Onizuka 01:58, 12 July 2008 (PDT)

Thankies (^_^). Ok, merged the talkpages and cleared the other. That fixed the problem. Greetz, Zai Lynch^{(talk|contribs)} 04:05, 12 July 2008 (PDT)

Second parameter of Template:Multi-lang

Hi Strife, thanks for fixing Template:LSL Function/zh-Hans (although currently it's only used in llGetPizza/zh-Hans XD). So the second parameter of Template:Multi-lang are mandatory for translations? --Geneko Nemeth 07:40, 18 July 2008 (PDT)

It's not mandatory for language codes that don't indicate a dialect. It's easy to read two char tags but we sometimes get false positives so, if we added support for dialect detection we would likely get a lot more in the way of false positives though now that I think about it, it might not be that bad of a problem. I'll put it on the list of things to investigate. For the time being languages like Traditional and Simplified Chinese, you will need to use the appropriate dialect tags. -- Strife Onizuka 10:52, 18 July 2008 (PDT)

Hmm, it seems to be a bit broken. Using {{multi-lang|2=zh-Hans}} (not specifying base page name) gives you a wrong base page name with an extra trailing / (e.g. "Quickie Wiki Intro/") --Geneko Nemeth 16:22, 25 July 2008 (PDT)

For complexity reasons, the "/" is considered to be part of the code, you should be setting it to {{multi-lang|2=/zh-Hans}} -- Strife ^{(talk|contribs)} 22:48, 25 July 2008 (PDT)

Clustered Linksection(s)

Heyas Strife!
While translating, I noticed that the related links for related functions are always the same (for obvious reasons). So I wondered if it would benefit the portal in case those were outsourced with a template for each cluster. For example, all communication function links (llWhisper, llSay, llShout, llRegionSay etc.) in one cluster. Why would it benefit? Changes in the description of one of these functions would be visible to all related functions. I'm currently lacking an appropriate example, but I noticed differences in the descriptions of some links. This could be unified with such an additional template. So I'm referring to the |also_functions= {{LSL DefineRow||[[FUNCTION]]|}} part.
Greetz, Lynch ^{(talk|contribs)} 22:36, 11 September 2008 (PDT)

I have thought about that, and a number of the templates do do that (script permissions for example), the problem is you have to add in extra conditions to keep the article from linking to itself. Alternatively a special brief description set of pages could be created with template to inline those descriptions where needed. A giant switch statement can't be used because it kicks the crap out of the wiki (I tried). -- Strife ^{(talk|contribs)} 09:34, 12 September 2008 (PDT)

Ultimately I never came to a decision as to the correct solution and at the time I was the only one concerned with the issue. All solutions are a bunch of work and with the wiki, it's no good to make a decision if nobody wants to do the work. It looks like we might have the critical mass needed to make a decision and implement a solution.

There are really 3 solutions and they each have nasty implementation caveats.

1. Each article is a template too and use the <includeonly>, <noinclude> and <onlyinclude> tags..
   • Complicates the articles and if not implemented properly on each article will result in a huge mess.
2. Each article has a child article that contains the description.
   • Requires the generation of a huge number of pages.
3. System of templates and divided database of descriptions
   • The core DB templates will be included multiple times
4. Topic specific templates that provide links with descriptions for that specific topic.
   • A description might be different between different topics, this might not be a bad thing.

--Strife ^{(talk|contribs)} 09:48, 12 September 2008 (PDT)

Hmm... I'm not even sure if it's such a bad thing. I was concerned about it in the beginning too but now I'm seeing it as some kind of "Where am I and where can I go from here?" feature, with a "current article in a nutshell" description. So I'm not sure if effort and outcome of hiding the link are in a decent relationship. Since the links aren't clickable either when they are linking to the current page. See llAddToLandPassList/de for an implementation in a German translation.

Lynch ^{(talk|contribs)} 00:05, 13 September 2008 (PDT)

It does make sense. On many constant pages currently we just inline the table and ignore the self-link problem as you have. Maybe we should be thinking about modules for topics; like what they have on wikipedia (footers and right side floaters). I'm all for anything that saves us work and makes the articles better. -- Strife ^{(talk|contribs)} 00:27, 13 September 2008 (PDT)

So with wikipedialike modules, you're referring to something like the Template:The Dresden Dolls in the The Dresden Dolls (album) article? (Would we be able to build such a shiny hide/show javascript feature too?) Looks neat indeed... Lynch ^{(talk|contribs)} 00:45, 13 September 2008 (PDT)

That's what I was thinking of yes, my initial thoughts are that given the current layout that it isn't the best solution but I can't quite see how to make it better. Something to think about but in the mean time standardized links seem like a reasonable stopgap solution. As to collapsible sections, that is something that comes as a feature of later versions of MediaWiki (I've got a jira on collapsible sections/tables). It really only requires copying the javascript over. The sortable tables JS needs updating too. -- Strife ^{(talk|contribs)} 00:52, 13 September 2008 (PDT)

The only reason we use the "LSL DefineRow" template for links was because I was too lazy at the time to create a specialized template for it. The entire DefineRow solution was never a perfect solution even for it's intended application (which is something that has annoyed me). -- Strife ^{(talk|contribs)} 00:59, 13 September 2008 (PDT)

Okiesh, voted on WEB-235 (created July 2007? (x_X)).

I'm currently using Template:LSL DefineRow/de in Template:LSL Security Links/de. So should it be(come) a box instead with a change in Template:LSL Function/de? Or can I continue to build up clusters in such a way?

Lynch ^{(talk|contribs)} 01:17, 13 September 2008 (PDT)

I say, with DefineRow derivatives do what seems appropriate. As long as the appearance (of the articles) is consistent it really doesn't matter how you get there. Refactor to your hearts content if the wind blows you that way. -- Strife ^{(talk|contribs)} 01:26, 13 September 2008 (PDT)

Wow, that sounds philosophical. I will store that quote (^_^) luv ya Lynch ^{(talk|contribs)} 01:38, 13 September 2008 (PDT)

function/de

Sorry for the extra work with /de functions. I was sure Template:LSL Function/de would automatically register them to /de cats but haven't payed attention to it... Will have a look at the few translated ones to ensure that they aren't cluttering the english cats. Greetz, Lynch ^{(talk|contribs)} 03:06, 23 September 2008 (PDT)

No biggy, I only just noticed the problem and it drove me to fix some template bugs. -- Strife ^{(talk|contribs)} 07:44, 23 September 2008 (PDT)

LSL Caveats - Range

Heyas =)
I recognized some LSL caveats and wasn't sure how to word them properly, so I'll leave the suggestion up here for you. So, when you got a linkset and attach a script with a listener to a childprim, the listener is only triggered when the chat is spoken in the listeningrange of the root prim. While, when a llSay is spoken from a child prim, it's heard in a 20m radius around that child prims location (not root prim). So the prim listens at root and speaks at child. This should somehow be mentioned, I think. I also recognized that the llRezObject function is failing if the location is more than 10 m away from the child prim who has the script attached, again. So all functions which only work within a certain range should have a note if the range is measured from the prim where the script is attached in or if it is always the root prim.
Greetz, Lynch ^{(talk|contribs)} 14:43, 1 October 2008 (PDT)

I'll take a look at the wording for the llRez* functions and see what I can do to clarify. You are right that the chat/listen thing should be documented, this is the first I've heard of it thou and I've never come across it in any of my strangest of experiments (trust me on them being strange, ask me about the link-growth experiments some time). You should probably make a jira topic on it under SVC, just to see what information bubbles to the surface on this, a low priority bug maybe? -- Strife ^{(talk|contribs)} 20:39, 1 October 2008 (PDT)

Some bits of memory or false memory bubbled up as I was writing the caveat for listen and is reflected in the caveat. Take a look and tell me what you think. -- Strife ^{(talk|contribs)} 21:09, 1 October 2008 (PDT)

Google helped me to dig out VWR-2923 which is appearently missfiled (wrong category) but describes the same problem. I think the explanation you gave (prevention from spy scripts) could be the reason indeed, although there is no official statement on it that I was able to find. Thx for the clarification in the articles! =)

P.S.: I'll poke you on that link-growth story the next time I see you around (^_^).

Greetz, Lynch ^{(talk|contribs)} 04:45, 2 October 2008 (PDT)