Path of Exile Wiki talk:Community portal/Archive 7

Categorization fixes
I noticed several categorization errors through Special:WantedCategories and was wondering if there is a designated bot account to handle such a task, or if I should do it myself (I'm familiar with AWB). These are the fixes needed: Thanks, ~Bobogoobo (talk) 06:47, 9 September 2017 (UTC)
 * Category:Body Armour icons -> Body armour icons
 * Category:Boots icons -> Boot icons
 * Category:Gloves icons -> Glove icons
 * Category:Stave icons -> Staff icons
 * Done.--Kordloperdlo (talk) 10:08, 23 June 2020 (UTC)

ref link format
I think reference links changed their format recently. Of the [1] notation, the opening bracket and the number are a link and in the yellow-ish link colour, whereas the closing bracket isn't. I might be wrong, but I think all of it used to be a link. Anyway it looks rather odd and I doubt it is intended. --aRTyficial (talk) 05:32, 16 September 2017 (UTC)
 * That's really odd. I think we might need to bring in the Gamepedia folks to look at this, although it's somewhat of a minor issue. —Vini (t|c) 06:09, 16 September 2017 (UTC)

Map Vendor Results as Properties
I wanted to suggest including the 3 to 1 map vendor options in the (map) item template (or a separate template) which adds that information as page properties and can also handle a unified display format. We could also mention maps that are connected on the atlas and are not already covered by the vendor recipe upgrade path. --aRTyficial (talk) 14:37, 20 November 2017 (UTC)
 * Yeah, it's something I've planned on adding. Actually I've a system in general to support any arbitrary vendor recipes to obtain specific items. --OmegaK2 (t|c) 11:46, 21 November 2017 (UTC)
 * What's the current status on this? I've seen a test edit but I think it currently does not display anything based on that. Are those parameters fine to use? If so, I'd like to put them in all War for the Atlas map articles.
 * Is there any interest to document connected maps? I wanted to ask before I start editing the 140ish map articles. --aRTyficial (talk) 16:52, 11 January 2018 (UTC)
 * I can't say I've tested this extensively since the port to cargo, but it should be working. supports the display, but it won't show anything in the infobox currently.
 * There is connection info on the area data, but I believe you mean the atlas connections which seem to be different. I believe I can pull this from data if necessary, not sure what use it really has though --OmegaK2 (t|c) 18:58, 11 January 2018 (UTC)

Lapis Amulet
Lapis Amulet should have more unique variant, but the list was generated by a template, is it a SMW problem? Neokowloon (talk) 17:01, 16 December 2017 (UTC)

Cargo caching
Can a regular editor solve cases where wrong information is displayed to due cached cargo data? In particular I tried to correct List of unique maps earlier (eventually leaving it as is) and now I've got a problem at Basilica Map (War for the Atlas) because I accidentally saved a wrong parameter index at first. Even though I corrected it and tried stuff like cache clearing and null edits, the page still displays "Crimson Temple Map" twice under "Item acquisition". --aRTyficial (talk) 05:09, 13 January 2018 (UTC)
 * I'm afraid you're gonna have to live with it until cargo allows attaching/declaring multiple times per template or the modules has been refactored to only attach once per template. When you were null editing you probably just added two/five new rows with the same item instead of updating the specific row. Here's a a list of issues that we're trying to work around. --Illviljan (talk) 06:56, 13 January 2018 (UTC)
 * I've manually overwritten an issue at Heretic's Veil and added the "Category:Cargo caching issue" to it to tag pages that were bandaid fixed. Please feel free to change the category, I just figured keeping track of those cases should help. --aRTyficial (talk) 19:52, 22 January 2018 (UTC)

New map
Should the map release in version 3.1.0 to have the parameter of release version = 3.1.0, because if all updated map were used the same version number, the list in War for the Atlas would generate a list of all map of the update, not that 32 new maps only. Neokowloon (talk) 06:36, 13 January 2018 (UTC)
 * The old maps had parameters like, so started adding the release_version to the new maps accordingly. I don't think an automated list makes sense in the version 3.1.0 War for the Atlas article, in particular not with maps also being renamed etc. which complicates querying for actually new ones. --aRTyficial (talk) 06:49, 13 January 2018 (UTC)
 * I've been thinking of revising that for items to the version the original version was released and just keeping the removal version. I think it probably makes more sense when thinking about version number is queried/used most of the time. --OmegaK2 (t|c) 14:02, 13 January 2018 (UTC)
 * I don't like that version history is being split up either, it makes it much harder to get an overview of the evolution of the item. That's something that could be solved with  or similar for example. --Illviljan (talk) 10:13, 14 January 2018 (UTC)
 * Allright, since everyone seems to agree with this let's use the initial release version of an item for this. I'll edit the parameter description to reflect that. --OmegaK2 (t|c) 16:39, 14 January 2018 (UTC)

Map redirects
Currently a lot unsuffixed map names redirect to the "(Atlas of Worlds)" Map articles. Should we start converting them into disambiguation pages, change the redirect to "(War for the Atlas)" or delete them entirely after adjusting old links? --aRTyficial (talk) 07:55, 14 January 2018 (UTC)
 * I think we need to be a little clever about this so we don't double the workload unnecessarily because this will happen again. Can we create a template for this? The use cases it needs to be able to handle that I can think of is:


 * 1) Appended suffix.
 * 2) Suffix change.
 * 3) New map name.
 * I'm more in favour of redirects than disambiguation pages because I think it's enough to maintain all those map pages. But disambiguation pages can possibly be generated if the template is clever enough.
 * --Illviljan (talk) 10:06, 14 January 2018 (UTC)
 * Conditional redirects do not work it seems, but I actually expected that. Maybe I've misunderstood what you mean with template, but with centralized redirects out of the picture, I think most of your suggestions fall flat, right? --aRTyficial (talk) 10:45, 14 January 2018 (UTC)


 * Not sure i done it right or not, i converted some redirect into Category:Disambiguation pages. Neokowloon (talk) 19:51, 14 January 2018 (UTC)
 * The problem with this is that it multiplies necessary map edits by two next league (slight exaggeration), editing map page AND map disambiguation page, I think it's enough to maintain just the map pages. But my "simple" idea was squandered unfortunately so maybe this is the way to go for now. --Illviljan (talk) 22:45, 14 January 2018 (UTC)
 * I think the disambiguation pages can be handled automatically. We create something like  and let it list all articles that have the page base name and a suffix. Since the suffixes are standardized, we can even include comments about the version number based on those. --aRTyficial (talk) 03:53, 15 January 2018 (UTC)
 * exists now. I didn't start putting it into pages yet because I wanted to wait for confirmation. --aRTyficial (talk) 07:54, 15 January 2018 (UTC)

