User talk:Macklin

I like old school talk pages …
Hi. Say, why are you removing "no"s from  infobox fields? --  -- 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 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. --  -- 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)
 * Template:Infobox item / Template:Infobox item poe2: Only show field if "is_soulbound" is "yes", since 99% of items aren't soulbound.
 * Template:Infobox armor / Template:Infobox armor poe2 / Template:Infobox shield / Template:Infobox shield poe2 / Template:Infobox weapon / Template:Infobox weapon poe2: Show row if "is_soulbound" is "yes", or "is_unique" is "yes", then also substitute the displayed value with if it is empty (the infoboxes might already do this). This might just be dumb/too much, so we could also only show the row if "is_soulbound" is "yes".

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

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?) --  -- 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): {| style="margin-left:50px;" ! Fields ! Result

* or any combination of "no" or empty values *
 * is_soulbound     = no
 * is_unique        = no
 * 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.

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: 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: Have I understood this correctly? --  -- You talkin' to me? -- cCContributions -- 18:28, 22 November 2018 (UTC)
 * show no icon for non-unique/soulbound items
 * show both icons for items with one of both attributes

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
Congratulations, Macklin, and welcome in the team!

You might want to have a look at these:
 * Pillars of Eternity Wiki:Administrators
 * Pillars of Eternity Wiki:Administrators guide
 * Pillars of Eternity Wiki:Administration policy

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! --  -- 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:  will be displayed the same way as.
 * 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 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:  makes a "–". ;) And the other ones I also use (and have in mind):   for "…" and   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,  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:

Location
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 … --  -- 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.
 * 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).


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

Acquisition

 * 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  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:
 * Add variable declarations to all infoboxes that could make use of it and don't have it at the moment – if there are any.
 * Botwork:
 * 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  in the "Find and replace" "Advanced settings" mask …
 * Place/replace " ==Description== RegEx placeholder; see above with the above.
 * Place/replace " ==Location== RegEx placeholder; see above with the above.
 * Place/replace " ==Locations== RegEx placeholder; see above with the above.
 * Place/replace " ==Acquisition== RegEx placeholder; see above 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 )? If you think it looks weird/dumb then don't worry about it.

Regarding the, 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   and the next  . 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: 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.
 * 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).

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:
 * Template:Infobox armor
 * Template:Infobox armor poe2
 * Template:Infobox item
 * Template:Infobox item poe2
 * Template:Infobox shield
 * Template:Infobox shield poe2
 * Template:Infobox weapon
 * Template:Infobox weapon poe2

Templates with Cargo queries that at least reference "location" parameters. Hilariously most of these don't even pass the location to the row template.
 * Template:Cargo armor
 * Template:Cargo armor row
 * Template:Cargo grimoire
 * Template:Cargo grimoire row
 * Template:Cargo items
 * Template:Cargo items row
 * Template:Cargo quest items
 * Template:Cargo quest items row
 * Template:Cargo shields
 * Template:Cargo shields row
 * Template:Cargo weapons
 * Template:Cargo weapons row

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 = "";

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

// New content const string DESCRIPTION_HEADER = "== Description =="; const string DESCRIPTION_COMMENT = ""; const string ACQUISITION_HEADER = "== Acquisition =="; const string ACQUISITION_COMMENT = "";

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 <span class="gamepedia_pro_user"> -- 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, just by replacing   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  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, without the changes to infoboxes ever made … Perhaps I'll add this as well, though have to care for declension issues. Objections? -- UserCCCSig.png <span class="gamepedia_pro_user"> -- 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  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 <span class="gamepedia_pro_user"> -- 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)

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? —37.120.37.12 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? -- 185.153.35.180 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   where x is each level increment (0 for levels 1-3, 1 for levels 4-6 and so on).


 * So the actual multipliers are:


 * 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
Ahoy! 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)