If the matches are reported with the above match slip you could produce data similar to sports statistics. Imagine being able to produce stats like Whisper lives the entire match 60% of the time and of that 60% that squad wins 95% of the time. In matches where Whisper dies they lose 78% of the time. By only collecting the scores and that squad played this squad, you'll be missing some of the details.

Interesting idea for the match slips, it's on my wishlist. Unfortunately if you are having anyone calculate MoV than you're doing it wrong. You should be entering kill points into my program and it calculates MoV for you. The only thing the TO has to remember is that if you completely destroy a squad that only has 98 points then you still get credit for 100 kill points.

If you had the match slips check-box method, then MoV would definitely be getting calculated automatically. This would be a really good thing. You would, of course, need a failsafe to be able to enter data in manually, even allowing for the possibility that you don't even have the squad lists, just the MoV itself.

So, first step has to be to get a standard language to express squads. XML, JSON, QR whatever. Then the squad builders should add functionality to express squads in that language. That should be achievable.

The second step is a bit tougher right? The TO software. There are a few options, but the most flexible it would seem is a web app that runs on a database backend. I think building stand alone software that runs on peoples laptops or desktops or tables is a bit old school.

Maybe the solution to that is to not only agree on a standard squad language, but also a standard tournament and game reporting language. If the TO software can output the results into a standard JSON/XML document that has each match, each result, etc, that could be consumed by any other TO package or a centralized data store of ALL tournament results.

I think that's the goal, right? A central repository of all the results everywhere.

So, we need to all agree on a standard language set to express squads and tournament results and publish that somewhere for all to see. Then I think the final step is to build a central repository that can accept TO results into it, that each XWing player can register a username with, and that can consume the TO results, and spit out rankings and reports, and any **** query we want.

Maybe I've restated the problem, but I don't think anyone has suggested a standard reporting language for tournament results.

We need a way to express an individual game result in a standard language, and a way to express an entire set of games in a standard language. Those languages need to be fully extensible. To me that seems like an XML document type.

Who wants to start. I would, but I'm far from an XML expert.

And I think ideally, the perfect TO software is Web based and completely transparent so that the participants can see the results in real time as they are reported during a tournament on their devices, and each participant can see the breakdown of his MOV score, or whatever the tie breakers are at the time so that reporting errors can be caught immediately.

The standalone TO software package will always have the lack of transparency problems. There is no good reason that spectators from around the globe cannot get near real time reports of the tournaments as they happen, other than no one is publishing that data. The data is entered into a computer between rounds, that data should be published to the web as it happens. Sure, some locations don't have web access, but I think that is the exception to the rule, and not the norm.

And if it's web based, when a new FAQ comes out, the software only has to be updated once, and doesn't have to be distributed to each TOs laptop etc. The downside to this is network outages are crippling, which is why some won't want to do this, and that's totally prudent. So the TO software suites out there should output to a standard that can be consumed.

That's what I think.

So, first step has to be to get a standard language to express squads. XML, JSON, QR whatever. Then the squad builders should add functionality to express squads in that language. That should be achievable.

The second step is a bit tougher right? The TO software. There are a few options, but the most flexible it would seem is a web app that runs on a database backend. I think building stand alone software that runs on peoples laptops or desktops or tables is a bit old school.

Maybe the solution to that is to not only agree on a standard squad language, but also a standard tournament and game reporting language. If the TO software can output the results into a standard JSON/XML document that has each match, each result, etc, that could be consumed by any other TO package or a centralized data store of ALL tournament results.

I think that's the goal, right? A central repository of all the results everywhere.

So, we need to all agree on a standard language set to express squads and tournament results and publish that somewhere for all to see. Then I think the final step is to build a central repository that can accept TO results into it, that each XWing player can register a username with, and that can consume the TO results, and spit out rankings and reports, and any **** query we want.

Maybe I've restated the problem, but I don't think anyone has suggested a standard reporting language for tournament results.

We need a way to express an individual game result in a standard language, and a way to express an entire set of games in a standard language. Those languages need to be fully extensible. To me that seems like an XML document type.

Who wants to start. I would, but I'm far from an XML expert.

