Xeno Series Wiki:Advanced editing

This page is for those that have become comfortable with the basic editing and syntax and want to go even further beyond.

Game data
Discovering things in a game by experimentation will only get you so far, and strategy guides don't cover everything (and aren't always perfectly accurate) even when they exist. That's why on this wiki, we make extensive use of data taken from a game by dataminers, if and when we can.

Game data is obtained in two ways: either by dumping the ROM of (your own copy of) the game, or by going to xenobladedata.github.io, a website dedicated to storing the data for each of the Xenoblade games. The data is stored in tables; usually, each row in a table corresponds to a specific entity (for a very liberal definition of "entity"), and a column corresponds to each of their properties. Interpreting them by sight takes practice, but it's helped by the fact that for each row in many tables, there's a handy list of other table rows that reference that one.

Unfortunately, not all columns have human-readable headers, and not all tables have human-readable titles (especially for Xenoblade Chronicles 3). This is a matter of what high-level source code information Monolith Soft decided to keep in the final product, and we only have access to the final product, not the source code. If you need help reading stuff, people in the Discord server will either be able to answer your questions directly or point you to the people most likely to know.

The data in xenobladedata.github.io can be read off the site as HTML tables, or downloaded to your local system for easier manipulation. Those looking to get into will probably be doing the latter option.

Unfortunately, at the time of writing, tools for managing and interpreting the data of the pre-Xenoblade games are just about nonexistent. So we're stuck with experimentation and strategy guides for the time being, until someone figures out the datamining for those games. (Who knows... maybe it'll even be you.)

Page data
When you look around the wiki, you will come across articles with large tables forming lists of links to other articles (e.g. Special (XC2)). Looking at the article's source code, though, the amount of code written to make the table looks to be way smaller than the size of the table that results, and you can't see anything that corresponds to the individual rows of the table. That's because the table is made by calling upon page data.

There are three main reasons to do this: it makes it much easier to change little things about the page which calls upon the data, it automatically updates all relevant pages if one edits or moves the page that sets the data, and it ensures that the page calling the data doesn't miss anything out.

Jargon: A page's data consists of a number of properties, each set to a specific value. For example, the Berryjammy page has the property  set to 907, done by including the text   on the page.

Setting page data
To set data for a page, use the  function. The Berryjammy example above sets just one property, but multiple properties can be set at once, separated by pipes :

This sets the page's "example property 1" property to the value "property 1 value", and so on.

In practice, page data is often set in an infobox template. This is because the infobox is already designed to take in a lot of parameters about the entity in question. Alternatively, if an entity's article has a "Data" section, the section will often be filled in with a bespoke template which (among other things) sets the page data. Either way, only one page needs to be edited to change how the data for many articles at once is handled, which is useful far more often than it is not. That's why page data for an article is very seldom set directly in the article itself.

