User talk:Rand Linden

Definitions for Land related articles

Heyas =)
I read your contributions to the sim and region article. I had in mind to merge land related articles (even poked a friend on it but I guess he's to swamped with other stuff atm). So I was wondering if you could help with a definition for parcel, estate and grid. Also the difference Main Grid (MG), Beta Grid and Teen Grid (TG), as well as the difference between estate and grid. I'm not sure but MG and TG don't seem to be different Grids (both Agni)? Currently available articles are: Parcel, Estate, Agni, Aditi, Grid
I'm just writing since your userpage sounded like you'd be into this kind of stuff. Sorry if this was the wrong way to request it.
Btw: You can register your userpage to certain Linden categories via Template:llEmployee. Oh and welcome :-)
Lynch ^{(talk|contribs)} 22:56, 16 December 2008 (UTC)

---

Hi, Zai! Thanks for pinging me, and yes, I'm interested in working on this kind of stuff. I'm pretty busy getting up to speed, and I'm also working on a couple of internal projects, so it may take a while for me to get to this, but I will do so ASAP. In the long run, I expect to be contributing to the wiki quite a bit...

In general, I am in favor of merging lots of little articles into more manageable-sized chunks. However, I was thinking of these two articles as glossary entries (I believe that is their Category). But maybe we want to think about a better way to do a glossary? I've seen them done in various different ways on wikis, e.g. one big article, an article for each letter, etc. Of course refactoring the Glossary would be a pretty big project, and I wouldn't want to undertake it without reasonable discussion and input from the community as well as other interested Lindens.

--Rand Linden 20:07, 17 December 2008 (UTC)

Heyas and thx for the reply =)

The current form of the glossary is quite new. It was a huuuuuge article before and we ripped it apart to turn it into a category. This was the first step. The second step would be, to scan this categories again for mergable clusters and then form them to helpful articles, while the original pages would become categorized redirects to chapters of these articles. For example: One Land article with chapters Parcel, Region (subchapter Normal Region, Void Region (Openspace), Homestead), Estate, Grid. The former articles about these topics would then be turned into redirects to these specific chapters, while they would still remain to be in the glossary category. That is the plan we (Gally Young and me) had in mind so far... Though we're quite distracted lately and not really working on it at the moment... There is even a to do list were some clusters are noted (besides the Help:Open Wiki Tasks page). The benefit of this over a Wiki page with entries sorted by alphabet is, that

1. articles can contain more info than just a few sentences and display related topics
2. information aren't scattered
3. entries can have more than one category

For example, a categorized redirect from Region to "Article: Land, Chapter: Region" could also be in the Category:Help/Land and not only in the glossary category.

These were our thoughts so far. I'm really happy that there's someone official now who'd like to take part in it! =)

Greetz, Lynch ^{(talk|contribs)} 21:15, 17 December 2008 (UTC)

That's an interesting approach, and one that could be a fruitful way to glean more contextually relevant information from scattered Glossary articles. However, if I understand what you are proposing, the end result would be elimination of a Glossary per se.

I personally think a Glossary with short concise terminology definitions can be very useful, in addition to more lengthy and detailed expository articles that put terms in context. Virtually every technical doc set I've worked on for the last 20 years has had a glossary....for good reason IMHO. Sometimes someone just wants a concise definition for a specific term, not a lengthy discourse. And Glossary entries can of course link to other pertinent articles to provide more detail and context.

You could still pursue the plans you outlined, but I would suggest reviving actual Glossary articles, and chunking them down into smaller articles, e.g. "Glossary A-F," "Glossary G-L," or even individual letters, if length warrants. Glossary definitions should have guidelines for length and format so they don't get too long and are consistent...

Anyway, that's just my take on the subject. Glossaries have traditionally been an unglamorous but important part of tech docs, one that is too-often ignored, IMHO. But, particularly for newbies, they can be invaluable.

--Rand Linden 18:07, 19 December 2008 (UTC)

Ah, I see the problem... My initial thoughts were, that it's somehow like in the Wikipedia, where the first three or four sentences (prior the first chapter) are used as a short summary like it would be written in a Glossary. We might be able to do the following:

Write the first few lines of an article as if it would be a Glossary entry and then prepare the article for inclusion with <onlyinlude> syntax. Then it can be included in a Glossary article sorted by alphabet and a second Glossary article sorted by content. It's basically what Strife did with llSetPrimitiveParams. Has the advantages that:

