Pillars of Eternity Wiki talk:Community portal

From Pillars of Eternity Wiki
Jump to: navigation, search

A single list of all attribute/skill boosts[edit]

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

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

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

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:

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 -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 08:29, 16 February 2017 (UTC)

Pillars of Eternity II: Deadfire[edit]

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

Request for administrator status[edit]

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) -- UserCCCSig.png -- 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. -- UserCCCSig.png -- 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! -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 16:09, 14 February 2017 (UTC)

Restructuring the creature pages[edit]

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

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

I think we need at least these new pages:

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.) -- UserCCCSig.png -- 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. 03:44, 3 August 2018 (UTC)

Categories restructure[edit]

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.

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

Item articles' sections[edit]

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? -- UserCCCSig.png -- 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.
-- UserCCCSig.png -- 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". ;) -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 15:25, 30 November 2017 (UTC)

Weapon(s) and Armor(s)[edit]

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? -- UserCCCSig.png -- 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 …
-- UserCCCSig.png -- 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 … -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 08:53, 2 December 2017 (UTC)

Capitalization in this wiki[edit]


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.) -- UserCCCSig.png -- 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"):
Really? I mean, with one upper-case within for the namesake? And how many capitalization redirects will this yield?
-- UserCCCSig.png -- 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)


Upper-case names Lower-case names User
Yes check.svg CompleCCity
Yes check.svg Tagaziel (talk)
Yes check.svg Pangaearocks (talk)
Yes check.svg Arawn76 talk

Universal field for enchantments in poe2[edit]

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. -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 21:41, 27 November 2018 (UTC)

