User talk:Strife Onizuka

Strife Onizuka
is hereby awarded with the

Geek Award
for
the most creative template name:
Template:Template
by Zai Lynch

You found my talk page... Find old discussions take a look at the archives: 1 2

JIRA issues on LSL function pages

Okay, as I've made no headway deciphering your templates (not that I'm familiar in the least with the more complex wiki functions in the first place...) I decided just to cut my losses and ask! Basically I was wondering if there's a reason why Template:LSL_Generic/Issues doesn't appear to list all issues, but instead seems to just list bugs only in the same way as Template:LSL_Generic/Caveats?

I just think it'd be nice if function pages would also summarise popular proposals relating to them in the deep notes section, which is what I believed was intended but it doesn't appear to do this right now.

For example, if you go to the LlStartAnimation page, in the deep notes you'll notice that there are zero issues listed, however, clicking the "Search JIRA for related Issues" link returns quite a few. It might be nice to see the deep notes tweaked to display these, but perhaps with a limit on how many are shown (though llStartAnimation is a fairly popular one to see JIRA issues for and only has 17 issues listed). Anyway, just though I'd ask/request, please poke my talk page if you respond to be sure I remember and look! --Haravikk Mistral 15:26, 12 September 2010 (UTC)

The template is not automatic. Take for example llBreakLink, it lists a single issue in the article, it does this by including the template Template:Issues/SVC-3510. There are many stub templates like Template:Issues/SVC-3510 that work this way, they contain the information about the issue and pass it along to a template that does the heavy lifting. The value of this method is that a single template exists for the Issue and if the issue is sited on multiple pages, they can all be quickly updated by modifying the template. From an organizational standpoint, it also makes it possible to see what all pertains to a particular issue.

The thing is, if you want all the issues on the wiki, they need to be imported to the wiki, and regularly updated as changes are made... but that could all be done with a bot. Wonder if Gigs could be enticed to incorporate it into SLJiraStats?

The goal of the Deep Notes: Issues section was to contain dead bugs and interesting feature suggestions. I never intended it to contain all issues pertaining to a feature. We don't add any value by duplicated the JIRA search engine results; the value we can add is by filtering them. Some of the bugs aren't bugs, and some of the feature suggestions are unworkable; I don't think these should be given screen space. Considering the resources required to manually include and update the issues, triage has to happen.

Unfortunately I do not have the free time to work on this, work and other responsibilities eat all my time. *wonders just how true that is* -- Strife ^{(talk|contribs)} 03:10, 16 September 2010 (UTC)

Ah yeah, seems I've completely misunderstood what it was doing! I wasn't thinking to list everything, just an automatic, and hopefully useful summary of say...the top ten bugs and issues? It sounds like way more work than it's likely to be worth though so probably better just to forget about it, unless there's some way to just embed an iframe with a portion of a JIRA search or something similar? But that would probably cause an unacceptable increase in JIRA page requests from people just popping over to look something up. But now I know how it does work I can at least pop useful relevant issues on manually, thanks! -- Haravikk Mistral 12:36, 18 September 2010 (UTC)

A related problem, I've tried to add a few top issues of interest to me onto my user page under Key Issues, however, I've tried to create two Template:IssueTable instances, but they both have the same content, despite the value of #issues being different for both. Is this some peculiarity in using this template more than once? If you could take a look at let me know it'd be handy, as IssueTable doesn't have any documentation =( -- Haravikk Mistral 11:36, 22 September 2010 (UTC)

You are hitting one of the caveats/bugs of the new parser engine. I forget how to get around it. I beleive the issue is intermediate caching, and the way around it is to make the template call dynamic or something like that. Without spending a bunch of time debugging the problem, I just don't remember how to work around it. -- Strife ^{(talk|contribs)} 14:37, 22 September 2010 (UTC)

It just struck me what the problem is, it's caching IssueTable. -- Strife ^{(talk|contribs)} 18:27, 22 September 2010 (UTC)

Aha! The "subst:" keyword seems to be for this (e.g - {{subst:User:Haravikk_Mistral/JIRA/Issues/SVC}}), as I believe it fetches the pre-processed contents of a page rather than the source. In any event, this works in my case as I created sub-pages for each category, I don't believe it would help for a page with multiple IssueTable instances though, as using subst: for any of them would just create a blank gap, but it solves my problem at least! -- Haravikk Mistral 11:29, 23 September 2010 (UTC)

Ghost Detector