Hey, that's not bad! I was thinking we would just create redirects, but this seems easier to manage. —Vini (t|c) 15:27, 15 January 2018 (UTC)
 * would this template created by other, to better use in the disambiguation page? Neokowloon (talk) 06:07, 16 January 2018 (UTC)
 * Currently the templates do similar things, but they are for different use cases. Technically one could create one template that does both, but I don't think that would be any better. --aRTyficial (talk) 08:36, 16 January 2018 (UTC)
 * I made before I saw this discussion, but it seems like it doesn't go against anything said here(?). I finished adding it to all the War for the Atlas maps a little while ago. I plan on adding it to the others in the next day or two unless someone tells me otherwise. --AnSq (talk) 15:14, 16 January 2018 (UTC)
 * Seems perfectly fine to me. --aRTyficial (talk) 15:15, 16 January 2018 (UTC)
 * Someone turned the disambiguation page back to redirect page (Special:Diff/410614), so that is the consensus? Neokowloon (talk) 07:15, 17 January 2018 (UTC)

F3llen changed a few Atlas of Worlds redirects to War of the Atlas and then added a few redirects to disambiguation pages. I don't think he saw the discussion here. Using the redirect there is not the consensus. --aRTyficial (talk) 13:51, 17 January 2018 (UTC)
 * Can the disambiguation block just be a section of the map page itself? There's barely any reason to examine the old versions and it just gets in the way of navigation 99% of the time.

