Pillars of Eternity Wiki

I like old school talk pages …[]

Hi. Say, why are you removing "no"s from |is_soulbound infobox fields? -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 11:38, 20 November 2018 (UTC)

While I don't go out of the way to make an edit just to change this, I think that because non-unique weapons are inherently never soulbound, it doesn't make sense to clarify that they aren't soulbound. In the case of items, I'm pretty sure there are no soulbound items, so this field doesn't make any sense. I'll avoid doing so if you think the field should be filled either way. Macklin (talk) 14:42, 20 November 2018 (UTC)

There are soulbound non-weapon/armor items

As I do not really like the used icons, what about reducing all this further to hiding the fields completely if "no"/not set, and only keeping the Yes check.svg where appropriate? On all items? We could change the infobox templates so that they don't show the field if set to "no". That also would have the advantage of being able to fill it everywhere correctly – something I like: fill every field, so that it doesn't look as if it was forgotten or the value unknown. -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 16:01, 20 November 2018 (UTC)

Well, that's certainly news to me! But generally for *most* items, the fact that they are soulbound or not probably won't be relevant to the average wiki-goer. You do make a good point, I was looking at it from a presentation perspective, but from a data perspective I think it is preferable to not have empty fields if it can be helped, especially if they are supposed to be binary. Hiding the row if if the field is no/unset is a good solution. Should we take the "is_unique" field into consideration? The is_soulbound field is more likely to be relevant to a viewer with unique items, and since a soulbound item is sort of like a unique, unique. Or does that just muddle things? Perhaps the logic should be structured like this:

Let me know if you had other ideas. I will make an effort to fill these fields for future edits - or hey just do a bot thing. Macklin (talk) 16:48, 20 November 2018 (UTC)

"News to [you]" ;) I wasn't here when most of the now-still-present infobox coding was done. And that idea of having every parameter filled, I developed on another wiki. Normally I'm using comments for non-binary fields, simply adding <!-- -->.

Yes, same for "is_unique". And as all soulbound items are unique – correct me if I'm wrong – we would only have the Yes:

Example Current New
Blade of the Endless Paths
The Grey Sleeper

Or would this omit too much information for the common reader, make things unclear or leave questions? (Should we discuss this further on the community portal?) -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 17:40, 20 November 2018 (UTC)

I was thinking more along the lines of "always have both fields present if is_unique is yes", and always show a field if it is "yes". That way we're not omitting information for those who may not know - even though people familiar with the game can assume that yes, soulbound items are always unique. By showing both fields we're also telling people that weapons aren't just one or the other, where otherwise someone might assume that a soulbound weapon is not a unique weapon, considering that the omission of field can lead people to assume that the value not present is a "no" (keeping consistent with the first example). In this case, the last two rows of your example would stay the same from old to new. (showing both fields when unique is yes):

Fields Result
| is_soulbound      = no
| is_unique         = no
 * or any combination of
  "no" or empty values *
| is_soulbound      = no
| is_unique         = yes
| is_soulbound      = yes
| is_unique         = yes

This might introduce inconsistencies if a soulbound item doesn't have the is_unique field present, but since there so few soulbound items, we can keep that in check. Just to clarify, for above when I say "weapons", I actually mean weapons, shields and armor. For specifically items, the second row of your example would still be true - i.e. only showing is_soulbound if it is "yes". Since as I said, the soulbound field there is irrelevant for a majority of items.

Fields (Infobox item) Result
| is_soulbound      = no
| is_unique         = yes

There's probably no use in moving to the community page, we'd likely still be the only ones discussing it anyway. But if you want (and for the sake of relevancy), shift this text there and we'll continue :p. Macklin (talk) 19:56, 20 November 2018 (UTC)

Well i agree only one checker for soulbound would be fine. But about Uniqueness i would add two more categories to the template

is_unique = yes
is_rare = no 
is_common = no

or change it to

is_type = unique or rare or common //empty shouldn't be working or be by default common

depending on the selection the titlebackground in the infobox could change it's color Arawn76 (talk) 18:35, 20 November 2018 (UTC)

Sort of unrelated, but I disagree. Rarity or commonality isn't really a thing in poe1 or poe2. The loot tables are entirely based on chance per container (where the game randoms a float between 0 and 1 and checks if it's below the OutputChance). So you might have a container that always spawns an item, and another container that only spawns the same item half the time. Items themselves don't have a factor that makes them spawn less or more overall. Though you could in theory calculate an average of all the chances a specific item has to spawn, and how often it turns up in loot tables. I have a feeling it wouldn't really mean anything, and would probably be skewed. Generally more expensive = rarer, right? Macklin (talk) 19:56, 20 November 2018 (UTC)

Have you checked the rare items more closely? You are a bit wrong if you think that's a complete mix. The loot tables have several fixed categories out of which they will drop. The Question is just which categories do they have when opened.

Therefor, rare items are items that add attribute enhancing stats, be found on several occasions. The harder you play, the luckier you are that you have them. So i think they are worth mentioning , specially if you play in Path of the Damned and level scaling mode.

It should be a bit helpful in that direction.

Maybe so:

Is_soulbound = yes Is_uniqe = yes Is_rare = yes => shows unique and soulbound

Is_soulbound = no Is_unique = yes Is_unique = yes => shows only unique

Is_soulbound = no Is_unique = no Is_rare = yes => shows only rare

Is_soulbound = no Is_unique = no Is_rare = no => shows nothing

That's just a tinly little bit extended if else to a cascading if else if else

  • If Is_rare = true
    • If Is_unique = true
      • If Is_soulbound = true
        • =>show soulbound and unique
      • Else
        • =>show unique
    • Else
      • => show rare
  • Else
    • => show nothing

But without changing the template you can do it so:

Example New
Common Item
Rare Item
Unique Item
Soulbound Item

Arawn76 (talk) 00:02, 21 November 2018 (UTC)

