Pillars of Eternity Wiki talk:Community portal

A single list of all attribute/skill boosts

Hi everyone. I've been looking for a list of all available attribute and skill boosts, but all I could find was a lot of data scattered around multiple articles. So I went ahead and created such a list myself, posting it on the Wikia. I wondered whether it would be OK for me to copy this list to this wiki, as well, and if so, what a good article name for it would be. --Koveras Alvane (talk) 19:47, 23 May 2015 (UTC)

That looks great! Please do copy it over here. The same article name, Attribute and skill boosts, will work. Thanks for your work on that!

--Alianin T • C 19:53, 23 May 2015 (UTC)

Since the two wikis are using similar licenses, I went ahead and copied the content verbatim. I tried to categorize it properly and cross-link it as best as I could. --Koveras Alvane (talk) 20:13, 23 May 2015 (UTC)

Making the "Attribute and skill boosts" page obsolete again

Actually, the way the wiki has evolved now, it would be much more useful if all buffs and debuffs for attributes/skill were listed on their corresponding pages - like we already do for other kinds of stats like Accuracy.

For example if a reader wants to know how to max their character's perception, they'd naturally look for that information on the Perception page - and probably leave disappointed.

And even if they did manage to find the Attribute and skill boosts page, getting the information from it is cumbersome, because the various buffs for a single attribute are spread over three very long tables, with lots of buffs for other attributes listed in-between.

Thus, I'd like to split up and move all of the info currently on the Attribute and skill boosts page, to the 11 already existing pages (as a subsection called Buffs in each of them):

Might Constitution Dexterity Perception Intellect Resolve

Stealth Athletics Lore Mechanics Survival

After I'm done moving the info, the Attribute and skill boosts page can be deleted.

If we do it consistently (and I plan to), it won't be "scattered data", it will be structured information located in the expected places.

Normally I'd just go ahead and do it, but since the creation of that page was discussed here, it seems proper to also discuss its elimination here first. So: Any objections?
--Ineth2 (talk) 13:49, 3 September 2015 (UTC)

Sounds good to me. While we're at it, I think we can remove the "list" on each attribute's page for when it's used in dialogue. No one's updating them, and there's so many of them I don't even think it's worth cataloging.

--Mechalibur (talk) 19:21, 3 September 2015 (UTC)

I think those are useful to have, in principle. How about splitting them off into separate pages (named something like Uses of Perception in Interactions), and only linked to from the main attribute pages? That would solve the problem of there being so many of them that they'd clutter the attribute pages. Regarding "no one's updating them", all it takes is for someone who knows how to decompile/search the game date, to sit down and do it. Not sure if it'll happen, but I think the chance is higher if we keep the partial lists in some form so that they'll discover it and get the idea to improve it... :P

--Ineth2 (talk) 19:48, 3 September 2015 (UTC)

That's a potential solution if someone has the time/resources to compile a list. I still think it would be easier to mention them in quest pages where the stat is relevant. For example, if I need a certain amount of resolve to convince that one ogre in Dyrford to stop attacking the farmer's pigs, I'd probably be looking that up on the relevant quest page, not on a list of resolve-related skill checks.

Mechalibur (talk) 20:10, 3 September 2015 (UTC)

True, though if you're for example building a "speaker" character and wondering how much you'll need of certain attributes to get access to as many dialog choices as possible, you'll want such a list.

We have this "Semantic MediaWiki" thing now though, right? Does this mean we could only mention the stat checks on quest pages, and make sure to tag them appropriately so that index pages like "Uses of Resolve in Quest Interactions" could be auto-generated from them? If technically possible, that might be the most maintainable solution. Can someone who knows Semantic MediaWiki comment on this please?

--Ineth2 (talk) 20:27, 3 September 2015 (UTC)

Yes, SMW can be used to include information from other pages. We will need to come up with a layout for including the information on a quest page. I can then template it to make it easy for the average person to include it on the page. --Alianin T • C 14:25, 7 September 2015 (UTC)

Thanks for the confirmation. I've been reading up on SMW a bit myself. I think we should wait with using SMW for this until we have a full picture of what the data looks like. (See Uses_of_Might_in_interactions#Quest_dialogs as a first approximation.)--Ineth2 (talk) 16:30, 8 September 2015 (UTC)

I've started the process of moving the info - see Might and Uses_of_Might_in_interactions. --Ineth2 (talk) 16:30, 8 September 2015 (UTC)

Unifying item lists

Hi there! I am planning to do a series of changes in wiki pages, so I would like to hear your opinion before I screw something up :)

Right now, we have separate lists for most of item types (like Gloves, Small shield or Estoc). Generally, I would like to see all items of the same inventory slot on same page—divided by sub-sections, if there are more types of same-slot items (like Helmets, Hats and Hoods in Headgear page). This would be perfect with the exception of user-enchantable items (armor, weapons and shields), as there are too many of them. Also both weapons and armor have their Unique- lists (Unique weapons, Unique armor). So, what I want to do:

• join Amulet and Cloak pages to separate Neck gear page, as they share same Neck inventory slot
• create separate Unique shields page for shields, as they are also craftable items like Weapons and Armor
• create redirect pages for all item types that share same inventory slot to their common wiki page
• add all three Unique- lists to Template:Item_navbar

Is this reasonable for everyone?

Also we have this semantic wiki thing and I am thinking about possibility to use it to have item description, stats and enhancements entered only on one page (preferably own item page, like Cladhalíath) and include it on all other pages that use it (eg. Spear and Unique Weapons). Now I am no expert in this thing, so I don't know whether this would be possible at all. What do you think?

—FurloSK (talk) 11:38, 13 August 2016 (UTC)

---

I'm OK with having a page for each inventory slot that lists all its items, but we should avoid the "create redirect pages for all item types that share same inventory slot to their common wiki page" step. The issue with redirects is that Semantic MediaWiki treats a redirect page as referring to the target page itself. For example, all cloaks currently have the semantic property "Has item type::Cloak" (added automatically by the infobox). If you change Cloak to be a redirect to Neak gear#Cloaks, then that property will automatically be re-interpreted as "Has item type::Neck gear", and the information that it is a cloak will no longer be represented in the semantic data. Of course, we currently don't actually use the semantic data much. But I'm hoping that we'll get better at that, and therefore we should structure the wiki the in a way that works well with Semantic MediaWiki. This means:

• Each thing, type of thing, or concept, needs its own page (not just redirect).
• Overview pages that cover groups of things or may exist, of course, but only in addition to the individual pages.
• Redirects should only be used for synonyms or alternate spellings and the like, and never to redirect specific concepts to a larger concepts.

We don't strictly follow these rules yet, but we should try to get closer, not farther away from them.

