User talk:Immute

Hello, all. Please feel free to leave me a message below. —Immutetalk 17:35, 6 November 2011 (UTC)

Template:Bl
Hey, can you use the preview button instead of making heaps of (very) minor changes? – ultradude25 ( T &#124; C ) at 09:21, 7 November 2011 (UTC)
 * Yeah, I agree that this is annoying. I tried using preview, but it wouldn't show my changes because the template hadn't been purged. From now on, I'll use a test template; I'll experiment on it, and port the final results back to bl. Hope this helps. :). However, I can't think of any more changes to make for the time being. Thanks for the feedback. :) —Immutetalk 16:57, 7 November 2011 (UTC)


 * Actually, since the template wasn't includeonly'd, it was showing the changes, but the switch had no default so the end result was an empty span. You should've given it something to parse.
 * In the case of includeonly'd templates, you can just change the starting includeonly tag so that it's no longer valid (remove the < from it perhaps), so that it'll show the template normally. – ultradude25 ( T &#124; C ) at 17:08, 7 November 2011 (UTC)
 * I was referring to the transcluded documentation; I, at least, couldn't see changes with it. I see what you did with the template.  Very clever!  I'm looking at the documentation for templates now; it's clear I need to learn more... —Immutetalk 17:15, 7 November 2011 (UTC)


 * I wasn't talking about the documentation part, of course you wouldn't be able to see the changes there as until you press save, your changes don't actually exist to anyone but you. – ultradude25 ( T &#124; C ) at 17:51, 7 November 2011 (UTC)
 * So how can I see my changes? (Also, someone other than I just had the great idea of adding alt-text to these labels!) —Immutetalk 17:53, 7 November 2011 (UTC)


 * Like I said, unless the template in includeonly'd (in which case you just need to break the includeonly tag), you just have to give it something to parse. Now that the switch has a default, it'll always show [X] instead of just nothing. If you want the other switch options, you'd do it the same as what actually using the template does, so in this case, is the only input, so you'd feed what you'd normally put in the template to it, so for a it'd be , etc. – ultradude25  ( T &#124; C ) at 17:59, 7 November 2011 (UTC)

Oh, no worries :) Didn't mean to complain. --31stCenturyMatt 17:29, 11 November 2011 (UTC)

Empty headings
I think empty headings are important to have. They are present so that in the event where someone is adding things, they are present for minor edit of just the said section. This reduces the likely hood of people editing the whole page, only to find someone else did a minor edit in a completely unrelated section. Is there another reason aside from the typical "they make the page long" that I'm not aware of? Chiisana 02:44, 12 November 2011 (UTC)
 * You make a good point. Additionally, I've seen a lot of noobs put annoyances in a bug section because there was no annoyance section prefabricated for them in the right spot.  So yeah, I'm totally behind this now, with the caveat that instead of being totally empty, the dummy subsections contain the text "None.".  On a side note, one unfortunate consequence of having subsections at all is that the edit history has become substantially less helpful.  All of the edits now read (-> Bugs) or (-> Annoyances), etc. instead of (-> Redstone & Pistons), etc.  It makes it a lot harder to track down a change to a section and attach it to a user.  I try to edit whole sections rather then subsections, so it is clearer what I am doing, but I think it will be difficult to try to get everyone else to follow this practice; moreover, it reduces the fault-tolerance of the system to concurrent modification, as you pointed out. —Immute [talk]
 * Thanks for the reply. Yes, my impression is that it makes editing a little bit easier, and less likely to run into the 'someone else edited the page during your edit' situation.  I do understand the clutter, and will attach a "None" or "None at this time" text if I were to add any new sections from now on, though. Chiisana 03:53, 13 November 2011 (UTC)
 * Sure thing! Glad we can agree to agree.  :)  —Immute [talk]

Known bugs proposal
For each bug, we will put the following information: Mojang's status of the bug, Severity of the bug, OS-Specific?, Single- or multi-player specific?, Survival or creative specific?, Bug disputed?, Last known tested version of bug. The headings would have codes that we can have a table of contents in the top of the page, so not only editing by section go to the correct one (i.e. [PiB] would stand for Pistons; section bugs), but also so users can quickly use +  to find it. What do you think? Cool12309(Talk 03:24, 23 November 2011 (UTC)
 * Hello? Did you click the page and skip this message or...? Cool12309(Talk 02:39, 26 November 2011 (UTC)
 * Hey, sorry; I've been out for Thanksgiving. Your idea sounds quite promising. Anything that reduces overhead in submitting bugs makes it less likely for bugs to appear in the wrong section, so we have less filing work to do. —Immute [talk] 07:14, 26 November 2011 (UTC)