And I think ideally, the perfect TO software is Web based and completely transparent so that the participants can see the results in real time as they are reported during a tournament on their devices, and each participant can see the breakdown of his MOV score, or whatever the tie breakers are at the time so that reporting errors can be caught immediately.

The standalone TO software package will always have the lack of transparency problems. There is no good reason that spectators from around the globe cannot get near real time reports of the tournaments as they happen, other than no one is publishing that data. The data is entered into a computer between rounds, that data should be published to the web as it happens. Sure, some locations don't have web access, but I think that is the exception to the rule, and not the norm.

And if it's web based, when a new FAQ comes out, the software only has to be updated once, and doesn't have to be distributed to each TOs laptop etc. The downside to this is network outages are crippling, which is why some won't want to do this, and that's totally prudent. So the TO software suites out there should output to a standard that can be consumed.

That's what I think.

While your assessment is accurate, the problem lies with getting it done. It would take me a long long time to get all of this done. If someone else wants to get it going, I'd gladly help with design or be available for consulting.

Until that day comes I will continue on my path of making my program marginally better. The discussion of format of data is completely unnecessary as it is only between myself and MajorJuggler at the moment. The only reason we have been discussing squad list format is because there are multiple squad builders. I think one is good enough, but people seem to have their preferences.

After discussing this with WickedGrey offline, we came up with this:

A card can be uniquely identified by the SWXnn ID of the expansion it appears in and the (0-based) index into the alphabetized list of cards per expansion. That is, suppose in the future, "SWX42 - Least Wanted Expansion Pack" is released, with the following cards:

• 0 - Bomb Torpedoes
• 1 - "Dakka Dakka" Cannon
• 2 - Redbeard McShootington

Then "Redbeard McShootington" can be identified using the pair (42, 2). We can then base64 encode the uint8 array [42, 2] to "KgI=". Ships and their upgrades would be delimited by commas; we don't need delimiters for upgrades since we know we're using 4 characters per card [1] .

I'm using the list of SWX numbers at: http://community.fantasyflightgames.com/index.php?/topic/113554-wgencon-today-are-all-the-skus-spoken-for/#entry1204216

To determine the card index, per-expansion sorting would be performed only on the alphanumeric parts of the card's name. In the case of similarly named cards in the same expansion (e.g. Dash Rendar pilot vs. crew) it's okay, because we'll always encode the pilot first and upgrades later [2] .

This means each tool that uses this format must have an up-to-date list of cards and expansions it knows about. This should not normally be a problem, since for tournaments, only released content is available for play, and wave releases are infrequent.

I've created a proof of concept encoder here: http://codepen.io/geordan/full/CxoBL

