Thread:Guy Bukzi Montag/@comment-35102879-20191218221644/@comment-34918040-20191219030152

Hi CrazyTriangle333,

thanks! This is absolutely crazy. Do you happen to be some kind of telepathic medium? Less than 24 hours ago these were the exact topics of a Discord conversation I had with another wiki user! :D


 * Do you still plan to make the boxes data contributions easier, for both contributors and for you, the data admins?

Yes. The long-term plan is to have an HTML form that lets users enter their box opening results.


 * An Excel sheet was mentioned for this in a previous thread...

This is a temporary solution I tried with two users who had large amounts of boxes to contribute. I've sent them an Excel sheet where they could enter they data, and they sent it back to me.

The problem is that this Ecxel sheet would have to change often, especially after game updates. Users would have to change it manually on their computers; furthermore they would have to follow a strict structure of entering the data. This can be the source of many errors. I can handle this with the current two users working with the sheet, but not with a multitude of contributors.


 * Raw boxes data stored in a database, right? I couldn't find this on the project's pages. Is it that you yourself update the statistics in the boxes template pages and you've got the "raw" data stored in your database somewhere? Do you plan to mention this somewhere?

Sort of. I misuse an Excel sheet as a database. See screenshot to the right, that's how it actually looks like. Here's how the system works:
 * Every box opening has one line, every column stands for exactly one card type.
 * If you want to have the statistical data for just one box to update a wiki template page, you can filter the table by box name, date or whatever else you want.
 * I wrote some Visual Basic code which then extracts the statistical parameters, converts them into wikitext and copies this to the clipboard so that I can insert the wikitext in the statistics section of a box template. It would be too much work and error-prone to type in all parameters manually.

This is the "offline part" of the system. In the Excel "database", one dataset is represented by one table row.

Once the data is in a template, the wiki modular system takes over. This is basically just another type of unconventional database where I misuse the wikitext markup language to simulate database functionality. In the wiki "database", one dataset is represented by one template.

I don't know how deep you dived into this, but here's how it works:
 * Style method: The style method uses predefined display styles. If you place a box template, say  on a page, this template calls a8box-meta which then passes the parameters needed for the display style to a third-level template. In this case, the style is "compact" which calls A8box compact. Other styles are listed  on Help:Pro Kit Box modular system.
 * Parameter method: The parameter method lets you directly extract the value of any parameter in a box template by using . It's basically a simulated and simplified SQL query. For example, every box template has a parameter called   which is the number of items (cards) that a box contains:   &rarr; . All parameters are listed on a8box-meta.  With the parameter method, you can also build sentences and even calculate:   &rarr; Three  and one  will grant a total of  cards.  This is the reason why not only the table, but also the text in the Important preliminary remarks section of the "Myths" page is completely maintenance-free: The text rewrites itself as soon as any box data changes.

This said, let's come back to your question about my future plans:
 * I want to convert the Excel sheet to a real database. With currently more than 13,000 rows and counting, filter processes have become incredibly slow.
 * The database should be hosted on a server, not my local computer. This would enable us to run the above-mentioned HTML form where users can enter new data that would be directly added to the database after being approved by a data admin. Problem: As far as I know, Fandom doesn't allow to host data bases, so the server space would have to be a) outside Fandom and b) for free.
 * The ideal case would be a bot that gets box data from the database and injects it into the wiki box templates. Problem: It's possible to program bots on Fandom, but I'm quite sure that they won't allow it to get data from outside Fandom. I'd prefer the database to be hosted on Fandom so it's all on the same server. I'll have to negotiate with them.


 * In the comments below the Nitro Efficiency Index, you can see we've got a short discussion about keeping the cars data at one place and make various lists (like the Index) from them.

That's exactly what I'm planning. Designing a modular system for vehicles would instantly render the following features completely maintenance-free:
 * Infoboxes on vehicle pages
 * Stats pages
 * Upgrade pages
 * Nitro efficiency index page
 * Vehicle list page
 * any other list that contains vehicle data

As there would be no statistics, the offline Excel part of the system would not be needed. Editors could just edit the vehicle template.

BUT: This would be a bit more complicated than the box modular system, as many cars appear in several games which require completely different parameters. A solution could be to create templates like,  ,   etc.


 * [...] use a MediaWiki extension like PageVariable [...]

The parameter method already does this. would deliver 5.

The style method could deliver a table row for the Nitro efficiency index page. Example:


 * [...] which is possibly the only acceptable extension for this purpose here on Fandom.

does not work here because we need data to be updated, not permanently replaced.

A few other points have to be considered. For example, Asphalt Wiki also has "historical" purposes. Storing all vehicle data in templates would render all tables current, but historical data would be lost. One may ask "Who needs old data?", but there were several cases when I was grateful to find older data on wiki pages for comparison purposes. And, finally, we can track GL's tricks and know how it was before a change.

A solution could be to hard-code old data if a game update changes vecicle stats or prices. This task is a bit nasty. If you have a look at the page, for example, you'll see several older box versions listed. Technically, when box data changes, I copy the last template version before the changes to a new template with a name like Boxname (4.2.0). I don't do this if only the box price changes, but I certainly do it if the drop rates change because otherwise statistics templates would display wrong data.

One would have to decide which change triggers such a preservation process. As I see it, new template versions should be built if upgrade prices or stats change, because we have old and new versions of upgrade and stats tables.

Or the community agrees that there's no use in preserving old upgrade prices and stats. This would be the easiest solution. But nonetheless, tables should display an additional game version tag so readers know if the information is outdated. This would require different tags for upgrade prices, stats and others, which requires thorough maintenance again.

As you see, putting vehicle data into templates would be great, but there are many traps to be avoided. It takes a lot of planning, and I simply didn't have the time to do that for now.

I'm currently testing the portability of the Pro Kit Box modular system for the Kit Boxes of Asphalt Nitro. It works fine so far; I'm learning where the system should be more flexible to guarantee portability.