• Hi, I went through how this Statistics project for A8 boxes/cards is implemented and I must say, good job! :) I wonder now what are your plans for the near future, if you've got a moment...

    1. Data contributions automation. Do you still plan to make the boxes data contributions easier, for both contributors and for you, the data admins? I think it would be great to be able to easily fill the data into a table and to have them in the form usable for database import. An Excel sheet was mentioned for this in a previous thread...

    2. 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?

    3. Using a similar approach for cars stats? 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. I did some research and it seems there are probably 2 posibilities: a) rewrite the cars pages, so they use templates as the boxes pages do, b) use a MediaWiki extension like PageVariable which is possibly the only acceptable extension for this purpose here on Fandom. What do you think? And do you think it's worth the effort? I have some doubts about it ;)

      Loading editor
    • 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?
      Statistics sheet
      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 row; 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 {{Daily Kit Box|style=compact}} 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 items which is the number of items (cards) that a box contains: {{Daily Kit Box|#items}} → 10. All parameters are listed on {{A8box-meta}}.

        With the parameter method, you can also build sentences and even calculate: Three {{Finish Line Box|es}} and one {{Champion Kit Box}} will grant a total of {{#expr:3*{{Finish Line Box|#items}}+{{Champion Kit Box|#items}}}} cards. → Three A8Box Finish Line Box Finish Line Boxes and one A8Box Champion Kit Box Champion Kit Box will grant a total of 39 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 {{a8vehicle}}, {{a9vehicle}}, {{axvehicle}} etc.

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

      The parameter method already does this.
      {{a8vehicle|DS Survolt|#nitroefficiency1}} would deliver 5.

      The style method could deliver a table row for the Nitro efficiency index page. Example:
      {{a8vehicle|DS Survolt|style=table nitro efficiency}}

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

      subst: 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 A8Box Random Box 1 Random Box 1 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 tables 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.

        Loading editor
    • Hi Guy,

      thanks a lot for your long, yet thoughtful answer :) It is exactly in line with what I was guessing and I like the ideas and plans you have. I also totally agree that not only the rewrite for vehicles and their stats has to be a lot of work. So I have not much more to add now :) Just a few points:

      1. Yes, I like the trick of getting properties (e. g. "#items") from the templates via nested "{{{ ... }}}" expressions, it took me a while to get it :)

      2. When I was writing about "alternatives to transclusion by template", I didn't mean to use the "{{subst:template name}}", I meant the other ways described on the linked page.

      Enjoy the Holidays! :)

        Loading editor
    • And finally, wasn't the other user Geceo? :)

        Loading editor
    • Ah, ok; I thought you were referring to subst:. I never worked "outside" a wiki, and to be honest, I'm not even sure if any of us has the user rights to install MediaWiki extensions.

      I've read the description for the labeled section transclusion. It would be interesting for some other purposes. Unfortunately, it cannot be used together with template parameters and parser functions, which excludes it for our goals because we definitely have to calculate with the transcluded values.

      Semantic MediaWiki is HUGE. It seems to be extremely powerful, and these properties seem to be exactly what we'd need for a decent data handling. I guess it is a specialty of our type of wiki that we have so many "items" that have large amounts of properties.

      Our template system, on the other hand, has its limits. I'm still trying to reduce the number of template calls when a simple box (or another item) is displayed. Long box lists tend to exceed the maximum number of template includes. And a template like {{Weighted average common boxes}} (still undocumented, but alrady in use) even produces 84 other template calls for one single use...

      But so far the system works. Using the system for vehicles would be not so dangerous in terms of template include size because lists like the Nitro efficiency index would "only" use 3 templates per row.

      No, the user wasn't Geceo, it was admin talk. :-) But I've noticed that Geceo is a very busy editor.

        Loading editor
    • > I'm not even sure if any of us has the user rights to install MediaWiki extensions.

      AFAIK admins of a given Wiki can ask Fandom for installing extensions, see the acceptable extension page I linked to. BTW when I look at the page again, I must say I overlooked that they accept a "Variables" extension on request, they don't mention the "PageVariable" extension. Just a detail (not a question on you), but I wonder if someone made a "mixed extension" of those two which would enable to define a variable without outputting it, use it on the same page and on other pages as well...

      When speaking about Semantic MediaWiki, Fandom write they no longer enable it because of performance and stability problems. As you write, the templating approach hopefully doesn't have those problems (so far).

        Loading editor
    • Yes, I asked for an extension once, but it was already on their list, so there were no problems. Our News system works with DynamicPageList.

      Unfortunately, the Variables extension is scoped to only a single page, so nothing for us. :-(

        Loading editor
    • I see.

      Yes, exactly, and the PageVariable cannot be used to read variables on the same page (provided the extension would be even acceptable by Fandom), for a change. So a mix of those two would come handy...

        Loading editor
    • For now, I have a look at Category:Pages where template include size is exceeded from time to time.

      There aren't many pages that have such a huge amount of box templates. I'm also planning to stop using {{A8boxinfo}} inside the box templates. It would be a bit more code and I would have to change more than 200 box templates manually, but this would mean 200 template calls less in lists where drop rates are displayed.

        Loading editor
    • Hi!

      The "vehicle" template would be incredibly useful to make use of the vehicle stats. At the moment, the stats pages are static and not very informative, because what the players want to know is whether vehicle X is better than vehicle Y. Just look at the comments on every car page, half of the comments are "Is this good for MP?"

      So why not try to make something that would give answers to the most common question? Sure, this idea requires a lot of planning, but the hardest part is certainly to have clear ideas of everything we want to do, so that we can define the templates with the right depth and complexity.

      Because I'm in the process of doing a garage template, I would really love if the "a8vehicle" template could be called with the current setting of the vehicle, for example:


      This call would return the most recent available stats of a 0500-0000 DS Survolt (including speed, nitro, etc.) and its current rank (if it's possible to automatically compute it, based on upgrade rank percentages, then it would be perfect, otherwise the player would have to give the rank manually in another parameter).

      So what I would like is:

      • Template:a8vehicle|DS Survolt|0500-0000|v4.7

      where v4.7 would be the version of the game (if omitted, most recent available stats would be returned). It would return:

      • Acceleration
      • Top speed
      • Handling
      • Nitro
      • Stock rank
      • Max rank
      • Max-pro rank

      If we could have a template for each vehicle, that could even take as parameter the version of the update of the game (e.g. v4.7), that would return all possible stats, a lot of useful pages would be possible, with no maintenance (well, we would still have to input the basic data, like stock stats, stock rank, max rank, maxpro rank and upgrade percentages, nitro efficiency values, when they change).

      UPDATE: sorry, I just realized there's probably no known formula to compute a "level X" upgrade stat for a given car. Knowing the stock stats for the DS Survolt, and even the upgrade rank percentages, gives no information as to what the level 4 acceleration is.

        Loading editor
    • F**K! Wiki has swallowed everthing I had written!

      Again, ultrashort:

      It already exists:

      But it's outdated because it is run by a single person or a small team, and when GL changes 20 cars, around 1,000 parameters would have to be changed manually.

      Wiki Problem: We can't host a database here. We could offer similar tuning buttons to those on a8tune, but we need a permission for every single JavaScript line we are running. And JavaScript works a bit different on a wiki server.

        Loading editor
    • Yes I know about A8Tune and how outdated it is. They should turn this site off, as it misleads the players.

      Just to know, is there a formula to compute the value of the acceleration, top speed, handling or nitro, given a start value? I doubt GameLoft don't use a formula but I never read anything about this.

        Loading editor
    • I'm pretty sure there is a formula, althogh I am NOT sure if Gameloft uses it in-game or has the values first calculated somewhere and then hard-wired in the code.

      For example, the Android tuning app and both warn that ranks may differ by ±1 which points to rounding errors due to a formula that GL doesn't use in the same way.

        Loading editor
    • It's striking that both the app and a8tune got outdated at roughly the same time. Maybe they both used a data dump that they got somehow, but didn't get one after the changes by GL.

      Also, if you click on the BMW i3 on a8tune, just scroll down a littlle bit, and you will find upgrade prices—do they look familiar to you? Yes, it's an exact copy of our upgrades page.

      It would be interesting to examine if a8tune uses formulas or a database with all values fixed and not computed. I'll ask CrazyTriangle333 who is familiar with JavaScript if they can have a look at the site and tell us how it works. I simply don't have the time to do that at the moment.

        Loading editor
    • By the way, I'm testing out a new stats table format for vehicles. You may want to have a look at Ford Mustang GT Fastback (stats). "Car Power" is the same as "Rank" in A8. Car power increases are shown in green. If editors entered all rank increases for every level instead of just max and pro, we would have all the values we need to provide the rank, speed etc. for every possible tune. The stats table alone could do this.

      Unfortunately, editors never entered these values, and it's a lot of work to watch rank increases with every upgrade. Furthermore, all data is useless when GL "rebalances" a vehicle.

      The best would be to have a dummy account on a rooted phone with a hacked version of A8 with unlimited tokens, credits and fusion points. After changes by GL, one could just reinstall this version, upgrade all cars and fill in the new values.

        Loading editor
    • It would be interesting to examine if a8tune uses formulas or a database with all values fixed and not computed. I'll ask CrazyTriangle333 who is familiar with JavaScript if they can have a look at the site and tell us how it works. I simply don't have the time to do that at the moment.

      Hi guys, sharing a screenshot from a8tune:

      can see the stats are computed in PHP (provided the real language is not masked ;)) and they are fetched by JavaScript via Ajax calls to the PHP server (after every single click on the left / right arrows).

      So it looks like we can't tell how exactly they compute the values. Maybe they delegate the computation to some of those XLS sheets linked in a8tune page footer. There are also other seemingly useful links in the footer, but unfortunately all the resources seem to be in Russian, so a little language barrier here...

      From what I've seen so far though, I guess they do compute the stats using various formulas in the end.

        Loading editor
    • You can check the result of the AJAX call at:

      The values seem to be calculated, as can be guessed by the fact that they are not rounded (e.g. "264.30000000000001" for top speed).

        Loading editor
    • The real missing tool about the A8Tune website, or this Wiki, is that we cannot easily compare the vehicles without asking the other players. That's why people always ask, when they have to buy a new car, "Is this car better than this other car?". But they should be able to deduce the answer by themselves if the data could be fused in a table or even better, in a colourful fancy graph.

      As an example, let's say that I want to know what vehicle is the best choice for MP in the very "populous" [1310-1360] bracket (though, the precise definition of a "MP bracket" is still unclear to me), where you can meet MAX-PRO Donkervoorts (D1341), a lot of MAX-PRO Survolts (B1357) and a few other cars (Ariel Atom V8, Alfa 4C, Honda S2000, Lancer, etc.). In theory, we could even meet some S-Class vehicles in this bracket, like e.g. the Arrinera Hussarya GT (stock rank is S1289).

      Since the FLU update, GameLoft has equalized the stats of the vehicles so that "(Top Speed + Nitro Speed) / Rank" give out a constant value among cars at Stock and MAX-PRO:

      • A8 icon max-A8 icon pro vehicles now all have a (TS+N)/Rank value near 0.264 (or 0.265 for the most recent vehicles, like the Zerouno);
      • Stock vehicles have a (TS+N)/Rank value near 0.254 (a notable exception here is the "Festival" vehicles, which are created much less competitive, e.g. the Zerouno is only at 0.238);
      • A8 icon max vehicles DON'T necessarily have a "near equal" (TS+N)/Rank value, because the upgrade rank percentages aren't equal among vehicles. It means that there may be some surprises if we had all the A8 icon max ranks and (TS+N) values. As an example, given two vehicles A and B with identical stock and A8 icon max-A8 icon pro stats, but with very different upgrade percentages, then in theory Vehicle_A at A8 icon max could have a quite faster or slower speed than Vehicle_B at A8 icon max. I may be wrong about A8 icon max vehicles stats, but it's interesting not to forget that upgrade rank percentages aren't yet equalized (and I think they should be, it would make the rank much easier to predict).

      Well, if we want to keep things simple, we just have to remember that A8 icon max vehicles are better than Stock and worse than A8 icon max-A8 icon pro. There shouldn't be a lot of very large "competitiveness oddities" due to upgrade rank percentages, anyway.

      So, what would be very useful (and possibly quite fun to play with) is a tool where you could check for a given rank what is the overall best vehicle. And in this computation, we could even include the Acceleration, Nitro efficiency and even maybe Drift radius to output a realistic answer.

        Loading editor
    • Hi Geceo,

      thanks for sharing your thoughts and interesting findings about the upgrade rank stats. As you write, there are quite a lot of factors which make a "good MP car" and I guess it won't be quite easy to have such a measure "purely calculated".

      Luckily (although not for old players with MP-tuned cars), it seems that after all the changes GL made, the more you get your car to MAX-PRO, the more MP-competitive the car generally gets now? So not much "MP-tuning" needed today? Still, there is the question which car to choose for MP at the 1st place, is that what you +/- say?

      Today, you can experiment and succeed with lots of different MAX-PROed cars, which I find somewhat entertaining. I can't speak for everybody, but my need for a "comparator tool" is therefore not that big as in the past. Anyway, it would be great if GL could share their own statistics of MP races results - I think that would be "by-design" the most relevant source for finding out the best MP cars. But I'm a little bit afraid GL will never do that... ;)

        Loading editor
    • Hi CrazyTriangle333,

      You're right, it's not absolutely necessary, but I find the idea of a comparator very interesting. It's more like a scientific challenge to find a good formula, based on the stats, that would express the "MP competitiveness" of each car in the game. It's also very interesting to understand how a Wiki can make computations.

      Even though GameLoft has rebalanced the ranks relatively to the Top Speed, there are still big gaps of "competitiveness" when you look at Acceleration, nitro efficiency, steering radius and drifting radius (and maybe weight, which is maybe the hidden capability to knock out, or being knocked out, but I don't know if this stat actually exists in the game).

      In the same bracket, these less visible stats (I mean less visible than Top Speed and Nitro) make some vehicles really uncompetitive, whereas others shine. I upgraded my stock Mazda Furai to B1293 at 5500-0000, and I find the car seriously horrible to drive, even though the (TS+N)/Rank is not too low (0.259 should be enough to win from time to time). The nitro is annoyingly weak (perfect nitro is at 15), and the drift radius absurdly wide (it seems as bad as the Agera R). I made a few races today (all unboosted), and couldn't win any.

      So, in this example, we could imagine a formula that take into consideration the abysmal "perfect nitro" efficiency of the Furai, and the excellent nitro efficiency of the Donkervoort, and display a value that tells the players that the Donkervoort is much more competitive than the Furai.

      Have you looked at User:Geceo#Garage? The problem with this table is that every data must be copied. But it's interesting. Based on this table, I made a race with my Cadillac XTS and easily won against three Survolts. Players think that the Survolt is necessarily good, and the XTS a big slow sedan, but a MAX-PRO Cadillac XTS has a better "(TS+N)/Rank" than a similarly ranked Survolt, even if the Survolt has a better nitro efficiency and a better acceleration too. So yes, I was last after the start of the race, but I could pass each of them during the first lap (btw, the XTS seems to be hard to knock out: a Survolt tried to knock me out using the wall at the start, but his Survolt was knocked out instead of the XTS, I guess he was surprised).

      About GameLoft sharing the results of the races with us, it would surely make the most reliable statistics, but do GL save the results at all? It would make up a very big pile of apparently quite useless data. :)

        Loading editor
    • Hi Geceo, I see your points and agree :)

      Regarding Cadillac XTS, thanks for the tip, I will try right away :) Although of course, MP results are not that comparable now when it's outside a MP season... Edit: Yeah, Cadillac XTS seems pretty good. The problem with Survolt is that it is far from max-pro at Cadillac's 1137 max-pro rank. So it is no surprise Cadillac can beat it easily, isn't it?

        Loading editor
    • Yes! Isn't it fascinating that we can use a boat and win? :)

      We have to remember that a lot of players have little or no knowledge about the internal stats, and the importance of the (TS+N)/Rank. They certainly believe that the Survolt is great at all ranks.

        Loading editor
    • Yes. And Yes. :)

        Loading editor
    • CrazyTriangle333 wrote:

      "Today, you can experiment and succeed with lots of different MAX-PROed cars, which I find somewhat entertaining."

      and I agree. MP Tuning is not really possible any more since they have changed the rank increase for Acceleration and Handling to only +1 per level. I think GL wanted to make MP less scientific with this change, and to avoid deception for newer players who may have "mistuned" their cars in terms of old tuning rules.

      On the other hand, a comparator would be just fancy to have. I cannot object because I've made exactly the same with all the box comparison pages.

      But I discovered the limits as well: Too long tables will exceed the maximum template include size. I'm currently working on decreasing nested template calls to avoid this. Makes the code less nice to read, but more effective.

        Loading editor
    • A FANDOM user
        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message
Community content is available under CC-BY-SA unless otherwise noted.