Path of Exile Wiki talk:Community portal

Format of modifiers with min and max values are changing in 2.4.0

For those that haven't read today's announcement they're changing how modifiers with min and max values are displayed.

• Before: Adds 22 - 44 Physical Damage, (Template:SMW query mod)
• Upcoming: Adds 22 to 44 Physical Damage

Basically, the opposite of what we're doing. This means a lot of items, unique items, their legacy variants and more I can't think of at the moment will be out of date and very misleading all of a sudden. Nothing truly is sacred in this game. --Illviljan (talk) 08:53, 8 August 2016 (UTC)

Where does it say that they're changing how numerical ranges are formatted? —Vini (t|c) 10:04, 8 August 2016 (UTC)

Look at the first item.--Climmels aka SirProblematique (talk) 10:29, 8 August 2016 (UTC)

Ugh... Earnestly, I have to ask: What is the purpose of this change when the damage ranges are still displayed with a dash in the top section? —Vini (t|c) 10:34, 8 August 2016 (UTC)

Due to a 'specific reason'. — Freeeeez aka TheFrz — 10:42, 8 August 2016 (UTC)

The only thing I can think of is that they want to allow for damage range modifiers with negative numbers. —Vini (t|c) 02:38, 9 August 2016 (UTC)

I've send Chris an E-Mail asking about this, perhaps we can get a bit of a headsup.

In any case, I think it may be wise to come up with a replacement for the (x to y) format. Perhaps just replace the "to" with some sort of special character?

Unicode examples/ideas (x 〜 y) (x 〰 y) (x → y) (x ↔ y) (x ⇄ y) (x ▸ y) (x ⬌ y)

--OmegaK2 (t|c) 17:48, 8 August 2016 (UTC)

Was checking the interval page for some inspiration and [x,y] (or [x;y] for less ambiguity) could be a alternative as well.--Illviljan (talk) 18:28, 8 August 2016 (UTC)

The ranges in headers will not be affected currently and more info will be available in the upcoming announcement according to Chris. --OmegaK2 (t|c) 10:36, 12 August 2016 (UTC)

So basically the ranges will be officially shown as (x-y). This is trivial for me to adjust in the mod exports and any pages that will be using the updated item template, since the mod info is fetched from the mod pages.

What shall we do with the damage headers? They're (x1 to x2)-(y1 to y2) format currency, not sure if it's a good idea to change it to (x1-x2)-(y1-y2). Leave as is? It would be the opposite of the stat text though. --OmegaK2 (t|c) 00:37, 23 August 2016 (UTC)

The current format on the wiki is actually (x1–y1 to x2–y2), not (x1 to x2)-(y1 to y2). Do we want to change to (x1 to x2)-(y1 to y2), or is there a better format? —Vini (t|c) 01:14, 23 August 2016 (UTC)

Uncompressed DDS files from the ggpk for the wiki

If you've been trying to get images for the wiki from the content.ggpk recently, you'll probably have noticed that they are "no valid dds file".

The image files are compressed with google's brotli library. The first 4 bytes of the file are not part of the image data, but rather a byte-size of the uncompressed image. Some "dds" files may also be text file to contain a pointer to another dds file (like *2DArt/Whatever.dds

If you don't want to handle that yourself you can use PyPoE as long you install the brotli library manually, basically follow those steps

• Install Python 3.4 (NOT 3.5) and PyPoE
• Navigate to the brotli releases https://github.com/google/brotli/releases
• Download the lastest wheel for 3.4, i.e. Brotli-0.5.2-cp34-cp34m-win32.whl
• Install with pip install Brotli-0.5.2-cp34-cp34m-win32.whl

Then using the pypoe_ui command in the ggpk viewer, you have check in the options menu that dds files are uncompressed upon extracting them.

Also at this point another thanks to GGG who pointed out what compressing is being used :) --OmegaK2 (t|c) 02:29, 19 August 2016 (UTC)

Naming scheme for items

Hey, currently we have

Two-Stone Ring (ruby and sapphire) (named after 2d art features)

Two-Toned Boots (red and blue) (named after 2d art colour)

Avian Twins Talisman (Fire Damage taken as Cold Damage) (named after stats)

I believe this should be changed to be more uniform, I propose naming things after their stats and not their appearance. It's also cutting a middle step, you can associate the item with the stats right away instead of going through the middle man.

--OmegaK2 (t|c) 08:48, 25 August 2016 (UTC)

This is fine with me. The ruby and sapphire Two-Stone Ring article name can be Two-Stone Ring (fire and cold resistance), for example. —Vini (t|c) 09:22, 25 August 2016 (UTC)

I agree. Though since you brought it up, the Avian Twins' name does seem rather wordy. Perhaps it could be simplified to "Avian Twins Talisman (fire taken as cold)"?

--Connor (Talk | contribs) 09:26, 25 August 2016 (UTC)

I think it's better to stick to the naming of the stats more closely.

Vini used lower case, I matched the case. What's better? --OmegaK2 (t|c) 05:56, 27 August 2016 (UTC)

I used sentence case, which is consistent with what we do on the rest of the wiki. The name of the item is a proper noun, so it gets capitalized. The rest is not, so it's lowercase. —Vini (t|c) 10:04, 27 August 2016 (UTC)

Well, the stat text are in sentence case generally, but I've noticed GGG considers things that have a more special meaning in terms of the game context as proper nouns, i.e. "xxx Damage" (like Physical Attack Damage, Spell Damage, Fire Damage, etc), "xxx Resistances", "Flask", "Critical Strike Chance", etc

Here a good example where you can see it in action:

Cursed Enemies you Kill have a %1%%% chance to Explode, dealing a quarter of their maximum Life as Chaos Damage

In that case you can pretty much tell apart which things have a special meaning the game.

I could argue that if I see such text and come to the wiki as a user I'd expect the spelling to match, not be different. That's why I'd make it like GGG does it on the items. They even do the very same capitalization in other languages as far as I can tell (at least for the ones with roman letters). --OmegaK2 (t|c) 23:15, 27 August 2016 (UTC)

Namespaces for 'data' pages

So it came up that should probably have some name spaces for the more raw data-like pages so they don't show up in the main name space/search. At the same time this could avoid naming conflicts pretty well.

I'm currently considering the following namespaces:

• Area:
• Buff:
• Passive Skill:
• Mod:
• Monster:
• Stat:
• Skill:

Thoughts, suggestions? --OmegaK2 (t|c) 23:01, 27 August 2016 (UTC)

This is a good idea for mod and stat. I'm not so sure about the others - what pages would be moved to these namespaces? We don't want skill names to no longer show up on search, for example. --Qetuth-(talk) 10:46, 28 August 2016 (UTC)

I'm not sure if we need separate namespaces for all of these. We want areas, buffs, skills and monsters to appear in search. The only namespace in particular that I think we definitely need is mods. —Vini (t|c) 11:26, 28 August 2016 (UTC)

They're for "more raw" pages like the mods. I plan to do exports for things not mentioned yet, frz is working on the passives. The idea is to have things with a regular name appear on the main name space. So for example, we'd still have Forest Encampment on the main name space, but the data on Area with a name like which are 3 distinct areas each with sightly data associated with them for example.--OmegaK2 (t|c) 12:29, 28 August 2016 (UTC)

Version 2.4 updating

I'm currently pushing all changes and additions regarding to modifiers and base items to the wiki.

The syntax for ranges has changed from (min to max) to (min-max) to reflect the naming changes GGG did.

Speaking of naming changes, several skill gem progressions probably need updating due to the changes from "Deals x-y damage" to "Deals x to y damage". --OmegaK2 (t|c) 10:29, 2 September 2016 (UTC)

