Template:KemoTalkTable

WARNING: This template uses the PavFace template in both its code and its usage. Please read PavFace's style guide before reading this style guide!

KemoTalkTable is a template that allows users to fill in a large table with the IDs and participants of KemoTalks. KemoTalkTable may a little confusing, due to a necessary but mechanically unusual step that isn't often found in such templates, but at its core it is an extremely simple template that will allow you to easily fill out a full table without having to fiddle around with the code. For this demonstration, we will be using, because the person who made this template and this style guide loves her. Note that because the talks haven't been imported to the wiki as of this writing, the examples being used are not what will actually be on Komodo Dragon's page.

In KemoTalkTable, the parameters friend and friendid make up the table's header. Because the table is collapsible, when you first open a Friend's page, these will be the only things they are able to see. If you expand the template with only these two values having been defined, then the first row of the template will just be a mess of code and rot and whatnot. The parameter "friend" defines the name of the Friend, while the parameter "friendid" prints the icon. The value of friendid should be equal to the ID value that is used when using the PavFace template - in Komodo Dragon's case, this is 0029.

The values talk1 and talk1friends turn that mess into an actual functional table. However, it isn't as easy just filling in the numbers all at once. As you can see, only two talks on the table are filled in - talk2 and talk2friends allow for the second talk to work. Because different Friends in Pavilion have different amounts of KemoTalks, the table is designed to have talks entered one by one, with each cell on the table defined by their equivalent parameter. The talk# and talk#friends parameters are currently coded to support up to 104 separate talks, but this will likely be expanded in the future as Pavilion updates to accommodate however many talks Serval will end up getting. She'll have a lot.

You may also ask why KemoTalkTable standardizes to using PavFace rather than simply using text to define which Friends are involved. There's the honest answer, which is that I think it's cooler, and I didn't code PavFace for nothing, or the technical answer, which is that I think it's more user-friendly. Using images rather than text allows users to quickly determine which Friends are used at a glance, as all that text put so closely together could make it difficult to distinguish what information belongs where.

This example contains a few new concepts, the first and most important of which being the row2 parameter. The "row" series of parameters tell the template that it's allowed to add a new row, This may seem silly, but it's genuinely required to get the template to work properly. Without the row parameters, the table would display all 104 potential talks - that's 208 cells and 26 rows - at once, even if they're all blank. Because of the row parameters, these entire blocks of code are told to simply not exist at all unless given the go-ahead, and end the table right there. There's three other important things about the row parameters that must be kept in mind:


 * 1) There is no row1 parameter. The row parameters start at row2, because all Friends have at least four Talks. Why? Because all Friends have been shown to have at least five Archive Talks achieved by level-up. As such, the first row will always, without fail, exist, no matter what Friend the table is being used for. The parameters thus start with row2, so that when filling in information, you are aware which row on the table you are telling it to create.
 * 2) The input for row parameters can be almost anything. I'm serious, it can. Check it out for yourself - I lied and didn't use "y" on the actual template above, even though I did in the code example. The template simply needs text input of any kind at all to be told to allow the row to exist. While this means you can input something silly if you'd like, I strongly recommend avoiding it. Future editors may see while attempting to update the page and become confused. Also, I did say almost anything - you should avoid using wiki markup or templates, as that may confuse MediaWiki when attempting to parse the page. Or it could not. You really shouldn't try either way.
 * 3) There can only be four KemoTalks per row. That means eight cells - four talk# cells and four talk#friends cells. Once you fill these in, you must begin a new row, or any talks you enter will simply not display. If you're wondering why you can still only see two rows after putting in 20 talks, not remembering to use row parameters past 2 such as row3 or row4 might be why. Also, the code breaks if you try to use the same parameter twice. The row2 parameter will only create the second row, the row3 parameter will only create the third, and so on, and do not use them out of order for the same reason.

Now then, there are some other important things to note in this example.


 * From row 2 onward, talk# and talk#friends parameters without values do not display text. The reason for this also has to do with why there is no row1 parameter - as there are a minimum of five KemoTalks for every Friend, there will always be at least four KemoTalks to fill up that first row. There's simply no need to code this hiding thing into it. The first talk of every row also lacks this, so don't start new rows unless you have a talk to fill it in with.
 * Archive Talks use the Friend's own image. They also do not require to link to any pages. This is because even if other Friends appear in the talk, the game itself only counts the Friend the talk belongs to as a participant. However, because it's redundant, the Friend will not be listed as a participant on the table for any other Talk. The differences between Talk 551 and Talk 560 illustrate the difference between a normal talk and an Archive Talk.

Lastly, cameo appearances. Cameo appearances are defined as when a Friend appears in a Talk that does not belong to them, such as an Archive Talk. If no cameos are known, the template simply displays "none", that they do not cameo in any talks. For cameos, PavFace is not used because the owner of the talk is irrelevant - this simply catalogs which other Talks a Friend can be seen having dialogue, for all readers who want to see all of a Friend's dialogue in Pavilion. For cameos, rows are created automatically, so a cameorow value is not needed. Currently, the template supports 24 cameos, but this may be expanded in the future.

That should be it. It's a long explanation, but using this template really is as simple as inputting some values. There's simply a lot to cover when it comes to explaining why it works.