User talk:Murph

How are you able to board the Aeris 3A?

Hi, how are you able to board the Aeris 3A as you said here? I'm stuck on the ladder which is to far back, so I can't reach to the cockpit. — xZise [talk] 16:15, 18 November 2013 (CST)

It's a case of getting to the top of the ladder, then jumping onto the winglet using Shift+D+Space. Not the easiest thing to do, not 100% reliable, but it is possible. --Murph (talk) 23:15, 18 November 2013 (CST)

Ordinal character vs degree symbol

Hi I noticed you use the masculine ordinal character (º; U+00BA) instead of the degree symbol (°; U+00B0). There is technically a difference, so if possible it would be good when you use the degree symbol in the future. — xZise [talk] 11:15, 2 May 2015 (UTC)

Damn, you're probably right! I thought it was opt+0 (OS X 10.10) for it, but I'll gladly accept that could be the wrong magic keypress. I'll try to figure out the correct one. Thanks.  :-)

--Murph (talk) 13:06, 2 May 2015 (UTC)

Yup, you are absolutely correct. opt+0, which I mistakenly used, gives:

º

MASCULINE ORDINAL INDICATOR

Unicode: U+00BA, UTF-8: C2 BA

I needed shift+opt+8, which gives:

°

DEGREE SIGN

Unicode: U+00B0, UTF-8: C2 B0

Now I just need to somehow remember that obscure key combination for the next time… ;-)

--Murph (talk) 13:24, 2 May 2015 (UTC)

Hehe ;) Well I checked the Unicode codepoints for the characters you've written and got 00BA back ;) so I was pretty sure that it's different. Funny thing though: My font in the browser displays it underlined so the difference is obvious to me ;) (that is how I discovered that). — xZise [talk] 14:57, 2 May 2015 (UTC)

Ahh, I was wondering how you had spotted it. They are pretty much indistinguishably identical in my font. I've revised my recent edits to correct them.

--Murph (talk) 15:28, 2 May 2015 (UTC)

Position of description

I noticed you moved a lot of descriptions. I personally think that they are worthless for an article. It's a funny/snarky comment about the craft but it doesn't help you to understand that craft which is why the description in most cases is one of the last “trivia like” sections. — xZise [talk] 13:38, 28 May 2015 (UTC)

I think it was just the stock craft I changed. Yes, overall, some of them are relatively low value, but others actually do state the intended role of the craft, or tell you something about it. Even those that don't tell you much, KSP is a quirky game with a variety of humour spread randomly through it, and I don't see why the official wiki should shy away from that, as long as it doesn't get out of control and make it significantly difficult to read the articles, or get confusing about the line between humour and factual information. It just seemed to me to have a reasonable logical flow to it as (lead para)->(Squad's description)->(detail). They are all reasonably short, and clearly marked, so I don't feel the less useful of them are causing difficulty with the overall flow of the article. Over the years, I've seen the technique of inserting sometimes humorous, sometimes philosophical, etc quotes and/or thoughts quite widely used in a variety of literature, from something on the cover of technical reports, to something inserted at the start of every chapter of a book (ranging from tech books to fiction). I'm not advocating changing all of the parts like that, but on balance I think the craft articles are better with it at the top and it doesn't harm access to the primary detail content below it. Typically, with a float right picture, the quote and the picture should end fairly closely in the vertical flow, giving the full width to the main content below them. --Murph (talk) 14:09, 28 May 2015 (UTC)

Template:Documentation

Leaving a message on my own talk page to preempt any possible queries. I'm importing Wikipedia's Template:Documentation, as a first step towards addressing some of our undocumented non-trivial templates, with the goal of making life easier for editors. It will take a little time, and is a work in progress. I fully intend to sort out all the red links, odd categories, broken images, etc. --Murph (talk) 06:43, 30 May 2015 (UTC)

Update. It's still ongoing. Much of the framework is in place now, but still many links to fix, and bits of tidying up and polishing to do. Images will remain broken on stuff that's not visible to ordinary visitors, to be fixed later when our wiki's image uploads are working again. Images visible to visitors, I'm fixing as best I can with the broken image handling (making use of the few images which are working, but even those fail if you want a different size to the sizes that were cached by the server before it broke). --Murph (talk) 16:47, 31 May 2015 (UTC)

*mbox

Is there any advantage from having the different *mboxes? Couldn't we use {{Box}} for all of them? To be honest I'm a bit overwhelmed by your changes with the templates copied from Wikipedia so there might be other cases were just copying Wikipedia's implementation isn't sensible to us. — xZise [talk] 11:11, 4 June 2015 (UTC)

The main advantage is that it made it much quicker to pull in other templates. There wasn't a specific need for the full *mbox family from WP, although we already had bits of them laying around from a long while ago. I pulled them in as a matter of convenience to support other templates. I could potentially convert them into compatibility templates which ultimately use {{Box}}, or even convert in the opposite direction (not that I'm actively proposing that), but that is a slower and more complex process than just having them available as-is.

