User talk:Sealbudsman/Archive 1

From Minecraft Wiki
Jump to: navigation, search

Proposal for templates so we don't have to touch the (newer) snapshot pages quite so much, moving forward[edit]

Good afternoon KnightMiner, Goandgoo, Majr, Dinoguy1000, BDJP007301, BoxFigs (Feel free to flag anybody else in),

I want to talk nav boxes, snapshot pages, and more broadly some problems I see and templates I propose.

The snapshot pages create a lot of busy-work, I don't have to tell you. Here are some situations I was thinking of which definitely put us to work that I think we shouldn't have to do:

  1. Disregard this first example; KnightMiner points out below, correctly I think, that {{t|LatestMinorVersion}} and static values suffice for prevparent.
    Mojang releases 1.7.11. We now have to go back* and update prevparent on all the 1.8 snapshot pages.
    *When I made the [[Template:LatestMinorVersion|LatestMinorVersion]] template, I hadn't thought ahead to see that it wouldn't be generally applicable in the place I had put it.. For instance if after they release 1.8, they start putting out snapshots for 1.8.1, LatestMinorVersion wouldn't be the proper thing to put in prevparent. What needs to go in prevparent is literally the previously released version, not the latest minor version of the previous major release.
  1. Mojang hypothetically releases 1.8 as 1.8.2. We now have to go to all snapshot pages, and change 1.8 to 1.8.2 not only three places in each nav box, but in the Fixes section where it says '.. before 1.8', in the lead where it says '.. sixth snapshot for 1.8', and in the {{history}} entries throughout the wiki.

I know a lot of you are willing to do that level of work, as you have clearly been doing what it takes to make the "older snapshot pages" project come to fruition, and I applaud that -- But I just wonder if there was interest in doing it a different way going forward, to eliminate some steps.


I've made some simple templates to address all that, so that things are more "set it and forget it":

[[User:Sealbudsman/Template:VersionByIndex]]
[[User:Sealbudsman/Template:ReleaseName]]

  • Per Majr's comments below about the need to keep things clean and using a bot to subst old usage of this template, I've now called it {{[[User:Sealbudsman/Template:ReleaseName|ReleaseName]]}} and changed the usage somewhat to reflect this.
  • The idea with VersionByIndex ReleaseName is that it allows the page to read '1.8' until you find out it's actually 1.8.2, then you only need to change it in one place. And, if after that, you are expecting it to be 1.8.3 but they give you 1.8.4, again you just change it in that one place. Same if you are expecting 1.8.5, and they reveal it was 1.9 all along: Change it in one place.


[[User:Sealbudsman/Template:VersionPrev]]
[[User:Sealbudsman/Template:VersionNext]]

  • The idea behind VersionPrev and VersionNext is that it literally maintains a list, so that given a version, it says what should be its nextparent.


They would be applied like so, in a snapshot page (example nav box shown):


Sealbudsman
Edition

Java Edition

Type

Snapshot

Release date

July 30, 2014

Snapshot for

[[Java Edition {{User:Sealbudsman/Template:ReleaseName|1.8}}|{{User:Sealbudsman/Template:ReleaseName|1.8}}]]

Download

Server

Protocol version

Data version