Of course, this doesn't mean that you can't move the item list from Cloak to Neck gear. Just make sure to keep Cloak as a proper page. It may be short (probably just the intro and in-game description, then the header "Types of Cloaks", and underneath it the words "See Neck gear"), but that's okay.

--Ineth2 (talk) 12:54, 15 August 2016 (UTC)

---

Thanks for reply, I will keep to your advices then.

Another (kind of) related question is, what to do with items that have the same name as their category. Right now, we have for example Small shield page listing all the small shields and, thus, we can not create proper page for Small shield item. This is the same for eg. Robe, Brigandine and every other common item. If we need to keep "type" pages in singular because of Semantic Wiki, do we want at all to have standalone pages for basic items?

Sorry for asking possibly stupid questions—better safe than sorry :)

—FurloSK (talk) 11:12, 18 August 2016 (UTC)

---

Hm, not sure. Wikipedia tends to add a disambiguation in parentheses to the article title, when two concepts share the same name. So e.g. "Small shield" could be the weapon type, and "Small Shield (item)" the item. Or maybe we can continue get away with letting Small shield represent both concepts together? Not sure what exactly is affected by that. I can't devote a lot of time to the wiki this month, and you've probably got the best overview of the item pages anyway, so I guess... whatever you decide :) --Ineth2 (talk) 16:34, 21 August 2016 (UTC)

---

Some time has passed, FurloSK is implementing his concept, and the wiki evolves…

I'm relatively new here, started editing around two weeks ago. What I now notice is, that there's a page for each basic weapon (type), e.g. Stiletto, with the Category:Stilettos (plural-s). After FurloSK has applied his filter template, the page looks as follows: to the right a weapon type infobox, as first paragraph the in-game description, and below a table listing all stilettos from the respective category in no specific order. And at the bottom of the page a second infobox, for the base item itself, with no further explanation and looking, as if it was there by accident. (The described layout is the same for all basic weapons, the template is already applied to.)

In my understanding this would be a nearly perfect layout for a page called "Stilettos", but not for the base item. I'd like to have that changed:

• Standard item layout for the base stiletto, weapon infobox to the right, description, etc.
• Then a subsection with the other "base" weapons, i.e. the fine, exceptional, etc. variants, those the player can enchant by himself without extra effects. Again with infoboxes, perhaps reduced to the differences.
• The page "Fine Stiletto" and alike should redirect to this subsection. (Though I don't know exactly in which form that might conflict with the semantic thing…) Thus the basic enchanted weapons aren't any longer categorized, and the filter doesn't look for them: They're not part of the table anymore.
• Then the next subsection "Variants" (better than "Types" and same as for creatures). And here applies the filter, the table is generated.

Conflicts between the item- and the weapon type-infobox templates should be handled in the templates itself – and only one infobox should appear for the base stiletto.

Anyway, the current layout can't stay as it is.

And a note to FurloSK: I would appreciate an answer to my last comment on your talk page. In general, here should be more communicating…

From a – hopefully – constructive, capable and reliable contributor,

-- CompleCCity (talk) 07:49, 23 December 2016 (UTC)

Some more thoughts about this:

• No separate infoboxes for the enchanted versions of the basic weapon, but a table similar to the currently used one
• Add item infobox features to the weapon type infobox, so that it looks like an item, but works as weapon type
• Differing icons/images for the enchanted versions could be added into that table
• The variants should be listed in alphabetical order, the enchanted base versions by their grade

I've added a comment about creatures on Talk:Pŵgra, that somehow contradicts what I'm saying here. But I really think, that weapons, armors, creatures and all other categories, that have sub-categories, should be handled in a similar way. So if we make articles for each and every single weapon, then we should do this for creatures as well. But if we only make articles for base items, and add variants to that page, then the same should again be done with creatures. (The current creature tables don't look very attractive, something should be done there in any case…)

I have time, I have energy, I feel motivated to change some things here, make them better, fix them, complete them. So, all I need is some feedback from all you other contributors (not really high in numbers, currently) and we can start a discussion about all this. Please, reactions!, FurloSK and ineth, and probably Alianin and what know I who else… ;o)

-- CompleCCity (talk) 11:58, 23 December 2016 (UTC)

---

Hi there, here are my few thoughts on your feedback.

In the first place, thanks for your comments, I agree with some of them and we can together work on applying them to this wiki. But please, do not rush and pressure (on me or anyone). I am working on wiki as a volunteer in my free time, so I have a feeling that comments like "I would appreciate an answer to my last comment" (which you left 5 days ago and today it's Christmas) and "here should be more communicating" are not really the best way to communicate. The same goes to claims like "Anyway, the current layout can't stay as it is". Noone of us is owning the wiki, we are together contributing to it. Stop demanding and start offering. Meaning no offense :)

As to the specific things you mentioned:

• Item templates: I made them (and item categorisation) in accordance with patterns that already existed on this wiki. If they were wrong, we can of course change them—the fact that now every categorization is done in templates should make it much easier ;-)
• Organization of Item pages seems pretty logic to me. They contain second infobox, because the first one is for item type and the second for base item. I am strongly against putting them together: those two are different concepts, really, and thus should be handled by different templates. If you want to change those, please make sure you don't break all the semantic properties it is currently assigning (on base item pages, like Stiletto, those are both properties for weapon type and base item).
• Naming of Item pages: as with other things, I just continued with the customs already present on this wiki. We previously discussed whether base item (Stiletto) should have the same name as general page for Stilettos with Ineth and came to conclusion, that there's no real need to change all pages to plural (and yes, we wanted to avoid correcting all hundreds of links going to singular pages). Semantically, it would probably be more correct to have Stiletto for base stiletto item and Stilettos for Stiletto weapon type listing all the variants, but it is hardly worth the effort.
• Lists in Item pages are ordering items by these sorting keys: (1) appearance in game (base/wm1/wm2), (2) uniqueness, (3) damage/deflection/DR (if applicable), (4) item name. The reason why it seems to be "in no order" to you (which you would not claim if you just looked into Template:Weapon list source code) is that Semantic Mediawiki is sorting damage alphabetically (as it is range X-Y, not a number), so damage 9-13 of base Stiletto is after Exceptional Stiletto's 12‑17 damage and therefore they are not sorted properly. I know about this problem and am working on solution.
• Removing separate pages for common item types (fine, exceptional): you are right, this would strongly interfere with Semantic Wiki processing. Moreover, as Ineth said above, "Each thing, type of thing, or concept, needs its own page (not just redirect)". This seems pretty legit to me, both from semantical and technical point of view. So I wouldn't go for removing already existing fine- and exceptional- item pages.
• "Variants" instead of "Types": man, variants! I totally agree with you! :) I spent literally half an hour staring on that "Types of…" header, unsatisfied with the word and thinking about some appropriate synonym, but nothing came to my mind. "Variants" is perfect, I will gladly use it from this moment onwards. Thanks!
• Creature pages look totally horrible. I think most of them haven't been maintained in a consistent way for a long time. So I agree with you, something should be done with them. Would you be willing to do this? From what you have already said, I am convinced that you would be more than capable to take responsibility for them and to give them some logically consistent structure and update all the pages to follow it. Also some kind of Creature infobox template would probably be handy (something parallel to Item infobox). Then we should also look on NPC infobox template, as currently it rejects any race different from "humanoid" races, so all creature NPCs are now raising semantic wiki errors.