Pretty much all of the end-user-visible WP templates that I have imported are quite mature now, there shouldn't be a great deal of ongoing maintenance needed for them (and it should be fairly easy to import newer revisions of non-Lua functionality from WP, as I am actively trying to minimise the differences). Once I've finished cleaning things up (cleaning up my own work), they will just work as designed.

I'm not trying to pull everything in from there, just have a solid and reasonably comprehensive core which supports easy template documentation and future cases where we see an individual template on WP that would be useful (i.e. many of the cases are dependencies for more useful stuff). It also supports routine editing of main articles, when editors familiar with WP's templates can just use what they already know, i.e. I hope that it makes our wiki more accessible to a wider group of editors.

Yes, some cases don't make immediate sense to import from WP, such as {{Infobox}}. Others, like {{Navbox}}, we were moving towards emulating WP (and already had a copyright infringing, unmaintainable, and undocumented instance of it), but in a way that was harder to maintain and offered less functionality.

--Murph (talk) 11:38, 4 June 2015 (UTC)

Moving page

Hi I've to admit that when I move a page it also suggests to move (up to 100) subpages (e.g. moving Foo will move Foo/bar with that option). The only problem is when it doesn't move the subpage because its target already existed (the flag pole had this in two languages). There was sometimes an issue (at least before the update not sure if it happened after it) that it didn't move the subpage because of an error. I'll also take a look at commons.css later sorry for the delay. — xZise [talk] 08:30, 11 June 2015 (UTC)

Sure, but you paid attention to the details to produce the best possible overall result, including the manual bits where the automatic help from MW fails. So, thanks for doing that.  :-) --Murph (talk) 11:14, 11 June 2015 (UTC)

Could use some markup help

Hey, I was wondering if I could get your help with the project I'm working on over here: User:VariousMetals#New stats table template, User:VariousMetals/Stats table, User:VariousMetals/Template:Stats table header

Basically, I'm trying to create a universal template for part stats tables that would automatically select headers based off of a set of input parameters listing the modules used by the parts in the table. The code I have there so far is probably pretty inefficient, and doesn't really work properly. Ideally it would be condensed into a single page rather than being split into Stats table and Stats table header, but I had trouble keeping the size of the template manageable unless I split it off. I was hoping you could help me improve it, since you're the markup expert around here (you have my full permission to edit anything in my userspace if you need to). VariousMetals (talk) 15:32, 11 June 2015 (UTC)

Sure, I'll take a look when I get a moment. Hopefully sometime today, once I've finished up with some cleanup work on the navboxes. --Murph (talk) 16:23, 11 June 2015 (UTC)

Ok, so I think I see where you are trying to go with your ideas so far, the general direction. It does seem like it's worth investigating, to see if it gives a better overall result than the status quo. I think I can see some good sense in it in terms of maintainability and ensuring consistency between the various tables. I've got some ideas for how to move it forward. I'm slightly concerned about passing table data rows into the template due to the sheer number of pipe characters needing to be escaped for the larger tables, i.e I'm not sure that "content=<100s of table cells>" is such a great idea. I'm going to throw together my take on what you've started, and we can take it from there. I'm still running the ideas around in my head right now to pick the "best" approach for it, but should start some code quite soon. --Murph (talk) 03:47, 12 June 2015 (UTC)

First fairly quick and rough re-imagining of your work at User:Murph/Template:Stats table header. Rather than just "fix" your templates, I basically gave myself a clean slate, then pasted in bits of your stuff that fitted with what I had imagined in my head. The text alignment is a bit all over the place in the header, but that's something I worry about right at the end, after the hard bit of figuring out all the colspan and rowspan stuff, etc. I.e. I wasn't even trying to make it look pretty beyond the very basics needed for proof of concept. If you think the concept is good, I'll happily spend time making it look good, beating the MW parser into submission to prevent the odd visual formatting.