Mass replace per bot?
In every skill gem article  needs to be replaced with   twice, once each in the sections "Quest reward" and "Vendor reward". This seems like a typical bot task, right? --aRTyficial (talk) 11:35, 15 January 2018 (UTC)

Disambiguation Pages and Redirects
I would like to propose that we adopt a similar strategy for Disambiguation Pages and Redirects that is used at Wikipedia. They prioritise the most referenced/looked up article over others. I realise this is subjective but I believe I have two instances that most people would agree with as the most common use case.

So for example with maps, when searching for  I should get the current   version, not a disambiguation page. Each map page could list a similar header like. When a new version is released, to avoid a mass reshuffling we could make the map name page a simple direct to the current version. So it would just be a matter of running a bot to change the redirects to the latest version. The disambiguation pages already automatically add new versions.

This could also apply to searching for support skill gems. Right now the primary page for a name is often the mechanic, buff or passive tree node when you search for a gem without the word. But very few if any build guides actually include the word  in the skill gem name list. This is likely people's first use of the wiki too, to determine how to obtain them. Experienced players likely still do this too for quality, level thresholds (I know I do) more often than they are trying to research specific mechanic, buff or passive tree node for a build. Critical Strikes or Area of Effect should lead to the support gem, instead of the mechanic (it doesn't disambig the skill gem even) in my opinion.

--Ofbeaton (talk) 16:07, 22 April 2018 (UTC)
 * I think the important part here, which was missing from the previous map redirect discussion, is that this will apply to the built-in wiki searches and it should help people finding what they want a bit more easily.
 * The changes themselves are for the most part pretty much doable by bot. It would essentially entail 3 steps
 * 1) redirecting the pages to the current version
 * 2) creating new disambiguation pages for each map name
 * 3) adding a disambiguation header to each of the redirected map pages (that template would need to be created)
 * It should be a similar procedure for support gems, though it may require some manual fixing for cases where there are overlaps with other mechanics sharing the name.
 * Overall I think this seems like a better solution then what we have now, so I'm pretty much in favor of this --OmegaK2 (t|c) 16:50, 22 April 2018 (UTC)
 * Redirecting the map name to the current version of the map instead of showing a disambiguation page makes sense. Redirecting critical strike to Increased Critical Strikes Support seems daft when there is already an established article there that describes the game mechanic. —Vini (t|c) 18:11, 22 April 2018 (UTC)
 * The argument is that people search for support gems much more than game mechanics/buffs/keystones, and build guides shorten the names of support gems and that's how they are quick searched in the wiki bar. So instead of exact name, the thing people most likely mean should win, not the thing that is technically most accurate. But like I said it's a bit subjective, so if consensus cannot be reached on a specific redirect obviously it should stay as it is. Headers pointing to alternate pages can help a lot. This is what Wikipedia does because it makes the most sense to the user, instead of what makes the most sense to the editor. --Ofbeaton (talk) 18:22, 22 April 2018 (UTC)
 * There is a concept in the game called "critical strike". It just makes sense for the article by the same name to describe that concept. If you search for articles containing the word "crit", the support gems appear within the top few results. —Vini (t|c) 18:47, 22 April 2018 (UTC)
 * The map redirect is good. I disagree with the gems though. "Pierce" as a mechanic is at least as important as "Pierce Support"; the Pierce mechanic article can have a note/link at the top to make the other page easily accessible, but turning "Pierce" into a simple redirect and thus creating the need for an article name like "Pierce (game mechanic)" seems horrible.
 * We can consider popularity with existing redirects like "Critical Strikes" (with ending s) which currently leads to "Critical strike". I would not mind having that one lead to "Increased Critical Strikes Support" instead, since it is not forcing another article away. --aRTyficial (talk) 22:22, 22 April 2018 (UTC)
 * Critical strikes correctly redirects to critical strike. It shouldn't go to a different article just because you've pluralized it. I suppose an argument could be made for redirecting Critical Strikes (capital 'S') to Increased Critical Strikes Support. —Vini (t|c) 23:16, 22 April 2018 (UTC)
 * Critical strikes correctly redirects to critical strike. It shouldn't go to a different article just because you've pluralized it. I suppose an argument could be made for redirecting Critical Strikes (capital 'S') to Increased Critical Strikes Support. —Vini (t|c) 23:16, 22 April 2018 (UTC)