Again, thanks for your comments and effort. Feel free to reply if I have mistakenly skipped any of your questions or comments.

—FurloSK (talk) 12:44, 24 December 2016 (UTC)

---

Learnt something new, {{hr}}, thanks for showing me this! :o)

So, at first it seems as I have to make apologies for my tone, and yes, you're right, I say sorry, I'm aware that it was a bit… um, "rough", "demanding" as you call it.

The background is, that I've come here (after buying the game and starting to play it) in search for information and with the intent to contribute to the wiki, as I usually do for games I'm playing (most of my work you find on the Fallout wiki, much less on The Witcher's – both, English and German –, and some more on wikis of another host). I thought it's a great game, it would have a great community, it must have a great wiki – and then I came about this… sorry! … this mess. This nearly dead community. This wiki, looking as if a bunch of capable editors had started a great thing – and then abandoned. That doesn't reflect my experience with the wikis I'm active on. And the more sad, as it is for this great game. Then I looked for its channel on slack (where Alianin did invite you to), Alianin created a channel, but there also nothing happens. Ineth doesn't show up there, and there's no people to talk with. Maybe you in the next time, which would be great, because communicating there is like chatting, much faster, much more comfortable and easy, compared to editing talk pages. And thus more efficient.

A word about my "experience": The Fallout wiki also has only up to 6 regular contributors, and there's usually only few communication – but because it's not necessary. This small community simply works together, no need for big discussions. But when they are needed, they come, it works, things are talked about.

Here, I see a big need of talk about improvements. And as we certainly do not own the wiki, we are nevertheless that part of the community, that cares about the wiki, that shapes it, that changes it… With "we" I mean the few people who are still active here, making edits nearly every day, appearing in the month's contributors' list. And from those people, admins e.g. – Congratulations! btw. – I don't demand, but I expect to react to questions, to comments on talk pages, I expect from them page patrolling, having an eye on the recent changes, react on comments from the edit summaries or to newly created templates. Of course I know that you, that we are all volunteers here, and of course I will not demand such a thing, but sometimes I do ask for it. (And, by the way, though contributing here for only a couple weeks and yet having less than 500 edits, I really thought about attending to a sysop role as well – I am one at The Vault. And I behave the way, I just mentioned above in my expectations.)

You say, I should offer rather than demand… I have offered. I even have begun changing. But as those are things affecting a large part of the wiki, several, many articles, I do need feedback on my offers and thoughts. Without that I don't dare to go on changing, or would do it with the awareness of risking rollbacks… or at last and for the worse would loose motivation.

And, as I have offered, I have time. I don't think, arguments regarding the needed effort or the number of affected articles should be a concern. Changes take time, changes need effort – but this is usual, for a wiki as well. And seriously, temporary consequences of probable greater changes to articles can't in any way be worse than the current look of many other articles.

And now for the constructive part of the discussion:

• Staying with weapons… A stiletto is at the one hand a weapon type, defining most of properties for all stilettos found in the game, and on the other hand a single item, using exactly these properties. Then there are variants to it, first the base enchantments (fine, exceptional, superb, legendary), which only alter the base properties, and second the unique variants, which have additional properties, custom enchantments. I really like the idea of an item page for the base stiletto, with an item infobox as for all items. With two tables, one listing the regular enchantment versions, and the second listing the uniques.
  • As for the complications if merging the weapon type infobox into the item infobox: the latter already does reflect all information from the former one, with slightly different wording. So there's actually no need for a visible second infobox on the page, it's redundant. Why not hide it? Make the weapon type infobox invisible?
  • And for the split into two tables without redundant, doubled information: We could all unique and semi-unique (weapons with additional custom enchantments on top of those, the player can apply, but not unique to the world) weapons of a type sort into a subcategory "Unique stilettos". Only the base version and the fine etc. variants remain in the parent CAT "Stilettos". Your filter uses the unique-SubCat, et voilà!, clean tables. And the Fine Stiletto could be an item page as all other.
• The sorting: I did take a look into the template and noticed the sort key, also noticed you were working on the Has Name… But it looks, as there's no specific order. I'd prefer the item's name as first priority, but that is something that can be discussed later.

The creature pages… I have done a start, pointed you to my sandbox draft. But that also is something I won't like to roll out without further discussion and feedback (yet have to take a look onto your talk page and the probable answer you gave me there…) And additionally it's something I'd like to do at the time, I'm through with the game, or at least have my bestiary complete without cheat. Probably I create a second, cheated char later, for some more extensive wiki work, and will do so before having finished the game with my current first char. But that also needs some more time. But yes, I'm willing to do that. As I am willing to do much more things here…

As you said, today's Christmas. So have – have you all! – a very, merry Christmas! Discussion goes on, when it goes on, but we really should wait for Ineth's comments on all this, probably this will take up to the next year. But if my recent arguments are something you could approve – and they don't mess all things up, only change some layout –, we as well could begin, and perhaps Ineth comes back, takes a look and says "Fine!". ;o)

CompleCCity (talk) 15:35, 24 December 2016 (UTC)

---

I'm personally fine with merging infoboxes for pages that represent 2 concepts, as long as the intro sentence of the article makes that clear. ("X is a Y and Z in Pillars of Eternity" or somesuch).

A similar situation will arise when we create a separate page for each kind of creature. For example, take the creatures currently covered by the page Dragon:

• Drake will become a creature page.
• Cail The Silent will become both a creature page, and at the same time also an NPC page.

So its infobox would have to contain:

• all the things from Template:NPC infobox (location, quests...),
• all the things from the yet-to-be-created Template:Creature infobox (defenses, special abilities...)
• all the things represented in both infoboxes (level, attributes...).

--Ineth2 (talk) 14:08, 15 February 2017 (UTC)

See also Pillars of Eternity Wiki talk:Guidelines/Creature pages -- -- You talkin' to me? -- cCContributions -- 08:29, 16 February 2017 (UTC)

Pillars of Eternity II: Deadfire

See my entry on the admin noticeboard. -- -- You talkin' to me? -- cCContributions -- 13:36, 27 January 2017 (UTC)

Request for administrator status

Hello dear Pillars community!
Hello Ineth2, hello FurloSK, hello Tagaziel!
Hello Alianin!

I'm compleCCity, and I started editing this wiki on December 8th, last year. Today I've exceeded the 1000 edits mark (though some of them could as well had been made by a bot), which was a self-set goal to ask for administrative user rights. Planned to do this I had nearly from the beginning…

I am administrator at the Vault since around a year, though I had some off-time during last summer. I am from Germany, which sometimes is noticeable in my wording and grammar – hopefully not too bad.
I have some experience with a lot of wiki-related stuff, but no deep experience with template coding or CSS. Which doesn't discourage me from looking into it, however.
Since my start here, I'm "patrolling" the recent changes on a nearly daily basis. I've welcomed other, new contributors. I've introduced some of my ideas and thoughts about this wiki, not always striking the right chord. I've edited articles, templates, their documentations, categories, images. I've created some templates, I've begun cleaning up categories and images, created a lot of red links… Future plans contain completion and unification of all abilities and talents, then their overview pages, then continuing with the images/icons and their re-categorization. I still plan the introduction of guidelines and policies. But here's a lot to do, so some of my "projects" have to wait.

Why admin? Now, I have experience. I feel related and responsible for this wiki. I take my work seriously. These days, after the official announcement of Pillars of Eternity II: Deadfire, the wiki may regain many editors, filling up existing pages or creating new ones with unverified information, gathered from all the internet. The wiki itself has to prepare for the game successor. Layout and design questions may appear. The news have to be maintained, made up-to-date; I already mentioned this on the admin noticeboard. And even if I said that I'm not the most experienced person with CSS and templates, the rights to edit the MediaWiki could help. I'm part of the Slack community, which makes communication easier. And the less important reasons: it would make my work here much easier, especially regarding the categories and images cleanup (I see lots of deletions in the future ;o).

The wiki could use an additional admin, with Ineth only visiting every few weeks, FurloSK with a head full of personal stuff, and Tagaziel as a global admin with far above 100 wikis to maintain. So, here I am. Take a look at my contributions to see what I am doing. Ask me questions on my (relatively vestal) talk page. Or discuss with me on Slack's Pillars channel. Or… make me admin. :o) -- -- You talkin' to me? -- cCContributions -- 17:52, 28 January 2017 (UTC)

At the risk of pulling a Thaos, I'm promoting CCC. I know him from a dozen other wikis and he can be trusted with the keys to the kingdom, comrades! Tagaziel (talk) 10:10, 29 January 2017 (UTC)

Many thanks!

If concerns exist – feel free to comment. There's nothing that couldn't be undone or reverted. -- -- You talkin' to me? -- cCContributions -- 11:28, 29 January 2017 (UTC)

Hi there, and sorry for being MIA so much, things have been a bit crazy for me in real life these last few months.

From the change log it's clear that you're very productive and having a positive impact on the wiki, and it would be a shame if you were impeded in your efforts by not having access to admin tools like page deletion. So, no objection from me... Welcome aboard!

--Ineth2 (talk) 15:56, 14 February 2017 (UTC)

Many thanks to you, Ineth2, for the welcome, your opinion, and especially your confidence in me. I hope, I don't disappoint you, or the community. (Though I have been a bit lazy these last days.)

I wish you the best for a bit more straight life in the future, and would be happy to see you more frequently again – but private life always comes first! -- -- You talkin' to me? -- cCContributions -- 16:09, 14 February 2017 (UTC)

Restructuring the creature pages

I've moved this section to Pillars of Eternity Wiki talk:Guidelines/Creature pages, please continue the discussion there. --Ineth2 (talk) 19:47, 15 February 2017 (UTC)

Codifying guidelines for editors

Until now, the wiki mostly grew by editors looking at the existing content and trying to structure/layout/format additional content accordingly, as best they could guess the earlier editors' intentions.

I think it's time to actually write down our "best practices" and usual ways of presenting different types of content, that we have discovered to work well and that we like to use to improve consistency across wiki pages.

The Pillars of Eternity Wiki: namespace already has the following page, but that's pretty generic stuff (and not much at that):

• Manual of Style

I think we need at least these new pages:

• Guidelines — Created as a stub for now.
• Guidelines/Quest pages‎‎ — I plan to write this one.
• Guidelines/NPC pages‎‎ — Written.
• Guidelines/Creature pages‎‎ — Created as a stub for now, so its talk page can be used.
• Guidelines/Item pages‎‎
• Guidelines/Ability pages‎‎
• Guidelines/Location pages‎‎
• Guidelines/Screenshots — I plan to write this one.

The plan is for us to:

1. Create the new pages listed above (and maybe more if needed).
2. Discuss them on their respective talk pages, and iterate on them until we get them into a decent state that all wiki admins are okay with.
3. Then add a prominent link from the community portal to the "Guidelines" overview page (which will in turn link to the rest of them).

Please give feedback on the ones that have already been created, on their respective talk pages.

And FurloSK and/or CompleCCity, please volunteer to write some of the remaining ones... :) Basically, just documenting the status quo is a good start, then improvements can be discussed on the respective talk page.