• Every article has a neat short introduction which gives an overview.
• Glossaries are sorted in the way which is most intuitive to the reader.
• Content is centralized and you just need to edit one article in order to change the description at every page displaying the Glossary lines.

Every such entry can have a "Read the full article about topic" link on the bottom. So that's just some brain storming... I would leave Category:Glossary nevertheless for the ones interested in more than just the preview. But can stand side by side *brainstorm*

Lynch ^{(talk|contribs)} 00:38, 20 December 2008 (UTC)

Firewalls

Heyas Rand! =)
Saw your article about Configuring Your Corporate Firewall to Allow Access to Second Life. I wanted to redirect Firewall to this article, but stumbled upon other articles which seem to cover the same (or a similar) topic.

• Firewall Configuration
• Firewall Usecases
• How do I configure my hardware firewall

Do you think they can be merged? Or maybe just redirected to your article since it might be the most up-to-date one?
Greetz, Lynch ^{(talk|contribs)} 22:29, 9 March 2009 (UTC)

Hi Zai, Thanks for your edits! Holy cow you're quick!! Yes, I will merge these articles... May take me a day or two, but I will do so.

Also, I see you added the new article to the Help portal, which is great. However, it's not really a "bug fix" so it probably shouldn't be in that category. I think "Viewer" is better. I'm not familiar with the Help template.... Do I just do:

{{Help|Viewer=*}}

I looked at the template, but it's not obvious to me.

Hehe, thx ^_^

Yepp, {{Help|Viewer=*}} would register it to the viewer category. Might be a good idea to do that. Can also register it to both, Category:Bug Fixes and Category:Help/Viewer. Since it might be that people find themself beeing unable to connect to SL and might not think about their firewall. So they might expect to experience a bug and therefor search in the bug fixes. When they stumble upon that article, they might think: "Oh, right...d'oh!". So maybe having it in both cats would be a benefit. Can always clean it up once the cat becomes to crowded (which it - unfortunatly - currently isn't). {{Help|Viewer=*|BugFixes=*}} would register it to both. So I'll leave the choice to you :-)

Neat article btw!

Lynch ^{(talk|contribs)} 22:41, 9 March 2009 (UTC)

SL CERT Template

Many thanks Rand! Sitearm Madonna

User Group Edit Restriction?

Hi Rand! Yesterday and today I've had two people tell me they couldn't edit SL Public Wiki pages - said they got a "don't belong to the group of users needed to edit the page". Yesterday 22-Apr-09 was Kwame Oh trying to edit Community Gateway Public Relations Links. Today 23-Apr-09 is Ppmediadev Blinker trying to edit the page he started called User:Ppmediadev_Blinker/sl_certification. I am unable to duplicate the error.

So before I chase it down I thought I'd ask, is there now a user group edit restriction?

Thanks! :) Sitearm Madonna 14:17, 23 April 2009 (UTC)

AFAIK, there are no such restrictions on this wiki. In fact, I don't even know that Mediawiki supports group restrictions. So, basically, I have no idea. My best guess is it's some kind of error with our wiki hosting site. If you find out anything of interest, please let me know.

--Rand Linden 17:35, 23 April 2009 (UTC)

They were probably upset by the loss of authentication error message that crops up (when the server twin that created the edit page is not the server that receives the edit page); the solution is to click the save button again. I find the bug useful, it allows me a last chance to make more edits. -- Strife ^{(talk|contribs)} 22:44, 23 April 2009 (UTC)

What Strife said. Just an add that it would generally be possible to restrict stuff for certain usergroups. See Special:ListGroupRights (additional groups can be added, existing groups can be modified). Tho it's not restricted in this wiki here. -- Lynch ^{(talk|contribs)} 23:22, 23 April 2009 (UTC)

Grazie zum Alles! Sitearm Madonna 23:46, 23 April 2009 (UTC)

Re: Talk:Pyogp#PyOGP docs

Hey there! =)