In Wikipedia,  goes to the insect. redirects to  the band. Clearly pluralisation can change context.--Ofbeaton (talk) 00:34, 23 April 2018 (UTC)
 * That's an interesting exception. I congratulate you for finding it. —Vini (t|c) 01:46, 23 April 2018 (UTC)
 * I disagree with both aRTyficial and Vini. If poe build guides reference "link with  and  " and that is the most common searched term for the skill gem, then we should direct users to said skill gems, and have a header pointing out   exists. That is because I believe users search for gems far more than they ever look up mechanics or buffs. The fact we currently bring up a mechanic (for Critical Strike) without the user even knowing how to search for the gem I think is a bad user experience. At least   has a header pointing out the support gem, though even in this case I would argue we should have a   and make the main Fortify the skill gem. Clearly such a change would not be popular amongst editors, but as a user we should support the most common thing people mean, not perfect article titles / organisation. This wiki is meant to be used, not just for prosperity/history/index. In my mind, it is a question of are there enough vocal users to purist editors, though even Wikipedia goes for usage instead of purist categorisation at this point. But maybe I am wrong about usage patterns? Do we have stats for pages? And for disambig links? --Ofbeaton (talk) 00:34, 23 April 2018 (UTC)

You are very opinionated about the way you personally would like it to work. I believe that there is merit beyond being a "purist" to having the concept name direct users to the article describing that concept. It's a matter of maintaining sanity in organization. —Vini (t|c) 01:34, 23 April 2018 (UTC)
 * For sure I'm opinionated, just like you are sharing your personal opinion on how you think it should work. I thought the point of this discussion was to see if we could reach consensus, though this is the internet. My main interest is in trying to apply https://en.wikipedia.org/wiki/Wikipedia:Disambiguation#Is_there_a_primary_topic? to this wiki, as I personally believe it is good policy. "is primary for a term...if it is highly likely...to be the topic sought when a reader searches for that term." The last part is the key point I am trying to make. But I fully acknowledge that I may be wrong in the support skill gems being the primary topic. But I notice you haven't said anything to prove the mechanic or buff is either, aside from the names match. It seems we all agree that for maps the current league maps should be primary (not disambigs themselves). --Ofbeaton (talk) 01:52, 23 April 2018 (UTC)
 * You're the one proposing a change to the existing consensus, my dude. Following Wikipedia's guidelines, the primary topic for "critical strike" is the in-game concept, critical strike. The Increased Critical Strikes Support gem is a subordinate concept to critical strike, and therefore a secondary topic. —Vini (t|c) 02:01, 23 April 2018 (UTC)
 * I was going for the contention in the topic that is being searched, and the page the user is ending up at. This could also apply In a few cases, there is some conflict between a topic of primary usage (Apple Inc.) and one of primary long-term significance (Apple). In such a case, consensus may be useful in determining which topic, if any, is the primary topic. The key here is really search, and how the wiki will not return search results but send you directly to the page. I do content that the fact users cannot search for the names of support gems as they appear in common usage in build guides and end up on the skill gem is not the desired behaviour. But I guess that is where we disagree. And since I have made the mistake of responding to you in the hopes of convincing you, I have drowned out any hope of meaningful discussion occurring in this now page long section or other voices joining in. --Ofbeaton (talk) 02:15, 23 April 2018 (UTC)
 * @Ofbeaton: I am entirely for proper search results, search autocomplete and redirects, aswell as easy page navigation and good user experience. I'm partially opposed here because I think there are a lot of assumptions being made about user behaviour and article popularity. In other wiki projects I worked on and even for the wikipedia the typical trend seems to be that people follow links or use google to access wiki pages, the wiki search bar itself is surprisingly unpopular. Sticking to the given examples I could just aswell argue to redirect to "Increased Critical Damage Support" because crit builds often favour the multiplier gem over the chance gem. If we had an actual name collision and had to decide whether "Critical Strike (support gem)" or "Critical Strike (game mechanic)" gets the right to lose the suffix and become the main page with a disambiguation header, then I would also favour the gem. This is not the case here though. If people see the item ingame and look up the name, they should get the right page. If they use google instead of the search bar, they likely get the right page. If people read a guide with posted gems, linked items or fully written gem names, they have the right gem name. As I said I am also in favour of looking at existing redirects, things like "Crit" certainly do not have to redirect to the game mechanic, having a gem or disambiguation page is likely the better option. Putting more disambiguation headers/notes into pages where needed is good, and I already supported it in my comment above. Moving main articles around on a guess what kind of shorthand people might use due to guides is the issue.
 * I'd also ask you to not squeeze in cheap shots like "editor vs. user" or insinuate that we are stubborn and destructive. Discuss the project, not people. --aRTyficial (talk) 02:22, 23 April 2018 (UTC)
 * Thanks for your reply aRTyficial. It was really well thought out and expressed, I can see your counter-argument clearly. You make a good case why it should not be changed. I agree about the cheap shot, I apologise and will strive to do better. I will settle on adding a disambiguation header where appropriate then, like found on the Fortify page. --Ofbeaton (talk) 02:31, 23 April 2018 (UTC)
 * If you enter a term into the search bar that matches exactly with the name of an article, then yes, it returns that article. Searching for articles containing a term is slightly more effort, but still possible. I contend that a solution which maintains sanity of organization is to make liberal use of disambiguation hatnotes. —Vini (t|c) 02:28, 23 April 2018 (UTC)
 * That is a great point about search OmegaK2. It is really important to note that if you search for a title and a page with that exact page name exists (or a redirect), you don't get search results, you get sent to that page instantly. This can be really confusing for users, especially if the result is not what most people expect.--Ofbeaton (talk) 00:42, 23 April 2018 (UTC)
 * Just my 5 cents if we do any kind of a voting here. In case of "Critical Strikes" support/mechanic I would like it to stay as is because as an experienced player I often search mechanics pages for a list of related unique items and skills. As for maps, it should be changed as discussed above. However we had an issue before when a bot updated maps but didn't update redirects and didn't create new ones. If this task can be automated then it would be nice to do the change. &mdash; thefrz &mdash; 05:43, 23 April 2018 (UTC)
 * I agree with Vini here. I don't think the skill gem pages are important enough to warrant a redirect in this case. I do like the idea of the map redirects though. --Climmels aka SirProblematique (talk) 09:51, 23 April 2018 (UTC)
 * For the cases where there are no existing pages I've made redirects for support gems without the "support" part at the very least. Won't have to override any topics about a specific topic in that case. I think the same could probably done for lower case variants and so, but that would be require a bit more double checking (for instance, I think Critical strike and Critical Strike for instance should be all be mechanics redirects).--OmegaK2 (t|c) 06:21, 26 April 2018 (UTC)
 * I have applied the redirects, map disambiguation pages and hat notes etc via bot (hat notes are still running as I write this) --OmegaK2 (t|c) 14:38, 25 May 2018 (UTC)