--Ineth2 (talk) 17:44, 16 February 2017 (UTC)

This perhaps sounds like plagiarizing, but on my… um… source wiki (:grin:), the Vault, the sidebar looks a bit different from here, and I like the idea to have a link to the guidelines right there, visible for all and accessible without any detour.

And I have specific ideas for the screenshots guideline:

• A note about the changeable ZoomRange with recommended values and related things.
• A description of how to disable GUI elements for a clean screenshot. (Which I'd like to be required for uploading new screenshots. Though this would make nearly all existent images bad quality.) -- -- You talkin' to me? -- cCContributions -- 18:19, 16 February 2017 (UTC)

I'm sorry to put this here appended both to an old discussion and somewhat as a topic shift, but I wasn't entirely clear how to create an entirely separate subsection in the general "talk" area and this is, in a sense, pertinent to main editors thinking about guidelines: Should this wiki, as a generalisation, think about a policy for avoiding spoilers concerning the Engwithians and the nature of the gods? At present, three of the wiki pages on gods have explicit references to the matter (in the case of Abydon, in the lede of the main text.) It's in the nature of new players to consult broad-brushstrokes lore pages. For example, an entirely fresh character rolling a Priest for their PC would very likely want to figure out if there was a god they liked the lore of: having the business with the Engwithans right there undoes quite a lot of the central storytelling of the game, in my view rather needlessly.

I wasn't sure if it was an aesthetic aversion for the conventional "major plot spoilers for Pillars of Eternity 1" type spoiler-hiding buttons, or simply that a lot of work would be involved in "policing" spoilers. Or perhaps as people added content for WM1, WM2 and POE2 they weren't thinking any longer of POE1 spoilers. (I wouldn't be surprised if the editing history of the Abydon article reflected that, e.g.) At any rate, something to consider. 156.57.146.174 03:44, 3 August 2018 (UTC)

Categories restructure

Following the Admin noticeboard topic Preparing the Wiki for Pillars of Eternity II: Deadfire and because discussion pages shouldn't be placed in the main name space, I've moved the original article to a subpage of this community talk.

You can find and participate in the discussion here: Pillars of Eternity Wiki talk:Community portal/Categories restructure.

-- -- You talkin' to me? -- cCContributions -- 08:34, 10 November 2017 (UTC)

Item articles' sections

One question: "Acquisition" or "Location(s)"?

Same then for quests. Though here it would be clear: it has to be "Acquisition", because "Location" means something different for a quest.

Opinions? -- -- You talkin' to me? -- cCContributions -- 10:49, 29 November 2017 (UTC)

Definitely locations for items. For quests, this should be covered in the lead or the synopsis section. Tagaziel (talk) 14:43, 29 November 2017 (UTC)

Why "definitely?" ;)

And singular or plural? (And that's not dependent on the amount of entries.)

Also I'd definitely go for a bullet point list, again independent from the amount of entries.

-- -- You talkin' to me? -- cCContributions -- 14:51, 29 November 2017 (UTC)

Yes, it's dependent on the amount of entries. Location for items available in a single place, locations for multiples. Tagaziel (talk) 15:10, 30 November 2017 (UTC)

So if there's only one, currently, and some contributor finds another one, they – besides adding the info – have to consider changing the section heading? That's … um … No. The same way as we use bullet point lists for single entries as well, we should name it consistently pluralized.

By the way, you didn't explain "definitely". ;) -- -- You talkin' to me? -- cCContributions -- 15:25, 30 November 2017 (UTC)

Weapon(s) and Armor(s)

Yes, I know, an armor's plural still is "armor", not "armors" …

Okay, getting back to a former discussion here. I still don't see the real purpose of having an article that's named e.g. Hunting bow, but instead of giving a brief information of the in-game item, it lists an overview of all possible variants of this item, and only then – far down at the bottom of the page, hidden below a large table – there's the expected infobox and hopefully some acquisition info.

As the wiki's migrated to Cargo instead of SMW, the {{item infobox}} soon gets deprecated and will be replaced. As of this, I think all former arguments regarding SMW dependent conditions in this and the {{weapon type infobox}} can be considered deprecated as well.

So, again, what I would like to have:

• An article named e.g. Hunting Bow (in-game capitalization) which has a standard infobox, a regular intro, the Description and Locations, perhaps more info like Trivia. Then a section "Enchanting" with a small table that contains an overview of the fine, exceptional, superb and legendary variants, focussed on the stat differences, and a link to the unique variants, not a whole table again.
• The current Hunting bow will become Hunting bows, as it is an overview, a list article, not one for a single item. It may still consist of a table with all possible variants and the weapon type infobox, but nothing else. The latter's purpose should be added as basic non-table information on the article as well, such as "Hunting bows are ranged weapons with a basic damage of …" Weapons with a weapon type bonus, such as Accurate, should have stated this as well in a descriptive manner.
• I'm not sure whether Hunting bow then should redirect to one of both articles or rather become a disambiguation page; perhaps the latter's the best solution.

This way we can have brief and clear articles for every possible single weapon and not confuse the reader, who's looking up the values of their Hunting Bow and how and where to acquire one. And still their possibilities of enhancing the weapon are listed.

The infobox's section header that repeats the weapon type name – "Hunting bow", followed by "Combat Type", "Range", "Handing", etc. – could be renamed to something like "Weapon type: Hunting Bow" or simply "Weapon type related". More ideas?

All this of course also applies to the armor pages.

This will in the first instance require a lot of work and time until all links are adjusted, but I'm capable and willing of doing so. And I think this is the best solution for these pages.

Pangaearocks, I really ask for your feedback on this. Tagaziel, yours as well – but Pangaea, you do have more insight into the templates, SMW and the possible consequences of these changes. So, is there something speaking against all this? -- -- You talkin' to me? -- cCContributions -- 16:40, 30 November 2017 (UTC)

---

I support turning Hunting bow into hunting bows as an overview page, with the hunting bow page being one for the regular variant (it's standard practice for me, don't know about you, PR). There's no need for disambiguation when a simple Template:For will suffice.

With that said, I also don't see the need for an article spelling out the properties of a weapon, effectively repeating the infobox.

Also, plz no capitalization. It's wildly inconsistent. I'm using it for now because it's faster, but I support decapitalization as the standard. Consistency is easier to maintain when you don't have to wonder if hunting bow should be capitalized. Tagaziel (talk) 17:13, 30 November 2017 (UTC)

---

I completely agree that we should have a page for each individual weapon, and that has been my intention all along - just like with creature pages. When I created those a few months ago, I created for instance Bears for all types of bears, and Bear for that individual animal. We should do the same for weapons, and can then use the plural version (like Hunting Bows) for an overview of the different types of hunting bows. The game uses capitalised names for weapons, so I think it would make most sense to do the same on the wiki. Then redirect e.g. (the current) Hunting bow to Hunting Bow. For those particular pages, maybe we can have that "did you mean?" thing on top of the article, with a link to the plural version, so people can easier find the overview of the weapons.

I think it's a bit pointless to start doing this manually though, spending tons of time on tiny name edits on maybe 1000 pages, when a bot can do that a great deal faster, in the right timeframe. Besides, the pages will have to be redone as part of the Cargo migration anyway. However, since SMW is heavily integrated on item pages, I simply can't do those as step one, as I first need to make templates for "sub" pages, like enchantments and recipes, so all those pages don't break when I migrate the main item pages to Cargo. That's why I have postponed item pages until last. It will involve a lot more work. I have also had a slight hope of User:Furlosk coming back, as he's bound to have a better overview of all that stuff than me or anybody else, since he did all that work with SMW. Right now the item pages also work well for the most part (though there are some errors here and there), so there has been less urgency to migrate those pages. The information is probably more up-to-date than abilities and talents and such too, where a great deal of pages contained incorrect information.

The job on item pages is basically to do the same job as currently, but via Cargo instead of SMW. It needs to be done at some point though. −Pangaearocks (talk) 19:39, 30 November 2017 (UTC)

---

I'm opposed to capitalization because it disturbs the flow of text, as random capitalization does, especially when you have items with descriptive names, such as "Unfinished Letter" or similar. "You find an Unfinished Letter" looks worse than "You find an unfinished letter", since capitals are conventionally used to denote either proper nouns or the beginning of sentences. Furthermore, decapitalizing articles allows for more consistency - especially since the Tyranny wiki uses exclusively decapitalized titles, as does The Vault and other wikis that I've inherited or helped find - so it'd be kind of jarring to switch between Obsidian wikis and have random capitalization.

Not to mention, decapitalization is the current wiki approach, so altering and moving existing pages around by hand is piling work on top of work. Tagaziel (talk) 19:56, 30 November 2017 (UTC)

---

I don't exactly get it why that shall be done by a bot – perhaps because of my lack in experience with them. It's not a simple move, pages have to be created for this to work, and page content has to be altered. And if I am willing to do it, why not let me do?

I would keep/place SMW templates for tables, which then could be easily replaced by new Cargo ones.

For capitalization, see below …

-- -- You talkin' to me? -- cCContributions -- 16:05, 1 December 2017 (UTC)

---

When a bot can do this more efficiently and faster, I'm not sure why you want to waste time on it? Also because all these pages will surely need to be redone as part of the migration to Cargo, including renaming (and possibly some new) fields in the infobox. A bot is much better at doing this, and if you make small edits to 1000 pages first, there is a good chance all that work is wasted too. Similar to the recent edits to Crafting actually. Not sure why you did that considering you know I'm working on a template for it, which again is likely to mean your work there is wasted, because the content will in the near-ish future be automatically generated by Cargo. I'm also worried that if this work is started now, it will break SMW, which is currently heavily integrated on all item pages. I don't have a full overview of the possible impact, as I'm not nearly as knowledgeable about SMW as I am about Cargo. Pangaearocks (talk) 20:29, 1 December 2017 (UTC)

---

Because it's my time? And I can freely decide upon how to spare it? ;) (Yes, I feared, those edits on crafting might be redundant …)

I already have done such a move/edit, namely for the Great Sword/Great swords. It's not as I would change the information on the pages itself, so I don't see an impact on SMW. And if I carefully watch the contained properties of each of those pages and look that there's no loss of them, then I think it would be safe.

Anyway, such "preparing" work would make future editing, such as the switching to Cargo, a bit easier, wouldn't it? And it's not really a 1000 pages. ;)

This is connected to the capitalization topic, so I continue there … -- -- You talkin' to me? -- cCContributions -- 08:53, 2 December 2017 (UTC)

Capitalization in this wiki

Discussion

So here we finally are, a topic preying on my mind since I started editing here.

I don't see that "decapitalization is the current wiki approach", as you mentioned, Tagaziel. Instead I have done attempts in the opposite direction, as well as Pangaearocks did.

The game's encyclopedia, the informative pop-ups the game fades in when holding the pointer above a "link", do use capitalized terms within the flow of text. Example:

Accuracy is part of almost every attack. It influences how likely the attack is to affect the target. Accuracy is defined primarily by a character's class and level but it is also influenced by Perception, Talents, and other active effects, such as spells or items. When an attack is made, the Accuracy is compared to the appropriate defense on a target to determine how the attack roll will be modified. If Accuracy is above the target's defense, it will be more likely to result in a Hit or Crit, less likely to result in a Graze or Miss.
Any Ability or Talent that does not use a weapon as part of the attack gains a small Accuracy bonus based on the level of the character.

Also nearly each "item" (incl. spell-, ability-, talent-names, etc.) uses upper-case letters for nearly each part of the name, similar to capitalization as it is used in titles. As I think to have observed, most of this wiki's random editors adopt this.

On the other hand, coming back to the aforementioned example, I do see the advantage of using consistently common rules. That text then would look like this:

Accuracy is part of almost every attack. It influences how likely the attack is to affect the target. Accuracy is defined primarily by a character's class and level but it is also influenced by perception, talents, and other active effects, such as spells or items. When an attack is made, the accuracy is compared to the appropriate defense on a target to determine how the attack roll will be modified. If accuracy is above the target's defense, it will be more likely to result in a hit or crit, less likely to result in a graze or miss.
Any ability or talent that does not use a weapon as part of the attack gains a small accuracy bonus based on the level of the character.

Far more easy to write, as one doesn't have to care about a specific term's spelling, such as class and level aren't capitalized by default.

But then we also have to think of several spell names, especially the chants: they look and feel like poetry or song titles – and thus should use the proper, current capitalization. But how would that be consistent with unique item names, which sometimes are poetic as well?

There could be more said, but at the moment I will leave it as this. Actually I don't have a preference, I could live with both, "Hunting Bow" and "Hunting bow". But if I am the one to tip the scales, as it currently looks like, I'd say upper-cases. (By the way, I have started to create an overview regarding this.) -- -- You talkin' to me? -- cCContributions -- 16:05, 1 December 2017 (UTC)

---

I'm a little uncomfortable about voting over this issue, because I'm not entirely sure about the best approach, and we are only 3 active editors here at the moment. Tagaziel made reasonable comments on the matter, however, and for the time being I am leaning towards lowercase, and have put in a vote for that. Given the bigger content needs on the wiki, however, I don't think this is something that urgently needs attention right now, as regular users probably wouldn't give a toss whether links they click on have upper- or lowercase letters. The actual content is the reason regular users visit any given wiki, and that is the part I strongly feel we need to focus our attention on. There is also the issue I mentioned above, about possible dire consequences for item pages given the heavy SMW integration on those pages. Properties have required/allowed fields set, and it's quite possible that changing pages and infobox content will result in a traffic jam of yellow warning icons. Quite frankly, I don't see the need to change all these things around, at least right now, given negligible upsides at best, and possibly big downsides. Pangaearocks (talk) 21:49, 1 December 2017 (UTC)

---

I see the issues with SMW, which have to be observed carefully in this process.

The urgency of the matter, however, in fact is related to what you see as main priority: if new content, such as the items from the Deadfire Pack (Deadfire pack?), missing abilities and all the things beta/PoEII, is to be created, why generating unnecessary work by naming them the one or other way, if there's a policy for it some day and probably lots of moves are coming up? Why not doing it the right way from the start? It's not as I would start moving all pages now to lower cases, that would be done step by step …

Okay, though only from three editors yet, but the poll yielded a result (and makes my "glossary" redundant). And regarding several articles' naming done by past editors and admins, this only furthermore approves the result. One last attempt (for some new item from the last "expansion"):

• One-Eyed Molina's Gold-Fingered Spike-Finger

vs.

• One-eyed Molina's gold-fingered spike-finger

Really? I mean, with one upper-case within for the namesake? And how many capitalization redirects will this yield?

-- -- You talkin' to me? -- cCContributions -- 08:53, 2 December 2017 (UTC)

Ahh there did you put that poll. Lower case is totally relativ, variations do you need anyway. I see more syntax failures, where keeping a certain structure is more important than this. Arawn76 (talk) 17:42, 6 December 2018 (UTC)

---

Btw, ok this topic is been over a year now old, but i've read a bit through it and must smirk with a cheeky grin. I see and understand your reason a bit when you write all lower description lower case you are on the first hand faster but it's just you or the one that is used to it. Now think about if someone new comes to it and writes you have there a discrepancy and then somewhere else, this makes it far more complicated since you can't foresee the action of someone else and the other can't foresee your action beforehand, that isn't used to it. You have it quite simplier, so far if i look towards how i write or often see someone else writes not just only in the wiki, generally, when you simply write and then preview, you see automaticlly which word needs a redirect since it's a variation. Click on it, redirect, finish, next time when you write somewhere else this is no more needed. That's just preadvanced thinking, people write an item mostly so as they see it ingame. And my experience is quiet simple. Ok i personally look more on structure, a good view and a relaxed real life. Keep the base Structure 1:1 like the game displays, watch on syntax completeness, descriptive textflow low, picture low. To many rules scare off, cause failure, sorry to say. Arawn76 (talk) 22:26, 6 December 2018 (UTC)

Poll

Upper-case names	Lower-case names	User
		CompleCCity
		Tagaziel (talk)
		Pangaearocks (talk)
		Arawn76 talk

Universal field for enchantments in poe2

Sort of continuation of Template talk:Infobox weapon poe2... note that this is also applicable to poe2 shields, items and armor.

Tagaziel has brought up an interesting point here, questioning the need for the 3 different fields that currently exist (as remnants of the poe1 template) in Template:Infobox weapon poe2, where they could instead be substituted with a single, universal field. I think that this is actually a good idea, since it takes any guesswork out of which field an enchantment belongs in. We wouldn't be losing the categorization/distinction of an enchantment as being a weapon bonus or an enchantment, since the enchantment infobox already contains a "type" field, which seems to be used to store this information already (assuming that it has been filled out correctly). One field that needs to be thought of with this universal approach is the poss_enchantments field, since we would still need a way to identify an enchantment as one that isn't on an item by default. Perhaps poss_enchantments could be the exception to a universal modifier field.

Additionally, if we still wanted the infobox to categorize enchantments, the infobox template could query the type field of the enchantment, and group them that way instead.

Also relevant is the idea of making a new infobox + cargo table for poe2 enchantments. This is something that I think needs to be done eventually, since there are a few fields in the Template:Infobox enchantment that do not apply to poe2 enchantments, as well as missing support for the amount of ingredients required to enchant some items in poe2, but this is where it gets a bit hairy...

If you look at any enchantable item, you'll see that the upgrades are all listed in Template:Pe2crafttable and Template:Pe2craftmods - a fantastic bit of work by Tagaziel. But I question, was this meant to only be a temporary solution, a fast track of data from the game files? There's a clear disconnect between enchantments that are already applied to weapons and these craftmods, where there doesn't need to be. So I'm suggesting that we also look into the possibility of migrating/merging pe2craftmods as part of creating a new template meant for poe2 enchantments. There's also the case of pe2craftcons, but I will make a post in Template_talk:Infobox item poe2 regarding a few additions I have in mind for items specifically.

One thing at a time though! We can worry about that last part later. I'd like to get some opinions on the universal field suggestion before incorporating it into the proposed changes. Macklin (talk) 13:48, 27 November 2018 (UTC)

Seems, the time has come for me to delve deeper into the matter. I guess, I should take some looks into the actual games and how weapons (and other items) work, how their bonuses are shown, how that what's reflected here by an infobox actually looks in-game (it's quite a time since I've played PoE1, and never started PoE2 until now …). Give me some days, please, to get an opinion. -- -- You talkin' to me? -- cCContributions -- 21:41, 27 November 2018 (UTC)

Proposal for administrator status

Herewith I propose to grant Macklin administrative rights to this wiki. Not for the need of another sysop, but for

• caring for the wiki as a whole;
• patrolling the recent changes, reverting vandalism and fixing edits by unexperienced users;
• actively talking with the community;
• a high amount of high quality contributions;
• knowledge of the game and how to get verified data and image files;
• good knowledge of coding and actually using this in the template namespace;
• expanding and improving our Cargo experience.

Having administrative tools available would help Macklin to do even better work.

As administrator Ineth2 has last been active nearly eight months ago, administrator FurloSK visits only occasionally, wiki manager Tagaziel is still globally active on – as of now – 256 Gamepedia wikis and has a lot to do elsewhere, and I – as the wiki guardian – may become more inactive again than I currently am and also don't have that much insights in especially Pillars of Eternity II: Deadfire, I think, expanding the team wouldn't hurt. (Phew – long sentence … ;)

I'll leave comments with a link to this proposal on the other administrators' user profiles, so that they become notified. If there's no reaction by them in a week from now on, I will use a different way of contacting them. If there's no reaction in another week, well …

A tenday, not a week – sorry. Messages sent. -- -- You talkin' to me? -- cCContributions -- 12:14, 17 January 2019 (UTC)

Dear Pillars of Eternity community,
if something speaks against this, please leave a comment with your reasoning below. Of course you also can approve of it, instead! :) -- -- You talkin' to me? -- cCContributions -- 11:19, 7 January 2019 (UTC)

