User talk:Macklin

From Pillars of Eternity Wiki
Jump to: navigation, search

I like old school talk pages …[edit source]

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
Estoc
Estoc Please define which game this appears (see Template:Game for more info)
Estoc icon.png
General
Equipment slot
Weapon type
Value
10 Copper pands (cp)
Estoc Please define which game this appears (see Template:Game for more info)
Estoc icon.png
General
Equipment slot
Weapon type
Value
10 Copper pands (cp)
Blade of the Endless Paths
Blade of the Endless Paths Please define which game this appears (see Template:Game for more info)
Estoc icon.png
General
Equipment slot
Weapon type
Soulbound
No
Unique
Yes
Value
2,210 Copper pands (cp)
Blade of the Endless Paths Please define which game this appears (see Template:Game for more info)
Estoc icon.png
General
Equipment slot
Weapon type
Soulbound
No
Unique
Yes
Value
2,210 Copper pands (cp)
The Grey Sleeper
The Grey Sleeper Please define which game this appears (see Template:Game for more info)
Estoc icon.png
General
Equipment slot
Weapon type
Soulbound
Yes
Unique
Yes
Value
2,210 Copper pands (cp)
The Grey Sleeper Please define which game this appears (see Template:Game for more info)
Estoc icon.png
General
Equipment slot
Weapon type
Soulbound
Yes
Unique
No
Value
2,210 Copper pands (cp)

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
Soulbound
No
Unique
Yes
| is_soulbound      = yes
| is_unique         = yes
Soulbound
Yes
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
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
Estoc Please define which game this appears (see Template:Game for more info)
Estoc icon.png
General
Equipment slot
Weapon type
Value
10 Copper pands (cp)
Rare Item
Estoc Please define which game this appears (see Template:Game for more info)
Estoc icon.png
General
Equipment slot
Weapon type
Value
10 Copper pands (cp)
Unique Item
Estoc Please define which game this appears (see Template:Game for more info)
Estoc icon.png
General
Equipment slot
Weapon type
Value
10 Copper pands (cp)
Soulbound Item
Estoc Please define which game this appears (see Template:Game for more info)
Estoc icon.png
General
Equipment slot
Weapon type
Value
10 Copper pands (cp)

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)

Administrator[edit source]

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[edit source]

(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:

==Description==
<!-- Please make corrections to this section further up inside the infobox -->
{{description|{{#var:description}}}}

==Location==
<!-- 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:
==Description==
<!-- Corrections? Use the infobox at the top, please. -->
{{description|{{#var:description}}}}

==Acquisition==
<!-- Additions? Use "location" in the infobox at the top by adding a new line with an asterisk at the start, please. -->
{{#arraymap:{{#var:location}}|;|x|x|\n}}
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] == '{')
            {
                depth++;
                //Console.WriteLine("Depth +1 now " + depth + " around \"" + GetStringAheadOfIndex(text, i, 10) + "\"");
            }
            else if (textWithoutLoc[i] == '}' && textWithoutLoc[i + 1] == '}')
            {
                depth--;
                //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;
                    break;
                }
            }
        }

        // --- 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);
        }
        else
            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);

    Console.WriteLine(descriptionRegex.ToString());

    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. 68.235.165.129 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)