Table caption instead of a complex title row requiring maths to figure out a colspan. Approached the params from a different angle, so module1, module2, module3 replaced by resourceName and moduleName — that's just going to be so much easier in the long run, I think, and should hopefully eliminate the need for horribly complex nested if and switch statements. There's basically no nesting in there at all, just 1 level deep of optional table fragments. Cells which I felt were not really adding much trimmed out, to basically the minimal number of header cells required for the information being presented (but not any real problem to support the extra cells if there's a strong desire for them). Source fairly readable for a quick first draft.

If you really want the module1, module2, module3 approach, i.e. if you see a big advantage to going down that road, it can be done, and I'm willing to help. This alternative is just going to be vastly simpler in terms of code, if it will serve the purpose. Things like {{Navbox}} can use group1 and list1 without too much pain, because they are basically not processing the values of those parameters, just a simple "if non-null, output" in the middle of the correct chunk of markup. As soon as you want to make complex decisions based on the value, and support the same decisions for module1 to module20, complexity rises considerably.

--Murph (talk) 06:47, 12 June 2015 (UTC)

I cleaned up the extra space in the header, since I had a little spare time. --Murph (talk) 05:27, 13 June 2015 (UTC)

Thanks, this was essentially what I was looking for. I'll probably mess with it some more after I add the rest of the resources, but it looks great. That said, I'm going to put implementing this on hold until the file problems get fixed. The main reason for that is that this needs to work in conjunction with the other project to divide the stock parts page into sub-pages and replace the main page with thumbnails. Also, I've been brainstorming a bit about the stats table formatting and I'm still having trouble coming up with a good permanent solution to managing the excess info while keeping the tables standardized. VariousMetals (talk) 00:52, 22 June 2015 (UTC)

Great, I'm glad to have been of some help with it! :-) I quite understand waiting on the server being fixed. (I understand server problems, and appreciate that it sometimes takes time to fix them, but this one has frankly become a bit absurd, speaking as someone quite familiar with Unix/Linux system administration and that side of MediaWiki. I see it as something that should normally take a day or 2 max, not a month or 2 and counting…) Feel free to ask for more on this as and when you're doing more with it. --Murph (talk) 15:18, 22 June 2015 (UTC)

Well the person who was actually responsible left two weeks ago: http://kerbaldevteam.tumblr.com/post/120554265630/devnote-tuesday-slow-news-day-i And I don't know what Squad's plan is (just that as of recently there has been no replacement) but I doubt that it will change soon. — xZise [talk] 08:22, 23 June 2015 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

Yes, I had spotted that. I'm rather hoping that Squad do have still have someone looking after their servers. It would be nice to at least get something along the lines of "we've not forgotten the wiki community", or maybe even "we're going to try to take a look and see if there's anything that can be done quickly that would improve things". Part of me wonders if it's as simple as the "standard" reason why this stuff breaks as a result of a MW upgrade, namely the permissions on w/images and w/cache getting reset to 755/root/wheel when you extract a new MW tarball, and the a cron job or cleanup of LocalSettings.php for the job queue; or alternatively checking if PATH is correctly configured (and image tools are installed). Cleaning up the 2 obsolete extensions should be pretty easy too, just comment/remove "require_once" for them (then later delete the specific w/extensions/<name> directories if step 1 didn't break anything, once the dust has settled). The simplest things which could cause the problems vary between 5 minutes and an hour to fix for someone with root on the server, which is the thing I find most frustrating. I will, however, refrain from holding my breath… --Murph (talk) 09:05, 23 June 2015 (UTC)

You should go start up the page Tutorial:How to fix the wiki migration problems and add what you just wrote. ;) VariousMetals (talk) 12:33, 23 June 2015 (UTC)

Repetitive changes

Hi just as a note I've a bot here so if you have similar changes for multiple sites it may help out. E.g. to move all headers one down I could just replace lines in a certain format (if you are familiar with regex: =+.*=+ replaced with =\0= or headers one level down =(=+.*=+)= replaced with \1) on certain pages (it would help to have some kind of list or all in the same category).

Another thing are changes like this http://wiki.kerbalspaceprogram.com/index.php?title=1.0.2/Box&curid=9272&diff=65066&oldid=61130 Another way to handle that is to have the </noinclude> in the same line as the opening curly brackets (which is afaik what I've usually done). — xZise [talk] 17:07, 14 June 2015 (UTC)

Thanks, I'll keep it in mind. I'm quite fluent in regex, I've been using it since the days of physical 80x25 green screen terminals. For changes on longer articles, or where there's a large number of changes following a pattern, I often paste the article source into vim (or sometimes Emacs, I've always been fairly neutral on that great debate, as each has advantages), work on it there, then paste it back into the wiki, or filter it with traditional Unix tools like sed, awk, etc. I'm also familiar with pywikibot, so I'll extend the same offer right back to you, if you ever need another pair of hands or eyes with anything like that.

Yeah, I could have just collapsed the leading newline onto the </noinclude>, I just have a personal preference towards template first, documentation second. It's not something I'd go out of my way to change on existing usage, only when doing something like trimming a potentially troublesome newline that I've spotted in the course of editing something else. At least one of the articles had a blank paragraph caused by those newlines, so I just trimmed them all as I was going through reviewing the series of articles.

--Murph (talk) 17:48, 14 June 2015 (UTC)

Ah yeah I usually also have the documentation after the template. I just excluded that notification as it's shown on top. But whatever works for you. I actually need to check my script (it automatically searches through the pages ending with /Box or similar and adds the notification) if that adds a \n at the end of the line.

And I don't have such a long track record that I know anything about terminal-only systems :D — xZise [talk] 18:13, 14 June 2015 (UTC)