Talk: Community portal

Companion information & Dialogue pages[]

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:

Sub-sections of an overarching page - Create a new page, something like Companion dialogue + Companion dialogue (Deadfire) with a section (== Serafen ==) for each companion.
Sub-pages of character pages - Make a subpage of the character page (e.g. Serafen/Companion dialogue). This isn't as commonly done for forward-facing pages, but might be preferable and gives you the option to transclude the content to another page if needed.

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

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:

0:14 Symbols of Woedica on banner
0:25 Statue of Galawain (maybe)
0:52 Aedyran symbols on sword (and others), probably random.

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:

We continue to have two wikis, one for Pillars of Eternity and one for Avowed (this seems to be what is currently happening)
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. --81.103.238.198 10:45, 31 July 2020 (UTC)

Oh gosh, I missed this section. My apologies for the late reply! But from the rear:

Regarding the URL changes: This is an ongoing process caused by the fact that Google will dinges our standing with each successive algorithm update, which isn't a huge issue at the present (as we're the biggest Pillars of Eternity Wiki in existence), but will compound over time. We don't lose anything beyond that, at least until work begins on the Unified Wiki Skin, which will require a substantial redesign of the site (it's still a fair ways off).
Re: Avowed: I support including all of its information on the wiki wholeheartedly. It makes sense: We have years worth of work poured into the wiki already and have a good basis - especially regarding lore - to set it up. This will require new templates and rethinking some of our old ones, yes, but with a new wiki we'll be, essentially, starting from scratch across the board. It's trying to break a door that's wide open already. I think we have enough brain matter between us all to make a good shot on it and we have the combined experience of the Fallout Wiki and others to lean on.
Re: distinguishing between the games. I've actually tried to balance this, by moving high level pages to their game titles (eg. Pillars of Eternity weapons, Pillars of Eternity II: Deadfire weapons, Avowed weapons, as on the frontpage), and achieve a little more equal distribution of attention. The Fandom Wiki won't be a problem, since we can maintain or delete it at our discretion and last I checked, it doesn't even come near ours in terms of PV; makes sense to continue when we have the high ground ~~Anakin~~.

Again, sorry for the delay! Tägäżïël 15:53, 17 February 2021 (UTC)

Thanks for the reply! No worries about the delay, I'm sure we still have plenty of time to discuss things before we hear any more of Avowed. Most of the issues I initially brought up were things that we'd probably have to tackle anyway if a Pillars sequel ever came out. The reply above yours mentioned this, it's an interesting perspective and one that makes me less hesitant about things. At this point most of my concern comes from distinguishing content, which is perhaps not as bad as I'm making it out to be. As you mentioned, we have the reference of, and experience with the Fallout wiki, which is already way more complex than this wiki in terms of what it has to cover.

That being said, I feel that there's still room for improvement in distinguishing the existing games and making it so that when it comes time, Avowed content can be added as frictionlessly as possible. Facilitating this raises a lot of technical questions that seem minor, but could have overarching implications for the structure of the wiki. As an example, say a Sword exists in Avowed, should we then create a disambiguated page for all three games and create a disambiguation page in its place? What would the poe1 disambiguation suffix even be? Currently (in this example), items that exist for both pages have the poe1 page as the "main" article, with a notice linking to the equivalent Deadfire page, which is already a fairly clumsy solution. I know this seems minor and kind of trivial, but it's many decisions like these that should be thought about in advance as not to compound the issue when Avowed is added to the mix. When the game actually comes out I'm sure we'll have much more clarity regarding what direction we should take, though I think we should at least take advantage of all the time we have now.