---

Not exactly sure how to respond, but I'd be honored to - thanks for the proposal!

Having admin perms probably wouldn't change much of how I do things, but perhaps when things do come up that require such permissions, I wouldn't need to pester an admin about it, so there's that. And my eye has been on that pesky deletion page for a while now =P. On the topic of activity, regardless of admin status, no one can say that with certainty they'll be active until the end of time, so it's understandable especially when someone gets tired/bored of the game, the subject of the wiki. Not even I can promise that I won't. However I still have a long mental list of things that I'd like to improve, and even at 500 hours in (I do a lot of testing) I'm pretty far from finishing Deadfire, so both of those things should keep me busy regardless. Macklin (talk) 12:24, 7 January 2019 (UTC)

Wait, you didn't have adminship already? That's a grave omission, I'll fix it asap. Tagaziel (talk) 09:17, 8 January 2019 (UTC)

Huh? You had that already in mind, Tagaziel? -- -- You talkin' to me? -- cCContributions -- 13:30, 8 January 2019 (UTC)

A tool/hack for taking better world map screenshots in Deadfire

Taking screenshots of some of the larger islands in Deadfire isn't easy. Just look at the number of screenshots that exemplify this. Tagaziel knows this best, he clearly must have had a really fun time stitching them together. Although I admire his effort (the seams are very well hidden!), I thought they could be better. So I made a small hack that enables this, you can check it out here.