In practical purposes, then, a Whisper/Howlrunner swarm ( https://geordanr.github.io/xwing/?f=Galactic%20Empire&d=v3 !s!79:27,36,46:-1:9:;18:-1:-1:6:;10::-1:-1:;10::-1:-1:;10::-1:-1:) would encode to

Ewg=Bg4=DgQ=DQs=EwA=,AwQ=FQE=,AQA=,AQA=,AQA=

which is not too onerous to type, and results in a nice, small QR code.

[1] We could compress it to 3 characters per card if we allocated 9 bits for expansion number and index but I'm lazy, and WickedGrey likes the idea that the first two characters in the code mean the expansion, and the last two mean the index, so theoretically people could start to recognize codes. I think he's nuts. And I'm too lazy to try to get the bits lined up as it is.

[2] In the event an expansion someday has two identically named upgrades but with different slots (e.g. suppose they released R2-D2 astromech and R2-D2 crew together), then... we'd have to disambiguate their names somehow.

I'm not even touching that one. Incredibly overcomplicated.

What do you do for cards that come in two different expansions?

Advanced Sensors from the Lambda Shuttle, and from the E-Wing.

What do you do for cards that come in two different expansions?

Advanced Sensors from the Lambda Shuttle, and from the E-Wing.

I think you would simply have it first come first served. The Lambda had it first so you build it as a Lambda upgrade. this way when new ships come with a previously released card you don't have to recode it.

I was also thinking about using the FFG product codes for the ship number, as a similar method. Then I realized that the Scum Z-95, HWK-290, Firespray, and Y-wing all come in the same expansion pack. So there goes that idea.

I'll try to get a list together tonight for my proposed method, which uses the 1 or 2 letter prefix before Pilots / Upgrades. Since we will be continually adding new numbers to each category, it makes sense to be consistent from the outset and make the numbering within each category go in ascending order of release date. Ordering within the same release would then be by:

• Ships: same ordering as FFG product code. For Scum reprints use the original product code to sort, so for example the ordering for wave 6 would be: StarViper, M3-A, IG-2000, Scum Y-wing, Scum Firespray, Scum HWK-290, Scum Z-95.
• Pilots: by ascending order of pilot skill first, and alphabetical sorting 2nd
• Upgrades: by alphabetical order

If you have any SQL or database work in general, I can help

Only read the first post of this thread, so maybe it's already obsolete; but I have experience in Objective-C, Swift, Xcode, and Mac-related software development in general.

I also have a finished swift app that calculates the complete probability density functions of jousting encounters between all ships that have been released so far (no movement, however, and yet without upgrade cards).

Please let me know if anything of this is of any use for the project.

Only read the first post of this thread, so maybe it's already obsolete; but I have experience in Objective-C, Swift, Xcode, and Mac-related software development in general.

I also have a finished swift app that calculates the complete probability density functions of jousting encounters between all ships that have been released so far (no movement, however, and yet without upgrade cards).

Please let me know if anything of this is of any use for the project.

Have you met MajorJuggler? If you're interested in the statistics side of things I'm sure he could use the help. He calculates these things ad nauseam.

Only read the first post of this thread, so maybe it's already obsolete; but I have experience in Objective-C, Swift, Xcode, and Mac-related software development in general.

I also have a finished swift app that calculates the complete probability density functions of jousting encounters between all ships that have been released so far (no movement, however, and yet without upgrade cards).

Please let me know if anything of this is of any use for the project.

You are perhaps the very soul I've been looking for!!!!

I also have a finished swift app that calculates the complete probability density functions of jousting encounters...

.. you had me at PDF...

In all seriousness, I do have several Matlab scripts to do stuff like this. I haven't posted the code, but some of the outputs are here:

http://community.fantasyflightgames.com/index.php?/topic/100360-using-lanchesters-square-law-to-predict-ships-jousting-values-and-fair-point-values-work-in-progress/

It's out-of date, I need to add a thread topic just for the PDF of number of hits to kill each stat line, which I recently added.

In any event, I don't know that it's directly applicable to this topic, but there currently is no really good X-wing math probability calculator online. The best i have seen is xwingdice.com, but it is very limited. I don't personally need one since I have my own scripts, but other people would find it interesting. I don't really have any particular interest in writing web code however.

I may not be very experienced, I'm currently studying programming, so I have never created a full application with a complete front-end, but I have made a lot of minor programs. From schoolbook examples to mathematical applications. If there's anything I can help with I'd gladly join in. The languages I'm familiar with is mostly the regular ones, C, C++, Java... So general time consuming code-crunching I could probably assist with.

What do you do for cards that come in two different expansions?

Advanced Sensors from the Lambda Shuttle, and from the E-Wing.

Fortunately, it wouldn't matter; both the shuttle version (13, 0) and E-Wing version (18, 0) would decode to the same thing. You could encode using either pair.

I was also thinking about using the FFG product codes for the ship number, as a similar method. Then I realized that the Scum Z-95, HWK-290, Firespray, and Y-wing all come in the same expansion pack. So there goes that idea.

I'll try to get a list together tonight for my proposed method, which uses the 1 or 2 letter prefix before Pilots / Upgrades. Since we will be continually adding new numbers to each category, it makes sense to be consistent from the outset and make the numbering within each category go in ascending order of release date. Ordering within the same release would then be by:

• Ships: same ordering as FFG product code. For Scum reprints use the original product code to sort, so for example the ordering for wave 6 would be: StarViper, M3-A, IG-2000, Scum Y-wing, Scum Firespray, Scum HWK-290, Scum Z-95.
• Pilots: by ascending order of pilot skill first, and alphabetical sorting 2nd
• Upgrades: by alphabetical order

What you're suggesting seems pretty close to my format; why the difference? Is it because you want to have more ship data directly encoded in the format (like the ship type)? Since we're heading in the direction of opaque IDs, we're already going to have to look them up in an ID mapping, so there's no need to re-encode that data.

In other words, multiple ships in the same expansion pack wouldn't be a problem, because we'd have to look up what the eighth pilot in Most Wanted is, and the list would tell us it's New Boba Fett (or whatever) in a Firespray-31.

I like these goals. Going back to this proposal again. First, using a prefix before each category:

• Ships: same ordering as FFG product code. For multiple reprints within a single product code (Scum wave 6 Most Wanted), use the original product code to sort.
• Pilots: by ascending order of pilot skill first, and alphabetical sorting 2nd
• Upgrades: by alphabetical order

Feel free to check for mistakes. We can get the upgrades later. P.S. This encoding is about as future proof as you can get. As new ships, pilots, and upgrades come out, you add them to the end numerically.

What you're suggesting seems pretty close to my format; why the difference? Is it because you want to have more ship data directly encoded in the format (like the ship type)? Since we're heading in the direction of opaque IDs, we're already going to have to look them up in an ID mapping, so there's no need to re-encode that data.

In other words, multiple ships in the same expansion pack wouldn't be a problem, because we'd have to look up what the eighth pilot in Most Wanted is, and the list would tell us it's New Boba Fett (or whatever) in a Firespray-31.

2) It's also by definition future-proof, since new releases get appended to the end numerically. That might also be the case with your encoding but it's not immediately obvious to me, which means it is probably too complicated.