Touching on SEO briefly, I actually think that the wiki now is in way better standing than it used to be a few years ago. Even if it doesn't do as well as Fandom, it's still much improved. No doubt there were some issues with the recent migration, but even now most of my Google searches seem to have the wiki in the top spot, if not close to it (though maybe it's tailoring the results for me, haha). The question is whether that persists with new content or big changes. Avowed seems to target a much wider audience than Pillars, which could be a good or a bad thing for visibility of this wiki in particular.

Can't think of anything else to follow up on or comment on, though I might put some more effort into tidying up some parts of the wiki that still have poe1 as a primary focus (e.g. Category:Locations), to try and further the compartmentalisation of game-specific content.

While I have your attention, and on an unrelated topic, I also noticed a few issues with the wiki on Fandom Mobile. There are likely more, those are just a few I came across. I'm yet to take a closer look to see if some of these can be addressed with changes to templates alone, or if they require updates to styles. From what I've read Fandom Mobile seems to use different style sheets + JS only accessible to Wiki Managers - though again I haven't actually confirmed this. Could you comment, and perhaps if you have the time take a look at a few pages yourself? All the best! Macklin (talk) 06:26, 18 February 2021 (UTC)

I also think it is a good idea to keep Avowed on the same wiki as POE, since it takes place in the same world. And as a user of the wiki, it would be confusing probably to find information about the game word I'm playing in on a different wiki. And as a wiki creator I have to say: if we separate the wikis, would you want to write and update articles about Eora, the Timeline, etc twice? And for references we'd have to crosslink between the wikis. So personally I feel like we should keep them together, even if it's just a spin-off game.

As for disambiguation, I made a plan years ago when I started with the German wiki. I think something like this would be good:

if it's relevant to all games, just the name (eg. Eora - it's relevant everywhere)
if it's only relevant to one game, imo it's fine to keep just the name (eg. Caed Nua - only plays a role in POE1, no need for any disambig)
unique things should have unique articles, and sections for different games (eg. Aloth#Poe1 and Aloth#Poe2)
for things in multiple games have {{poe|sword}} and {{poe2|sword}} etc. (for wiki creators - the template takes care of the correct url, no need to memorise the system) and then have a disambig page Sword which links to them all. As for which system to use for the different pages I'm not sure. I'm not actually a fan of long page names "Pillars Of Eternity II: Deadfire World Map" comes to mind... I'd rather we have "World Map (Poe2)" or something like that. In any way, it should be consistent. Not "Pillars of Eternity II: Deadfire Sword" and then "Armor (Deadfire)", that's just confusing imo. But that's just my opinion. :)

CAPSonYT (talk) 08:06, 19 March 2021 (UTC)

Suggesting {{avo}} or {{av}} as the shortened form of ''[[Avowed]]'' (as CAPSonYT has already created in Template:Avowed/de) to be used like {{poe1}} and {{poe2}} and within {{game|avo}}. Any yeas and nays? :P Macklin (talk) 17:10, 18 March 2021 (UTC)

Giving temporary effects their own pages (poe2)[]

(This is a follow up to Yogaman28734's comment on my user page)

My opinion on this a bit mixed. Status effect don't really fall under the "ability" umbrella, so I'm against adding them as an Template:Infobox ability poe2 since their structure greatly differs, and doing so would only muddle things. This is partly why pages like Status effects and Status effects (Deadfire) exist, to provide a net for these sorts of cases. Don't get me wrong, I understand the need to provide frictionless access to this information - say if someone searches for "Ondra's Blessing" they won't get any directly-named results since it's only present in the status effect pages. Having a dedicated page would in theory provide a place to go into more detail, and would provide technical information too. But we should evaluate the need to have dedicated pages over the tables on the status effects pages, since even with my suggestions below I'm still a bit hesitant whether it's even required over just a redirect to said pages.

So my suggestion, if we actually want to follow through, is to create a new infobox e.g. Template:Infobox status effects poe2. This would be strictly for temporary effects that are granted on their own, e.g. general purpose buffs and debuffs, non-permanent bonuses, injuries, resting and prostitute bonuses, and would NOT include any statuses that are already covered elsewhere or are a direct result of a consumable or ability. Permanent effects are all passive abilities, and would not fit in this category. Note that status effects will only appear the "Current Effects" section of the character sheet if the StatusEffectGameData object contains an AfflictionComponent - this would be a good basis as to what to include and what to exclude.

Within the infobox, I suggest we provide a couple of unique types, though a few of these are not terms used in-game. For example:

Affliction, for actual AFF_ negative effects associated with an attribute. Although most debuffs ("Other afflictions" in Status effects (Deadfire)) are marked as afflictions, true afflictions are those grouped by Attribute type in AfflictionTypeGameData. Interestingly, looking at the game files it seems they planned a lot of other disease-focused affliction groups/types that didn't make it into the game such as "AFT_Bedfellow_Mites", "AFT_Chest_Worms", "AFT_Red_Lung", etc.
Inspiration, for actual INS_ positive effects associated with an attribute.
Injuries, negative effects that stack like afflictions.
For all other effects, I'm not entirely sure what to use, perhaps buff/debuff, boon/bane, bonus/penalty.

I'll avoid going into more detail than that, as this is just an idea at this point. Thoughts, opinions, or other possible solutions are welcome. Do we think this is needed? Would it clarify things or just serve to confuse users? Macklin (talk) 11:09, 23 January 2021 (UTC)

Portable infoboxes[]

As Tagaziel mentioned, we need to eventually migrate all infoboxes to portable infoboxes (see also here) so we can keep on top of all the new features provided by the Fandom platform updates that have been rolling out over the past year or so. The primary benefit, as I understand it, is to ensure consistency across desktop and mobile. This is something that has been a huge push for Fandom, as a lot of wikis (including this one) have tended to only focus on the desktop experience. Other than that, from my brief look it seems to be a vastly superior system compared to the convoluted table-based layouts that we've come to accept. It adds a whole slew of neat features like panels, which allow parts of the infobox to be tabbed (this will be huge for cross-game pages), and collapsible sections which can help tame some of the longer infoboxes. On top of this it will greatly reduce the complexity of infobox templates by offloading the layout work and allowing editors to focus more on the data side of things.

However this does mean somewhat significant visual changes just from the way the layout is handled. I've quickly put together an example below of one of the less complex templates on the wiki, copying most of the styling of the existing infoboxes, with associated CSS in a theme called "eternity" at the bottom of MediaWiki:Hydradark.css. Portable infoboxes seem to be slimmer by default (272 vs 300px) - which might not seem like much but is actually very noticeable on pages. The styling can be adjusted as needed depending on whether we want to stick to the existing look or go in another direction.

I think the plan is to go through each infobox and create a /sandbox subpage for each as a staging area, containing a full remake of the infobox as a portable infobox. Examples of each will go here (and/or on the subpages themselves) with before and afters so that any changes to the theme/styles can be tested easily. After thorough testing, and if all seems good, we can then shift the new templates over the top of the existing ones (hopefully without issues). If anyone wants to help with this effort, feel free! There's a whole bunch of great documentation covering portable infoboxes over at Fandom. Macklin (talk) 19:45, 26 March 2021 (UTC)

Wow! Looking at the source code for the new portable infoboxes... that is so much nicer! I would be up for rewriting some of the infoboxes to the new portable infoboxes.

I won't be able to help with styling though, as my experience with CSS is minimal. - DasCapschen (talk) 08:26, 27 March 2021 (UTC)

You're welcome to start anywhere if you'd like, just be sure to use a sandbox subpage similar to the example below. Some styles aren't set up yet, especially for the more complicated infobox features. If you wanted to mess around with styles locally (even with limited experience, you might find the need to) I would suggest looking at Chrome's local overrides, which can be used to modify and persist style changes locally before actually submitting them to the wiki. Macklin (talk) 09:25, 27 March 2021 (UTC)

Oh, that's a neat feature I didn't know about. Alright, I'll give that a go. Also, now that we can use tabs (panels) in infoboxes, I guess we should combine all the 'infobox' and 'infobox poe2' variants into just the first one, and have two tabs for 'poe1' and 'poe2' (can even have a third 'avowed' tab), since they will be hidden if empty. One thing I noticed is that, although described in the fanbox article you linked, it seems the infoboxes cannot handle <gallery> tags for image sources right now (even without specifing the eternity theme). DasCapschen (talk) 10:16, 27 March 2021 (UTC)

That's quite a big undertaking, and one that goes a bit beyond the scope of this project. I think as a first step we should just do a one-to-one translation of existing infoboxes, then worry about cross-game stuff and taking advantage of those features, since much of the existing framework relies on having separate dedicated pages (e.g. items). I'm sure there will be exceptions where we can implement this sort of stuff without repercussions, and situations where it would be beneficial or even required for an infobox to cover multiple games. This would involve redesigning existing templates to provide fields applicable to each game (e.g. field_pe1, field_pe2, etc), and fields applicable to all games. One example of an infobox that needs to have its parameters reworked is {{NPC infobox}} - it's probably the oldest template that is still widely used. I had a prototype of this in the works a while ago, but I shelved it.

They would need to be evaluated individually, but I think good contenders for cross-game infoboxes (that are currently already split) would be the "type" infoboxes, and the bestiary infoboxes. Most others are way too tailored to the game, or are too fragile to make these sorts of changes to, since doing so would inherently mean merging (and in some cases re-merging) the pages they belong to. Infoboxes that are currently generic (not pertaining to any specific game), but have fields that are game-specific would of course benefit from adding game-specific fields. Again though, for now I'd think of adding portable infoboxes as more of a visual update instead of an overhaul.

I'll have to take a look at the gallery tag myself, as I said I've only added styles for a couple of tags, while everything else doesn't have a defined style so they might not appear properly. It could also be that it simply doesn't work, as you said. Galleries would be nice, though you might be able to do the same thing with panels or a <tabber>. Macklin (talk) 12:18, 27 March 2021 (UTC)

Great start on the infoboxes DasCapschen! I've fixed a few of the CSS issues (images, some minor border issues), let me know if you find any more. I also found that portable infoboxes strip out HTML entity characters, meaning some hacks to insert new lines, non breaking spaces, and other control characters will no longer work. In addition to this, the formatting of list items is slightly different, wrapping new lines to the left of the bullet point instead of at the start of the sentence. This is an easy fix though, but do you think it looks better or worse this way? The logic behind conditional fields might need to be evaluated too, just remember that if the <format> tag results in an empty string, the entire data tag/row will not be listed. Also feel free to experiment with layouts - the horizontal group layouts look pretty good but there needs to be a good reason and place to use them.

Also apologies for having to deal with my mess in Template:Infobox ability poe2, it's a rather complex parser function used to generate ability nth Level x ability strings (it's more complicated than that though). Because of the above limitations, I'll have to move this over to Lua - I was planning on doing that anyway to make it a bit more readable. If you find any more functions you'd rather not deal with, just leave them and I'll handle them later.

Lastly, we should stick with using sentence case headers (e.g. "Area of effect" vs "Area of Effect"), as is used in section headings and other infoboxes. Macklin (talk) 08:55, 28 March 2021 (UTC)

Ah, it stripping HTML Characters explains why 'infobox ability poe2' is missing spaces now... actually, it seems to not strip everything. Things like   seem to work, but   is stripped out.

As for the bullet point lists, I think we should make it as before, that a wrapped line begins at the sentence start, not left of the bullet point. Imo that makes it clearer that it is a part of that bullet point.

Conditional fields, and especially fields with multiple inputs are a bit difficult right now, since I'm not quite sure what's the best way to handle them, and the Fandom documentation of portable infoboxes doesn't really describe those.

No worries about that. If I find any complicated code, I'll just leave it as is and try to integrate it so it hopefully works correctly. :)

Alright, I'll keep it that way then. - DasCapschen (talk) 09:34, 28 March 2021 (UTC)

All table-based infoboxes have been updated to portable infoboxes, with the exception of:

Template:NPC infobox - New template is done, but needs to be text-replaced on all character pages.
Template:Infobox organization and Template:Infobox nation - Need to be merged since they are very similar.
Template:Infobox ship - Currently working on updating the content to include more info.

There might be some issues here and there, such as missing fields, validation issues, and layout/display issues - especially with the change to fixed column sizing. I have tried to validate as many pages as I can given the hundreds of articles some of these infoboxes cover.

Speaking of column sizing, this could probably be changed on a per-infobox basis to better suit the needs of the infobox itself, though for now I have shortened some labels to account for the restricted width.

There are also some issues with portable infoboxes in general that I should mention:

Removal of line breaks and some HTML entities such as spaces/LF/CR. Most obvious result of this is that line breaks in tooltips are no longer respected - I'll write a JS snippet to work around this, probably to convert \n to 
.
Forced insert of paragraph tags before and after the infobox - even if the template is completely flattened. Why it was designed this way baffles me. I have tried to mitigate it as much as possible in CSS, though there's only so much I can do. Right now, layouts with anything other than text immediately after the infobox (on the next line following the }}) will have issues with excess line breaks. It could be another job for client-side JS to forcibly remove the <p> tags on either side of a portable infobox, but this will cause content jumping.
Some images on mobile are blown up way beyond their original size (e.g. item icons). Looks awful but I can't change that.
Galleries don't have accompanying "theme" CSS yet (I am yet to test it).

Thanks again to DasCapschen for the help in migrating infoboxes, I appreciate it! - Macklin (talk) 15:05, 23 June 2021 (UTC)