Thanks. I discovered that property of llKey2Name by accident. It's odd because, for instance, llDetectedName gives a non-empty string for ghosted avatars. -- Something Something 05:21, 10 November 2010 (UTC)

Friendly greetings

You seem to have found a "fix" for my horrible script and....messed it up. Please compare my original to yours and do some testing. They are different in the result. I would appreciate you fixing your "fix". Best regards --Kireji Haiku 02:42, 14 December 2010 (UTC)

I'm sorry you took the edit personally it was not intended that way. The example you contributed is valuable and nontrivial, however examples are held to high standards and it didn't meet them. I was faced with two options: rewriting it or deleting it, I felt it had merit so I rewrote it. My goal as always is to provide the most useful content to our users, and in this case down compatibility needed to be sacrificed. The script as it was designed required every prim to have at least one face have full glow, that didn't sound entirely useful, so I changed it to accept some glow (I notice that I also changed it to require every face have glow... which doesn't sound useful, so I'm going to revert that).

Examples have one major goal: Be educational, teach good coding practices and problem solving. Here is where the script went awry:

1. Names should be descriptive. The function names were a bit generic but single letter variables are definitely not descriptive, especially when they are globals, they really should describe the purpose they fulfill.
2. Using globals instead of locals & parameters may be efficient, but it degrades readability and adds a new vector for script bugs. This sort of optimization has no place in examples (except in an article on optimization techniques). The situation is made even worse by using non-descriptive variable names.
3. The script contained code that complicated it without aiding readability or improving functionality. Examples need to be streamline, having it meander requires the reader to needlessly keep track of more things.
4. I felt that the functionality provided had too narrow an audience, that by changing how it functioned that it would be more useful to more people. Down compatibility is a secondary consideration for examples, not a primary consideration.

P.S. I take it you didn't noticed there is a bug in your script: A single prim object with at least one avatar sitting on it could return the wrong result. IMO examples should not be attributed in the script text, it's what the history page is for after all, but I know the community and I don't always agree so I don't fight it. Personally I don't want my name associated with buggy code, so if you really want the script to be 100% compatible I'll have to remove my name and give you all the credit.

P.S.S. I think we may have different notions of wiki content ownership. When I post content on the wiki, I do so with the full expectation that it will be edited, that it will mutate into something I did not envision, into something I may not entirely agree with. We do not control the content after we have posted it. It's why there is the text below the edit box: "If you don't want your writing to be edited mercilessly and redistributed at will, then don't submit it here." Wiki culture is different. I may own my contributions but I don't control their fate. They are my children, being changed and influenced by the people around them, being made stronger in the process. But I digress

P.S.S.S. In the future if you want to convince someone they should do something, don't insult them first, it's counter productive. A better way to approach this situation would have been to say: "I disagree with some of the changes you made, specifically blah blah blah, could you please look into it? I did not appreciate your tone and I am quite insulted." It's a mistake to mix the two messages, people are prone to take offense and not do what you want out of spite. In a situation like this being snarky just isn't productive (though it does blow off a bit of steam which can feel good in the moment). Just FYI, nothing more. -- Strife ^{(talk|contribs)} 07:43, 14 December 2010 (UTC)

I didn't take it personally and was just trying to make you aware of your rewrite not doing the same like my script. Maybe you don't read in-world messages, as I had sent you a message thanking you for your rewrite and trying to point out the differences between the two. The script I had provided would check a link-set on whether or not it has glow. And yes, that would return a false result if avatars sit on it, but I thought nobody would use the script to check if a link-set is glowing while sitting on it, but I might be wrong and should have pointed that out in the description. So I see your point there and support your critique on that. However my script would return "glowing" for a prim if ANY number of faces have SOME glow (not 1.0, as you said it would do). Maybe you now understand my view when I see your rewrite as being more streamlined and easier to read, however you limit the script down in its original ability of detecting glow by forcing it to return positive only with all faces of a prim glowing. Anyway, I'm not up for a fight and to be quite frank just too lazy for it, a builder inside of SL asked me if it's possible to detect whether or not there's a bit of glow on all prims inside a link-set of his build and I just felt like sharing my approach of writing a script for that. If that script doesn't meet wiki standards in terms of streamlining it towards being absolutely foolproof and readable for just about anybody, I'll have to refrain from doing so in future.--Kireji Haiku 18:13, 14 December 2010 (UTC)