{{version nav
|edition=java
|image=
|type=Snapshot
|date=July 30, 2014
|parent={{[[User:Sealbudsman/Template:VersionByIndex|ReleaseName]]|1.8}}
|serverdl=[https://s3.amazonaws.com/Minecraft.Download/versions/14w31a/minecraft_server.14w31a.jar Server]
|prevparent={{[[Template:LatestMinorVersion|LatestMinorVersion]]|1.8}}
|prev=14w30c
|next=
|nextparent={{[[User:Sealbudsman/Template:VersionNext|VersionNext]]|{{[[User:Sealbudsman/Template:VersionByIndex|ReleaseName]]|1.8}}}}
}}
14w31a is the forty-first snapshot released for {{[[User:Sealbudsman/Template:ReleaseName|ReleaseName]]|1.8}}.
; From released versions before {{[[User:Sealbudsman/Template:ReleaseName|ReleaseName]]|1.8}}


I'd appreciate your thoughts, whether this is a welcome suggestion, one that needs refining, whether a more talented template-er could improve this, etc.

  • For instance can you use variables within a page, so you don't have to replicate {{[[User:Sealbudsman/Template:ReleaseName|ReleaseName]]|1.8}} so many times?
  • Would this make the long pages like 1.8/Development versions burdensome to the server by way of having too many templates? I heard that template overload is a thing.
  • Is there another way to do this?

Sealbudsman (Aaron) (talk) – 17:50, 4 August 2014 (UTC)

This definitely seems like a good idea to me, and I like that you've already done the legwork to come up with a functional system. And I should be able to answer your questions:
  1. Yes you can, because variables are amazing. =D You can, for example, set a variable in one template and then use it in another template, as long as both templates are transcluded onto the same page and the template that sets the variable is transcluded first. This would allow the snapshotfor, prevparent, and nextparent parameters to be reduced to two (and potentially just one) parameters - and I think, with a bit more careful design, we could also throw the prev and next parameters in there, too (though for that I'd suggest instead investigating a Lua module, for which I'd point to Majr, since he's been the one doing all the Lua work around here =D ). It shouldn't even be necessary to make the editor directly transclude VersionByIndex; the infobox could do it automatically. And it would mean you wouldn't have to include the parameters in the VersionByIndex transclusions in the page's prose, just a "naked" {{VersionByIndex}} call would be sufficient. I can update the template to allow this if you'd like to see how it works from the code side of things.
  2. You're talking about the template limits here. This isn't actually a concern, since the infoboxes don't get transcluded onto the version history pages, but it does mean we can't use the parameterless transclusion method, at least not without some care: we have to include the parameters on at least one VersionByIndex transclusion that will get transcluded onto the version history pages.
  3. There may be, but I'm not nearly as good at coming up with new methods for doing things as I am in figuring out how to implement them. =D
ディノ千?!? · ☎ Dinoguy1000 21:35, 4 August 2014 (UTC)
Doing all 3 in one step would be awesome; you hit the nail on the head identifying the main barrier to that. I hunted around, and wasn't sure if it was possible to make something like: #versions = [1.7.10, 1.7.11, 1.8, 1.8.1]; #idx = #versions.indexOf( #version ); echo #versions[ #idx + 1 ]; -- using wiki markup.
I'm not sure what you mean, that if you transclude VersionByIndex in the infobox, you can make a naked call to {{VersionByIndex}}? Why would that be the case, or can I see a working example?
Even without the infoboxes, there are the lines like 'Fixed in 1.8' to think about, and those would be all over the 1.8/Development versions page. Would those kind of transclusions contribute to the limit, or are you saying there's a way around that by doing things carefully at the top?
Sealbudsman (Aaron) SealbudsmanFace.png (talk) – 22:00, 4 August 2014 (UTC)
My opinions (I'll try to answer the latest questions next, trying to avoid another edit conflict)
For {{[[User:Sealbudsman/Template:VersionByIndex|VersionByIndex]]}}, {{version nav}} could call it up, rather than the editor calling it.
Parent versions: Previous is either going to be an unchanging value (1.8 is released, now 1.8.1 is getting snapshots, 1.8 is not going to change to another version) or the latestMinorVersion
Next is either going to be an indexed version (1.8 or 1.8.1 may come after 1.7.10) or unknown (1.8 may have next of 1.8.1 or 1.9). It may be useful to add a template here, maybe loading from the parameter snapshotfor (1.8 would start as blank, then we hear of 1.9 and set it to that, then we hear of 1.8.2 and change it again).
As for your last three questions, answered to the best I can:
  1. You can add page variables, but you would still end up repeating the variable's name a bunch (called using {{#var:ExampleVarible}}).
  2. I don't think a few small templates like these would increase the page memory too much, since each one is only used four or five times per version, and templates like {{BlockLink}} get used a lot more on a single page. Also, most of the templates would be in the infobox, and the 1.8/Development Versions]] only loads the content. The majority of what template overload is causes by is either Lua or Extension:Loops (neither of which you are using).
  3. None that I can think of, other than updating it manually. After 1.8 is released, there will be little need to change 1.7, and ect.
To summarize/clarify: It may be most useful to do this by merging {{tl|LatestMinorVersion}} and {{[[User:Sealbudsman/Template:VersionByIndex|VersionByIndex]]}}, then calling it up in {{Version nav}}. You could make VersionByIndex to default to the latest, or take an indexed value. And VersionNext may also be useful, although only until we the next parent is released.
Edit from slightly later:
You could easily call all the needed templates from {{version nav}} at the same time, thereby removing a few arguments, and storing the information elsewhere.
And yes, such a call is made in {{version}} to {{version link}}, so it displays the latest version using {{version link}}, or compares them and links to {{version link}}. And as for the "Fixed from versions before x version" on the 1.8/Development versions, we are still unlikely to reach any sort of limit.
--KnightMiner (t|c) 22:17, 4 August 2014 (UTC)
As for prevparent.. That's true, it's one or the other.. but do you know at the point you write the snapshot page, which one it is? Are you suggesting you do know which it is, and so don't need a template in that case?
Sealbudsman (Aaron) SealbudsmanFace.png (talk) – 22:19, 4 August 2014 (UTC)
Yes, I'll give an example.
  • 1.8 is getting snapshots, and the latest version is 1.7.10, use {{tl|LatestMinorVersion}}, since 1.7.11 or higher may become released.
  • 1.8 was just released, and 1.8.1 is getting snapshots. Since minor version snapshots are not as extreme as major version updates, it is unlikely for a version to get released between 1.8 and 1.8.1, so you use static and/or indexed. Minor versions tend to be performance related and rarely have major rewrites or features needing a version in-between. The also come out quick enough to prevent that
--KnightMiner (t|c) 22:30, 4 August 2014 (UTC)
I think you're right, I've modified the proposal to reflect this.
Sealbudsman (Aaron) SealbudsmanFace.png (talk) – 15:14, 5 August 2014 (UTC)
It might be possible using some convoluted #switch monstrosity, but as I said, I'd recommend Lua instead - it'd be far simpler to just have an array where each version is listed alongside its parent version, plus whatever's necessary to allow for finding the previous/next parent or minor version.
That's because there's not really any good terminology. =C I meant that, if variables are used correctly, a template could be transcluded once with parameters, to allow it to set the proper values for the variables, and then it could be used again without any parameters, instead loading the needed values directly from the variables. I'll adjust VersionByIndex in a minute to show this.
All template transclusions (and ParserFunctions and, I think, a few other types of wiki markup) contribute to the template limits. I haven't checked the 1.8 version history page yet, but I'd be surprised if it was anywhere near the template limits currently, aside perhaps from just raw size. If the functionality is implemented in a module, though, it'll be more lightweight than a pure-wikimarkup/ParserFunctions solution. ディノ千?!? · ☎ Dinoguy1000 22:12, 4 August 2014 (UTC)
Here are the template limits for the current version of 1.8/Development versions (which you can check by viewing the page's source and searching for "NewPP"):
NewPP limit report
Preprocessor visited node count: 46829/1000000
Preprocessor generated node count: 23050/1000000
Post‐expand include size: 791293/2097152 bytes
Template argument size: 18379/2097152 bytes
Highest expansion depth: 11/40
Expensive parser function count: 41/100
Lua time usage: 0.780s
Lua virtual size: 31.42 MB / 50 MB
Lua estimated memory usage: 0 B
ExtLoops count: 0/100
ディノ千?!? · ☎ Dinoguy1000 22:19, 4 August 2014 (UTC)
I want to avoid having large switches/lua tables of versions building up. This is only necessary for versions that are actually changing ({{t|LatestMinorVersion}}, for instance should not contain any versions before 1.7, as those will never change). The same goes for the usage of {{Dev version list}} in the navbox. It is only currently necessary for 1.7 and 1.8. The rest of them will never change and should just be a static list, although it is fine to use it temporarily while the version pages are being created. Unfortunately, it isn't easy to get DPL to subst nicely, so the list would need to be written out manually.
The release name changing from the development name is a more widespread issue than just the version pages, basically every page with a history entry for that version has to be updated. So we probably need a template such as {{Release name}} which would be used for versions that are currently being developed (then a bot can subst it once the version is released) and templates for the prevparent/nextparent links (can probably just throw some switches in {{version nav}} if that's the only place it'll be used), which can then be subst once the version will no longer change. MajrTalk
Contribs
⎜ 06:49, 5 August 2014 (UTC)
That's a good point about the version pages. I suppose you had been using a bot to change for instance 1.7 to 1.7.2, across all those history cases? If so, was that a satisfactory way of going about it? Would having a {{Release name}} thing make it any easier, or improve usability in any way -- or would it be another source of headache, just another thing to keep track of?
Sealbudsman (Aaron) SealbudsmanFace.png (talk) – 15:14, 5 August 2014 (UTC)
Nah, it was just all done manually. I wouldn't be surprised if you could still find references to 1.7 on the wiki. It's not really that important as long as it redirects to the right place.
A template certainly makes updating easier, as you just modify one or two templates instead of hundreds of pages, and it can be cleaned up by a bot later once the version number is certain. I'd also like to make shortcut templates such as {{1.7}}. Having these makes it more convenient for people to use in articles, because they just have to put braces around the version number, rather than having to type an extra template name, and it's easier to keep track of when all the references to a particular version have been cleaned up, when there are multiple uncertain version numbers. MajrTalk
Contribs
⎜ 04:52, 7 August 2014 (UTC)

┌───────────────────────┘
You didn't need to edit the history or infobox of any pages, everything that uses {{version link}} already goes through {{release version}}... MajrTalk
Contribs
⎜ 03:04, 8 August 2014 (UTC)

Sigh.. ah well. I misread you when you indicated that it was a more 'wide spread issue'. Always ask, that's the lesson here. – Sealbudsman (Aaron) SealbudsmanFace.png (talk) – 03:15, 8 August 2014 (UTC)

nextparent[edit]

So, KnightMiner, Goandgoo, Majr, Dinoguy1000, BDJP007301, BoxFigs (same crowd as last time),


What about changing nextparent in specific cases such that:

|nextparent=after {{1.8}}

substitutes 1.9 for after {{1.8}}?


So, when for example, 1.8 is released as 1.8.1, a bot changes all {{1.8}} to 1.8.1, resulting in:

|nextparent=after 1.8.1

and nextparent would then be substituting 1.9 for after 1.8.1.


And when for example, the next one is released as 1.8.3, the bot changes all nextparent=after 1.8.1 to nextparent=1.8.3, and somebody is free to remove the after 1.8.1 substitution from nextparent.


Thoughts?

Sealbudsman (Aaron) SealbudsmanFace.png (talk) – 15:50, 7 August 2014 (UTC)

What about using 1.8.x to achieve that effect. On previous it uses the latest, and on next it can use an unknown next version (starting with nothing, and later becoming 1.9, or 1.8.1). --KnightMiner (t|c) 22:04, 7 August 2014 (UTC)
That is good, except for one thing: between when a 1.8 version is released and a snapshot for the next 1.8 is released, we would absolutely need to run the 1.8.x-removing bot and reassign it in the navbox, freeing up '1.8.x' for the next version. That'll be fine though, right? – Sealbudsman (Aaron) SealbudsmanFace.png (talk) – 22:37, 7 August 2014 (UTC)
Hmm, that is a problem, unless 1.8.1x or 1.8.1.x is added for that purpose. I think the goal with this is to never make a bot be needed immediately, and rather when the bot owner can run it. --KnightMiner (t|c) 22:47, 7 August 2014 (UTC)
Yes, the bot shouldn't ever be relied on, it's just going to be to cleanup afterwards so we don't build up big switches. I think 1.8.1? or after 1.8 would make sense. I mean, it can really be anything, you just need something to differ it from wanting to exactly specify a version.
(Also you can use {{ping}} for pinging people.) MajrTalk
Contribs
⎜ 03:19, 8 August 2014 (UTC)

Issues for 1.4[edit]

Hi there, if you have time or are interested, would you be able to link up the bugs from 1.4 (versions + snapshots) to the bug tracker, and sort them? At the moment most of those pages don't have links to the bug tracker, and seem fairly incomplete. Thanks GoandgooTalk
Contribs
Edits
12:52, 12 August 2014 (UTC)

I'd be interested, sure. I'll put it on my to-do list. – Sealbudsman (Aaron) SealbudsmanFace.png (t|c) – 13:35, 12 August 2014 (UTC)
Just note that versions before 1.4.2-pre used the Minecraft Wiki bug tracker, and linking to an individual bug is a little harder there. --KnightMiner (t|c) 13:57, 12 August 2014 (UTC)
Yeah, I think that may be somewhat of a phase 2, after first linking things from bugs.mojang.com, which is straightforward. Linking to the wiki bug tracker might be quite a slower process. But why not! – Sealbudsman (Aaron) SealbudsmanFace.png (t|c) – 14:38, 12 August 2014 (UTC)
ok thanks, 1.5 fixes also need to be sorted as well. GoandgooTalk
Contribs
Edits
21:11, 12 August 2014 (UTC)

Removing links to status effect[edit]

Why? Meeples10t ~ c 22:08, 6 September 2014 (UTC)

Those links to status effect were pointing to the anchor on the 'list of status effects' table. I put a bunch of more anchors within the table, so the status effects can each be linked directly. And for the existing redirect pages like Health Boost that just redirected to Status effect, I made them redirect to Status effect#Health Boost.

In other words, Health Boost goes to the Status effect page, like before, but now it links straight to the specific Health Boost entry. And now the Health Boost link cam be used intuitively. – Sealbudsman (Aaron) SealbudsmanFace.png T, C, b 22:17, 6 September 2014 (UTC)

Style guide[edit]

In this edit, you imply that the style guide says not to include history information for the fact that Guardians initially were immune to fire in the history section. I'm not seeing it on Minecraft Wiki:Style guide, though. Do you have a pointer? Anomie x (talk) 22:06, 9 September 2014 (UTC)

Minecraft_Wiki:Projects/Rewrite_for_Style/General_guidelines, under Section -> History. But you seem to be right; I don't find it in the Minecraft Wiki:Style guide itself. – Sealbudsman (Aaron) SealbudsmanFace.png T, C, b 22:20, 9 September 2014 (UTC)
The guideline on keeping bugs out of history was based on the general guideline of keeping information in the relevant sections. As bugs come and go with every version, there is no need to list every bug (the bug tracker does that well enough), and the only reason they get added in the first place is because of the same type of people who think bugs are trivia. As for whether it is a bug or not, that is currently left up to the discretion of the editor. --KnightMiner (t|c) 03:00, 10 September 2014 (UTC)
In this particular case, I wonder how many videos and such are out there that say Guardians can't be killed with fire that noting when it changed would be useful. But, meh. Anomie x (talk) 03:28, 10 September 2014 (UTC)

Reopened Issues Filter[edit]

It seems that you are having trouble listing issues that are only currently reopened instead of all issues that had been reopened at one point in time. For all reopened issues I recommend the following filter: project = MC AND status = reopened AND updated > "2014-08-28 10:40" ORDER BY updated

If you want to only list issues previously listed as Fixed, then the following filter should work: project = MC AND resolution changed from "Fixed" AND status = Reopened AND updated > "2014-08-28 10:40" ORDER BY updated DESC . (both make use of the status = Reopened, which limits the status to issues that are reopened) -Sonicwave talk 01:30, 19 November 2014 (UTC)

It seems good! – Sealbudsman (Aaron) SealbudsmanFace.png T, C, b 18:37, 19 November 2014 (UTC)