• @name change Pyogp → PyOGP: yes, please.
• @sentences vs. subpages: Subpages would have the benefit of the default breadcrumb feature, once Rob implements it (guess that will be the next time when he follows-up on the issue, since it's basically ready). Though that would be superfluous with your navbox.
• @Category:Pyogp Kitchen Sink: no preferences.

Greetz, Lynch ^{(talk|contribs)} 01:29, 29 April 2009 (UTC)

Hey, Zai! Thanks for your feedback, as always! As far as the default breadcrumbs, I think we should definitely implement that, because it's so easy. I'll talk to Rob about reassigning the Jira to me.

That being said, I think it makes sense to have some guidelines about when its appropriate to use slashes in a title, and when it isn't. For user pages, chat log transcript pages, code/API docs, and other intrinsically hierarchical reference type docs, I think they're fine.

But my feeling is that in general, for readability, titles should be English words and phrases. Then add breadcrumbs the "old fashioned way." That's just my preference based on usability and experience. And I admit, I do like the little nav boxes, because I also find they add usability. Breadcrumbs are good, too, however I realize there are shortcomings of the "basic" Breadcrumbs2 extension.

--Rand Linden 07:07, 29 April 2009 (UTC)

Welcome and thx for beeing so responsive :-)

I think the reason why I sometimes prefer subpages over sentences is, that the sentences tend to become wordier than neccessary (making it harder to reach the connected pages), while the folderlike structure of the subpages makes the editors distill the essence out of the headline. The wikipedia had a similar discussion once and the end was, that they're skipping the subpage style in the main namespace in favour of sentences (Wikipedia:Subpages#History of subpages). Reading their reasoning and yours, I can agree that they both make sense and that guidelines would be a good idea to deal with the issue. Though I wouldn't dismiss the subpages in main namespace completely, like Wikipedia did. It pays off in some maintenance stuff and gives fast access to breadcrumbs (without the need of a sysop), while it would otherwise make the Mediawiki:Breadcrumbs page unnessecarry long. Should bring it up @Project:Editing Discussion.

Yeah, the breadcrumbs are more the "where did I come from"-part, while the navbox provides a "where can I go to", so the navbox is a neat tool.

-- Lynch ^{(talk|contribs)} 11:10, 29 April 2009 (UTC)

Talkpages

I was just experimenting with MediaWiki features at a wiki were I got sysop rights. I stumbled upon a features used by the Wikipedia and many other wikis. It's possible to display a default message when people edit a talkpage. I'd think it would be neat if you could place {{talk}} at MediaWiki:Talkpagetext as only content (see Manual:Interface/Talkpagetext). It's more effective than placing the template at pages where guidelines aren't followed. Lynch ^{(talk|contribs)} 16:59, 29 April 2009 (UTC)

Figured that WEB-1071 is the more official way to request this. Sorry for the spam :-) Lynch ^{(talk|contribs)} 17:49, 29 April 2009 (UTC)

Template:DefaultBreadcrumb update

Hi Rand!
Wanted to give you an update on the breadcrumb code. I figured, that they way it treated talkpages was unsatisfying. It's now treating them as if they were subpages of the associated articlepage (it's deployed on this wiki so you can see the result on top of this talkpage, e.g.). The updated code for the LL wiki would look like

{{#vardefine:bcname|{{#titleparts:{{SUBJECTSPACE}}:{{PAGENAME}}}}}}[[Main Page]] > {{#ifeq:{{#var:bcname}}|{{#titleparts:{{#var:bcname}}|1|-1}}||[[{{#titleparts:{{#var:bcname}}|1|1}}]] > {{#ifeq:{{#var:bcname}}|{{#titleparts:{{#var:bcname}}|2|-2}}||[[{{#titleparts:{{#var:bcname}}|2|1}}|{{#titleparts:{{#var:bcname}}|1|2}}]] > {{#ifeq:{{#var:bcname}}|{{#titleparts:{{#var:bcname}}|3|-3}}||[[{{#titleparts:{{#var:bcname}}|3|1}}|{{#titleparts:{{#var:bcname}}|1|3}}]] > }}}}}}{{#ifeq:{{NAMESPACE}}|{{TALKSPACE}}| [[{{SUBJECTSPACE}}:{{PAGENAME}}|{{#titleparts:{{#var:bcname}}||-1}}]] >|}} {{#ifeq:{{NAMESPACE}}|{{ns:0}}||{{NAMESPACE}}:}}

in case you'd like to have it there as well. Greetz, Lynch ^{(talk|contribs)} 23:18, 7 May 2009 (UTC)

Looks cool (haven't really been following the changes too carefully). -- Strife ^{(talk|contribs)} 23:44, 7 May 2009 (UTC)

Thx (^_^)

I just hope there's no connection between default breadcrumbs (in general, not this revision in particular) and WEB-1078...

*shivers* -- Lynch ^{(talk|contribs)} 00:26, 8 May 2009 (UTC)

Inclusion vs. Redirect

Heyas! =)
I'm curious why you chose to include Statistics Bar in Statistics Bar Guide, instead of redirecting it? Additionally: Will you be at the Doc Team office hour tomorrow?
Greetz, Lynch ^{(talk|contribs)} 19:12, 26 May 2009 (UTC)

Hey Zai,

I did that for some internal work I'm doing related to providing online help in the Viewer from wiki content. (I'm working on a "proof of concept"). If you prefer, I could move it into another page. Really, of course, you are right; there is no good reason to do it the way I did.

I will try to drop in to the doc OH tomorrow.

--Rand Linden 20:04, 26 May 2009 (UTC)

Hm, I'm not sure if I understood, though I'll bother you at or after the OH with it (^_^) lookin forward to! Seems to become a wiki-all-stars meeting -- Lynch ^{(talk|contribs)} 03:14, 27 May 2009 (UTC)

update

Heyas =)
I just noticed that we got MW 1.14 now and read through the release notes. I noticed that there is a possibility to add an "on-wiki external image whitelist. Items in this whitelist are treated as regular expression fragments to match for when possibly displaying an external image inline."
It might be a good idea to delete File:Ll_color_vert_100.gif and embedd it from an external source? For copyright of the image itself.
On a selfish note: Can you set $wgEdititis = true? It would add edit counts to Special:ListUsers.
Greetz, -- ^{(talk|contribs)} 11:10, 24 June 2009 (UTC)