First I need to apologize, when I wrote my last comment I hadn't carefully reread your script, if I had I would have noticed your use of llCeil, which does as you point out return true for some glow. So my argument on that point is baseless. Between work and other obligations, I had forgotten about that aspect of the script and just went on my memory of what I thought the script was doing. As to fighting, I agree it's a waste of time and effort. However I hope you do continue to contribute to the wiki, every contribution is valuable as they grow the understanding and knowledge base of the community. Standards evolve and the content does as well, content has to be nurtured, given room to grow. Immature content just needs to mature is all; the only time stuff gets deleted is if it's factually inaccurate or needlessly repetitive. If I thought the contribution was trivial and obvious I would have stripped your name from it (attribution on one liners is blatant self ego boosting and makes the wiki look unprofessional). The only reason I attached my name was so that you wouldn't be forced to shoulder the costs of supporting code that you did not write. Please don't take away from this that your contribution was without value, or that I had no respect for it or you.

I should mention the reason for my terse comment in the edit was for a simple reason: I couldn't be verbose with the text limits of the field.

As to messaging me, all my IMs get sent to an email account I rarely check, I only ever go inworld to keep my accounts active and go to meetings (pretty rare) because my internet connect is total suckage. I had no idea you IMed me; for all correspondence I use the wiki and email.

You would be quite ticked at me if I were to describe my scripting habits with regards to code I post. I know I was when I saw people do what I do, but I don't really have the option. It's an ROI equation, should I make possibly buggy contributions or make no contributions at all? I wish I weren't forced to make the choice. If I weren't here doing this who would take up the mantel? Who would look after the templates? It would avoid problems like this maybe but would the community be better off? I honestly don't know but I suspect not.

If you're still reading, what changes or improvements would you like to see made to the documentation? An upcoming project is to incorporate collapsible sections into the documentation, I'm just not sure yet how to do so, I could do with some input. I haven't called for input from the community yet because I haven't rolled out the new Constants template yet (which will revolutionize the PrimitiveParams documentation). Given the potential of collapsible sections we are at a point in time where we should consider redesigning the documentation from the ground up. Maybe a contest? -- Strife ^{(talk|contribs)} 22:33, 14 December 2010 (UTC)

P.S. Does it work as it did before now? -- Strife ^{(talk|contribs)} 23:48, 14 December 2010 (UTC)

Hi, no it doesn't. The first problem is your thing with the double exclamation mark, that always returns 1 for me. And the second being you're still stuck with [PRIM_GLOW,ALL_SIDES], you don't do a loop through the sides. I will post a re-do of mine again, if you find a way to do what you wanted to do with the double exclamation mark thing, let me know.Kireji Haiku 21:16, 17 December 2010 (UTC)