A gem that had issues was Added Lightning Damage SupportAdded Lightning Damage SupportLightning, Support
Icon: L
Level: (1-20)
Cost & Reservation Multiplier: 120%Requires Level 8Supports any skill that hits enemies.Per 1% Quality:1Superior2Anomalous3DivergentSupported Skills deal 0.5% increased Lightning DamageSupported Skills have 1.5% increased Critical Strike ChanceSupported Skills have 1% of Physical Damage Converted to Lightning DamageSupported Skills have (1-21) to (8-402) added Lightning DamageThis is a Support Gem. It does not grant a bonus to your character, but to skills in sockets connected to it. Place into an item socket connected to a socket containing the Active Skill Gem you wish to augment. Right click to remove from a socket., it had the skill progression table displaying N/A. You can use Added Lightning Damage SupportAdded Lightning Damage SupportLightning, Support
Icon: L
Level: (1-20)
Cost & Reservation Multiplier: 120%Requires Level 8Supports any skill that hits enemies.Per 1% Quality:1Superior2Anomalous3DivergentSupported Skills deal 0.5% increased Lightning DamageSupported Skills have 1.5% increased Critical Strike ChanceSupported Skills have 1% of Physical Damage Converted to Lightning DamageSupported Skills have (1-21) to (8-402) added Lightning DamageThis is a Support Gem. It does not grant a bonus to your character, but to skills in sockets connected to it. Place into an item socket connected to a socket containing the Active Skill Gem you wish to augment. Right click to remove from a socket.s skill progression as a template if you wanna help update the rest of the skills with issues.--Illviljan (talk) 11:11, 2 September 2016 (UTC)

Since the "Deals x-y damage" is being changed to "Deals x to y damage," perhaps we should consider the order of those modifiers for all future items on the wiki? Most of the current weapons and such have "Adds (Min₁-Max₁ to (Min₂-Max₂)" on the page, but there are some exceptions such as The ScourgeThe Scourge
Terror ClawClaw
Quality: +20%
Physical Damage: (63.6-81.6) to (205.2-235.2)
Critical Strike Chance: 6.30%
Attacks per Second: (1.65-1.72)
Weapon Range: 11Requires Level 70, 113 Dex, 113 Int2% of Physical Attack Damage Leeched as LifeAdds (35-50) to (100-125) Physical Damage
(10-15)% increased Attack Speed
Minions have (10-15)% increased Attack Speed
Increases and Reductions to Minion Damage also affect you at 150% of their value
Minions deal 70% increased Damage if you've Hit RecentlyWith increasing mastery over death
comes an increasing desire for it. which have "Adds (Min₁-Min₂ to (Max₁-Max₂)" instead. The former one has the lowest value of the minimum and the lowest value of the maximum listed first then the highest value of the minimum and the highest value of the maximum listed second, whereas the latter has both the lowest and highest minimum values together and the lowest and highest values of the maximum together as well. The second one seems to be more understandable since the values in the first parentheses should represent the range of added minimum damage while the second parentheses should be for the range of added maximum values. GGG's own website, as poorly updated as it is, also has that syntax as shown on the prefix mod page. --—Domo (talk) 06:19, 5 September 2016 (UTC)

The mods of unique items will change to be similar to Shrieking Essence of AngerShrieking Essence of AngerStack Size: 9
Essence Tier: 6Upgrades a normal item to rare or reforges a rare item, guaranteeing one property

Bow: Adds (59-79) to (118-138) Fire Damage
Two Handed Melee Weapon: Adds (109-147) to (220-256) Fire Damage
Other Weapon: Adds (59-79) to (118-138) Fire Damage
Armour: +(42-45)% to Fire Resistance
Quiver: +(42-45)% to Fire Resistance
Belt: +(42-45)% to Fire Resistance
Other Jewellery: (27-30)% increased Fire DamageRight click this item then left click a normal or rare item to apply it.
Shift click to unstack.. The uniques needs to be reworked manually though which will take time, see Path_of_Exile_Wiki_talk:Community_portal#Item_template_v2:_Updating_unique_items for more info how to help.--Illviljan (talk) 06:39, 5 September 2016 (UTC)

Item template v2: Updating unique items

I've added support for the unique items to the item template, but it works very different from how the old item template works.

Unique items will fetch their data from the base items, and add any stats from their mods. This means for an unique item, you need to do something like this:

<onlyinclude></onlyinclude>{{Item
|rarity                           = Unique
|name                             = Stone of Lazhwar
|class                            = Amulets
|base_item                        = Lapis Amulet
|flavour_text                     = You are slow, foolish and ignorant.<br>I am not.
|explicit1                        = BlockingBlocksSpellsUniqueAmulet1
|explicit2                        = IncreasedCastSpeedUniqueAmulet1
|explicit3                        = IncreasedManaUniqueAmulet1
|release_version                  = 0.9.3
|alternate_art_inventory_icons    = race season 7, race season 10
}}

Unfortunately there is no proper list of unique items so it means it will have to be done manually to some extend. I pre-generated a list of out matching mod names and flavour text names:

http://omegak2.net/poe/uniques.txt

Those may be incomplete, contain mods they shouldn't or the order may be incorrect. Change things to match the existing unique items. For a more detailed guide on how to set those take a loot at the docs here over at Template:Item#When_to_use_mod_id_and_mod_text

Also the name of the item, the base item and the release_version need to be added. The latter is optional, but should be set.

You may also need to set alternate_art_inventory_icons if there are any alternate art versions of the unique.

Please also make sure the <onlyinclude></onlyinclude> is infront of the item template. The old item template transcludes the pages and transcluding the new item template will cause really big problems. Those tags can be later removed with a bot rather easily once the old template is decommissioned.

Once the unique pages are updated, in a second step the list of xxx pages should be updated using the item module queries. You can base this on similar pages.

--OmegaK2 (t|c) 16:23, 2 September 2016 (UTC)

This looks fantastic, great job. I will help updating the pages manually when I find the time (somewhere tomorrow). --Climmels aka SirProblematique (talk) 20:51, 2 September 2016 (UTC)

Everytime I work up the resolve to convert a item class I run into question marks: How will we deal with race uniques such as Relic of the CycleRelic of the Cycle
Crude BowBow
Quality: +20%
Physical Damage: 11-28.6
Critical Strike Chance: 5.00%
Attacks per Second: 1.54
Weapon Range: 120100% increased Physical Damage
10% increased Attack Speed
+30 to Accuracy Rating
Projectiles Return to you from final TargetInto darkness, horror, madness...
So goes the descent.? Those aren't shown in ordinary unique tables at the moment. Also I can't find modifiers for The ScourgeThe Scourge
Terror ClawClaw
Quality: +20%
Physical Damage: (63.6-81.6) to (205.2-235.2)
Critical Strike Chance: 6.30%
Attacks per Second: (1.65-1.72)
Weapon Range: 11Requires Level 70, 113 Dex, 113 Int2% of Physical Attack Damage Leeched as LifeAdds (35-50) to (100-125) Physical Damage
(10-15)% increased Attack Speed
Minions have (10-15)% increased Attack Speed
Increases and Reductions to Minion Damage also affect you at 150% of their value
Minions deal 70% increased Damage if you've Hit RecentlyWith increasing mastery over death
comes an increasing desire for it..--Illviljan (talk) 17:27, 7 September 2016 (UTC)