Could you add jira.secondlife.com to the whitelist, this way we can use the icons from jira without having to upload them to the wiki. -- Strife ^{(talk|contribs)} 11:51, 24 June 2009 (UTC)

Hey guys, So sorry for the long delay, but I just noticed this request. This isn't something I can do, because it requires shell access. So, you'll need to enter a Jira, and then Yoz, Rob, or someone at Cascadeo will handle it.

Thanks, --Rand Linden 16:20, 15 July 2009 (UTC)

Spell check in isle MediaWiki:Revreview-completeness-5 needed

One too many "p"'s on MediaWiki:Revreview-completeness-5 -- Strife ^{(talk|contribs)} 11:44, 24 June 2009 (UTC)

Copyright

The copyright notice on the wiki hasn't been updated yet this year: "Copyright © 2024 Linden Research, Inc. Licensed under $1 unless otherwise noted."
(please sign your comments, it's annoying to have to check the change log; oh and please create a new section if you leave a comment on a talk page, it's disruptive to the last conversation otherwise). -- Strife ^{(talk|contribs)} 01:23, 26 June 2009 (UTC)

Follow up on widget problem

Hi Rand!
I had some more thoughts on the widget problem and came up with WEB-1189 and WEB-1190. Maybe you can have a look at them. :-)
Greetz, ^{(talk|contribs)} 14:56, 27 June 2009 (UTC)

Media

Hi Rand! :-)
Wondering: is Category:LLMedia the same as Category:Media? -- ^{(talk|contribs)} 20:37, 17 August 2009 (UTC)

Hey Zai, Yes, good catch. I prefer just "Media" as it's a real English word :-) Also, all the articles in Category:LLMedia are old and deprecated. I'm going to move them into Category:Media, and mark them as such. Thanks again

--Rand Linden 21:52, 17 August 2009 (UTC)

Ah, I see :-) Welcome! (Btw, there seems to be something wrong with the Linux download link) -- ^{(talk|contribs)} 07:11, 18 August 2009 (UTC)

Media Rendering Plugin Framework

Hi Rand, any chance of getting this unprotected since it seems no more dangerous to edit than the page documenting Downloads for example? If that's not possible can you please add {{Help|Viewer}} to the top since that appears to be a help page and I think viewer is the correct categorization. Thanks. GW ^(T|C) -- 06:44, 22 August 2009 (UTC)

Hey Gordon,

I protectedt this at the request of the Media API project manager. He's out of town atm, but when he returns, I'll suggest we unprotect it, as I agree with your assessment. Meantime, I added the Help|Viewer template to it as you suggested. Thanks.

--Rand Linden 18:42, 24 August 2009 (UTC)

Monobook

Hey Rand :-)
Telling from your edits, you might want to vote on WEB-1187. :-)
-- ^{(talk|contribs)} 22:49, 19 October 2009 (UTC)

Thanks, Zai; I will. But we can still use User:<username>/Common.css, right? Or does that even work?

--Rand Linden 22:52, 19 October 2009 (UTC)