In these (standard) situations, there are two steps to setting page data. First, the infobox template (or whatever template is used to set the data) has to have the  function (wrapped in   tags, so the template page itself doesn't accidentally get properties set): Note that in the example, the properties are "set" to a variable name in triple curly braces. Recall how template pages work: a variable name in triple curly braces means that the template calls that variable name as an argument.

Step two is to call the (infobox or other) template on the page with data you want to be included. The arguments to the template should be the aforementioned variable names which were wrapped in triple curly braces, and the values of said arguments should be whatever value you want the corresponding property to have on this page:

Let's look at an example. The XCX collectibles have their data set using Template:Infobox XCX collectible. The template page contains the following, wrapped in includeonly:

Then, an XCX collectible article sets the data by providing the relevant arguments to the infobox. For example, in Strawlenny's case:

Thus, the infobox template is told that the  argument should be 30, and therefore sets the Strawlenny article's   value to 30.

In this example (and almost any other example you'll find), note that the pagename property is set to  in two curly braces, rather than three. PAGENAME isn't an argument of the infobox template; instead, it automatically returns the name of the page the template is included on. This is useful for linking, since the name of the page to be linked to won't always match the name of the collectible given in  (e.g. if disambiguation is needed).

For entities which aren't relevant enough to have articles but for which it'd be useful to call upon their data (such as individual enemy attacks), there is the "Extra data" namespace. Articles in this namespace aren't designed to be looked at by ordinary wiki users; they exist solely to store data.

Calling page data
To automatically call upon all pages with a certain property, often to generate a list, we use the  function. This function takes in several arguments.

The first determines which pages to include by specifying those with a certain property value; for example. asks for pages with xc1 pc art st_type set to 18. You can also specify a range of property values; for example,  asks for pages with Xc3 discussion ID greater than 0 (which returns all discussion pages, since they all have ID greater than 0). If the returned list isn't what you expected, check the below section on property types.

An important argument to  is the   argument, which tells the ask function how to present the returned pages. Very often, the ask function is used to make tables with one row for every entry, so the template argument will be a template that generates a row of a table. An example of such a row template is Template:XC1 PC art table row.

Besides the property which the ask function is asking about, additional properties from the returned pages can be taken in and used as arguments in the template. This is done by including the property as an argument to the ask function, prefixed with a question mark. For example, to include the name of the returned pages as an argument in the template, have  be an argument to the ask function.

Other arguments for the ask function can be given to affect how the output is formatted; see the documentation or look at other examples on the wiki. The help article Xeno Series Wiki:Data templates has an in-depth example.

Property types
Sometimes you'll want to do an  for which the output should be sorted in some manner, or for which you want to only ask for a subset of all pages with some data. If you go ahead and do this the "obvious" way, a la  (to get all weapons with BdatRow less than 33), you may find a completely different list appearing than what you intended.

The reason for this is because by default, a property is interpreted as a string of characters. The ordering associated with this string is lexicographic ordering rather than numerical ordering; so, for example, 1 < 10 < 11 < 2. To have the wiki backend parse the property as a number (or in general, anything other than a string), you need to give the property its own page and tell the wiki about the data type you want the property to have.

Such a page is at, and the page's content needs to have   (or whatever type you want in place of "number") somewhere in it. It should also have a category. Aside from that, the page text can be whatever; usually some explanation of what the property is. For example, the page Property:Xc1 gem ID consists of the following: A Has type::number that represents the ID of this gem in XC1.

In an ideal world, every property would have its own page and explicitly say what its type is. This is not an ideal world, and the amount of extra editor effort this would require is not nearly enough to be worth the small benefits over just adding a property page when necessary to change the type.

Programming
Wiki syntax is a markup language, not a programming language. That means it formats plaintext into something that looks nice; it doesn't calculate things. Nevertheless, sometimes you need to calculate things, so there are some functions that provide basic programming structures.

A couple of the most common ones are as follows.

Parser functions


If  is identical to , "value for case 1" is displayed, and so on. If the string doesn't match any cases, "default value" is displayed. Entire templates ("enums") are built off this function, to conveniently map numbers to entities.

"Your mathematical expression here" gets calculated and displayed. This is handy when interpreting and displaying data in a human-readable, intuitive way (e.g. finding the expected number of enemies you'll have to kill to get a specific drop), as well as updating variable values (see below).

Displays one of two results based on whether the input is pure whitespace or not. Very handy in infobox templates to conditionally include specific arguments. Note that sometimes there's a difference between "space", "blank", and "not specified", while other times there is no difference.

This is a string comparison. It's commonly used in templates, to check if the value of a passed argument is equal to some predetermined value.

"Expression" gets evaluated as a truth value (0 or empty input is false, any other valid expression output is true).

The documentation can be found here.

Variables
Variables are necessary for loops. To declare a variable  and initialise it to 24, use. Then,  will return 24.

Variables can be changed (otherwise they wouldn't be variable). For example, if  is set to some numerical value,   increments it by 1: it takes i's value, adds one, evaluates the result, then sets i to the result. (Whitespace was added for readability in this example; it does not affect the processing.)

Be wary that all variables are global; variable "i" refers to the same "i" whether you're on the page itself, or on a template eight layers deep. While this can be useful, it means you need to watch for and avoid a template chain all trying to use the same "i" for their looping.

Further documentation can be found here.

Arrays
If a variable is a box, arrays are a box of boxes. They're defined in much the same way:, where the   tells the parser how to split up the given argument. The main usages after this are accessing a certain index with, or printing the whole thing with  , which here would result in "3-and-8-and-29". Several other functions and array-manipulating templates are available.

Further documentation can be found here.

Loops
Loops can be used to help calculate and display a large number of values. There are several ways to do this: the following two are most useful.

If  is not whitespace,   is parsed and displayed. This repeats until the condition text is whitespace, so the output should have something that eventually changes the condition text to whitespace (probably using an  parser function or the like).

This automatically defines a variable  and initialises it to. It parses and displays, then repeats with the variable 1 higher. This continues for  cycles; it is similar to a "for loop" in many programming languages.

The variable in question can be used in the output (in this case with ).

The documentation for MediaWiki loops can be found here.

Automatic page creation and editing
Xeno games are complicated, and each one has a huge number of entities of all sorts of different types. The number of enemies, attacks, items of each type, NPCs, and the like often numbers in the hundreds if not thousands. Our goal is to have information on each entity, often a full page, but manually creating hundreds of articles and filling in all the relevant information for each one is not only prone to error - it can be mind-numbingly exhausting. That's why we like to automate our workflows whenever possible.

When there's a huge number of pages that need to be made for each entity in a large set, it's a good idea to set up some sort of script to write the pages for you. This is especially true in the likely scenario that data needs to be added to the pages (via an infobox template or otherwise).

Suppose there's a BDAT table where each row corresponds to an entity we'd like to have a page for (this happens a lot). A typical process for making the pages might look like this: The idea is that you want to have as much of the process automated as possible; that means having all (or 99%) of the basic article be automatically generated by your program just as you want it to appear, and double-checking everything against one (or a small number of) articles so that you get the vast majority of them right the first time. Going back through every article in a set of hundreds to make a minor edit is never a fun time.
 * 1) Make a template with arguments corresponding to the columns of the BDAT table. The template should be written to add data to each page which includes it, and also showcases important data it takes in in a human-readable manner. (This is often an infobox template, or otherwise intended to simply take in data.)
 * 2) Write a program that does the following:
 * 3) Takes in a BDAT table (in some form, possibly HTML if obtained from xenobladedata.github.io) and parses it.
 * 4) Splits the table by row.
 * 5) For each row, creates the syntax for the template you made earlier, where the value for each argument in the template is the entry with the corresponding column and row in the BDAT table.
 * 6) Makes a text file for each row. Writes to each text file the syntax for a barebones wiki article about the corresponding entity, including the template with all the data. (You almost certainly won't be able to include detailed descriptions at this point; anything that can't be automatically generated will have to come later.)
 * 7) Choose an entity from your set, and create its wiki page by copy+pasting the corresponding text file your program created.
 * 8) Hit Show Preview (or, if necessary, Save Page). Check how the page looks, check how your template is presenting the data, check the properties that are being added to the page.
 * 9) If anything's incorrect with how the template is presenting the data, then modify the template, wait 15 or so seconds for the change to propagate through the wiki backend, then check the preview again. Rinse and repeat until the template is presenting the data how you want it.
 * 10) If anything's incorrect with any other aspect of the article, then go back and debug your program, and have it generate the text files again. Check what the page corresponding to the new text file looks like.
 * 11) Once you're happy, you may want to repeat the debugging process with any entities in your list that may cause weird behaviour, just to be absolutely sure your program is creating the text you want it to.
 * 12) When you're ready, go through the list of output text files. For each one, create the corresponding wiki page, copy+paste the contents of the text file in, and save the page. This step is usually done manually (although it can be automated; see below).