I think these uniques should be marked as a limited drop to a certain league, but I guess we can use drop_enabled parameter for now. The modifiers for unique items since version 2.2.0 are messed up and you can only guess does a given mod belong to that item or not. I've put an example how I searched for mods, see UserProfile:TheFrz/test2. Also I had a problem that a mod was marked as a monster mod, so if you can't find a mod you can try to change Had mod domain and Has mod generation type to +. Also keep in mind that SMW strings are case sensitive but I believe you know that — Freeeeez aka TheFrz — 18:31, 7 September 2016 (UTC)

Yeah, the issue for me was that the stat text has links in it. The ScourgeThe Scourge
Terror ClawClaw
Quality: +20%
Physical Damage: (63.6-81.6) to (205.2-235.2)
Critical Strike Chance: 6.30%
Attacks per Second: (1.65-1.72)
Weapon Range: 11Requires Level 70, 113 Dex, 113 Int2% of Physical Attack Damage Leeched as LifeAdds (35-50) to (100-125) Physical Damage
(10-15)% increased Attack Speed
Minions have (10-15)% increased Attack Speed
Increases and Reductions to Minion Damage also affect you at 150% of their value
Minions deal 70% increased Damage if you've Hit RecentlyWith increasing mastery over death
comes an increasing desire for it. has 70% increased Minion Damage if you have Hit Recently which is the stat text I searched for, but the the explicit mod has links in it which is necessary to add in the search to find it. You learn something new every day. --Illviljan (talk) 18:59, 7 September 2016 (UTC)

I believe I read that SMW also has a technical limitation on the first 70 characters on text searches, so searching something at the end might actually fail (I might check when I am back at my home comp). I want to add raw stat text for that purpose at some point. --OmegaK2 (t|c) 06:11, 8 September 2016 (UTC)

The new item template is causing many unique items to lose their artwork because apparently the website can't find it. Is this just something that we wait on for the site to update itself, or do we actually have to go back in and upload those images with the pathing the template seems to want? Many items are not displaying in their tables either due to the artwork not being shown or else something in the new template is throwing it off. —Domo (t|c) 03:02, 18 September 2016 (UTC)

The files simply need to be renamed to use the <item name>_inventory_icon.png naming scheme. You can do that manually if you want, the people updating the pages should be doing it though...

Which items aren't being shown by "else something in the new template is throwing it off."? By not being shown I mean not being in the list AT ALL. --OmegaK2 (t|c) 03:39, 18 September 2016 (UTC)

The page at https://pathofexile.gamepedia.com/List_of_unique_wands is showing less than half of the unique wands that actually exist in game. After going through each of the pages, all those wands do indeed have their artwork but only the ones not showing have been updated to the new template. As best I can tell it looks like the new template was coded properly for at least one of the wands that's not showing. —Domo (t|c) 12:46, 18 September 2016 (UTC)

Think of images as normal pages. The old templated wants File: <item name>.png page, the new templates wants File: <item name> inventory icon.png. If the page exists (and it has an image) it will be displayed as an actual image, if not then it will be displayed as a link to non-existing page (red link). The solution is to rename old icon pages to new ones. As said you can do it manually, but it's much simplier to do so using a bot. I've made one, so just tell me what pages to move and I will do it.

The other thing is fated items and Descent league uniques. These have the same images as other items, and instead of uploading duplicates of these images it's better to say template what image to use with |inventory_icon = parameter.

The problem with wands is that after updating all wands, the old template {{item table}} should be replaced with a new one. User:Tonemis started to update wands but hasn't finished yet, so moving to a new table template doesn't make much sense. — TheFrz — 13:19, 18 September 2016 (UTC)

What Domo is talking about (I surmise) isn't the images as such, but that the unique item is entirely missing from the list. I noticed the same with the https://pathofexile.gamepedia.com/List_of_unique_claws where both Bloodseeker and Essentia Sanguis were missing until I did nul updates to their respective item pages. Likewise Essentia was missing from the unique version section of the Eye Gouger item page until a nul update. Considering it's been over a week since those claw pages were updated to new item template it seems unlikely it's just a caching issue that'll sort itself out, no? If I find any more such items I'll leave the pages as is and drop the names here if that's helpful for tracking the issue down. twitticles (talk) 15:25, 18 September 2016 (UTC)

Addendum: https://pathofexile.gamepedia.com/List_of_unique_daggers is missing both Goredrill and Heartbreaker. Edit: And Fragment of Eternity. https://pathofexile.gamepedia.com/List_of_unique_swords is missing Dreamfeather, Hyaon's Fury, The Princess, Prismatic Eclipse under the one-handed section, more under the other sections. I reckon this applies to every unique item list. twitticles (talk) 15:30, 18 September 2016 (UTC)

It is wiki caching related. Not much you can do about that other then doing null edits --OmegaK2 (t|c) 17:39, 18 September 2016 (UTC)

It's becoming more and more apparent that we're changing templates. The pages that uses {{item table}} slowly looses items and needs to be replaced with a clever query or template. Special:WhatLinksHere/Template:Item_table shows the pages that uses that template. I suspect the league pages are more important since they may be used for zana purposes?--Illviljan (talk) 17:29, 19 September 2016 (UTC)

I think it is adviseable to first finish updating the unique items before going through the item table instances since you can't really update them until all relevant entries are on the new template. --OmegaK2 (t|c) 17:49, 19 September 2016 (UTC)

Hi. I have created a bot called /u/PoEWikiBot running on reddit's pathofexile subreddit. It shows items parsed from this wiki page. I have noticed that many items have stopped working, and saw the notice on the wiki about updating the item template. I am currently just parsing the regular HTTP wiki pages for the item data. The pages themselves are found via the opensearch API (pathofexile gamepedia com api.php?action=opensearch&search=...). Is there another preferable way to find item data for uniques? Is there a specification or something for how the new templates will look? I just made an account to ask this, so I'm not sure I will remember to look back here again. You can also find me on reddit, where my username is also ha107642. -- ha107642, 23 September 2016 (UTC)

I can't promise the things will stay how they are rightsince the template is subject to changes rather heavily. We're also currently discussing using cargo instead of SMW due to some issues, but for the time being I would recommend using the SMW API. Parsing the HTML is a lot of work also causes more load on the wiki I believe.

I see you're reconstructing the item templates, I think using the browsebysubject api has what you need, for example look at the output here:

https://pathofexile.gamepedia.com/api.php?action=browsebysubject&subject=Rebuke%20of%20the%20Vaal

Might want to look at Template:Item to see what properties there are or better yet to a look at Module:Item2 and check their pages about what they do/mean. --OmegaK2 (t|c) 20:52, 23 September 2016 (UTC)

Thank you. Though is it possible to get only the "Has_infobox_HTML" property from the browsebysubject action? Otherwise, there does not seem to be any big gains to have. The browsebysubject json page for Rebuke of the Vaal is 31 kb, while the HTML page is 42 kb. Since I only need to parse the HTML, I don't need to load image/css/js files. But I'm guessing it might also reduce the strain on the web server internally, so I might use it anyway. The browsebysubject approach brings other complications though, as mentioned below by TheFrz. I do not know how I would get an item template from this page: https pathofexile gamepedia com api.php?action=browsebysubject&subject=Vessel%20of%20Vinktar (I don't think I'm allowed to post links). For the HTML version I could just look for the "Variants" header and try to follow the link to one of the items in the list, or something like that. I would need to come up with something similar for the API.

Edit: https pathofexile gamepedia com api.php?action=askargs&conditions=Rebuke%20of%20the%20Vaal&printouts=Has_infobox_HTML <-- This page shows only the infobox, and is thus only 2 kb. However, the problem still remains with "multi-items".-- ha107642, 26 September 2016 (UTC)