" I don't even see the code anymore. I see Han Solo, C-3PO........."

I like this system for the system to cover the squads.

" I don't even see the code anymore. I see Han Solo, C-3PO........."

I like this system for the system to cover the squads.

You still can't see the Phantom in the code though, because it's cloaked.

Looks easy enough to overview. Though it could be useful to have a definite standard on how to add ships so it doesn't get jumbled over time, since expansions usually come out with both rebel and imperial ships. It's not essential, but might help a bit to decide that you add e.g. rebel ships first and then imperial. With wave 4 as an example we'd add them in this order: Z-95, E-wing, TIE Defender, TIE Phantom.

Not really that important, but always good to have a system.

There already is!

Since we will be continually adding new numbers to each category, it makes sense to be consistent from the outset and make the numbering within each category go in ascending order of release date . Ordering within the same release would then be by:

• Ships: same ordering as FFG product code . For multiple reprints within a single product code (Scum wave 6 Most Wanted), use the original product code to sort.
• Pilots: by ascending order of pilot skill first, and alphabetical sorting 2nd
• Upgrades: by alphabetical order

In the event a release includes multiple new ships (we haven't seen this except for the Core set, but just in case) the ship ordering should be in alphabetical order.

In the event a release includes multiple new ships (we haven't seen this except for the Core set, but just in case) the ship ordering should be in alphabetical order.

Good catch. For the Core release we had a separate X-wing and TIE Fighter expansion so I just went by those product numbers anyway. But it could happen in the future.

Hi

I really like the idea of a squadron interchange format that would let you move squadrons between mine, geordan's and fab's. And for any other apps, too, such as a tournament organiser.

And even better if you could use a QR code to make life easier. I would suggest that this is separated out, though. First you scan the QR which takes you to a squad builder, then you click an "export" button and get the squadron in some kind of universal format.

Anyway, I've had some thoughts on the format. I vote:

Yes to JSON.
Yes to it being human-readable.
Yes to it being concise.
Yes to it linking back to the original squadron builder.

Edit:

Perhaps give each pilot and upgrade a very limited string code, max 6 characters?

How about a 2-dimensional nested JSON array. Something like:

[
  {
    "luke": {
      "astro": [ "r2d2" ],
      "elite": [ "push" ],
      "mod": [ "engine" ]
    }
  },
  {
    "wedge": {
      "astro": [ "r7" ]
  }
]

Where the key is the pilot, and the value is and array of the upgrades. Readable, concise... The only problem is needing a set way of naming the pilots and upgrades.

Vs