Perhaps I will go through sometime and update some of the worse ones with screenshots that don't have any seams. This also opens up the possibility for an interactive world map using the actual tile set, something I think would be really cool.

Understandably, not many people would have a use for this tool, and it's not really intended to be used during gameplay, but I figured I would at least share it just in case someone wants to know. Macklin (talk) 06:02, 9 January 2019 (UTC)

Portrait category structure proposal

Figured I would take some time to tackle restructuring at least one branch of categories - portraits. I think it's relatively safe to do so, since it's less of a "forward-facing" category tree than one that deals with articles.

I've already created a portion of this structure - inspired by the character category tree - but I haven't added anything that wasn't already in those categories:

• Category:Portraits
  • Category:Portraits by game*
    • Category:Pillars of Eternity images - Portraits
    • Category:Pillars of Eternity II: Deadfire images - Portraits
      • Category:Beast of Winter images - Portraits
      • ...
  • Category:Portraits by gender*
    • Category:Female portraits
    • Category:Male portraits
  • Category:Portraits by race*
    • Category:Aumaua portraits
      • Category:Coastal aumaua portraits
      • Category:Island aumaua portraits
    • Category:Dwarven portraits
    • Category:Elven portraits
    • Category:Godlike portraits
    • Category:Human portraits
    • Category:Orlan portraits
  • Category:Portraits by type*
    • Category:Small portraits <- e.g. File:Aumaua female PoE1 portrait 1 sm.png
    • Category:Large portraits <- e.g. File:Aumaua female PoE1 portrait 1 lg.png
    • Category:Conversation portraits <- e.g. File:Female_Aumaua_B_Convo.png
    • Category:SI portraits <- no uploaded examples, but file names end with _si
    • Category:Composite portraits <- e.g. File:Eder composite.png