Adding skill modifiers (gear + jewels) to relevant skill gem pages
Hello, as a new player I've found myself continually surprised by the interactions of skill gems with gear and jewels that I did not know previously existed. I've since learned to scan the "list of unique jewels" page every time before assessing a skill gem, but I still struggle to locate all the relevant gear and enchantments. For example, some unique gear provides a skill on its own (or a similar skill, like Molten Burst), or grants it via modifiers (like shaper/elder affixes). Certain enchantments modify a skill gem as well. It's difficult to keep track of them all.

Would it make sense to add a section on each skill gem page titled something along the lines of "Interactions with items", then list the unique jewel along with relevant enchantments, followed by a second list of any gear/mods that add the skill or might otherwise have some interaction with it?

This could also be an opportunity to list which other support gems interact with the active skill. To an extent many skill gems already offer this bit of information, but it's not always complete. For build purposes having a concise, bulleted list of applicable supports could also be a convenience.

Obviously this is a huge undertaking. I'd only do it as I run across examples in my own research. I just wanted to see what the authorities here think, who have a more experienced grasp of what's best for the wiki.AnAdorablePuppy (talk) 08:36, 8 May 2018 (UTC)
 * In general, we already have enchantments via and threshold jewels via  (though it might be missing on some pages, feel free to add those templates).
 * I think adding a list of items that grant the skill or support via modifiers, as well as a list of modifiers that can appear on rare/unique items makes sense. It's best this is done via templates as well though.
 * Interactions with supports is very specific to the particular skill, so these sections are always done manually. I think it only warrants mentioning some unusual or unexpected interactions though, not standard interactions (for example, it that adds damage to the skill is something NOT worth mentioning). There are a ton of support gems in the game and it would clutter the page too much if you started to list everything.
 * Similar skills should be added manually under "see also" at the bottom of the page.--OmegaK2 (t|c) 11:58, 8 May 2018 (UTC)