I've cleaned up the formatting of this page a bit, removed indentation and replaced lines with that "stylish" little template as used on many other talks.

I'd say, we care about rare items when we have statistics for them. When loot tables are completely analyzed and chances calculated. We could, however, use different backgrounds for unique and soulbound items before that point of time. Would need a new class definition in CSS, I guess. Would perhaps somebody have the code for this already written? ;) Ugh, okay, I'm red-green blind and have some problems with colors – so, which colors, at least there I'd need ideas and support.

Back to the checkmarks and crosses – to make a long story short:

  • show no icon for non-unique/soulbound items
  • show both icons for items with one of both attributes

Have I understood this correctly? -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 18:28, 22 November 2018 (UTC)

Well that's ok. Think you can use Gold, Silver, Bronze and Aqua. Think that would even work for you fine.

About checkmates and crosses. Yes it seems so. Arawn76 (talk) 23:15, 22 November 2018 (UTC)

The indents were giving me a headache! And yes, that's about right. I was going to add a point about non-weapon, non-shield, non-armor items only showing the true fields - but if you think about it, we want to include accessories in the second point. I think we've come to a conclusion.

About the colours, I don't know - I'd have to see a mockup to get an idea of what that might look like before making judgement (chrome's F12 menu). And if anything I would just use the colours already shown on the icons for unique and soulbound items in-game The infoboxdescription1 class (that gradient title background thing in the infobox) would be a good candidate. Macklin (talk) 04:04, 23 November 2018 (UTC)

By the way, I've gone and implemented the changes discussed here. Doing anything beyond basic single condition ifs with ParserFunctions (like ORs and ANDs) gets real messy with the curly brackets, but hopefully it looks okay. Certainly works though =). Macklin (talk) 13:43, 24 November 2018 (UTC)


Congratulations, Macklin, and welcome in the team!

You might want to have a look at these:

I think, the Pillars of Eternity Wiki:Admin noticeboard is already on your watchlist

A note about "that pesky deletion page", especially regarding files: I have a personal policy about original contributions and creator crediting. I think, any wiki contributor who created something serious for a wiki should be given proper credits for doing so. If e.g. a filename was chosen badly or an image isn't of very good quality, the file can be moved to a new name or a better version of it re-uploaded on its own page – rather than uploading a completely new file as replacement and later delete the original contribution. Although unified filenames, important especially when used with placeholders in templates, may be easier achieved by mass-uploading a whole bunch of extracted files, regardless whether other versions of them existed before (this was done here on the wiki by another admin), this contradicts my policy; then that 'lazy' person would get the credits, and somebody else's earlier contribution would be deleted – not to their's (and my) liking, I guess. What I want to say is that, if it comes to deletion of "duplicate" files, take a look into the histories of the file itself and its replacement and rather delete the later copy while applying the needed changes to the original file. This, of course, doesn't apply to different file types: a JPG, for example, can't be moved to a PNG and if the PNG is of better quality (which it usually is), then the JPG can be deleted. (I know, this takes more time and work than the other approach.)

And before you now start mass-deleting [/irony off] categories, you don't see a sense in – like noted on that other discussion, "I personally think images shouldn't be sub-categorised in such a specific way as by race - seems unnecessary.": those were intended to make it easier for players who plan a new character to find a matching portrait (I will explain this on that discussion again when we're at that point).

And another interesting link – in case you haven't found this already …

Have fun! -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 14:03, 8 January 2019 (UTC)

Forgot something: that above mentioned other administrator also was keen of raising his patrolled edits achievement counter – please, do not patrol edits you can't verify the content of. I, for example, do patrol only fixes, format changes, such stuff, but not if new content is added which I haven't verified by playing or game files. -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 14:19, 8 January 2019 (UTC)
And another thing if it comes to deletions: always check What links here before deleting something (remember: categories can also be linked to). I just stumbled upon an image that had been deleted (not by you!) due to being "not used" – well, it was. If talk and user pages link to something that shall be deleted: be very careful when editing those, to not corrupt the previous meaning or intention of the link. Editing other users' pages theoretically isn't looked well at, though it seems to have become usual practice on Wikipedia, according to some invitations I've seen on certain user profiles there. One way of preventing a red link would be to use external link formatting for it: [https://pillarsofeternity.gamepedia.com/index.php?title=User_talk:Macklin User talk:Macklin] will be displayed the same way as [[User talk:Macklin]].
By the way – you might also find the special pages in general very useful (and now slightly expanded with your new rights). -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 15:46, 8 January 2019 (UTC)
Thanks for the extensive rundown and pointers! I will go through the links provided when I find time - there are a lot of strange new features that I need to learn. On patrolling, if I understand, it's like marking an edit as "seen by an admin and verified as correct"? And you're saying that I shouldn't patrol an edit that I can't personally verify as correct, regardless of it looks correct - but do patrol correct fixes and format changes that change the article in a positive sense. Let me know if I'm understanding it correctly (seems right anyway). It seems to me that patrolling as a concept might have flaws, in that it prevents (or at least dissuades) multiple admins from verifying content - isn't this something that you'd want, multiple opinions, right? Is there a similar feature that allows you to mark something as seen, but that needs to be verified (other than an edit, or talk page)? I guess patrolling would be more useful for high traffic wikis. If I'm honest I wasn't planning on patrolling anyway, but if you think it helps I will make a point of doing so.
Just to touch on the topic of the files for deletion, specifically for duplicate icons. I wasn't planning on haphazardly deleting the newer "copies" of a file, but instead going through them one by one and checking to see if they actually match the file from the game. Of course this doesn't work with original files like screenshots, and is really only intended for content directly from the game. I'm talking specifically about the item icons in this case. Just for context, there are two ways that the icons can be retrieved:
  • Manually cut it out from the icon atlas - which leaves the file at the mercy of whatever program is being used, potentially adding unneeded metadata and modifications to it (underlying stuff like png compression, color space etc).
  • Extract it from the asset bundle, which still uses the atlas - but has same unpacking methods as what would be used in-game - therefore producing a file that is bit-for-bit exactly how it is presented in game.
The availability of multiple methods of ripping and saving game data makes it such that we get these that look the same, but are logically different. I understand that yes, someone might have put in some effort to cut out individual icons, but ultimately I'm going to prefer accuracy over effort expended. Isn't this what we want?
Say a newer, duplicate file was uploaded that is more "accurate" than the older one in this sense. My judgement is to simply delete the old one, as this is most logical process, instead of messing around with preserving the oldest contribution - especially on something as trivial as an icon.
In terms of file naming (for icons in particular) it's a difficult topic, because on one hand I'd still like to adhere to the game, however there are some cases where the developers (or whoever named their files at least) seemingly had a complete lapse in judgement, producing file names that don't even adhere to their own standards. How we have it is a good mix of our own unification and reference to the game's own name for files "Poe2 <original file name> icon.png". So in the case that two files are identical, I'd lean towards the one that matches this. But you say that I should prioritize older files? In this case if the newer one has the correct name, should it be deleted and the older file moved to the same name? Seems like a bit of a long-winded way to preserve contributions and hurts my brain a bit.
However, your point also applies to other situations, and I do agree with it, so I will keep it in mind.
And your last sentence about categories, yep we'll get to that later. I actually think it's good to sort them, but it needs to be done better than as it currently is.
I did not mean to type this much! Oh well - it happens. Macklin (talk) 16:00, 8 January 2019 (UTC)
@ Patrolling: I think you've understood the meaning of it. If you see the necessity of "multiple opinions", then just don't patrol. Or do so, but then add something like {{verify}} to it. If you don't plan on patrolling, then let it be – I'm fine with that. (Although, I usually restrict myself from doing so if another editor with patrol rights has made changes after the unpatrolled edit – and so that red exclamation mark will stay there for the next three months, which I sometimes find annoying. ;)
@ File deletions: If that hurts your brain – first, you don't have to follow my personal policy (though I would prefer it) as long as it's not part of the official wiki policies, and second, you don't have to delete files, either. ;)
About file naming … okay, whole new (or old) topic – not now, please.
About file sources: I prefer the asset extraction (with as less modifications to the product as possible). Usually I have a directory with all extracted files somewhere on my harddrive, and move uploaded/already existing ones into a subdirectory. So I'm always able to upload the wanted version of the file (again). (Not currently, however, due to a lost drive.) If there are two versions of an icon, as you describe it, I still would delete the later one, then rename and reupload the earlier one – the name of the original uploader is still in the file's history. But – that's me, as said. (And if it was done by an IP – nobody cares.)
@ General: I see, you're using a hyphen, rather than a dash: ALT+0150 makes a "–". ;) And the other ones I also use (and have in mind): ALT+0133 for "…" and ALT+0215 for "×".
Hey, you don't have to change your way of working now – you simply have more freedoms and tools to do so. -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 16:37, 8 January 2019 (UTC)
And one more gimmick – the mentioned "permission" can only be given by Gamepedia staff. -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 16:48, 8 January 2019 (UTC)

Descriptions and locations[]

(Put this here as I doubt, <pre> works in the comments.)

What about unifying "Description" and "Location(s)/Acquisition" sections to make them all (at least for supporting infoboxes) use what I started once – how-to-edit tips:

<!-- Please make corrections to this section further up inside the infobox -->

<!-- Please make corrections or additions to this section further up inside the infobox (as bullet point list) -->
{{#arraymap: {{#var:location}}|;|x|x|\n}}

And there has been discussion about how it should be named, "Location(s)" or "Acquisition" – Tagaziel favored the former, and only with plural-"s" if it's really more than one entry. I can't recall where this discussion took place, however … -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 07:46, 10 January 2019 (UTC)

Anything to reduce the amount that this occurs is a good thing. I don't blame new contributors for not knowing this, so I think it would help - assuming people actually read it. What would be the best way to do this en masse if at all? I assume a find-and-replace in awb would work, I could come up with an expression that takes into account if there already is a comment on the page, spaces in between the subheader name, etc. Also, do comments even show up in the visual editor?
On Acquisition vs. Location: I prefer "Acquisition" as "Location/Location(s)" doesn't really make sense when an item is gained via a quest reward or any place where it isn't picked up from a specific location. While it would be cool having the title show "Locations" if there is more than one location, and "Location" otherwise, using "acquisition" doesn't require a plural (I think at least?) and would avoid needing this. Macklin (talk) 08:07, 10 January 2019 (UTC)
The only issue with "acquisition" I would have is that it then differs from the parameter name in the infobox where contributors are intended to be directed to (and anyway). And changing the parameter – which impact would that have on Cargo? I guess, a huge one. What do you think? -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 17:19, 14 January 2019 (UTC)
It's a small issue, I think most people would understand given the presence of "location" in the arraymap (though this is not shown in the visual editor). Maybe make sure to point out the field name in the comment? If we did want to change it to match the subheading (which I don't think we should, just due to the huge amount of unnecessary effort), we'd need to change pretty much every infobox item template, every page that uses those templates to store the field appropriately (as well as the variable name in the arraymap), and then the few Cargo queries to match the correct field name. Seems like a lot of work just for the sake of uniformity.
Effort is likely the reason poe2 armor pages still use dr_crush/slash.. instead of ar_crush/slash... like it should be. Although it would be nice (especially if it was done like this in the first place!), it's better not to worry about it since it's not shown to anyone that doesn't edit pages, and most people who do would likely understand.
On uniformity though, maybe we should decide which is preferred (Acquisition/Location(s)) and then consider using it for both poe1 and poe2 pages, since at the moment poe1 pages show "Location", while poe2 pages show "Acquisition". Even that sounds like a lot of work though, but at least it makes a bit more sense.
Also if Tagaziel preferred "Locations", why would he continue to create every poe2 item page with "Acquisition"? Macklin (talk) 18:30, 14 January 2019 (UTC)
The old discussion can be found here: Pillars of Eternity Wiki talk:Community portal#Item articles' sections.
Considering Tagaziel's own inconsistency and the lack of an explanation to his "definitely", I think we can clearly agree on generally using "acquisition" then (especically if it comes to distinguishing between a quest's place of acquiring it and the locations to be visited).

VE, FF, Win 10

I am able to see both, the comments and also the arraymap variable in VE (see image) – did I understand you correctly, regarding this?
I would change the comments to the following:
<!-- Corrections? Use the infobox at the top, please. -->

<!-- Additions? Use "location" in the infobox at the top by adding a new line with an asterisk at the start, please. -->
Unfortunately I don't know why the location parameter – in e.g. {{infobox armor}} at the very bottom, also in the source code of The Golden Scales – is placed right in the middle when editing the infobox with VE. For all infoboxes that have the "gui" parameter, it should be moved below that one (and possible new parameters added before), however, so that at least in source mode editing adding further locations is made easier.
We could also add __NOEDITSECTION__ to both sections – what do you think?
So, here's what would be to do – and I could do it, using my bot where appropriate:
  1. Add variable declarations to all infoboxes that could make use of it and don't have it at the moment – if there are any.
  2. Botwork:
    1. Move "location" to the bottom of article infoboxes; as I still don't know how to use RegEx, and thus am not able to move the already given values together with it, my bot can't do this – or could you perhaps quickly tell me how the replace text would have to look like? I guess, I'd simply have to add something behind | location = in the "Find and replace" "Advanced settings" mask …
    2. Place/replace "==Description==RegEx placeholder; see above{{description|{{#var:description}}}} with the above.
    3. Place/replace "==Location==RegEx placeholder; see above{{#arraymap: {{#var:location}}|;|x|x|\n}} with the above.
    4. Place/replace "==Locations==RegEx placeholder; see above{{#arraymap: {{#var:location}}|;|x|x|\n}} with the above.
    5. Place/replace "==Acquisition==RegEx placeholder; see above{{#arraymap: {{#var:location}}|;|x|x|\n}} with the above.
Or … you don't want to share your knowledge and would have to do it yourself. ;)
If I'm already running over all those articles, I could also change "dr" to "ar" (not familiar enough with the games to understand this, however).
Aaand … then I could also change the infobox parameter and arraymap variable, as well. Then only the "few Cargo queries" would have to be updated. -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 12:41, 15 January 2019 (UTC)

Ah, the visual editor does show a portion of the function. I was just assuming. Strangely my visual editor doesn't show the location field at all when editing the infobox.

Also, can we consider placing the comment on the same line as the header (like == Description == <!-- A comment here...)? If you think it looks weird/dumb then don't worry about it.

Regarding the __NOEDITSECTION__, it won't stop people from editing the section if they want to - and there might be other stuff in there that may need to be changed as well. I think it'll probably just make it messier.

They changed "DR" (Damage Reduction) to "AR" (Armor Rating) in poe2. Not sure if the math is actually different, but the wording is at least. So I give a thumbs up to this change (poe2 only though!). If you do, feel free to edit Template:Infobox armor poe2 as well. I'm fairly sure the only two cargo templates that reference these fields are Template:Cargo armor poe2 and Template:Cargo armor row poe2.

I experimented with a regex that would move location to the end of the infobox, which is possible, but would be better in a multi-step process. Awb's find and replace does regex well enough as anything, but I don't know if it has the ability to save a value for use in another find-and-replace. For more complex things I prefer to use C# in the modules function, so I know exactly what is going on.

So here's the steps:

  1. Capture the text between | location and the next <line feed>|. This will not match to instances where the location is already on the last line.
  2. If there was a match, remove capture from page text (removing the location field and it's contents, leaving no space)
  3. Next is to insert the capture on a new line before closing the infobox. Finding the closing curly brackets can be tricky, and it's probably easier done without regex.
  4. Add comment to description header.
  5. Add comment to acquisition header (and replace "Location/Locations").

As for replacing the headings with headings + comment, I would probably leave out the function and just replace the heading itself. If you were to regex match the heading with whatever was below it, you might remove locations or other info that have been put there accidentally. An example of this being done on purpose is for soulbound items e.g. The Weyc's Wand, which have ";Base" in between the header and the function. There are way too many unknowns to factor them all in. Replacing only the header however will not catch:

  • Pages where the function has been replaced (or ones that didn't have a function to begin with), leaving it with no function.
  • Comments that already exist, leaving it with two sets of comments. (I've factored this in anyway)
  • Pages that don't have a header (not sure they exist).

It's going to be difficult to catch every possible situation, but I think replacing the header with the header+comment is the safest at the moment.

On the topic of pages that don't have a function, like for example Svef which doesn't implement either, this is something that isn't easy to automate so we'll need to go through and change them manually. If you plan on stepping through the bot manually (which I would recommend, since who knows what could cause it to break), it might be a good idea to do this on a per article basis.

Infoboxes with "location" parameter:

Templates with Cargo queries that at least reference "location" parameters. Hilariously most of these don't even pass the location to the row template.

I purposely omitted location from most of the poe2 cargo tables. Didn't think it was really needed. I might add it in at some point.

Here's the module, you can load it from one of the toolbar menus. You can do other stuff with the awb tools (or if you want I can add them into the code below). Let me know if it works, or if there are any issues with it. Macklin (talk) 19:54, 15 January 2019 (UTC)

const string INFOBOX_OPEN = "{{infobox";
const string INFOBOX_CLOSE = "}}";

// Regex patterns
const string LOCATION_REGEX = @"(\|\s*location[\S\s]*?\n)(?=\|)";
const string HEADER_REGEX = @"(==\s?{0}\s?==)\r?\n?(<!--[\S\s]*-->)?";

// New content
const string DESCRIPTION_HEADER = "== Description ==";
const string DESCRIPTION_COMMENT = "<!-- Corrections? Use the infobox at the top, please. -->";
const string ACQUISITION_HEADER = "== Acquisition ==";
const string ACQUISITION_COMMENT = "<!-- Additions? Use \"location\" in the infobox at the top by adding a new line with an asterisk at the start, please. -->";

public string ProcessArticle(string ArticleText, string ArticleTitle, int wikiNamespace, out string Summary, out bool Skip)
    // Initially do not skip
    Skip = false;
    Summary = string.Empty;

    // Check to see if the text contains an infobox
    if (!ArticleText.ToLower().Contains(INFOBOX_OPEN))
        Console.WriteLine("Module : Page doesn't contain an infobox!");
        Skip = true;
        return ArticleText;

    // --- Step 1. Find a location field (doesn't match if it's already at the end of the infobox) ---
    var locationRegex = new Regex(LOCATION_REGEX, RegexOptions.IgnoreCase);
    string text = ArticleText;

    if (locationRegex.IsMatch(text))
        Console.WriteLine("Module : Found location field not at end of infobox!");

        // Save the location field
        string locationField = locationRegex.Match(text).Groups[1].Value;

        Console.WriteLine("Module : Field is " + locationField);

        // Replace the matched location field with an empty string
        // Do this in a new variable since we don't know if the below is going to fail
        string textWithoutLoc = locationRegex.Replace(text, string.Empty);

        // --- Step 2. Find closing infobox brackets ---

        // Get index of opening infobox brackets (this should always return an index since we checked if it does at the start)
        int openInfoboxIndex = textWithoutLoc.IndexOf(INFOBOX_OPEN, System.StringComparison.InvariantCultureIgnoreCase);
        int closeInfoboxIndex = -1;

        int depth = 0;

        // Find the closing curly brackets by incrementing/decrementing depth when we encounter sets of curly brackets
        for (int i = openInfoboxIndex; i < text.Length - 1; i++)
            if (textWithoutLoc[i] == '{' && textWithoutLoc[i + 1] == '{')
                //Console.WriteLine("Depth +1 now " + depth + " around \"" + GetStringAheadOfIndex(text, i, 10) + "\"");
            else if (textWithoutLoc[i] == '}' && textWithoutLoc[i + 1] == '}')
                //Console.WriteLine("Depth -1 now " + depth + " around \"" + GetStringBehindIndex(text, i + 2, 10) + "\"");

                // If we're back to a depth of zero, the infobox has been closed.
                if (depth == 0)
                    // i will store the index of the first closing curly bracket
                    closeInfoboxIndex = i;

        // --- Step 3. Shift the location to the end of the infobox ---

        // Check if we found the end of the infobox
        if (closeInfoboxIndex != -1)
            // Insert the location field at the end of the infobox
            text = textWithoutLoc.Insert(closeInfoboxIndex, locationField);
            Console.WriteLine("Couldn't find end of infobox!");

    // --- Step 4. Adding comment to "Description" header --
    var descriptionRegex = new Regex(string.Format(HEADER_REGEX, "Description"), RegexOptions.IgnoreCase);


    if (descriptionRegex.IsMatch(text))
        Console.WriteLine("Module : Found description header");

        // Replace the existing description header (plus any comment that may already be below it)
        text = descriptionRegex.Replace(text, DESCRIPTION_HEADER + "\n" + DESCRIPTION_COMMENT + "\n");

    // --- Step 5. Adding comment to "Acquisition" header ---
    // This pattern matches one either of Location/Locations/Acquisition
    var acquisitionRegex = new Regex(string.Format(HEADER_REGEX, "(Location|Locations|Acquisition)"), RegexOptions.IgnoreCase);

    if (acquisitionRegex.IsMatch(text))
        Console.WriteLine("Module : Found acquisition header");

        // Replace the existing acquisition header (plus any comment that may already be below it)
        text = acquisitionRegex.Replace(text, ACQUISITION_HEADER + "\n" + ACQUISITION_COMMENT + "\n");

    Console.WriteLine("Module : New text is:\n" + text);
    return text;
Oh, wow … with "could you perhaps quickly tell me" I actually meant a "simple/short way" – now it looks as if I had to learn programming first. ;)
But many thanks for your input! I'll look into this later. -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 10:09, 16 January 2019 (UTC)
No half measures I say! Also I didn't want to give you a vague answer and leave you to wonder how to do it (although I suppose that's the only way to learn). Most of that code covers just moving the location field. As I said, I guess it could be done in regex alone, but would be really really convoluted. Step 4 and 5 could instead (if you want) be done with a find-and-replace in AWB, either using multiple operations to cover the presence of spaces or no spaces between the equals and the header name, and the Location/Locations/Acquisition. Or with the regex specified (==\s?HEADER\s?==)\r?\n?(<!--[\S\s]*-->), just by replacing HEADER with the search term. Macklin (talk) 10:39, 16 January 2019 (UTC)
Also another point CompleCCity, if you do go through all those pages consider replacing all those {{lc:type}} in the opening sentence with just the type. Not sure why Tagaziel did this (there's probably a good reason), but I'm sure nothing would be harmed by removing them. Macklin (talk) 02:14, 19 January 2019 (UTC)
Perhaps that was originally meant as {{lc:{{#var:item_type}}}}, without the changes to infoboxes ever made … Perhaps I'll add this as well, though have to care for declension issues. Objections? -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 13:18, 19 January 2019 (UTC)
Sounds good to me. Keep in mind some pages have a space before the closing double curly bracket in the lc: and some don't. Yet another thing; some item pages like Boots of Speed (Deadfire) open with "x is a boots in...", which is just grammatically wrong. I'm not certain, but I think the best alternative is "x are boots in...". Other examples of types that have this issue are gloves, gauntlets, and bracers. What do you think? Macklin (talk) 13:40, 19 January 2019 (UTC)
Yes, as I did here: "Aegor's Swift Touch are gauntlets …" I think, this does work for item names, too, that are definitely singular. And I forgot there above that this should also be a link.
Could become a difficult setup for AWB, considering all this. Well, I'll see … -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 14:22, 19 January 2019 (UTC)

Sup! Thanks for your help. 01:36, 27 September 2019 (UTC)

And thanks to you for your recent edits. Hopefully you don't mind me tweaking things here and there. :) Macklin (talk) 11:11, 27 September 2019 (UTC)

How to use the "cargo enchantment item" template?[]

I created a new page for Freeze Damage Regen on Rymrgand's Mantle. I took most of the source from the other enchantment on that item Freeze DR Bonus. However, the table of items with that enchantment on the bottom of that newly created page is broken and I have no idea what I did wrong. Could you have a look and tell me what I did wrong? — 11:02, 1 May 2020 (UTC)

Thanks for that! This is a known issue with nested cargo templates that are shown in tables. Usually it fixes itself over time, but if you want an immediate fix you can perform a null edit on the page. To do this, simply go into edit mode and click "Save changes" without making any changes to the page or summary box. The edit will not be recorded or saved, but the queries on the page will be refreshed and the table will be fixed. Macklin (talk) 14:26, 1 May 2020 (UTC)
That's good to know, thank you! (I made an account in the mean time.) --Celenduin (talk) 20:26, 1 May 2020 (UTC)

Spiritshift percents[]

Hey! In your latest update to Spiritshift you've put percentage values in PoE 1 table, but they all seems to be wrong. Look at the damage range for level 1 (16-25) and level 16 (32-50), it's clearly a +100% increase not +75% as you wrote. The progression is not even linear. Is it some sort weird game mechanics and/or metagame knowledge or did you just copy the values from PoE 2 without double checking them? -- 10:00, 9 September 2020 (UTC)

Thanks for catching this! The damage scaling is shown in the game files as an adjustment of 1.15. I went through just now and checked the in-game damage values, and confirmed they are accurate in the table, and that no other bonuses were being applied. With the multipliers I have there, the damage values match with only +15% and +30% (rounded to the nearest whole number), but are off for all after that. My guess is I just originally checked the first two and assumed that they scaled linearly (1.15, 1.30, 1.45, etc) - but in fact the multiplier is determined exponentially (as you'd probably guessed) using 1.15 ^ x where x is each level increment (0 for levels 1-3, 1 for levels 4-6 and so on).
So the actual multipliers are:
Levels Shown as Multiplier Calculated damage
1-3 16-25 1.15 ^ 0 = 1.0 16 * 1 = 16 25 * 1 = 25
4-6 18-29 1.15 ^ 1 = 1.15 16 * 1.15 = 18.4 25 * 1.15 = 28.75
7-9 21-33 1.15 ^ 2 = 1.3225 16 * 1.3225 = 21.16 25 * 1.3225 = 33.0625
10-12 24-38 1.15 ^ 3 = 1.520875 16 * 1.520875 = 24.33400 25 * 1.520875 = 38.021875
13-15 28-44 1.15 ^ 4 = 1.74900625 16 * 1.74900625 = 27.9841 25 * 1.74900625 = 43.7251563
16 32-50 1.15 ^ 5 = 2.01135719 16 * 2.01135719 = 32.181715 25 * 2.01135719 = 50.2839297
I suppose I have some fixes to make! Goes to show I should double check all the values before stating things as fact. Makes me wonder how many other level scaling things I've bungled :( Macklin (talk) 14:04, 9 September 2020 (UTC)

Official Wiki Button[]


Due to the Fandom and Gamepedia merge, I don't seem to be able to post on profiles, so I'm leaving it here. I noticed that your Official Wiki Button on the top-left of the Wiki leads to an empty/broken page!

All the best,

EdmundKeppler (talk) 12:01, 5 October 2020 (UTC)

Thanks for the info! There's not much I can do about that since it's not part of wiki markup (you'll have to message Tagaziel or another Gamepedia staff member for site-related stuff). I think it originally linked to a list of other official/endorsed wikis, but I'll add it to the list of migration-related issues anyway (perhaps there's a Fandom equivalent page).
I tried commenting on my own profile, and it seemed to work fine so I'm not sure what the issue is there :|. Macklin (talk) 14:00, 5 October 2020 (UTC)

PoE1: Missing and misleading info about Spiritshift, strange note on Torment's Reach[]

Hey! Is there any reason why you've removed form-specific abilities from druid's Spiritshift table? Missing pieces of info are: bear having higher armor (there's a small note below the table), cat attacking faster (there's nothing, but the text referencing this feature has been left intact) and boar dealing wounding damage (nothing at all). The progression of weapon damage is also bogus. It's the change of the base damage, not a percent bonus being applied, which makes a huge difference in damage calculations. I find the current form of presentation very misleading and unnecessary.

I can't wrap my head around a note you've added to Torment's Reach. Are there any strict rules for all abilities as of the latest patch (e.g. all AoE abilities use these modifiers, all spells those etc.)? It used to be all over the place (similar skills could work totally different and vice versa), but I haven't tested it on 3.7. - Wiki Kaczor (talk) 11:46, 12 June 2021 (UTC)

Hi Kaczor, thanks for your recent contributions! Form-specific abilities are all there, I haven't removed anything on that front. You're referring to the enchantments and stats given to the weapons and armor provided in spiritshift form. In the case of Spiritshift Cat, the speed bonus comes from the weapon SpeedFactor of 0.5 (a multiplier to the attack time, not to the speed funnily enough), which is not shown in the UI. The weapons and armor have their own column, but are just links and do not have the enchantments/weapon bonuses/stats listed alongside them - this is for brevity, as it's a lot to cover on one table. I suppose for an overview/feature comparison it would be beneficial to keep side notes like these in the table, maybe in their own column.
The percentage was just a representation of the increase of the base, how the game internally scales the base damage of the weapon, though I totally understand how this could be misinterpreted as a bonus - my apologies. I agree that this should be removed to avoid confusion, as the calculation is already explained prior.
Regarding Torment's Reach, initially it seemed that table was just describing modifications to the components of the ability (Accuracy, Damage, etc.), something which is pointless since those examples apply everywhere. However I do understand the usefulness of distinguishing what factors translate through to the AoE targets, and what factors do not. It was not obvious to me that this was what the table was describing at first.
PoE's a complete shitshow when it comes to application of character stats, buffs, and bonuses on abilities, especially for things like this. While there are some rules for more basic stuff, when it comes to more complicated effects there doesn't seem to be any strict rules as to what is applied, what carries through and what isn't. Things tend to just come down to whether an ability/effect/attack just happens to be constructed in a way that meshes well with the programming logic, rather than something that is consciously a design decision. I do appreciate someone trying to make sense of it, but if you ask me I think you'll go crazy trying to find patterns and logic behind certain things, beyond mentioning edge cases and exclusions (even if they aren't intentional). If you think the note on Torment's Reach doesn't really apply, feel free to remove it - this wiki is a collaborative effort after all, and I see no reason to stand behind edits like this. Macklin (talk) 14:10, 12 June 2021 (UTC)
Thanks! I find the current version of the Spiritshift article much clearer.
If you interpreted the Torment's Reach edit differently than I intended, it didn't serve its purpose. It was meant to clear up the confusion, not to add to it. :) Maybe a simple listing what does/does not work with the AoE component would be better? The full attack seems to work as expected, so there's a little point to list every single mod as applicable.
I've asked about general rules, because I misinterpreted your note as "everything (TR included) follows the same mechanics" and though it was finally fixed in one of the later patches. Still, even if every ability works differently, it's beneficial to describe its quirks when they are known. - Wiki Kaczor (talk) 16:15, 12 June 2021 (UTC)
It's really up to you, but I think it would be better to outline situations that clearly deviate from what is expected, or what the player might assume. As you suggested, a listing of what works and does not work with the AoE could do the job. Although there is benefit to a cover-all-bases approach, I think it just leads to more ambiguity and confusion. You might also want to edit the effect string to add the Foe AoE damage too, as readers might mix it up with the +50% Damage as Crush. Pillars has a serious habit of leaving out effects that are mentioned in the description, but not in the effects block itself. Something like "Foe AoE: -2 Might for 2.0 sec, 15-25 Crush Damage".
There could well be some general rules, but I don't know enough about the combat system to identify them. From everything I've seen though, there are far too many exceptions and quirks for any sort of rule to cover in detail, and as I mentioned some things seem to depend on how they were programmed over how they were designed. Admittedly the wiki leaves a lot to be desired when it comes to combat mechanics, it's an area that could do with some serious TLC. Otherwise there are some great posts on the Obsidian forums and on other sites that go into more detail.
Honestly though (and on more of a general note of editing), if you ever come across something you think is BS or misleading, don't hesitate to change it (after doing your own testing of course). A healthy level of skepticism is key to reliable wiki content, since things could have changed, and you never know what kind of stuff people add under assumption, or without good proof (me included!) Macklin (talk) 05:05, 13 June 2021 (UTC)

Cargo and line breaks[]

Hey! I've noticed that some tables generated through the Cargo does not properly include all suitable objects (ex. He Carries Many Scars is missing from Plate armor page). I don't really know how exporting works under the hood, but I suspect it has something to do with line breaks. Properly exported items has a space (0x20) before each newline in their descriptions, while the missing items don't. I suppose it was some sort of an escape character that got mangled by the Fandom, but not before being passed to the Cargo. It may also be an encoding issue like expecting a carriage return after a line feed, but adding it manually doesn't make a difference. Do you know how to fix this? -- Wiki Kaczor (talk) 13:23, 25 July 2021 (UTC)

After a bit of poking around, I don't think it's an encoding or new line issue, as a lot of other rows have and handle new lines just fine. The space-before-line-feed thing is simply how the descriptions were formatted in the string tables in-game, and subsequently exist in some of the descriptions on the wiki (as an aside, carriage returns are stripped on MediaWiki when they go through the parser). Changing or null editing a page in any way can sometimes trigger its addition to the cargo table, and I think this is what you are observing. It may have been a coincidence, as I was occasionally removing these excess spaces alongside updating the description/acquisitions.
It's hard to say exactly what a lot of the issues are caused by without access to cargo logs, so I've just remade the table from scratch. As a result, some of the pages you've been tinkering with have reappeared and now have an entry in the Armor_poe1 table. You might still need to purge any pages which query the table (⋮ -> Purge in the top right), though this will happen globally once the cache expires. I fully understand trying to solve issues like these, and I thank you for your efforts in doing so. Feel free to undo the removal of line breaks in those pages too :P, and let me know if you spot any other issues! Macklin (talk) 14:13, 25 July 2021 (UTC)
Are you sure it's not just the character limit issue? He Carries Many Scars has been gone from the tables for almost a year (it disappeared after my last anonymous edit). I believe changes to Main/Template/Module namespaces usually take at most a few hours to propagate properly without additional purges/null edits. Does Cargo database behave differently?
Whatever the cause was, I'm glad it's working now. Thanks again for your help. -- Wiki Kaczor (talk) 15:14, 25 July 2021 (UTC)
Type restrictions on the cargo table which aren't met in the actual entries can cause issues, or so I've been told (like if a field is expecting a number but gets a string). I removed the character limit just in case, since a lot of descriptions are more than 1000 characters. Maybe it'll help, but who knows for sure. From what I can tell, cargo respects caching and propagates in the same way after a bit of time, I just like to make sure. Macklin (talk) 15:47, 25 July 2021 (UTC)

Cargo querry[]

Hi, I made some changes on the way Template:Cargo class item‎‎ works. It's now more efficient and doesn't use duplicate arguments anymore. I had to import a couple of module that won't need maintenance and can be used for other things too. I just wanted to know if you agree with the changes I made, as they affect a lot of pages. Will130 20?cb=20170831145530 (Talk) 17:53, 27 July 2021 (UTC)

Great stuff, I see no problems with that. A lot of the existing queries (especially the complex/hacky ones) need to be updated to use the Lua API instead of the parser function. These additions will give me the perfect excuse and a kick-start to do so at some point, which as you say should make the queries more efficient and workable, so thank you! The extra modules look like they'll be useful too! Macklin (talk) 18:10, 27 July 2021 (UTC)

Adding Tabber to abilities[]

Hello Macklin,

I've been following this wiki only recently and I've been thinking that the Class Abilities pages and Talents page (Pillars 1) are too long to read and require a lot of scrolling. I would suggest using a tabber function to allow one to alternate between the tables (i.e. one tab for Chanter "Active" abilities, another for "Passive") to save time. I can implement this myself, but would not do so without a staff member's approval, so please let me know what you think.

Majorman86 (talk)

Heya! I like the idea, but in practice I feel a bit indifferent about whether it is actually warranted. Many of the class ability pages aren't that long, and I feel like a tabber would just add an unnecessary barrier, an extra click to view the content.
For your specific example of separating active and passive abilities, I don't find the need to do so for every class through a tabber. If a user wanted to separate them, it should be optional through the use of the sortable "Activation" column. By splitting the tables, it sacrifices sortability across all abilities in favour of a more defined separation between a field that I don't think is that important enough to warrant it.
There are certainly class ability pages where I can see a tabber being beneficial, but the time that is saved clicking a tab is also time saved by using the ToC. You should also remember that content within a tabber tab cannot be searched (via the browser), and cannot be anchored to (which is done quite regularly, especially for the talents page).
I would suggest perhaps sandboxing some of the pages where you think using a tabber might yield the most benefits. Create tabbed versions of one or two of the more egregious pages as subpages of User:Majorman86, e.g. User:Majorman86/Chanter abilities, and then we can evaluate the need with specific examples.
Either way, thanks for all your edits so far, and thanks for asking beforehand! Although this is ultimately a collaborative project and you don't necessarily need to ask for approval, I do appreciate it nonetheless, especially for more significant edits. Besides, it's always good to talk and get second opinions on things before going in solo :) Macklin (talk) 04:19, 30 January 2022 (UTC)
Here's the preview page. Let me know what you think.
Majorman86 (talk) 07:14, 2 February 2022 (UTC)
Oh, I actually thought you meant poe1 pages only. Either way, it looks good but again it breaks anchoring to sections on any tab that isn't the one currently shown. An example of this is just to see the difference between anchoring to the page without the tabber (here) and the page with the tabber (here - note how it doesn't anchor at all). Because the tab content isn't actually visible in the DOM, the anchor is ignored. This might seem trivial, but it is done with every single ability page (the link in the type field of the infobox), plus links on the class page, and links in the family tree. It is a feature I'd rather not sacrifice to save the user from scrolling a bit further (assuming they miss the ToC).
Tabber is great and all, but using it on such long form tables means a lot of staggered scrolling up and down, and imo can actually make using the page more cumbersome, as you have to scroll back up to get to the top of the section to click the next tab to show the next table rather than simply scrolling past the tables in a linear fashion. Plus, the fact that the floating ToC in the top left makes it so that you can access the sections without using a tabber or scrolling at all, it just makes me wonder why use it in the first place.
It's for these reasons I can't vouch for using a tabber on ability pages. I can see them slightly improving the use of the poe1 ability pages (an example of that is as follows), although again at that point it's essentially just replacing the floating ToC with one that is horizontal, saving only a single click. Macklin (talk) 11:32, 2 February 2022 (UTC)
==List of spells==
All spells=
=== 1st level spells ===
{{Cargo wizard spells|spell|1}}
=== 2nd level spells ===
{{Cargo wizard spells|spell|2}}
=== 3rd level spells ===
{{Cargo wizard spells|spell|3}}
=== 4th level spells ===
{{Cargo wizard spells|spell|4}}
=== 5th level spells ===
{{Cargo wizard spells|spell|5}}
=== 6th level spells ===
{{Cargo wizard spells|spell|6}}
=== 7th level spells ===
{{Cargo wizard spells|spell|7}}
=== 8th level spells ===
{{Cargo wizard spells|spell|8}}
1st level=
=== 1st level spells ===
{{Cargo wizard spells|spell|1}}
2nd level=
=== 2nd level spells ===
{{Cargo wizard spells|spell|2}}
3rd level=
=== 3rd level spells ===
{{Cargo wizard spells|spell|3}}
4th level=
=== 4th level spells ===
{{Cargo wizard spells|spell|4}}
5th level=
=== 5th level spells ===
{{Cargo wizard spells|spell|5}}
6th level=
=== 6th level spells ===
{{Cargo wizard spells|spell|6}}
7th level=
=== 7th level spells ===
{{Cargo wizard spells|spell|7}}
8th level=
=== 8th level spells ===
{{Cargo wizard spells|spell|8}}
See, that's why I asked before implementing anything:)
P.S. How about using tabber in the stats Infobox to distinguish between standard/upscaled/PotD difficulty? E.g. the User:Majorman86/Sky Dragon Infobox (I couldn't format it perfectly, but you get the general idea).
Majorman86 (talk) 06:28, 4 February 2022 (UTC)