It may well be the case that the relevant data for an entity is spread across multiple BDAT rows in different tables, or consists of (one or more) entire BDAT tables. The basic process is the same; configure your program to take in and parse as many tables as are required, but it may be easiest to always output one text file per wiki article.

Sometimes you'll need to edit a lot of pages rather than create them. For example, maybe a lot of pages need Template:In other languages. The general idea is the same. Make a script that outputs the wiki text for each article (possibly to individual text files for each article, possibly all to one text file if the article is small enough), then manually copy+paste the relevant output text into each article.

Python and C++ are good languages to write your text-processing programs in. If you don't know how to program, unfortunately the only options at the moment are to either learn how to do so, or get someone else to write the program for you. The BDAT -> wiki page process is so dependent upon specifics that there's probably no way to make a one-size-fits-all program that you can download and run yourself without heavy tweaking. You can, however, ask other editors if they can send you their own programs as a starting point.

Using PyRikiBot
The wiki has a bot, User:PyRikiBot, to automate some tasks fully. Sadly, unless you are User:Sir Teatei Moonlight (the bot manager) or a bot yourself, you are probably not going to be able to fully automate page creation or editing all by yourself. That doesn't mean there's no way to do so; it just means you'll have to go through the bot manager as a middleman. Put in a request on his talk page or ask on the Discord server.

There are things that Riki can do much more easily than others. The main aspects to be kept in mind are making sure Riki knows where to place an edit, and making sure he can make the right change relevant to each page.


 * Generally speaking, Riki will naturally be able to make edits to all pages in a category. More specific sets of pages may or may not be possible.
 * Riki can easily find the start of a page, the end of a page, and headers. He can also find all instances of a given template, and argument calls to said template. In general, if you can find exactly where you want Riki to place/replace text by pressing Ctrl-F/Cmd-F and typing the same thing for every page Riki needs to change, Riki can probably find it; otherwise it'll be much harder.
 * The change being made typically should be basically the same text being placed/replaced for every page in the category. Slight deviations from this are possible; see User:PyRikiBot or talk to the bot manager for details.

If you make a page with the intention that Riki will later add something, make a header for it (probably with an incomplete tag). That way it'll be much easier for Riki to find the place on the page to add it.

It is possible to have Riki make pages. Doing so entails much of the same steps as above, but instead of making separate files for each page, you'll need to put them all in one file with specific formatting, and send that file to the bot manager. See the documentation for exactly what formatting is necessary.

Modules
When a high-use enum template gets insanely long, calling it becomes very slow, because in order to find the one correct entry in a #switch, it much iterate through every one of them in order. Modules are used to increase performance in these situations.

The  syntax tells the wiki to go to the page called "Module:module name" and execute the "function name" function using "param1", "param2", and "param3" as its arguments. Modules are not written in wikitext, but in Lua, a dedicated programming language with entirely different syntax and gotchas. The usage of modules is relatively new around here, so there's not too much in the way of specific advice yet.

For the documentation, see here.