!!llGetLinkNumber() returns 1 for multiprim objects or 0 for single prim objects; It's logically equivalent to llGetLinkNumber() != 0 however it requires less bytecode to express (you would not be without base to berate me for perpetrating this optimization/shorthand in an example script). You shouldn't need to loop through the sides, by using ALL_SIDES it should return a list containing the glow values for every side of the prim (not a very useful feature, in most cases uses it's better to loop through the sides). We then feed that list to the list stat function to get the max. I'll see if I can log in later to test it but right now I really need to fix the LSL documentation templates (the wiki upgrade broke at least one template, which in turn broke a lot of the LSL documentation; I'm trying to both find and fix the broken templates; and I don't know the precise cause). -- Strife ^{(talk|contribs)} 21:37, 17 December 2010 (UTC)

Fixed it finally, thanks again for the ideas and the input. !!llGetLinkNumber() doesn't seem to work, I know exactly what you're trying to do by writing it that way, but that always returns 1. Have tested it. And your return was a bit too fast to return a result, wouldn't wait until the end. If you can simplify it even further, go ahead. That's as far as I could get.Kireji Haiku 21:12, 23 December 2010 (UTC)

Is !!llGetLinkNumber returning one for a single prim object with no avatars sitting on it? That is the only time it should return zero. A single prim object with a seated avatar should return one. As to the early exit, once we find a prim with no glow, we can exit without checking the other prims. Logically speaking, we do not need to know precisely what the minimum is, just if it is less than or equal to zero. So instead of calculating the minimum we can exit as soon as we know the minimum is going to be less than or equal to zero. We know it will be less than or equal to zero if we have a value that is zero or less. The code should exit as soon as it knows the answer so as to not waste simulator resources (after all we need to encourage responsible coding). -- Strife ^{(talk|contribs)} 05:08, 25 December 2010 (UTC)

Help with template issue

Hi Strife, I'm hoping you can help to shed some light on a problem we have just discovered that has started to occur since we redployed the wiki yesterday. The symptom is that SOME pages, e.g. LlKey2Name display differently when you are not logged in versus logged in. Compare

• Logged in: http://screencast.com/t/e3K85IGni
• Not logged in: http://screencast.com/t/4OwWfihvhi

I think that this may be happening due to issues around templates, which is why I am contacting you. However, I don't really know the cause. The strange thing is that most other LSL function pages appear to display just fine when you are logged out; so there must be something in that page causing an issue. We would greatly appreciate any help! P.S. Here is the whole list of known issues: Second Life Wiki Known Issues.

Thanks --Rand Linden 17:15, 16 December 2010 (UTC)

I think it was generated before the extensions were installed. I purged the page (?action=purge) and it now renders properly for me (though I did see it the way you described but only when i was not logged in). It's weird. -- Strife ^{(talk|contribs)} 21:22, 16 December 2010 (UTC)

Maybe the cache just needs to be invalidated? -- Strife ^{(talk|contribs)} 21:24, 16 December 2010 (UTC)

Some triangulation: |constants={{LSL Constants/PrimitiveParams|get}} does not cause trouble on a test copy of llSetLinkPrimitiveParams, |constants={{LSL Constants/PrimitiveParams|set}} triggers the bug. Off to try on simpler stuff to see if there is a consistent pattern of some kind ... --Cerise Sorbet 21:47, 16 December 2010 (UTC)

The cache is not invalidating or refreshing. Check the mod date at the bottom of [[1]] and [[2]]. They are different. If you go into the history page and look at a previous version it will displays properly because it doesn't have a cached version but if you look at the current version (even with the version number, it does not display properly). Not even action=purge can budge it. A possible explanation is that the PrimitiveParams article is causing it to time out during rebuild. The new version of the template I'm hoping to get done by new year should be more sane and less time consuming (we hope). -- Strife ^{(talk|contribs)} 22:00, 16 December 2010 (UTC)

I thought it was only cache too but more appears to be going on. llKey2Name is displaying OK with a pair of Issue templates commented out. --Cerise Sorbet 22:22, 16 December 2010 (UTC)

The time issue I was seeing was caused by me having my account report the times in GMT+5 (which is weird seeing as i'm GMT-5) -- Strife ^{(talk|contribs)} 22:31, 16 December 2010 (UTC)

I've had a thought, I think it might have something to do with how bugs are duplicated (in both Issues and Important Issues). It looks to be the difference between the Get and Set primitive Params functions (Get are too new to have any flag bugs). -- Strife ^{(talk|contribs)} 22:42, 16 December 2010 (UTC)

It's not Template:Issues that is doing it, it's something about Template:Issue. I have this terrible feeling it's a problem with how #switch is parsed. When are we getting the new parser function extension? -- Strife ^{(talk|contribs)} 22:55, 16 December 2010 (UTC)

Oh it's definitely Template:Issue. I can't access it when logged out. -- Strife ^{(talk|contribs)} 22:55, 16 December 2010 (UTC)

I've disabled the code that detects if an issue is a bug, which appears to have fixed llKey2Name. -- Strife ^{(talk|contribs)} 23:14, 16 December 2010 (UTC)

#switch is not the cause, just the trigger. Maybe it's content duplication that is the problem? -- Strife ^{(talk|contribs)} 22:28, 17 December 2010 (UTC)

Mediawiki 1.14 added a |link= option for Image: tags. This would let you skip the imagemap for most uses that don't really need coordinates. --Cerise 03:38, 18 December 2010 (UTC)

There is a god ^_^ thanks for the tip. I'll deploy it post hast. -- Strife ^{(talk|contribs)} 03:40, 18 December 2010 (UTC)

Thanks so much for tracking this down, Strife and Cerise! This move/upgrade has certainly been more problematic than we expected.... :-(

--Rand Linden 19:05, 19 December 2010 (UTC)

They always are more problematic than anticipated. I'm sorry I didn't pay more attention to it earlier, I did notice the blanking on the test wiki briefly but not the common factor (since I spend all my time logged in, the first thing I always do when I connect is log in). I spent my time looking at differences between the highlighting. Never thought to look for differences between HTTP & HTTPS. -- Strife ^{(talk|contribs)} 19:30, 19 December 2010 (UTC)

Requested LSL Articles

didn't know this article existed

(o.O) -- ^{(talk|contribs)} 22:03, 27 December 2010 (UTC)