I think all user customizable css and js is off, including Common.css... -- ^{(talk|contribs)} 22:59, 19 October 2009 (UTC)

Template:Gloss

Template:Gloss needs to be fixed. Any article that includes it gets included in the Category: Viewer Help Templates. <noinclude> and <includeonly> tags are needed. -- Strife ^{(talk|contribs)} 16:16, 5 March 2010 (UTC)

Thanks for catching, Strife! I have corrected this oversight.

--Rand Linden 18:24, 5 March 2010 (UTC)

llEmail & email

Hiya Rand. Hoping you can answer this since you seem to know a thing or two about the system. I'm trying to nail down the character limits for llEmail and email. I don't suppose you know what they are or can find out? It would save a lot of guesswork to have a record of the true limits. I can carry on testing if need be. Verified figures direct from LL would be preferable though. -- Fred Gandt ^{(talk|contribs)} 23:44, 21 May 2010 (UTC)

Thank you for the response (on my talk page). -- Fred Gandt ^{(talk|contribs)} 23:59, 21 May 2010 (UTC)

Fred, got this back from a dev: Looks like the article on LlEmail is accurate. The code contains these lines:

   if(send_size >= LL_MAX_KNOWN_GOOD_MAIL_SIZE)
   {   
       llwarns << "send_mail message has been shown to fail in testing "
           << "when sending messages larger than " << LL_MAX_KNOWN_GOOD_MAIL_SIZE
           << " bytes. The next log about success is potentially a lie." << llendl;
   }

And LL_MAX_KNOWN_GOOD_MAIL_SIZE is 4096 bytes.

So this line in the wiki is accurate: "The 4096 byte size limit includes the subject line and automatically added text. The practical maximum body size is approximately 3600 bytes."

--Rand Linden 16:00, 24 May 2010 (UTC)

Thank you Rand. I have run a few tests that showed without doubt that there was a char count (3745) not bytecount cutoff. I would put that down to bytecount too, if I hadn't tried many different char combinations which would have returned vastly different bytecounts i.e. 3745 ampersands vs. pipes or mixed letters, using single byte spaces etc. I wonder, is it possible that the hard limit of 3745 chars is a side effect of something else...such as conversion of text from UTF_8 to crayon (I don't know much about that stuff)? So, although the internal system measures in bytes, it is unavoidable that a collection of 3745 chars will max out.

Anyway. Thank you very much for taking (asking around) a look. I would ask that as and when it seems appropriate you could also thank "the dev". -- Fred Gandt ^{(talk|contribs)} 19:03, 24 May 2010 (UTC)

XUI Reference

Hey Rand! I just noticed the work you did on the XUI reference to bring it up to date. When 2.0 came out, I thought all the work Admiral Admiral and I did would become obsolete. Thanks.

Mm Alder 21:25, 16 August 2010 (UTC)

You're most welcome! Thanks for all YOUR work that I was able to build upon!

--Rand Linden 18:04, 17 August 2010 (UTC)

Typecasting vs Rounding functions

Hiya. A question arose during a discussion between myself and Zai and I was wondering if you might be able to offer a definitive answer. Of the methods below which would (without question) be the best method of obtaining an integer from a float (the value of the integer is not of the greatest importance in this case)? By "best" method I mean the method that requires the least cpu time, causes the fewest potential memory issues (e.g. is least likely to use memory in any way that could be considered "poor practice" etc) and is simply the right way. <lsl>float float_value = whatever;

default {

   state_entry()
   {
       // METHOD 1
       llOwnerSay(((string)(llRound(float_value))));
       // METHOD 2
       llOwnerSay(((string)((integer)float_value)));
   }

}</lsl> If the question strikes you as being less than simple to answer the conversation between myself and Zai that led to me asking may help put it into perspective. Thanx -- Fred Gandt ^{(talk|contribs)} 01:46, 8 September 2010 (UTC)

Hi,

I don't know the answer myself, but let me ask around and see if I can find out.

--Rand Linden 21:32, 8 September 2010 (UTC)

Thank you :) -- Fred Gandt ^{(talk|contribs)} 22:28, 8 September 2010 (UTC)

Answer

From Babbage:

Method 1 will call in to C code.

Method 2 will stay in managed code, so is faster for Mono scripts. Also it cuts out one function call.

--Rand Linden 16:02, 9 September 2010 (UTC)