You can use the ask api interface to ask general queries like you would on the wiki. I suggest taking a look at the documentation for it, but generally here is an example:

https://pathofexile.gamepedia.com/api.php?action=askargs&conditions=Has%20name::Vessel%20of%20Vinktar&printouts=Has%20infobox%20HTML%7CHas%20base%20item

This basically similar to the {{#ask:}} parser function so looking at smw:Help:Inline_queries might help. Basically this searches all pages that have Property:Has name set to **exactly** "Vessel of Vinktar" (case sensitive), and returns all pages with the other properties Property:Has infobox HTML and Property:Has base item. You can chain multiple conditions by using a |, but please note the wiki has a limit on those.

In your edited messages the condition considered was exactly the page name which will always show that page only.

Browsebysubject is fairly useful to see what properties are available, ask is good if you know what you want. Not sure how your bot is working exactly, but the properties still might be a better approach if you don't watch to parse the HTML boxes which might vary more then the properties would.--OmegaK2 (t|c) 09:35, 26 September 2016 (UTC)

How safe is it to assume that each item has a property "Has name" with its own name? I tried a few, and "Lucky Deck" did not seem to work. If it is just some specific categories which do not work, it is fine. The pathofexile subreddit can only show unique items anyway, so those are the only ones I parse.

I already have the exact name of the page I want to access, and its URL. I get them from the opensearch API, which I call first. Is there anyway to use the page name or URL as a condition? I know little about how these properties are created and such.

If you are curious, the bot can be found here: https github com/ha107642/RedditPoEBot. -- ha107642, 26 September 2016 (UTC)

Divination cards still use an old, non-smw template, as well as some unique items, but we are working on updating them. All pages that use a new template have "Has name" property. By the way you can see what properties a specific page has by clicking "Browse properties" link on the sidebar, for example for Vessel of Vinktar (Lightning Penetration) it is Special:Browse/Vessel of Vinktar (Lightning Penetration).

In order to get properties from a page by its page name you simply do &conditions=Vessel_of_Vinktar_(Lightning_Penetration). — TheFrz — 13:46, 26 September 2016 (UTC)

Okay, thanks a lot! I can see that Vessel of Vinktar returns infoboxes for the has name search as well now, was it just recently added? It seems that the page having a "Has name" property is a fair assumption to make. Especially since it seems to solve the Vinktar case. And as long as you guys are in the process of updating the wiki, I can use the old parser as fallback. We'll see when I get around to updating the bot, but the information I have gotten has been very helpful. -- ha107642, 26 September 2016 (UTC)

It's not just unique items that uses Has name. Modifiers uses it too, or skill gems. For example, what's the Tyrannical mod? &conditions=Has_name::Tyrannical&printouts=Has_name|Has_stat_text, a lot of fun can be had with this.--Illviljan (talk) 20:41, 26 September 2016 (UTC)

It's worth noting that some items now have several pages, such as Atziri's Splendour and Vessel of Vinktar. — TheFrz — 21:00, 23 September 2016 (UTC)

So here's my concern. The wiki wasn't too hard to start editing. Once basic navigation was figured out most people with some rudimentary coding/editing experience could check a similar page, compare the differences and figure out what would be required to fix whatever the issue was. Missing page, same thing: check a similar page, copy the code and make the often fairly obvious modifications required for a nice new page. I would speculate that most users stop around this point because they're happy fixing the issue, and everyone else is happy the issue got fixed. Those who wanted more soon ran into templates and queries and SMW and rummaging around in Content.ggpk and whatnot. The slow increase in editing difficulty ended with a wall. Some would scale the wall, others would not but those who would not still had plenty of areas where their more limited knowledge/interest would let them edit things.

The new item template effectively moves part of previously accessible territory beyond this wall. Check a similar page and you're now met by a few lines of fairly incomprehensible template calls, queries and other magic spells.

While I understand some of the benefits, and there are certainly more benefits that I don't know about, increasing editing complexity adds up and the potential negative impact has to be considered at some point. If there are no, or few, new editors grasping the more difficult stuff, the burden on those who do will increase over time as experienced editors quit. If the wiki gets too complex and the handful who understand all or most of it quit, the wiki is dead.

This isn't a call for book burning and general iconoclasm, nor do I hope that's what it comes through as, just a bit of from my perspective warranted worry. Maybe some of the time spent learning fancy new tricks would be better spent teaching others the easy tricks? Food for thought, not pointing any fingers (other than at myself perhaps). twitticles (talk) 17:49, 24 September 2016 (UTC)

This wiki had and still has a huge problem that a lot of data become outdated every 3-4 months whenever a new big game patch comes out, and facts say it's not possible to keep everything up to date manually. The problem is there for years, and it just kept growing over time, and even created non-sense situations such as when somebody contacted Curse staff in order to find out whether the amount of unique items mentioned on the unique item page is correct and up to date lmao. The whole SMW + PyPoE project is about solving such issues as well as introducing many new cool features. For example now once we move all unique items to the new template, the amount of unique items can be fairly easy retrieved with a query, and there will be no need to edit it manually each time. Overall the benefits of this project are gorgeous and have been already discussed several times over the wiki, and even few times on this very page.

I agree that the rework increases editor's entry threshold, but this is a cost we have to pay. Lets put it this way: if there wouldn't be such a problem in the first place, there wouldn't be such a solution. What kind of editing wall stopped people from keeping information up to date back in a year or 2, when things used to be less complex? The answer is there always will be lack of editors no matter how simple editing process is, and you can barely do anything about it.

In the end it doesn't matter how big the wall is going to grow, there always will be simple tasks under the wall that somebody has to do manually, such as adding screenshots of monsters and areas, moving notes from the prophecy page onto their respective prophecy pages, or fixing wrong info about interaction between Emberwake and ignite, that is there for months now and even has been discussed. What kind of difficulty layer is that?

I (and probably others as well) would like to help people to understand how 'fancy new tricks' work, but, you know, 'lessons' are useless without any practice. The best way to learn things (e.g. SMW or Lua) is to play with them for some time. Once you get the core idea behind it, it's super easy to progress through it and learn many new cool things. — TheFrz — 17:48, 25 September 2016 (UTC)

I think you explained the situation quite well, TheFrz. This is an acceptable trade-off, in my opinion. The natural progression of these things always trends toward being more complex, but it's greatly exacerbated by the need for maintainability and the depth of information that users have come to expect from the wiki. The tools that editors have at their disposal are only going to get better over time. —Vini (t|c) 18:23, 25 September 2016 (UTC)

Central asynchronous information exchange for wiki updates?

One of the earlier suggestions on this page was for the wiki to have some sort of central place people can contribute information to, and then editors can sift through that info and update the wiki if something needs it. Has that sort of place been created yet? If not, it's possible that a new subReddit might work out, if it's given stronger moderation and rules on what can be posted than the main PoE subReddit. It'd be particularly nice if we could get more streamers with an interest in contributing to the wiki considering how much they play. I'm a moderator in ProjectPT's channel and when he runs across some sort of oddity on the wiki he or his chat give me a poke and say "Jack (I'm Jackalope_Gaming_ on Twitch), this should probably be fixed." And I've fixed a couple dozen pages just from that. I would be happy to help with whatever exchange place needs to be created so we can update the wiki better and faster. —Domo (talk) 04:49, 05 September 2016 (UTC)

This wiki uses datamining bots to update skill gems, base items, item affixes, map mods, character values, monster values etc. Problem is that querying for these semanitc mediawiki (SMW) properties requires a bit of knowledge. How can you tell if something is able to be queried? When previewing Added Lightning Damage SupportAdded Lightning Damage SupportLightning, Support
Icon: L
Level: (1-20)
Cost & Reservation Multiplier: 120%Requires Level 8Supports any skill that hits enemies.Per 1% Quality:1Superior2Anomalous3DivergentSupported Skills deal 0.5% increased Lightning DamageSupported Skills have 1.5% increased Critical Strike ChanceSupported Skills have 1% of Physical Damage Converted to Lightning DamageSupported Skills have (1-21) to (8-402) added Lightning DamageThis is a Support Gem. It does not grant a bonus to your character, but to skills in sockets connected to it. Place into an item socket connected to a socket containing the Active Skill Gem you wish to augment. Right click to remove from a socket. a "Facts about "Added Lightning Damage Support"" box appears at the bottom of the page, which shows all the properties this page can be queried for. The topic above for example discusses how to add these properties to unique items, which now all are wrong thanks to the value range change. You can read more about SMW here: Path of Exile Wiki:Semantic Mediawiki rework.--Illviljan (talk) 06:23, 5 September 2016 (UTC)

The datamining is one thing (and it looks like it's going well), but there is information on this site which can't be done via datamining such as what a map's layout is or a strategy to defeat its boss. GGG supposedly has also intentionally made some data unable to be datamined, such as where divination cards drop and what their frequencies are, so we have to manually compile that information. Having a central place for that where people can, for example, drop a screenshot of where a divination card drops, would help complete that gap in information. —Domo (talk) 07:13, 5 September 2016 (UTC)

This very page is a centralized location for discussing general issues pertaining to the wiki. For discussions about specific articles, the talk page of the article in question should be used. I would like to encourage people to engage with the wiki and use the tools that we already have. —Vini (t|c) 08:16, 5 September 2016 (UTC)

I believe his point is to have some other means of discussing the wiki that is more accessible to people then the wiki itself. I agree with that point, but at the same time using things outside of wiki can lead to people not knowing what's going on and I'm not sure that it actually promotes editing the wiki. I don't like the practice of "talking about changes and not doing anything" which seems to be coming from reddit in particular. I mean, after all someone has to the edit even if people post screenshots or whatever. Might as well do the edit right away.--OmegaK2 (t|c) 09:00, 5 September 2016 (UTC)

Yeah, I agree. Mediawiki talk pages are a little bit tedious to work with, and not the most accessible. However, I can't get behind the idea of setting a space for people to leisurely dump requests for changes to the wiki. The way to get things done is by having people take the initiative to make changes themselves. —Vini (t|c) 09:34, 5 September 2016 (UTC)

Omega has identified my intent, yes. But now that he mentions the issue of "talking about changes and not doing anything" it seems that any resource but the wiki itself could cause more issues than they're worth. So perhaps there could be work done on the wiki's pages to make them more user/newbie friendly? For example, these Talk pages are certainly a hurdle for new people since it requires some of the coding to say something. Granted, that barrier to entry does help prevent some bad changes going in so it's balancing the "signal to noise ratio" so to speak. Perhaps if the Talk pages could incorporate things that GitHub uses like pull requests or Issue threads to let people contribute more easily, while still ensuring people have to take responsibility if they clutter things up. —Domo (talk) 09:45, 5 September 2016 (UTC)

There is a channel on the PoE discord now related to the wiki. A number of the active editors and some of the admins are there to keep track of things. It may not be a perfect solution, but maybe it helps. --OmegaK2 (t|c) 04:47, 22 February 2017 (UTC)

Item Info Script: Parsing the wiki for unique item data

Hi, I'm the current caretaker of the PoE Item Info Script and wanted to ask two things in regard to parsing the wiki's unique item data.

Up to a while ago, the particular data file was created with a python script (not written be me) that fetched the html content of lists like List_of_unique_belts and then cleaned up the result. This worked, but the wiki's format was changed since then so I need to adjust the python script. It seems to me like using the API instead of "fixing" the previous method makes much more sense. Can someone who is more familiar with that topic comment whether the following query (then using json format) is fine or should be changed?

https://pathofexile.gamepedia.com/api.php?action=askargs&conditions=Has%20item%20class::Belts%7CHas%20rarity::Unique&printouts=Has%20implicit%20stat%20text%7CHas%20explicit%20stat%20text

I also wanted to ask whether the item template v2 has been fully implemented for uniques, or more specifically, whether the format change of "Adds (Min1-Min2) to (Max1-Max2)" mods has been completed yet. Do I need to check my results for plausibility or is it safe to assume that the order is the same new format wiki-wide?

Thanks, --aRTyficial (talk) 17:39, 10 December 2016 (UTC)

Hey. The query looks fine to me. All uniques use the new item template and should have that format for mods but since they can be edited manually bugs can happen. I suggest you to do a simple check if Min1 is the smallest number, Min2 is between Min1 and Max2, and so on. If you find any errors you can report it to us or fix the pages yourself. — TheFrz — 18:59, 10 December 2016 (UTC)

From what I've seen the values should be in ascending order with the new format, so it's simply Min1 < Min2 < Max1 < Max2. This implies that there are no items with Min2 > Max1 even though that combination is logically possible, but it seems GGG chose not to use it. I guess I'll use that check and see if anything pops up. --aRTyficial (talk) 19:13, 10 December 2016 (UTC)

Just for the record: My script did not find any item that violates the rule from my previous comment. --aRTyficial (talk) 19:56, 11 December 2016 (UTC)

Incorrect Skill-Gem Sorting

While reading Skill Gem I noticed that the skill Determination in the table of Active Strength Skill Gems is incorrectly listed unter 'V' instead of 'D'. I tried to fix this but couldn't find the exact location. While trying I noticed that Determination is not listed in Concept:Strength active skill gems excluding vaal gems. If someone with more knowledge of this matter could fix this it would be much appreciated. --Corranhorn4 (talk) 20:55, 23 December 2016 (UTC)

Edit: While reading further down I noticed that Minion Damage is listed double under Support Intelligence Skills, once under 'C' and once at the right place. --Corranhorn4 (talk) 21:07, 23 December 2016 (UTC)

Fixed, thanks for the report. — TheFrz — 21:16, 23 December 2016 (UTC)

Immense numbers of fictional user accounts created every day

I have noticed that large numbers of new user accounts are being registered on this site. If you check out the recent changes part, you can see that about 20 new accounts are created every day. These accounts are very obviously created by bots, because they look much like real names one would expect on facebook or other online chatting pages, not like gamer nicknames real people have here. Whoever who is behind this clearly isn't specifically focusing on this wiki. I do not see them inserting any spam or gibberish, though. It could mean that they are unable to get further beyond creating an account, banned quickly by something or they are a ticking timebomb to strike when the time is right.

In any case, the sheer number of accounts is rendering the 'Recent Changes' page useless and might even be hogging the server's resources. Is something done against that? A trivial PoE-related question placed in the registration form could stop most of them, I think.--DarkUnknown (talk) 10:13, 25 December 2016 (UTC)

This is a Gamepedia wiki - the log shows new Gamepedia accounts; not just new accounts created on this wiki specifically.

There's an option available to have pages with multiple edits to only be listed once in Recent Changes. This has the side-effect of grouping all new account registrations to a single, albeit long, entry in Recent Changes. I'd suggest you try it as it should help make the page more readable for you. —sarno | TALK | 16:03, 2 January 2017 (UTC)

To anyone who shares my dislike for the compact layout, you can also use the namespace filter: Select "User" and tick "Invert selection" (like here). --aRTyficial (talk) 22:25, 2 January 2017 (UTC)

Your explanation is not accurate. A Gamepedia account can be used across the network, but the account creation log only shows accounts registered on this wiki. It's fairly easy to see that this is the work of a bot. We don't currently have a permanent solution, but I will continue to bring this to the attention of the Gamepedia staff, since I also find it a nuisance to see the recent changes log flooded by the account creation log. —Vini (t|c) 04:59, 3 January 2017 (UTC)

It seems to be fixed. No more 5 new accounts per hour. Or is it just chance? --DarkUnknown (talk) 13:41, 3 March 2017 (UTC)

Yes, it's fixed. —Vini (t|c) 14:43, 3 March 2017 (UTC)

Great. Thank you. --DarkUnknown (talk) 19:37, 4 March 2017 (UTC)

Missing Divination Cards

I was scraping the 'Divination card' pages and noticed that both the 'Divination cards' and 'List of divination cards' are missing cards. The former is missing 20 cards and the latter missing 44. I tried to make a post on the discussion page for 'Divination card' but it got auto-flagged as harmful. Making a post here since I can't find any indication that someone is aware of or working on this. --eleventeens 05:50, 3 June 2017 (UTC)

Reworking the wiki for 3.0: a to-do list

As you all probably know, GGG is getting rid of the three difficulty system when they release 3.0. I'm a big fan of this decision, but since a sizeable portion of the wiki revolves around the normal-cruel-merciless progression, we'll have to rework some templates before 3.0 is released. I thought I'd create a to-do list in the meantime:

• Areas. Some areas are will be revisited in part two of the storyline but some won't. Their look will have changed, they will have other enemies and quests and sometimes even the connections with neighbouring areas will be different. Because of this I think it's best to create two seperate pages. For example, The Twilight Strand (part one) and The Twilight Strand (part two). Or The Twilight Strand (act 1) and The Twilight Strand (act 6)? We could make The Twilight Strand a disambiguation page then.

Obviously then the template will have to be changed in order to only show one area level instead of three.

• Monsters. As far as I know, unique monsters will not be encountered a second time in part two. So we just have to remove the cruel and merciless levels from the monster template.

• All quest reward tables will have to be reworked.

As far as new content goes, these are the most important pages articles that need to be created:

• The new storyline:
  • Act 5
  • Act 6
  • Act 7
  • Act 8
  • Act 9
  • Act 10
  • as well as a general campaign article where we list the acts and the difference between part one and two
• Articles for the new areas, monsters and bosses.
• More specifically, pages for act bosses are important to get ready on launch because people will want to read some information about them:
  • Kitava, the Insatiable
  • Tsoagoth, The Brine King
  • Arakaali, Spinner of Shadows
  • Doedre the Vile
  • Shavronne the Returned
  • Solaris & Lunaris
  • Maligaro, the Artist
  • Gruthkul, Mother of Despair
  • A general page on god enemies
  • Who knows what else
• The new NPCs in the expansion:
  • (...)
• New mechanics:
  • We need a template for Pantheon powers, similar to the passive skill template.
  • New skill- and support gems. I believe some of them are on the beta realm already.
  • Removal of double dipping, it's mentioned at least in the following articles. Perhaps we should also consider improving the damage article so people don't feel the need to create these non-exhaustive lists that the pages mentioning double dipping have?
  • Status ailments. They will become a part of the hit. Bleed and poison are going to be categorized as such for that reason.
  • Chill and shock. Change discussions: 1, 2, 3.
  • Mind over matter will not need the hit requirement anymore and will therefore affect damage over time as well. The page is mentioned in these articles
  • Vaal Pact change.
  • Power charge and Frenzy charge changes, update relevant articles and properties in Character.1
  • Check that properties in Category:Pages defining semantic stat data are up to date.
  • Add and update new and old unique items.

As a reminder, the wiki should always refer to the current version of the game unless specified otherwise. So please use the {{Upcoming content}} on articles about 3.0 content to make this clear. On existing pages, please don't change anything that still applies on 2.6. Instead, add a section about how 3.0 changes this aspect of the game without removing the old information.

What do y'all think?

--Climmels aka SirProblematique (talk) 11:10, 10 June 2017 (UTC)

We certainly have our hands full! I'm in the beta, and for now I can take care of pages for the new zones. I'll also be going back through the old zones, as some of those pages are out of date.

As for naming in "Part 2" zones, I think we should just add the act number in parentheses to the title. Also the "The World" template page is going to need some revision, since just adding everything will make it gigantic... I think it's best to have each act's list of zones in a segment that can be minimized, and every act except the one belonging to the page will be minimized by default (if that make sense). Magnanimous2 (talk) 01:38, 11 June 2017 (UTC)

I intended to update the zones with game data for 3.0.0. Manual creation of pages will still be required inside the main namespace, but the data points (like area level, vaal areas, etc) can be automatically put into the wiki. The current plan is to have a template call similar to {{il}} that copies the infobox from the Area namespace.

When that is done it opens up possibilities to automatically create area progression and lists per act.

--OmegaK2 (t|c) 10:36, 11 June 2017 (UTC)

Gem changes and additions can just be exported by PyPoE. This isn't really a problem.

I'm not sure we really need a template for pantheon powers, right now it's mainly a small table of powers which I don't think warrants the time and effort that has to go into a template.

I'll do a template with SMW support for the areas so it will cover some work, as well try to update everything else as needed. I doubt I'll be able to get the same for monsters done until release though, just too much research and extra effort that goes into that. --OmegaK2 (t|c) 10:36, 11 June 2017 (UTC)

I've basically finished that area module; the approach this time is sightly different: the data will reside in the Area: name space - the infoboxes need to be called in from the main name space. With the areas the item module can support areas as well for drops so we can use this in the future for divination cards and similar things.

A template for "new" area pages can be found here User:OmegaK2/area. If everyone thinks this is ok I'll turn it into a proper template suitable for substitution so we can create those area pages rapidly.

As for the page names we should just put the act in parenthesis behind it, so basically The Coast (Act 1) and The Coast (Act 6).

Also another step necessary would be to edit the "main_page" argument in the data pages once the article has been cerated - this is used to link to the main article in the infoboxes.

--OmegaK2 (t|c) 15:47, 2 August 2017 (UTC)

Moving divination cards to the item2 module

Soon (in 12h or so) I'll run a bot export moving the divination cards to the Module:Item2 based template. With 3.0.0 the drop locations will change and it is a good opportunity to update those properly, especially since the Area module is done.

The data in the template itself will be lost, but since the old locations remain in the text those can be used as basis if needed.

Once that has been done there will be a number of manual adjustments required, but most of this has to wait until it can be confirmed in 3.0.0:

• drop_areas - set this to the area ids of where the cards drop
• drop_text - add text here if there are special conditions (like the zana only card). Do not use for area drops
• release_version - find and set it to the release version of the card
• description - potentially some updates to interwiki links, but I've taken care of some basics
• When done, remove the old text where things drop from page

Once the divination cards are updated I'll look into adding proper drop support into the item tables so that those can be replaced as well. --OmegaK2 (t|c) 20:47, 2 August 2017 (UTC)

For divination cards that have non-area drop restrictions, like those drop from strongboxes or unique monsters, we use drop_text, correct? —Vini (t|c) 20:57, 2 August 2017 (UTC)

Correct --OmegaK2 (t|c) 21:24, 2 August 2017 (UTC)

Possible SMW optiimizations

Hey there, I got a bit too much enthusiastic today, so here's a bit more insight:

• The layout code for Item, Item list and Item link are all part of the same module. So if a small item link needs to be created, the whole module needs to be invoked. It should be possible to split the layout from the backend code.
• By default every SMW object target is not directly called, but queried by name. So if a page lists 10 items, it does 10 full queries rather than 0. A direct call requires the exact page name, but this sounds way more challenging than it actually is.
• Many properties hold identical information e.g. Property:Has level requirement HTML and Property:Has level requirement. I'm convinced managing more properties has a bigger footprint than putting two HTML tags into the respective layout sections.
• Placeholder conditions such as ~*Splinter* are very restrictive by design and probably need more calculation time than fixed statements. This design also results in chaining multiple OR expressions which are not optimal either.

The biggest gains can be achieved by not querying for the item name, but to directly call the page instead. There will be some hiccups, but in most cases they are easy to solve. Please don't take this in any way offensive, this is really just a honest advice from someone who had to manage the transition of a ~10 language wiki with ten thousands of index pages towards a sane SMW implementation. Molldust (talk) 21:45, 30 August 2017 (UTC)

Is there a plan of attack, or does anyone have any suggestions on specific places we can edit to help transition things to a less server-taxing state? I'm a mediocre coder at best but i don't mind repetitive busywork if someone points me in the right direction. Alleryn (talk) 22:53, 30 August 2017 (UTC)

There's less the "one" thing to do, but many small things that should be clarified and discussed: Where is the line drawn between items being standard and league specific. Are Breachstones standard because of the 10% map spawn chance? Are Perandus Coins standard because of Zana mod? Are there standard items that are not obtainable in any way in new leagues? Can Essence be turned into the base item of all essences (would deprecate Property:Is essence)? Molldust (talk) 23:17, 30 August 2017 (UTC)

Leagues: Generally it was intended to be set if the league flag on the zone is required for the item to appear. It seemed intuitive for a lot of people to use though for cases when items drop in relation to leagues though. This also means that league features that are now part of the main game should not have the league restriction set.

Essences: No. It is the way it is because of consistency with the how the game does it. Essences are infact base item types themselves and are not based of other items.

--OmegaK2 (t|c) 23:52, 30 August 2017 (UTC)

I certainly couldn't tackle all of this at once, so i started to think about how me might possibly optimize essences. I know i'm a total newbie and i'm not trying to step on anyone's toes, but i thought i'd just share my thoughts, for whatever they're worth.

My first thought was that it seems sort of wasteful to have these three properties: Is Essence, Has essence level restriction, and Has essence tier, considering that essences make up such a tiny fraction of all the items in the game. This is just my intuition talking, i don't know much about the underpinnings, but somehow it just seems like we are qualifying a whole lot of things as not essences. Maybe that's not so important, i don't know.

So then i thought what if we used a category-based approach. Like we could have Category:Essences and then subcategories like Category:Tier 1 (Whispering) Essences and so on. Each tier even shares the same essence level restriction (at least for all the essences currently existing), so that seems to eliminate some redundancy, although again maybe that's not so important, i don't know.

With a category approach, though, how can we easily create tables? Well on the other wiki i worked on, they used this tool called DPL (Dynamic Page List), which basically can create tables out of categories. So we'd create a Template:Essence and then each Essence would have any data we'd want to ascribe to it incorporated into that template, and then the DPL tablerow syntax could be used to automatically generate tables.

Again i don't understand all the inner workings, but intuitively it seems this method might be more efficient, since when we create the table, we only have to go through the items in the Category:Essences, instead of having to go through each item and checking the Property:Is Essence to see if it belongs in the table.

Surely there are some major cons to this approach (assuming the pros that i'm imagining in terms of efficiency are even real), like restructuring elements of some existing modules and so on.

So yeah, that's as far as i got and i'm winding down for the evening, so i just thought i'd leave what thoughts i had. Alleryn (talk) 01:56, 31 August 2017 (UTC)

The way things are categorized follows the way it is in the game (and game files), and it has its pros and cons. What issue would you like to be solved? Is it performance? Do we really have a problem with it and if we do are you sure it's SMW/module-related? In this case I would like to see some reliable proofs, but looking at profiling data on various pages it's all fine. — thefrz — 07:16, 31 August 2017 (UTC)

This discussion topic is about SMW optimization. I'm not trying to comment on whether that is necessary or not, but offer some (quite possibly naive) thoughts about how that might be achieved, and more generally my thoughts about logical ways to restructure content on the wiki. Whether that is necessary or not for performance reasons i don't know, but having a problem with performance is not the only reason to achieve a more desirable hierarchy/structure/methodology. It can be an end unto itself for aesthetic reasons, or promote future efficiency and ease of use. (Whether my above suggestion would actually achieve any of that is another matter entirely). Alleryn (talk) 10:06, 31 August 2017 (UTC)

I think most of this relates to Module:Item2, so it should be probably there on the discussion page.

1. Generally, I don't see a problem in general with moving the code to other modules, I need to look into how big the benefit actually is though, I believe there is some level of caching done. : Splitting "layout" and "backend" code is not possible though, since calculations for the layout need to be pretty much be done on the back end and for the case of items it's done for call anyway (also see 3.).

2. Names are used to have legacy compatibility (i.e. items that have changed their name) and ease the ability to link against an item without having to actually know the wiki page for it. In particular if the wiki page changes, name links will stay intact where as page links will break. I'm not sure why you say it doesn't do a query, it just goes by the page name if it is used. The page syntax in item links is supported though for cases the item names are ambiguous.

3. The information contained is not the same; the numerical value is intended for sorting and querying purposes and the HTML value is intended for displaying values accordingly. The whole point of having separate options is to reduce duplicate calculations which were slowing down large item lists.

4. So what do you propose in regards to not using LIKE (~**) ?

--OmegaK2 (t|c) 23:52, 30 August 2017 (UTC)

Essences: Having more essence properties is perfectly fine. Has essence level restriction and Has essence tier are only used by essences themselves. Property:Is essence scales way worse, because it needs to be set for all items at the same time. Category:Essences is a good alternative to base_type=Essence. I came up with this because Prophecy is a base type as well.

~**: I'll take unique items that interact with Curse as example: Property:Has gem tags should be extended on Enchantments and Modifiers, so the uniques can be filtered with [[Rarity::Unique]] [[Has gem tag::Curse]] rather than ~*curse*. Property:Has gem tags is currently broken btw, only the first entry is correctly parsed. This would drastically decrease special cases were the modifier id does not contain a special keyword for a certain interactioni (e.g. Sentari's Answer is missing on Curse).

HTML properties: I'm slightly confused. Can you link a table that benefits from this? {{#show:Abyssal Axe|?Has level requirement HTML}} is no advantage over <em class="tc -value">{{#show:Abyssal Axe|?Has level requirement}}</em>.

Legacy compatibility: This is in no way a sufficient reason to keep this feature. Most maps have legacy pages with identical name properties, this alone should render this obsolete. {{#ask:[[Arcade Map]]|?Has drop level}} reliably gives back just one value (it's still a query though, my apologies). {{#ask:[[Has name::Arcade Map]]|?Has drop level}} is way more uncertain.

Regarding performance, unfortunately it's very hard to do benchmarks. The wiki runs pretty solid because the caching does an insane job. Rebuilding the cache on the other hand takes quite long, you especially notice this on pages such as Leech that take ages to resave (15 sec). Molldust (talk) 08:30, 31 August 2017 (UTC)

Essences: Because you can't query for the absence of a property, is essence is set on all items. That way you can query for items that are not an essence. An alternative would be to set essence tier and essence level restrictions to some values but I think the solution is less clean. I don't really see the problem with having a property around

~**: Modifiers do not have gem tags. They're exclusive to skill gems. The information is there to extend of where the game devs even didn't want us to know about and we have to make due with what we have, but existing terms shouldn't be diluted in their meaning. However I believe I know what you're getting at; some sort of solution programmed into the module that can group certain objects into logical groups like "curse-related" without having to do complicated queries. That I can get behind, but the question still would be whether it is worth it; it still needs to maintained and I think most of these complicated queries are specific to a single page. It's still a good way to reduce query size to avoid hitting limits, but it's just a question of it's worth it for doing it for all the pages

HTML: This is used in item tables. The css class or HTML value may change if the value is changed - items with stats modifying particular value generally show that value in blue instead of white for instance. Level requirement isn't the best example because only a handful of items even touch it "explicitly". When you do an item table, instead of having to determine whether it has been modified for every item in the table, just the result is fetched from the property. This is a significant optimization.

il: Still, I don't see a good reason to change it either. It also make the search in lower case, which is another advantage. It helps for cases when GGG isn't consistent with capitalization of names. Again, you want to change the default for positional parameter (which is technically deprecated) which would just cause a lot of work for no real benefit. --OmegaK2 (t|c) 13:40, 31 August 2017 (UTC)

Essences: I specifically mentioned the case of base_item=Essence (see Prophecies) and Category:Essences as superior alternatives.

~**: The property name could be Property:Has interaction tags or Property:Has interaction. Naturally the queries are mainly intended for sole overview pages, it's their purpose. But there's 149 of those single pages and maintaining them ain't easy as well.

il: The inconsistent GGG capitalization can be worked around with redirects for those cases. Can you go more into detail why you think ambiguous name results are preferable? I want to emphasize that this point is especially a low effort task because 95% of items have the item name as page name. Regex can handle the remaining cases.

HTML: I see now, this is unfortunate. Molldust (talk) 15:02, 31 August 2017 (UTC)

A small follow up: You can't amass results based on the absence of a value, but you can filter them: {{#ask: [[Category:Stackable Currency]] [[Has base item::!Prophecy]]}}

And I think I have a pretty good compromise regarding name vs page search: If the module took base_item and searched first for the [Page] and then for "[Has name::Page]". This way you don't get ambiguous results and keep the lower case search feature. And the base_item_page could be deprecated as well. Molldust (talk) 06:31, 1 September 2017 (UTC)

Essences: As I said in a shorter reply base items are only for items that actually have base items. Essences are base items themselves. Categories could be used, but same problem that you can't query for the absence. I don't see the point why any of this is necessary at all when the current solution already works.

I don't like this hybrid approach as it can hide issues. You can find a result that seems fine, but it wouldn't show you the alternatives. Also, there still no reason for a change. --OmegaK2 (t|c) 12:38, 1 September 2017 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ So Prophecy is an actual ingame base item? And this is not the ingame code, it's an independent wiki. You're setting arbitrary limits by not allowing a second level of inheritance. I can promise you there's an actual Essence interface ingame. Property:Has base item is not visualized in the Item box at all, so the information is only displayed when chosen to. Please give me a link where [Is essence::false] is used as sole method to gather results. Don't ignore my points on purpose. {{il|Arcade Map}} results in an error and fixing this is more challenging that writing the correct page name. This is artificial complexity: Arcade MapArcade MapMap Level: 68
Map Tier: 1
Guild Character: +We create so that some part of us may remain after death.Travel to this Map by using it in a personal Map Device. Maps can only be used once. —The preceding unsigned comment was added by Molldust (talk • contribs)

Prophecy is an item, yes. The wiki is supposed to reflect the game, not make up stuff, that's hardly arbitrary. In particular the base item has one of the most complex functions of any of the parameters in the module, it makes no sense whatsoever trying to use that function in a fashion it is not intended to be used for and for a problem that is already solved. Base item names are in fact visualized at the top of every single unique item infobox, and base item page properties are utilized on base item pages to list related unique items.

The error literarily tells you what to do: "to write the correct page name"

Also a final word on those two points: unless you (or someone else) provides a compelling reason to change this, it won't change. --OmegaK2 (t|c) 13:51, 1 September 2017 (UTC)

I've been trying to follow this discussion. It's difficult for me to understand the actual issues Molldust is bringing up. I think what needs to happen before anything can move forward is to clearly define what the issues are. Only then does it make sense to discuss possible solutions. —Vini (t|c) 14:44, 1 September 2017 (UTC)

Regarding Property:Is essence, it's just bad coding practice. Boolean should be used as last resort for exclusive states such as "is alive/dead". There is no Property:Is equipment or Property:Is prophecy for the same reason. Can I resurrect Category:Essences and take use of it? You'll see that Property:Is essence is not required. I won't touch the property.

The error tells me otherwise: "Consider using page parameter instead." When I first was using the Template il, I did not know what this meant, because I expected the first parameter to BE the page parameter. And for maps the "page=" parameter is the de-facto standard, because of the legacy maps. It's a stumbling block that can easily circumvented by using A) page as standard or B) using a fallback. The reasoning both were denied (backwards compability and obscuring) are literally the same ones I'm trying to solve. Once a new item gets introduced with a similar name, all IL templates get broken unless they use "page=" (backwards compability) and intiutively the "page parameter" should be default rather than a "name parameter" because it gives ambigous results (obscuring).

To come back to the interaction property. Are you fine with Property:Has interaction?

Thanks for keeping the discussion going! I'm really appreciating the insight! Molldust (talk) 21:13, 1 September 2017 (UTC)

I am in favor of using Category:Essences if only just for categorization purposes. If we all agree to resurrect Category:Essences and use it to categorize Essences, then I don't immediately see any issue with you trying your approach of using Category:Essences rather than Property:Is essence to query for Essences.

I completely agree with you about Template:Il. Is there any reason not to have the first parameter be the page name if the template outputs an error if not given an item name that matches one and only one page name? —Vini (t|c) 22:43, 1 September 2017 (UTC)

Is essence::false is used on the currency page for example. Take the 'Orbs and Scrolls' table, what are you going to replace the query with?

I agree with the {{Il}} page parameter, actually I brought up this issue when we were moving to the new item module more than a year ago but OmegaK2 assured me there are going to be benefits in having 2 parameters. Since then didn't find any to be honest 😁 — thefrz — 09:46, 2 September 2017 (UTC)

If Essences get their own subcategory, they don't show up in Category:Stackable Currency. So Currency, Splinter and Blessing would drop the property while List of essences uses {{SMW item table|conditions=[[Category:Essences]]}}.Molldust (talk) 10:49, 2 September 2017 (UTC)

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:

• Category:Body Armour icons -> Body armour icons
• Category:Boots icons -> Boot icons
• Category:Gloves icons -> Glove icons
• Category:Stave icons -> Staff icons

Thanks, ~Bobogoobo (talk) 06:47, 9 September 2017 (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. {{Item acquisition}} 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 release_version = 2.4.0, removal_version = 3.1.0, 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 #lst 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 {{Map disambiguation}} 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)

{{Map disambiguation}} 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)

{{OtherMapVersions}} 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 {{OtherMapVersions}} 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)

Mass replace per bot?

In every skill gem article |filter_by_reward={{#show: {{PAGENAME}}|?Has name}} needs to be replaced with |filter_by_reward={{PAGENAME}} 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 Strand Map I should get the current War for the Atlas version, not a disambiguation page. Each map page could list a similar header like This article is about the War for the Atlas version. For other versions, see Strand Map (disambiguation).. 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 support. But very few if any build guides actually include the word Support 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)