Notes

• Categories marked with a '*' are used purely for sorting, and files should not have these categories added to them. All others will be categories that files will actually be categorised under.
• With this system (as previously), there's no easy way to find a file that for example, is a large portrait of a male boreal dwarf. This would only be possible with prebuilt DynamicPageList queries, or with Multi-Category Search, or even a Page Forms form that calls a DynamicPageList template (not sure if this can be done).
• DLC portrait images (images under Category:Beast of Winter images - Portraits for example) are not added to the base game category, but the category page itself is.

Alternatives

• In this example portraits from both poe1 and poe2 are lumped together. This is mainly because of the crossover of character portraits (not conversation portraits) between the two, only a dozen or so portraits are unique to poe2, and the rest are copied from poe1. A down-side to this is that there is no form of sorting under the games themselves. This is something that might need to be preserved, so an alternative structure could be to remove the "Portraits by game" category, and have:
  • The same structure as above, but for each game instead of it unified (e.g. a large portrait of an male coastal aumaua that exists in poe1 would be in the categories "Pillars of Eternity portraits", "Pillars of Eternity large portraits", "Pillars of Eternity male portraits", "Pillars of Eternity aumaua portraits", "Pillars of Eternity coastal aumaua portraits")
  • The same structure as above, but for each game AND an overarching structure (the same portrait as above would be in those categories AND "Large portraits", "Male portraits", etc). This might be overkill.
