Guild Wars 2 Wiki talk:Projects/Skill Version History
Templates[edit]
I've "imported" Template:Version history as well as Template:Unchanged skill history from the GWW and modified it to look like other notice templates on the GW2W. However, the layout of both templates will break if a PvE and PvP version exists and is linked (Pistol Whip (PvP) would be an issue. Here's an example on how it looks on the GWW).
Another issue would be: Should we use skill history templates for traits? Or should we create more templates (and categories) for traits (and effects)? -Nefastu (talk) 23:30, 29 August 2016 (UTC)
- The issue regarding split skills between PvE and PvP has been fixed. -Nefastu (talk) 13:13, 30 August 2016 (UTC)
- Currently, only Template:Version history, Template:Unchanged skill history, Category:Skill histories and Category:Unchanged skill histories are created. As there are 12*6*9=648 traits (without accounting for replaced and removed traits), there should be Template:Trait history, Template:Unchanged trait history, Category:Trait histories (as sub-category for skill histories) and Category:Unchanged trait histories (as sub-category for trait histories) as well.
- The issue then is for effects like Confusion (example here): Should there be a full page history for effects? If yes, should there be separate templates and categories? -Nefastu (talk) 13:30, 30 August 2016 (UTC)
- Not really sure why we need an Unchanged skill history template. The tag should be {{game update history}} or something. Skills and traits are already categorized, so a generic category works fine.--Relyk ~ talk < 14:36, 30 August 2016 (UTC)
- If both the un-changed and changed history tables can fit in one template, then I agree that only one should be enough. However I do think it's important that a page reflect that there is a table showing no changes, as opposed to simply the lack of a table showing history. -Darqam (talk) 15:22, 30 August 2016 (UTC)
- For consistency, every unchanged skill/trait should have a table as well (see the third example on this page). -Nefastu (talk) 15:50, 30 August 2016 (UTC)
- If both the un-changed and changed history tables can fit in one template, then I agree that only one should be enough. However I do think it's important that a page reflect that there is a table showing no changes, as opposed to simply the lack of a table showing history. -Darqam (talk) 15:22, 30 August 2016 (UTC)
- Not really sure why we need an Unchanged skill history template. The tag should be {{game update history}} or something. Skills and traits are already categorized, so a generic category works fine.--Relyk ~ talk < 14:36, 30 August 2016 (UTC)
- So regarding generic categories, something like this would be needed: Category:Game update histories with sub-category Category:Unchanged game update histories (to quickly determine which skills/traits/effects have remained the same) with both categories allowing to categorize by skills/traits/effects? Then we would only need Template:Game update history (with enough parameters to differentiate between changed/unchanged, unsplit/split:pve/split:pvp, skill/trait/effect). Additionally, maybe a template like Template:Game update history table nav and Template:Game update history table row should be introduced instead of using STDT table format for every skill/trait/effect page? -Nefastu (talk) 15:50, 30 August 2016 (UTC)
- (Reset indent) Uh guys the skill infobox template populates a bunch of semantic properties such that if I did
{{#ask: [[Has canonical name::Fireball]] | format = ul }}
- Fireball
- Fireball (Champion Grawl Shaman)
- Fireball (Destroyer Emberknight)
- Fireball (Destroyer Fiend)
- Fireball (Experimental Weapon)
- Fireball (Flame Legion Turret)
- Fireball (Imp Tonic)
- Fireball (Lesser Fire Elemental)
- Fireball (mastery)
- Fireball (Mythwright Gambit)
- Fireball (Pet Skyscale)
- Fireball (Qadim)
- Fireball (skyscale)
- Fireball (trophy)
- Fireball#WvW,PvP
- It'd populate a list including historical versions freshly documented! We'll need to turn those off. (I will do the template "fixes" required - I'm thinking we'll create {{Skill infobox/historical}} with barebones text) -Chieftain Alex 20:56, 30 August 2016 (UTC)
- Oh bugger... I'll stop creating infoboxes until something gets built up/changed. Until then I'll just make the tables and copy paste the infoboxes later. -Darqam (talk) 20:58, 30 August 2016 (UTC)
- Not a problem. Created {{Skill infobox/historical}}, feel free to rename ("/history" ?) Also are these pages going to live in the project namespace, or at, for example, "Fireball/history"? -Chieftain Alex 21:26, 30 August 2016 (UTC)
- The skill/trait/effect history pages should be (like on the GWW) a sub-page to the skill/trait/effect page, e.g. "Fireball/Skill history", "Dogged March/Trait history", "Confusion/Effect history". -Nefastu (talk) 21:31, 30 August 2016 (UTC)
- mmm. There won't ever be pages which have both "/Skill history" and "/Trait history" for the same base page, so why not consider shortening the subpage name a bit? -Chieftain Alex 22:03, 30 August 2016 (UTC)
- I imagine that should be fine, I'm trying to find a name overlap but so far have come up with none (which is surprising considering anet). As for why I'm putting things in this project space; I'm keeping things here until the contributors have had time to decide on formatting and details. Once things are clear, I'll make sure what I've done get formatted properly and then move things over. I would definitely agree that having them as a parent subpage is much more appropriate than on these pages.-Darqam (talk) 22:44, 30 August 2016 (UTC)
- What's with naming it {{skill infobox/historical}}? Call it {{skill infobox history entry}} or something. And I'd rather use a table format if we're doing it this way since infoboxes are a terrible way to show changes.--Relyk ~ talk < 00:57, 31 August 2016 (UTC)
- I imagine that should be fine, I'm trying to find a name overlap but so far have come up with none (which is surprising considering anet). As for why I'm putting things in this project space; I'm keeping things here until the contributors have had time to decide on formatting and details. Once things are clear, I'll make sure what I've done get formatted properly and then move things over. I would definitely agree that having them as a parent subpage is much more appropriate than on these pages.-Darqam (talk) 22:44, 30 August 2016 (UTC)
- mmm. There won't ever be pages which have both "/Skill history" and "/Trait history" for the same base page, so why not consider shortening the subpage name a bit? -Chieftain Alex 22:03, 30 August 2016 (UTC)
- The skill/trait/effect history pages should be (like on the GWW) a sub-page to the skill/trait/effect page, e.g. "Fireball/Skill history", "Dogged March/Trait history", "Confusion/Effect history". -Nefastu (talk) 21:31, 30 August 2016 (UTC)
- Not a problem. Created {{Skill infobox/historical}}, feel free to rename ("/history" ?) Also are these pages going to live in the project namespace, or at, for example, "Fireball/history"? -Chieftain Alex 21:26, 30 August 2016 (UTC)
- Oh bugger... I'll stop creating infoboxes until something gets built up/changed. Until then I'll just make the tables and copy paste the infoboxes later. -Darqam (talk) 20:58, 30 August 2016 (UTC)
- (Reset indent) I've added an alternative formatting section to this page to showcase a table format. Obviously table formatting is not my strength, but this may help us to decide what formatting we should use. -Nefastu (talk) 12:03, 1 September 2016 (UTC)
- I have to admit, that the table is indeed more compact and holds all relevant information. I really like the separation between cast, pulse and end effect and it is clearly visible in which column a change has taken place. But personally I still tend to prefer the infoboxes, though it is difficult for me to pin down advantages. I would say it is far easier to isolate a certain version of a skill from infoboxes than the table, mostly because of the distinct headers but also because of the compressed style of the table. It is simple to reach a specific version from the TOC (but that could be fixed). Furthermore I think infoboxes would be better for skills whose effects have been completely changed (do we have some of those?) where a table could imply continuity for the wrong reasons. Finally, as traits are far more diverse than skills in their effects and requirements, it would be a substantial amount of work to create a framework for the table while it is already possible to have a standardised design with infoboxes and skill facts. --Soulblydd (talk) 07:47, 6 September 2016 (UTC)
- @Soulblydd, The purpose of a version history is to view changes between versions. Don't see navigation to specific version being useful. The main reason to not use section headers and infoboxes is so all the entries are on a single page and you don't need navigation. Maybe if you want to highlight a change where the skill is completely revamped? We'd use {{anchor}} tags in any case. Traits and skills are almost identical and we do all the work in skill tables and trait tables (which we can copypaste).
- @Nefastu, {{skill fact}} isn't made for tables and the descriptions cause a ton of wrapping. I would display the skill facts in text and list them so it's easier to see how the numbers change. A majority of changes are damage and healing numbers and the additional formatting isn't helpful. It's only useful for effects and I would use {{effect}} there (The template doesn't include the description in the tolltip although that would be a good idea). --Relyk ~ talk < 03:26, 8 September 2016 (UTC)
- I'm hardly familiar with all the available templates on here, so thank you for your suggestion Relyk. I've updated the example page section - it looks quite a bit cleaner, though the code to create this table is a bit messy. There is still room for improvement (my suggestion would be grouping skill facts like range, radius and duration to a single column). Addendum: Maybe we should merge cells that have the same variable, example at the bottom of this german tech news site. -Nefastu (talk) 15:40, 8 September 2016 (UTC)
- There is now a merged cells example over here - the table is a lot cleaner, but the color scheme is broken. Alternating row backgrounds could be disabled, but do we want that? -Nefastu (talk) 00:02, 9 September 2016 (UTC)
- Relyk added another idea (thank you!): Game updates listed in a horizontal layout (see here). There are two more examples that I've added for this layout, to showcase its design. Personally, I prefer this over my suggestion, as it is easier to read and easier to create. What do you think? -Nefastu (talk) 08:25, 17 September 2016 (UTC)
- There is now a merged cells example over here - the table is a lot cleaner, but the color scheme is broken. Alternating row backgrounds could be disabled, but do we want that? -Nefastu (talk) 00:02, 9 September 2016 (UTC)
- I'm hardly familiar with all the available templates on here, so thank you for your suggestion Relyk. I've updated the example page section - it looks quite a bit cleaner, though the code to create this table is a bit messy. There is still room for improvement (my suggestion would be grouping skill facts like range, radius and duration to a single column). Addendum: Maybe we should merge cells that have the same variable, example at the bottom of this german tech news site. -Nefastu (talk) 15:40, 8 September 2016 (UTC)
- I have to admit, that the table is indeed more compact and holds all relevant information. I really like the separation between cast, pulse and end effect and it is clearly visible in which column a change has taken place. But personally I still tend to prefer the infoboxes, though it is difficult for me to pin down advantages. I would say it is far easier to isolate a certain version of a skill from infoboxes than the table, mostly because of the distinct headers but also because of the compressed style of the table. It is simple to reach a specific version from the TOC (but that could be fixed). Furthermore I think infoboxes would be better for skills whose effects have been completely changed (do we have some of those?) where a table could imply continuity for the wrong reasons. Finally, as traits are far more diverse than skills in their effects and requirements, it would be a substantial amount of work to create a framework for the table while it is already possible to have a standardised design with infoboxes and skill facts. --Soulblydd (talk) 07:47, 6 September 2016 (UTC)
Table layout[edit]
Continuing from the discussion on this talk page, I'm not sure about the layout of my skill history tables. If you have thoughts on these tables, please post.
Placement of the table within the skill/trait page should be in a fixed spot as well. In my example I've put it above the Notes
section. Should it be placed elsewhere? -Nefastu (talk) 23:30, 29 August 2016 (UTC)
- I would move it below Notes, but keep it above Trivia. The note section generally addresses only the current version of the skill, while the history section will focus on past versions. Therefore I assume the skill history will be less relevant for most users looking up the function of a skill/trait. --Soulblydd (talk) 09:32, 30 August 2016 (UTC)
Full page history layout[edit]
The style for the full page history is copied from the GWW (example here). Should it be improved? -Nefastu (talk) 23:30, 29 August 2016 (UTC)
- With regards to this, I think the layout should show the changes between each skill in a clearer fashion. I'm thinking maybe have the skill changes bolded/colored/whatever before the infobox, and if possible highlighted again in the infobox (although that last one might be painful to do). As it is now, I find it hard to quickly see the difference between each skill. -Darqam (talk) 23:58, 29 August 2016 (UTC)
- Agreed, I also think File:Historic content.png (we had it on our historical template before) is rather ugly - maybe use another quaggan icon for it? —Ventriloquist 09:17, 30 August 2016 (UTC)
- Since I haven't found a fitting quaggan icon in Category:Quaggan icons, I created File:Historic content quaggan icon.png, an edit of File:Historical content.png. Is this better than the old image? -Nefastu (talk) 13:11, 30 August 2016 (UTC)
- Agreed, I also think File:Historic content.png (we had it on our historical template before) is rather ugly - maybe use another quaggan icon for it? —Ventriloquist 09:17, 30 August 2016 (UTC)
- The example page now has two more revisions, with the newest being a version with icons added like or Stability. Does this improve readability? -Nefastu (talk) 13:11, 30 August 2016 (UTC)
- (Reset indent) Comparing Lava Font/Skill history with Guild Wars 2 Wiki:Projects/Skill Version History/Example/History, and considering the base I think we should leave out "changes" that didn't modify the expected workings of the skill such as "removed visual clutter", "added this skill fact" or "fixed that bug" from the full skill page and only document them in the table on the parent page. Similarly I'd like to add skill facts retroactively. In the example Lava Font, the skill fact of five targets has been added in June '14. But since the skill (presumably) never had an higher target cap, I'd also add the respective skill fact in the skill box of the original release. --Soulblydd (talk) 21:34, 30 August 2016 (UTC)
- Yeah, the main reason why I stopped doing those big pages is because I couldn't figure out a nice way. I'm in agreement with your statement, however I would ask that someone else than myself do those pages. I have very little experience with those things and I think someone who knows the minute details of it would do a much greater job than I. -Darqam (talk) 21:44, 30 August 2016 (UTC)
- Agreed. The table on the main page should include all mentions of said skill/trait/effect from game updates, while the full page history should only include changes that alter information included in the infobox. Regarding skill caps, there are some skills like Static Field (staff skill) that were uncapped (in that case, one should write something like "Reduced target cap to 10 (was previously unlimited)", so including the target cap for older versions may not always be right. I'll create a formatting guideline probably tomorrow. -Nefastu (talk) 21:44, 30 August 2016 (UTC)
- So far, the history page consists of two parts: the version history notice as well as the table that contains the changes. My suggestion: Create infoboxes for each version and put/hide it in a tabbed view (example), so that the reader can switch between the versions. -Nefastu (talk) 08:46, 17 September 2016 (UTC)
Implementation[edit]
Heya, so since my design idea are usually shotty, I'll let those mainly go to someone else. Until then I'll try and start re-creating the skill pages whenever I can (probably only really start on Thursday). For now I guess I'll put them in places like Guild Wars 2 Wiki:Projects/Skill Version History/Elementalist/Fireball. Once the project has a decided format I can easily go back to them and change them to the new accepted format.
If there is a better place to put these pages in the mean time speak up, if not I think I will leave them all in their own separate subpage of their class subpage. -Darqam (talk) 13:53, 30 August 2016 (UTC)
Scratch that, for now only making the tables here since they will just be copy-pasted anyway.-Darqam (talk) 22:46, 30 August 2016 (UTC)
Version history table templates[edit]
Since there is quite a number of tables that need to be created, I've created two templates that I suggest we should use: User:Nefastu/Sandbox (to be moved to {{Version history table row}}) and User:Nefastu/Sandbox2 (to be moved to {{Version history table header}}). The idea is taken from the Path of Exile wiki (row template, header template). I have very little experience with creating good templates, so please tell me what can be improved and/or modify the templates yourself. -Nefastu (talk) 16:27, 6 September 2016 (UTC)
- I've gone ahead and created {{Version history}}, {{Version history table header}}, {{Version history table row}}, Category:Version histories and [[:Category:Unchanged version histories]]. Regarding categories: My intention is to use sub-categories for skills/traits/effects to easily browse skills/traits/effects version histories only. Are these sub-categories created automatically or do they need to be created via template? -Nefastu (talk) 01:30, 8 September 2016 (UTC)
Table entry formatting[edit]
Game updates notes differ quite a lot - I suggest we should improve readability by formatting every entry by some guidelines (for example: splitting every change by bullets). What do you think? -Nefastu (talk) 01:23, 8 September 2016 (UTC)
/History page layout - what format do we want?[edit]
So I want to push this discussion: What format do we want for /History pages?
- Use skill/trait infoboxes?
- Use a table?
- What layout should be used for these tables?
- Use something else?
My own opinion to these points:
- We use infoboxes for the base page, as they represent how the skill is shown ingame. With a history page, we should use these so that the reader can see how any given skill or trait looked like in a previous version, especially if said skill or trait has undergone significant changes (example Mimic).
- Infoboxes do not showcase smaller changes (i.e. "Reduced cooldown by 15 seconds.") well, while a table is great for this. However, creating and updating these tables can (and will) be cumbersome. Still, I'd think this would be worth the effort. Maybe one or two templates could help as well to reduce the time required to create and update these pages.
- From the examples as well as some of my own testing, putting the game updates as column headers and effects as their own rows would the best and cleanest solution for this. While the changes are included as their own row in the example linked below, I don't think we should keep them there, as they bloat the table. I've put a version without the changes row at the bottom of the second example link - maybe a way to highlight one version in the table would improve readability to one version only (clicking the game update column highlights all cells that are in its column; maybe mouseover highlights cells and shows a styled tooltip under the table with the changes for this game update).
Examples are here and here. I want your feedback! :) -Nefastu (talk) 14:56, 11 October 2016 (UTC)
- I'm a fan of at-a-glance information, and I think our readers have been trained to see skills laid out in a more traditional format. Those tables do pass on solid information, but some of those are a tad unintuitive for people to just peruse. Also, I'm picturing some nightmares when it comes to keeping those headers working, especially for skills which have undergone some dramatic mechanics overhauling.
- The examples with the boxed text showing the changes is amazing; I also see that part taking up a lot of time. If they were to be included, would they be done on a second pass? G R E E N E R 17:51, 11 October 2016 (UTC)
- Thank you for your feedback! I don't think creating/updating the infoboxes (with the highlighted changes) takes too much time -
- for creating, all information is already gathered for the base page (Example) - so a bit of rewording for concise update notes as well as copying, pasting and modifying the infobox from the base page is still less work than gathering update notes for a specific skill and creating the version history table for the base page.
- for updates, my intention is to gather all skill/trait updates from the latest patch here, then update the infobox + version history table on the base page, with the infobox change + concise update notes on the /History page following right after that.
- (I don't exactly know what you meant with 'second pass', so here are my intentions regarding creating/updating version histories) :) -Nefastu (talk) 21:44, 11 October 2016 (UTC)
- Thank you for your feedback! I don't think creating/updating the infoboxes (with the highlighted changes) takes too much time -
- Hey guys. I've been thinking about this project, and have been drilling for data this evening. list of all skills which have been mentioned in updates, with nearest page edits. I'll be doing some more thinking tomorrow, but I expect I can pull the raw wikicode for the infobox for every revision id on that page. I'm not yet sure how i'll pull a useable wikicode string from each update page but it should be possible to slam down all the wikicode at once. -Chieftain Alex 23:18, 12 October 2016 (UTC)
- Obvious caveats to this method:
- if someone did a junk edit immediately after the update but before making the true notes, that revision would be pasted instead.
- if the skill infobox code has changed significantly the oldest wikicode might not work at all and will need further adjustment.
- although I might be able to take all the raw page data and paste it into notepad++ then use AWB to apply it with a robot, it may not be good enough and require a user to visit each page and run a script (yuck).
- -Chieftain Alex 23:30, 12 October 2016 (UTC)
- Obvious caveats to this method:
- Interesting, thank you. There are some points I'd like to address:
- Regarding junk edits: currently you're grabbing revision id's just after a game update (which mentions the skill) has been introduced. Why not grab revision id's just before such a change has been introduced?
- Not all mentions of a skill mean a skill change and not all skill changes mention the skill, example Magic Bullet: What I found are 2013-03-26, 2013-06-25, 2014-05-20 and 2015-06-23. Compared to your list, 2014-09-09 is included and 2015-06-23 is missing because in the first update, its mention is due to a bugfix for a trait interaction with said skill; in the second update it is due to the skill not being mentioned.
- Maybe since we are gathering changes manually, a tool to grab revisions by inputting dates would be better? -Nefastu (talk) 13:06, 13 October 2016 (UTC)
- Interesting, thank you. There are some points I'd like to address:
what qualifies for an update entry on the /history page[edit]
So far I've decided what qualifies for a spot on a /history page this way: If the game update changes how the skill works and something from the infobox has been changes, it should be put on the page.
Now there are some skills and game updates that really don't fit to this: example Into the Void, /history. If I apply my "filter" to the /history page, it would have only one skill infobox, indicating that this skill has not been changed.
My question is: what qualifies for an update entry on the /history page?
- Changes to skill behaviour that is documented within the infobox
- Changes to skill behaviour that is not documented within the infobox
- Changes to skill behaviour to fit skill facts (removal of undocumented behaviour)
- Changes to skill facts to fit skill behaviour (that was already present)
- Changes to the description
- Bug fixes
I don't like to clutter the /history page with update entries that don't alter information that is presented on there, so until now I only accepted #1 for entries. But with the example, I tend to accept #1, #2, #3 and #5. I don't think #4 or #6 should be included, but here I am asking for your opinion, so tell me if I am completely right or horribly wrong (or anything that's in between) :) -Nefastu (talk) 07:49, 17 October 2016 (UTC)
- I think 4 and 6 should be omitted as well, that isn't a change to the skill but rather a change to it's documentation or a fix. I think 1 and 5 are definitely worthwhile, but 2 and 3 I'm on the fence. -Darqam (talk) 13:19, 17 October 2016 (UTC)
- We could code the template such that you can show changes without the infobox. Would that be best? (then you could include any bug note you wanted) -Chieftain Alex 20:04, 17 October 2016 (UTC)
- When this page was created, I / we somewhat decided against entries that do not alter infobox information. However, after testing this with the new design over here, I suggest we use this for things that do not alter infobox information, though we should still leave out bug fixes, as most of the time, these are just bugs that have been introduced one or two days before the bugfix. In case of bug fixes of skill behaviour that has been around for a long time, we should consider it being #3 instead of #6, example Swap (I believe this 'feature' was in the game since launch): "Fixed a bug that allowed players to swap places with their clone after it was destroyed.". -Nefastu (talk) 21:00, 17 October 2016 (UTC)
Version history tables for skill type pages (and more?)[edit]
So far I already pushed all mesmer version history tables to their respective pages, but when I did that, I decided to put general updates to clones and phantasms to these pages instead of their skills that summon these: Clone#Version history and Phantasm#Version history. As you can see, these tables are quite big, and although I could have only included relevant information to skill balancing for skill version history tables, I believe this is the better way to put this. There are some points I'd like your opinion on:
- These tables do not fit precisely to the concept of this project: table plus /history page. Should this still be used for these pages? Should /history pages be included as well (though I don't know what kind of more detailed information could be displayed)?
- From gathering information from previous tables, there are more pages (that are still linked to player skills/traits/effects) that could utilize a history table, examples Minion or Transform. Should I/we create tables for these pages?
- Probably a bit more far-fetched, but should tables be created for pages that have nothing in common with this project, examples Xera, World versus World, Activity, Mastery?
These are some of my ideas for this project, maybe these could improve the GW2Wiki, maybe not. You tell me :P -Nefastu (talk) 00:05, 21 October 2016 (UTC)
Meaning of 'updated'[edit]
Reasons/examples why I bring this up: Weak Spot/history, Zephyr's Boon/history. When should we declare a skill/trait to be updated/changed through a game update?
- Major changes to the skill/trait (e.g. added feature, recharge reduction, moved to another trait tier/type).
- Changes to graphics ("reduced fx noise").
- Changes to tooltip/interface appearance: description updates/skill fact changes (e.g. "updated skill facts to reflect skill behaviour").
- Specifically for traits: Changes due to the specialization update (new icon, specialization/trait line rename).
- Bug fixes
Currently I'd say 1 yes, 2-4 leaning towards no, 5 no. Meaning only if a skill/trait has been changed so that it affects balancing, I consider it to be changed. But because I'm not confident enough on points 2-4, I'm asking here to find out a clear answer. —Nefastu (talk) 13:58, 30 October 2016 (UTC)
Skills that are no longer split[edit]
Example: Game updates/2017-02-22, Arc Lightning. How should we handle this? Keep the PvP version page, delete it? Remove the /history page of the PvP version or keep it? —Nefastu 19:42, 22 February 2017 (UTC)
- I would delete the /PvP page, but keep the /PvP/history separately from the /history and link to it from (inside) the table. --Soulblydd (talk) 19:47, 22 February 2017 (UTC)
Traitlines[edit]
I've created a mockup for a traitline history page in my Userspace. I'd like to link it on the traitline pages but I don't think that a full overview table on the traitline page is necessary. --Soulblydd (talk) 09:10, 29 July 2017 (UTC)
- I'd put that on Strength/history and link it from the Strength page, without the usual version history table. Regarding the format: the wide table is fine on a 1920x width display, but certainly not for smaller displays. Maybe we should change the format similar to other /history pages? —Nefastu 08:10, 8 August 2017 (UTC)
Special updates[edit]
Hey, so with today's update we will most likely see balancing for PoF as well as the introduction of new mechanics (barrier, count stacks/recharge). Since the 2015-06-23 specialization patch changed/prepared some things for the 2015-10-23 HoT release, should we add an additional line to Template:Version history table row? Since I cannot come up with a good name for this update, maybe you can help me out. Path of Fire pre-patch is currently my idea. —Nefastu 07:56, 8 August 2017 (UTC)
2022 review and updates[edit]
I've cross-compared all instances of Template:Version history table row with the various /history subpages and made amendments to 355 subpages + a bunch of the main pages too to align dates/notes and add missing updates. I think the two are broadly aligned now. The checklist subpages for this project will inevitably be out of date as a result of this.
We've been fairly good at updating the patch notes on the subpages from about 2021 onwards, however I was mostly finding we missed them between 2018 and 2021. -Chieftain Alex 12:41, 31 July 2022 (UTC)