Action speed
I have created the article, action speed to describe the concept of faster and slower speed from effects like Tailwind and chill. In game, effects that make the character's action faster are described as "you are faster", while effects that make the character's action slower are described as "you are slower". However, because this is not reflected on the character stat sheet, there is no label to describe the general concept. Being able to describe the concept using a single label would aid in understanding, therefore I would like to label it "action speed". Thoughts? —Vini (t|c) 22:28, 9 May 2018 (UTC)
 * Probably better than slow. The slow page should redirect to action speed instead though. --Illviljan (talk) 04:37, 10 May 2018 (UTC)

Thematic skill descriptions
I propose that the thematic skill descriptions present at the top of articles such as Blood Rage be removed. They were originally copied wholesale from the official site, but that page no longer exists and GGG isn't giving a similar treatment for any new skills. Therefore, keeping these descriptions on the wiki is anachronistic and has no real value for the wiki. —Vini (t|c) 18:23, 20 May 2018 (UTC)
 * Sounds fine to me. --aRTyficial (talk) 14:56, 22 May 2018 (UTC)
 * 👍 &mdash; thefrz &mdash; 05:44, 23 May 2018 (UTC)

Unique items with random modifier lists
Watcher's Eye Prismatic Jewel Limited to: 1  (4-6)% increased maximum Energy Shield (4-6)% increased maximum Life (4-6)% increased maximum Mana &lt;random mod&gt;   One by one, they stood their ground against a creature they had no hope of understanding, let alone defeating, and one by one, they became a part of it. Place into an allocated Jewel Socket on the Passive Skill Tree. Right click to remove from the Socket.

There are a few unique items on the wiki currently that draw their mod pool from a list. For some cases we've added multiple variants to the wiki, but we didn't do this for all items because of the sheer number of combinations (think watchers eye which basically has thousands of combinations).

The problem with either approach at the moment is that either we have a lot of wiki pages that can be annoying if you see a bunch of "duplicates" in item lists, and if you don't add the modifiers, you need to handle all those special cases manually.

I think I could add support for allowing a query for modifiers which pulls ALL modifier data into the item. Technically the item won't have all those stats, but having it set will make it appear in the various item lists. I'm not sure if the stat texts should also appear in the item box, even if hidden initially, it makes it hard to read and makes the infoboxes fairly large, but on the other hand in item lists it might seem odd that you'd have to navigate to the item page to see what the item actually does.