• Or we say screw it, fine categorization like this isn't needed, and have:
  • Category:Portraits
    • Category:Pillars of Eternity images - Portraits
    • Category:Pillars of Eternity II: Deadfire images - Portraits

And no further categories.

I'm going to leave this here for a bit before making any decisions. My personal opinion leans towards the first alternative structure, where each game has its own hierarchy like the above, and no overarching category. Macklin (talk) 10:23, 10 March 2019 (UTC)

Deadfire spells/abilities

While PoE1 has a complete wiki, PoE2 does not.

For example, we see the effects of spells for PoE1, but not for PoE2. Not that we need a wiki to know the effects, but just an example. - Can a page for a given spell be modified to specify changes from PoE1 to 2 ?

I am a bit confused as to where and how to add info for PoE2 if needed.

Answer : I just realized the main page for this wiki has a menu for PoE2 topics. Although still somewhat confusing in regards to how wiki normally function, this will do.

BarazSiriel (talk) 02:08, 11 December 2019 (UTC)

Exemple : PoE2 (Deadfire) Grimoires named on this wiki have spells that point (link) towards the PoE1 spell descriptions. This of course can only cause confusion and does not help. PoE1 and PoE2 spells should have clearly different descriptions/stats (could be on the same page for simplicity sake).

BarazSiriel (talk) 00:54, 13 December 2019 (UTC)

Deadfire spells (more generally called abilities) are yet to be added to the wiki. For now, references to poe2 abilities link to their poe1 counterparts (if any). This is temporary until an equivalent poe2 ability page is created. At the moment, poe1 abilities are stored within Template:Infobox ability, and I'd imagine a new template/table will need to be created for abilities in poe2, but reworked to better represent the differences between the two games. Deadfire ability pages will be created as a separate page entirely, with a disambiguation suffix. The fields for a poe2 ability infobox will need to be decided on, so if you have any suggestions, feel free to post them here! Macklin (talk) 11:28, 13 December 2019 (UTC)

Yes, exactly : a second template, placed under or beside would be fine. As for the fields, the new ones are, for example, Interrupts On. But, since all that info is in-game (does not require wiki consultation), the essential now is to make it clear they are the PoE1 spells. --BarazSiriel (talk) 18:18, 13 December 2019 (UTC)

I'm terribly out of the loop now, not having played the game for several years, but I took a stab at creating templates for POE2 abilities and talents. They are basically just copies of the POE1 version, though, so most likely many fields will need to be changed. But it's something I suppose. Pangaearocks (talk) 09:23, 15 April 2020 (UTC)

It's a start at least! The whole poe2 abilities thing is a huge undertaking, one that we need to be sure on before starting to add data. Perhaps now that you've made the templates I could take a closer look at what fields should be added/removed - thankfully a lot of it seems to be the same. One thing though, the templates should probably use the _poe2 suffix like other poe2 templates, for the sake of consistency. Macklin (talk) 20:23, 15 April 2020 (UTC)

Thanks, that makes sense. Had my eyes on the templates overview page, and then mucked up the titles. The naming pattern is too ingrained from the Witcher wiki I guess, where we use 1, 2, 3 as "suffix". Cheers for fixing it. Pangaearocks (talk) 01:06, 16 April 2020 (UTC)