Wow! (on two counts). Thanks for checking into this. I must change my ways. I assumed that although llRound ing was an extra function it was a nicer process to request. Thanks again. Also ---> Babbage is still around!? I thought he was one of the culled masses. Glad (if this is the case) he wasn't. -- Fred Gandt ^{(talk|contribs)} 18:35, 9 September 2010 (UTC)

Looking into Managed code and thus CLR I can't help but wonder if the disadvantages of "Garbage collection" might explain 1/2 the issues the grid experiences with MONO scripts. Don't worry too much about responding; I would talk with my dog about this stuff but I don't think he cares very much ;-) -- Fred Gandt ^{(talk|contribs)} 00:29, 10 September 2010 (UTC)

Fred: Babbage is around until the end of September, but unfortunately won't be with LL after that. :-(

Also, I think your observation about GC is fairly close to the mark....

--Rand Linden 17:47, 14 September 2010 (UTC)

Damn on the Babbage note. Seeing his Mandelbrot explorer early on when I was learning was inspirational. Such a nice bloke too. Corporations eh? What can you do?

GC....I was kinda right? Seriously? Wow! I must be actually learning something. Good old wikipedia ;) -- Fred Gandt ^{(talk|contribs)} 20:15, 14 September 2010 (UTC)

Template:Helplang, Template:HelpNoTrans & Map File

Just thought you should know, if you want the Map File tables not to be so big, before the last "<noinclude>" tag, add "|-" to both Template:Helplang & Template:HelpNoTrans. It should cause the table to shrink nicely (you will want to do the header row that appears on each of the Map File pages). -- Strife ^{(talk|contribs)} 21:20, 23 November 2010 (UTC)

Thanks, Strife!

--Rand Linden 23:08, 23 November 2010 (UTC)

Template:Win?

I was wondering why Template:Win exists, you could use the parser function {{uc:text}} instead and not rely upon inline style to do the transformation? -- Strife ^{(talk|contribs)} 18:28, 6 December 2010 (UTC)

Hey, Strife,

The reason we created that template was due to some controversy over how all (well, most) window titles in Viewer 2 are in ALL CAPS. Generally, in documenting UIs, it's a "best practice" to spell UI elements exactly as they are spelled in the UI itself (including capitalization). It also just looks goofy. Thus, the doc team objected to this profligate capitalization; however, we were not able to get the design and eng. teams to change it. However, our hope was that some time in the future, they might see the light and move to headline capitalization. Therefore, we created a template, which of course we could change accordingly if and when this convention ever changes. There is also Template:Winlink which is similar but also links to the help article for the window in question. It seemed like overkill to have the actual article titles be all-caps, so we have for example Viewerhelp:Advanced Sky Editor that links to Viewerhelp:Day Cycle Editor, which is actually titled DAY CYCLE EDITOR.

--Rand Linden 23:15, 6 December 2010 (UTC)

I see your point and the solution is good. With the LSL Portal we had a similar conundrum, which had to do with prefixing all of the LSL Portal article titles. In the end we opted to prefix only the categories (to avoid collisions) but that only happened after a good number of articles had already been created & prefixed. Fortunately all links went through link templates, so the transition only required moving a couple hundred articles. -- Strife ^{(talk|contribs)} 01:12, 8 December 2010 (UTC)

Template:EditLink

There's a good idea, wish I'd though of it. -- Strife ^{(talk|contribs)} 21:34, 8 February 2011 (PST)

Thanks, Strife! Boy, you don't miss a thing, do you? :-)

--Rand Linden 10:11, 9 February 2011 (PST)

Careful, stuff like this could go to my head. Either I'm attracted to the smell of future wiki innovation, seeing as it only happens when I'm around and I have some sort of sixth sense for it... OR (and my Ego says, much more likely) innovation can only happen when I'm around. :P Really it's just dumb luck. OK back to reviewing old LSL topic edits that I missed. Have a good day. ^_^ -- Strife ^{(talk|contribs)} 10:36, 9 February 2011 (PST)

Browsing chat history with CTRL + Up/Down arrow

Hi Rand, I'm working on https://jira.secondlife.com/browse/VWR-25321 which is "Make user aware of the 'CTRL + Up/Down Arrow' feature (which scrolls back message history)". That JIRA issue, which got recently Oz's attention. is about exposing the feature in the viewer. I wonder if the same feature has to be documented elsewhere. Using CTRL + arrows to browse the chat history is a semi-hidden feature, especially for new users. --oobscure 10:15, 27 May 2011 (PDT)