For example displaying a collapsible box in item infobox containing all the pssible modifiers seems a bit messy (see right)

So what are everyone else's thoughts on this? --OmegaK2 (t|c) 14:08, 25 May 2018 (UTC)
 * I prefer the drop down list. I think it will look better if you remove the expand button, for example:


 * Something to keep in mind though is that this might increase the template include size, which is a bit of an issue already. --Illviljan (talk) 16:25, 25 May 2018 (UTC)
 * Yeah, I'm not really sure what the best approach is regarding that. It doesn't make much sense to include that in the hoverboxes, but it probably does for item tables. Since the tables just use the stat_text field I can probably just add it to that, and add some logic that creates two infoboxes, one for the page (including the list) and one for the item hovers (without the list) --OmegaK2 (t|c) 16:48, 25 May 2018 (UTC)

Item classes
The item classes shown in item stat boxes do not reflect what is shown in game. Examples: Every item, as far as I can tell, shows the wrong item class name. The wiki should reflect what is shown in game, where possible. "Sceptres" might be the name of an item class internally, but the game tells players that a Crystal Sceptre is a "One Handed Mace". The internal name for claws could be "Pthblthmpl"; it's irrelevant to what players see in the game. —Vini (t|c) 21:02, 27 May 2018 (UTC)
 * reads "One Hand Maces". In game it reads "One Handed Mace".
 * reads "Thrusting One Hand Swords". In game it reads "One Handed Sword".
 * reads "Sceptres". In game it reads "One Handed Mace".
 * reads "Claws". In game it reads "Claw".
 * I've been meaning to do this for a while, just haven't gotten around to do it because I figured it wasn't very important. I believe non-weapons don't even show item classes at all. A list of what it actually shows so I don't have to look it up for each would probably speed this up--OmegaK2 (t|c) 17:03, 28 May 2018 (UTC)

Removing pages for deleted passives
When updating the passives to cargo I noticed there is a large amount of old passive pages for passives that no longer exist. They basically just only hold information about the passive itself (the name and the stats).

I don't really see the merit of keeping those around. What would be interesting about removed passives is old trees, but those pages don't really hold any of that information and I think knowing that "Chance to Shock" being removed in some version of poe (probably because it just got replaced or a slight name change) is rather useless. They also can not be maintained via bot automatically or updated to the new format. Instead of working on something for the old content or leaving old templates around I'd rather clean that out personally.

Does anyone here has some good reasons to keep those around?

Currently those pages show script errors, but if most people here agree to nuke that I'll just go delete the pages in question. Or restore the template if there is an overwhelming majority that sees the merit in those pages --OmegaK2 (t|c) 10:01, 29 July 2018 (UTC)


 * I don't see any reason to keep pages for passives that no longer exist. Let's nuke 'em. —Vini (t|c) 10:06, 29 July 2018 (UTC)

Leftover SMW code
Don't know how much SMW code snippets are left over throughout the wiki in general, but I have noticed some bits and pieces here and there. One example is on the Blasphemy Support page, with this piece:. Would be nice if the people with the correct privileges and skills could fix this, and other places with leftover SMW code.

Another small thing: Would it be pertinent to show Energy shield as a bullet point under the Game mechanics on the front page? It's an important defence mechanic that may become more popular in the Delve league. --Pangaearocks (talk) 17:42, 28 August 2018 (UTC)


 * Armour, evasion and energy shield are grouped under defences, which *is* listed as a bullet point on the front page. —Vini (t|c) 18:02, 28 August 2018 (UTC)
 * What about replacing 'defences' with 'armour', 'evasion' and 'energy shield' links? 'Defences' is a quite rare in-game encounter (keyword), but AR, EV and ES are meet very often. I am voting for having links to these pages instead of defences. &mdash; thefrz &mdash; 19:36, 28 August 2018 (UTC)
 * The main reason 'defences' is listed instead of all three is to reduce the number of links in that section. If it seems important to list them separately, then let's list them. —Vini (t|c) 20:46, 28 August 2018 (UTC)