Proposal for administrator status[edit]

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

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. -- UserCCCSig.png -- 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! :) -- UserCCCSig.png -- 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? -- UserCCCSig.png -- You talkin' to me? -- cCContributions -- 13:30, 8 January 2019 (UTC)

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

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

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:

  • 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.
  • 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:
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[edit]

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)
One more thing, about the actual pages. Don't recall the details of where I found the data now, but presumably it's reasonably accessible in the source files somewhere. What I found of great use both on this wiki and others is the usage of CSVLoader, which is a plugin for AWB. It's not straightforward, but seems like you know your stuff around the place, probably better than I did as well, so maybe it could be an option? It's great for making new pages from a CSV file, to make them fairly consistent. Can also be used to update existing infoboxes, but that's a much bigger pain in the lower back. Requires a truckload or two of regex, which is especially painful if fields don't exist in the infoboxes, but you need them. Know I used this for creating enchantment pages (after fixing heaps upon heaps of data in the spreadsheet/CSV), but seem to recall I made the bestiary pages manually, which was horribly slow :sadeothasface: Never got to the NPC pages/infobox back in the day, but much of that code can probably be safely copied and amended from the bestiary template. It has some code for might etc, which may prove useful. Pangaearocks (talk) 01:18, 16 April 2020 (UTC)
Thanks a ton for the info! I've used CSVLoader for minor stuff before, but not really anything of significant scale like whole infoboxes. With AWB I've mainly stuck with the handy module function, writing scripts to suit whatever needed doing en masse (where the input is less consistent and the output is conditional). I've also been using my own parser to generate wiki-formed journal tables (for poe1 and poe2) from a combination of gamedata JSON and stringtable XMLs, which is similar to what we want to do. Perhaps a combination of these two methods would be better, where AWB would run through each new page and the module would simply call on the parser to generate and return the exact data required for the page. Using CSVs as a go-between seems cumbersome, and I dread having to repeat what you've gone through for the enchantment pages.
But not to get ahead of ourselves! I'll be adding to Template talk:Infobox ability poe2 in the next week or so to share some of my ideas for the changes to the template itself, as I feel posting it here would make the page more crowded than it needs to be :) Macklin (talk) 04:26, 16 April 2020 (UTC)
As I've been working on this, I've realized that a few fields simply can't be obtained easily through GameData alone. For example the way that the effects block is constructed is way too complicated to replicate externally - so I think fields like this will need to be input manually. Theoretically I could also use something like MonoSharpInjector to run my own scripts within an instance of the game, using them to dump the effects block string to a file. I've already experimented with code injection in the past. Now that I think of it, it wouldn't actually be too hard to accomplish at all. Maybe I can still use a CSV to store data from the parser, enter the manual data as needed (or copy it from the aforementioned dump), then submit it all in one go with CSVLoader. The possibilities are endless! Macklin (talk) 10:05, 16 April 2020 (UTC)
Wow, that is definitely over my head, haha. Never used modules and scripts for things like that, but have looked into it (wrote a big script locally, but that was just for extracting data from a massive XML file). Sounds difficult, but if you can pull off that then it would be of great help I'm sure. I'm simply too out of the loop now to jump in easily. Using CSVLoader was good for some of the work I did, but it has weaknesses for sure. Getting all the regex to work properly is a pain, and sometimes I need several runs through the pages. Being able to use external programs or scripts would be much easier, especially as it would then be possible to use conditionals (which is a massive pain with regex, and I've basically given up on it). But banging two rocks together can result in flames too. Just takes more time and effort :D Pangaearocks (talk) 12:11, 16 April 2020 (UTC)

Companion information & Dialogue pages[edit]

Hi! I'm pretty new to the wiki, and to PoE in general, but I've been finding it very useful. I do have a few questions, though. For one, there's a lack of detailed information about the companions' arcs, especially in Deadfire. Is this intentional to avoid spoilers, or just a lack of time/interest? If the first (and even besides that, in general), would we benefit from making spoiler warning buttons to hide major plot details or decisions?

The other thing I was thinking about - I probably don't have to ask permission or anything, but I don't want to step on toes - is, would it be reasonable to make pages for companion dialogue and, for the Deadfire companions, instances that raise or lower relationship? I'm willing to sort through all the files and make the pages myself, I just want to make sure I'm not jumping the gun. Thanks!

--Suplex24 (talk) 03:32, 17 July 2020 (UTC)

I think a lack of time, if anything. For Deadfire at least, it would be very easy to come up with a list of dialogue that affects companion relationships, as well as the unique dialogue that is triggered when reaching a new relationship threshold (and any knock-on effects or results of reaching that threshold). I had intended to include this when I wrote Companion relationship, but figured it would need more looking into before going ahead with it.
And you're very right - you don't have to ask permission at all! However I'm glad you at least asked about it, because I've had some ideas brewing that could help out if you're willing to tackle it.
Here's my two cents on the matter (for Deadfire), what needs to be included and where I think it should go.
First is to decide on where to put all this content. I'm against adding this directly to the character pages, as it's likely going to take up a lot of space. Some options:
Each companion section (or page) should have a subsection containing a transcript of the dialogue at each threshold, and the results or consequences (if any) of reaching a relationship threshold.
Additionally, each companion section should have a table with the associated relationship-affecting dialogue as a result of TriggerTopic and CompanionAddRelationship calls (see below). This will be the biggest undertaking. Some notes regarding:
  • To source this I would use Notepad++'s "Find in files" function (or a similar function in your text editor of choice) to find all TriggerTopic calls in all "*.*bundle" files (CompanionAddRelationship calls can probably be listed separately). Given that these calls can be made on any event in-game (e.g. quest completion, item equip, etc), I don't expect it to be restricted to conversations only, although I haven't actually checked.
  • Whether this table covers all topic triggers (to avoid repeating data across companions that share the same topics), or is split to cover each companion separately, is up for debate.
  • Also keep in mind that relationships occur between the player and companion, as well as companions and other companions. We would want to cover player—companion relationships primarily (those where the player b1a8e901-0000-0000-0000-000000000000 is the speakerGuid in TriggerTopic calls, and the targetGuid in CompanionAddRelationship calls), since inter-companion relationships cannot be controlled by the player (other than via party composition). We may want to include a separate table, or integrate this data with the player table. I think inter-companion relationships have threshold triggers, and unique dialogue as well.
  • A table would likely include the following columns
    • "Notes" - any notes, e.g. when the dialogue or event is triggered
    • "Dialogue" - the actual dialogue that calls TopicTrigger, if within dialogue.
    • "Topic" - the name of the associated topic
    • "Strength" - the RelationshipValue property of the ChangeStrengthGameData passed with the TriggerTopic (Minor (4), Average (4), and Major (8)).
    • "Change" - This is the actual modifier to the companion relationship that is calculated per companion, taking into account the change strength, the global topic value, and the companions topic weight (Weak x1, or Strong x2) (see Companion relationship#Topic–relationship change). If the table is not per companion, perhaps include the raw modifier (changeStrength * topicValue), and then a list of companions affected with the actual modifier ((changeStrength * topicValue) * weight).
Anyway, you can see that although all the ingredients are there, it's a time consuming job and one that will take a bit of planning beyond what I've theorized here. If you decide to get into this, you might find a better way of presenting this information, as I'm just speculating on what might be required given what we already know about the relationship system and how it functions.
Pillars of Eternity, as far as I know, does not employ a relationship system in the same way as Deadfire does. I think that "relationships" there are based only on dialogue choices, quest choices, and perhaps the players reputation and disposition. I'll have to do some digging here, but I'm sure it won't be as involved as relationships in Deadfire.
You touched on spoilers briefly. In my opinion, spoilers are not something that we should be overly worried about. If someone's willing to go through the effort of looking something up on the wiki, especially something as plot-pertinent as dialogue, I think it's safe to assume they know the risks when it comes to spoilers. If something is super spoilery and is put in a relatively spoiler-free section, then go ahead and wrap it in a Template:Spoiler, or if needed a custom collapsible element as you see fit. But remember, doing so intentionally impedes access to this information, and can therefore make it annoying/aggravating to find stuff.
Macklin (talk) 09:17, 17 July 2020 (UTC)
Oh, man, thank you so much! I appreciate the lengthy, response, this gives me so many good ideas. For the dialogue/relationships I think I'll go with subpages, just because it was my experience using the Dragon Age wiki that inspired me to ask and that's the standard there, plus it's just convenient to have dedicated pages for each companion. It is, in fact, 3AM so I'm intending to go to sleep soon, but when I get up I'm going to crack open Visual Studio and start mining a bit and get to work on the tables. Thank you so much for the tips! I'd been pouring through the files earlier and you just helped solve some of my biggest issues with parsing how the conversation scripts worked.
And then with spoilers, that's more or less what I figured. In that case I'll feel free to add detail as I see it, especially since I'll already be going through the game files with a fine-tooth comb. Nothing too excessive, but shoring them up a lot from where they are now.
Thank you again for the advice! I'm really glad I decided to get involved with the wiki. I'm looking forward to helping it grow!
--Suplex24 (talk) 10:26, 17 July 2020 (UTC)
I was going to write exactly what Macklin said! For spoilers, the general approach this far was that the wiki is one big spoiler and most of the mysteries of PoE1 are spoiled by the sequel anyways. So the answer would be to not go out of our way to spoil the stories, but don’t actively avoid writing about them. Eg. Someone browsing for data on swords shouldn’t suddenly be told about a plot twist. Glad to have you with us! Tagaziel (talk) 14:19, 17 July 2020 (UTC)
I forgot to mention, (although you've probably already figured this out) all the companion topic data is found in characters.gamedatabundle, in the CompanionGameData objects. Most of the upper portion is already in the companion character pages and companion relationship, but I suspect you'll want to check out the TopicReactions and PlayerRelationship/CompanionRelationships arrays. TopicReactions are simply reaction strings that are picked at random as a reaction to relationship-altering dialogue (found in companionreactions.stringtable), while the PlayerRelationship/CompanionRelationships arrays directly relate to the conversations that occur between the player and companion (for PlayerRelationship), and companion and other companions when reaching a certain relationship threshold.
If you need further clarification, or a look into the logic behind the relationship system beyond the game data files and beyond the simplified explanation in companion relationship, I'd recommend making use of a .NET/Mono decompiler like JetBrains dotPeek to take a look at the game code yourself. If you want to play conversations in-game or fiddle with relationship values, the console is your best bet. I also checked, there are currently around 2268 TriggerTopic and 780 CompanionAddRelationship method calls in the game files (probably a lot less as a result of player dialogue options). Thankfully they seem to be exclusively contained in conversationbundles. Parsing game files will get you pretty far with this, though if you want to look into it I'd also recommend code injection as another option with much less friction and (relatively) minimal setup - there are some examples of that on my Github :thumbsup: Macklin (talk) 16:27, 17 July 2020 (UTC)

Avowed - a Pillars of Eternity game?[edit]

Obsidian Entertainment recently teased a new title during the Xbox Series X event. It's called "Avowed", and is supposedly their take on the Skyrim formula. While details are sparse, what is most interesting to me is that it's set in Eora - the very same as Pillars of Eternity.

While the trailer doesn't give much away, I'm very curious to see if there will be any crossover or relation with the existing games, as well as whether it could even count as a "Pillars" title. My initial thought is that this is unlikely, and that Eora was simply chosen as a shortcut to an already-established fantasy setting, although I hope that there's a bit more to it.

Some stuff I noticed in the trailer:

Anyhow, it's exciting to see more fantasy stuff from Obsidian! On a wiki-related note, it's hard to tell right now whether this game would fit into this wiki, or if it warrants creating an entirely new one. In time I suppose... Macklin (talk) 00:16, 24 July 2020 (UTC)

(General response to Tagaziel so I don't have to cram all this into a comment)

Right now I think it's safe to assume Avowed is a spin-off title, and not a "Pillars" series game. It's likely that although set in Eora, it will have nothing to do with the Watcher or the Pillars of Eternity story.

My creation of the page Avowed was a cautious tip-toe around making any sort of decision. I had seen the Fandom wiki and Atvelonis' good work there, but I figured either way we'd need to have some mention of the game here (it can of course be freely copied over or modified anyway).

I'll get straight to the point (rather bluntly, but it is what it is), there are two scenarios that I can see occurring. There might be other options, but generally it will come down to two things:

  1. We continue to have two wikis, one for Pillars of Eternity and one for Avowed (this seems to be what is currently happening)
  2. We do some work to make this wiki more of an Eora wiki, and eventually get to the point where this becomes the Pillars and Avowed wiki, with some asterisks and caveats, and stop work on the Avowed wiki.

Here, I made a table to cover some pros and cons of either scenario, of what I can immediately think of at least. Feel free to add anything you might think of!

Scenario Positives Negatives
Merged wikis
  • Expands this wiki's existing content to make it a sort of one-stop-shop (a good and a bad thing)
  • Continues our effort in covering all things Eora, rather than just Pillars stuff.
  • Allows Avowed-related pages to reference and add to existing Eora articles.
  • Avoids the duplication of Eora-related content across wikis, allowing more of a focused/collaborative effort.
  • Complicates the wiki a lot. As it is, the focus of the wiki seems to still be on Pillars of Eternity. For example Weapons, and pages like it still need to be scoped/prefixed/disambiguated. I have no experience with multi-game wikis, and I don't even know whether we've been doing it "right" here or not (I really have no idea how you guys even managed with the Fallout wiki).
  • Disambiguation suffixes will become almost mandatory, and disambiguation pages will become much more common.
  • Makes it harder to look for game-specific content, although this entirely depends on efforts made to solve the above issues.
  • The brand will become muddled. I think people will be confused if they have to go to a "Pillars of Eternity" wiki for content on "Avowed", and the SEO will probably be non-existent.
Separate wikis
  • Allows us to maintain focus on the cRPG "mainline" series (although it might end up being repeat of Fallout, where the first two games are cRPGs, and the rest are first person titles - yikes).
  • Allows the Avowed wiki to maintain focus.
  • Avoids the work needed to adapt this wiki to fit content of another game.
  • No brand-recognition or SEO issues.
  • Eora-related content becomes split/disjointed and difficult to maintain since efforts will likely be split, or we'll need to accept that the content will be in the context of the game (unless some miracles are performed with interwiki transclusion or some wizardry)
  • Makes it near-impossible to get an overview between Pillars and Avowed, as well as possible relations between them.

My initial opinion is that while it would be nice to cover Avowed here (for all the reasons above), the issues will need to be solved before it could even be viable, as right now the negatives for merged wikis seem to outweigh the positives. Without any solid plan in place as to what has to be done to make it possible, and some reasoning behind it, I think right now it seems to be easier to continue with a dedicated wiki, and to just deal with the fact that there will be duplicated content, assuming people think that's an issue at all, and assuming that there are as many connections to Eora as we think.

Another option is to half-arse it. We could cover Avowed and its possible additions to the world, and actively acknowledge its existence, but ignore the actual game and data side of things entirely and leave that to Avowed wiki. Bit weird, but a thought.

Ultimately whether to include Avowed content or not all depends on whether we want to diversify, and cover all things Eora (which may already be the case?), or stick to the wikis namesake and only cover Pillars of Eternity stuff. Of course this assumes that they don't announce some details that tie Avowed more into Pillars of Eternity, which might make it a different story entirely. We may need to wait for more information to come to a conclusion. They should have just called it Pillars of Eternity: Avowed and we could have called it a day lol.

As for the game itself, I'm pretty excited for it regardless. I'll probably contribute towards wiki content wherever it may be, but perhaps not immediately. There's a lot that suggests that it's in Unreal Engine, which may be a point in its favour towards it being more easily data mined, depending on what route they take (though probably not as easily as Unity games).

On a slight tangent, and if I'm honest, I personally think the Fandom wiki layout in general is super ugly compared to the Gamepedia layout. The navigation is bulky, there's a lot of wasted and misused space, and the entire experience feels more like a big advertisement for Fandom, and a wiki just for the sake of it, rather than a dedicated community site created by fans. I don't actively hate it, but I think it's made me avoid contributing to Fandom sites in general. I've also noticed that a lot of Gamepedia sites have migrated to Fandom (which reminds me, some of the navbar links need to be updated), and it's been making me a bit uneasy. Do you know if this is this something that is planned across the board?

Mind the mess, I skipped giving this a proper read through Macklin (talk) 13:52, 30 July 2020 (UTC)

I strongly lean toward this wiki being a "one stop shop" for the Eora setting. This wiki doesn't just document the games but anything under the Pillars of Eternity brand (card game, TTRPG, etc.). That makes it an even more arbitrary line between PoE and Avowed – Avowed is *kind of* a new Pillars game, but it's a soft reboot of the franchise, which isn't a surprise after Deadfire's disappointing sales.
I guess the test is: if Pillars 3 had completely revamped gameplay and was a Skyrim clone, would we want a separate wiki for it? Such a wiki would have nearly all of the same logistical issues of the Avowed wiki (except maybe SEO and confusing Avowed players not familiar with PoE). If the answer to that question is no, then what's the positive case for the Avowed wiki?
If you look at the level of activity on, say, the Skyrim wiki, compared to the TES wiki, that suggests that fragmenting the base of contributors will make both games harder to document. I recognise the problems with having them as one wiki outlined above, but overall I think they're far outweighed by the problems of them being separate wikis put together with the benefits of a unified wiki.
I guess the only question is how you do it. I guess this would need to be rebranded as a wiki for the Eora setting, with it being clear on the main page that the purpose of this wiki is to document the Pillars of Eternity and Avowed games. -- 10:45, 31 July 2020 (UTC)