I think that making the mapping between the encoded name/id/slug and the actual card text be something that people can't bikeshed[1] over is important. If you start allowing things like "Red" then people are going to start arguing over if it should be "Red" or "Red Squad" or "RedSq" or "Red Squadron" or oh dear lord kill me now.

You don't give the squad builders a choice in how they format the QR code. You give them a spec that they have to adhere to.

Everybody would output "Red" for "Red Squadron Pilot", or "Blue" for "Blue Squadron Pilot", etc.

If FFG comes out with "Redbeard the Pirate" later, then he gets called "Redbeard".

That's not what "future-proof" means.

Yes it is.

Mmm, no, I really don't think it is. Having an arbitrary mapping between (card_name, card_type) and a number doesn't protect you from much in the way of future changes to the game, unless you think that they're going to start changing the names of the cards. Is there something else we're not seeing?

Future-proofing means that if they errata in an EPT on a pilot then the parsing doesn't break. Or if they add an astromech that adds an extra modification slot and an X-Wing title that adds a systems slot, the parser doesn't get confused about which ID is which.

Speaking of, I could see adding something like "created_with": {"software": "YASB", "version": "v1.7.3", "released": "2014-08-22", "url": "..."} or similar, just to make it more clear where this list came from (and so that TOs can report back if there's a bug, etc.). This way, if there's errata that makes all TIE Advanced ships 4 points cheaper announced on 2014-10-01, the software could provide an alert saying "hey, this list is old; might want to double check it."

But as in all things, simpler is probably better. Though it would be interesting to get usage stats.

I think that making the mapping between the encoded name/id/slug and the actual card text be something that people can't bikeshed[1] over is important. If you start allowing things like "Red" then people are going to start arguing over if it should be "Red" or "Red Squad" or "RedSq" or "Red Squadron" or oh dear lord kill me now.

You don't give the squad builders a choice in how they format the QR code. You give them a spec that they have to adhere to.

Everybody would output "Red" for "Red Squadron Pilot", or "Blue" for "Blue Squadron Pilot", etc.

If FFG comes out with "Redbeard the Pirate" later, then he gets called "Redbeard".

Right, I'm talking about the spec writers arguing about the best way to abbreviate stuff (and let's be honest, the squad builder authors are probably going to be helping finalize the spec; they are going to need to be on board for this to go anywhere). There are about 300 "HR" vs. "Howl" decisions to be made, and while many of them are easy, it's still tedious.

Since we're not short on characters, I was saying we can just bypass all of that by not abbreviating anything.

---

In terms of platform, I think that the best bet is going to be something web-based, but that doesn't require calling home to the server to function. All of the required logic and processing would be in JavaScript and could either be loaded onto a laptop or tablet before showing up at the venue (and perhaps saved to disk), and then used through the course of the tournament. Once the browser is back in range of 'net, the results could get uploaded to a central server somewhere. Clever use of the HTML5 Local Storage could probably make the results persist through a browser crash, though I'd have to investigate that to know for sure.

Geordan's YASB is a good example of this; once the page loads, it doesn't need to call home again until you hit the permalink button.

Being able to bypass the whole Windows/OSX/Linux/iOS/Android deployment problem seems like a big win to me.

There's no point in complicating things if a verbose JSON representation fits fine anyway. If someone wants to run a bigger squad, they can use a bigger QR image and everything will just work. If you want to support really massive squads, allow QR images to be tiled by adding numQRImages and QRIndex fields to the JSON.

It would be great if all squadbuilders just acted as front ends, and queried an open-source web service for ship and upgrade info, squad->QR and QR->squad conversion, squad saving and loading, etc.

I have to admit, While I understand the function of Yetanothersquadbuilder, I don't prefer it as my first choice for squad building. I would ask that you either create a new interface, or allow/work out a way for all Squad Builders to potentially function within/with this app.

I ask it humbly, understanding that this sort of request might mean more than I expect it does.

Jacob

There's no point in complicating things if a verbose JSON representation fits fine anyway.

There is a practical limit to the size of the QR code that can be read by a mobile phone, limited by optics, lighting, and resolution. If you can stay further away from the limit, the better, the scans will be more reliable.

Signal to noise ratio and reliability is going to be important. It has to just work.

Hardware / system level approach vs just a pure software view....

The QR code will be sorted out I'm sure. We still need an Objective C programmer to start the Tournament app, or get Chris Brown to open the code up for his software for changes.

Chris is already working on updates to Cryodex right now. He already suggested using a bar code type system to read everything in. We were going to talk on Skype about it, but he was on travel for a bit so we have only connected by email.

Then this thread happened. :-)

Do you happen to know the language he is using for his software?

Do you happen to know the language he is using for his software?

From http://www.afewmaneuvers.com/articles.html/_/afm-articles/use-the-x-wing-cryodex-to-run-your-next-x-wing-r171 it looks like Java.

Yeah missed the Java Rintime requirement before. Java is a great way to develop for the Android side of this but not so much in iOS.

What's your reasoning behind wanting to be iOS-only?

What's your reasoning behind wanting to be iOS-only?

Not only, just included as well.

Sure, but that's probably not your problem. That's the problem of the QR reader software and the QR spec -- which already includes error correction schemes afaik.

Actually why not just store a URL to the user's squad in the image, and have that URL return JSON?

There's no point in complicating things if a verbose JSON representation fits fine anyway.

There is a practical limit to the size of the QR code that can be read by a mobile phone, limited by optics, lighting, and resolution. If you can stay further away from the limit, the better, the scans will be more reliable.

Signal to noise ratio and reliability is going to be important. It has to just work.

Hardware / system level approach vs just a pure software view....

Sure, but that's probably not your problem. That's the problem of the QR reader software and the QR spec -- which already includes error correction schemes afaik.

Actually why not just store a URL to the user's squad in the image, and have that URL return JSON?

There's no point in complicating things if a verbose JSON representation fits fine anyway.

There is a practical limit to the size of the QR code that can be read by a mobile phone, limited by optics, lighting, and resolution. If you can stay further away from the limit, the better, the scans will be more reliable.

Signal to noise ratio and reliability is going to be important. It has to just work.

Hardware / system level approach vs just a pure software view....

Honestly, I don't like the idea of a URL in the QR code. If the tournament software/app has a squad builder in it, all it has to do is interpret the data and not reach out. QR code can be prone to viruses and if the QR reader is set to connect to the webs it is exposed at that point.

Sorry yeah, they mean nothing. Geordan has built something that works and that people use -- you're just another voice on the forum. I'm sure your accomplishments in other areas are appreciated by others, but why should anybody here care? This an x-wing forum, the only credential that matters is what you've done for x-wing.

I hope Geordan continues his squad builder, which is my current favorite. It's the only one that works across all my devices. I also quite like the layout.

Obviously my hard earned degree, and years of experience in the industry and the fact that my software is used on a daily basis by many hundreds of people in the financial industry mean nothing.

Good luck with the project.

Sorry yeah, they mean nothing. Geordan has built something that works and that people use -- you're just another voice on the forum. I'm sure your accomplishments in other areas are appreciated by others, but why should anybody here care? This an x-wing forum, the only credential that matters is what you've done for x-wing.

I hope Geordan continues his squad builder, which is my current favorite. It's the only one that works across all my devices. I also quite like the layout.

Obviously my hard earned degree, and years of experience in the industry and the fact that my software is used on a daily basis by many hundreds of people in the financial industry mean nothing.

Good luck with the project.

Ok, let's drop the "calling out" post, it's counterintuitive to what we are trying to accomplish. Glentopher, said he was moving and so shall we.

It always amazes me how some people fail to remember that these FREE APPS are made voluntarily, out of the devotion of fans who take long hours to develop and polish these things. How so easy to forget.

It always amazes me how some people fail to remember that these FREE APPS are made voluntarily, out of the devotion of fans who take long hours to develop and polish these things. How so easy to forget.

Quiet code monkey we didn't enslave you to talk now get with the tappy tappy!

I'm not interested in developing this app - not that I don't believe in it, I think it's great and it should help TOs tremedously. I just don't want to dilute my efforts for vassal work and lose the little gaming time I have left in my schedule.

I'm not interested in developing this app - not that I don't believe in it, I think it's great and it should help TOs tremedously. I just don't want to dilute my efforts for vassal work and lose the little gaming time I have left in my schedule.

Yeah i've not tried vassel yet but i've heard nothing but good things about your work.

I'm not interested in developing this app - not that I don't believe in it, I think it's great and it should help TOs tremedously. I just don't want to dilute my efforts for vassal work and lose the little gaming time I have left in my schedule.

Your input is still tremendously valuable for this project. I'm open to listen to any suggestions as the plan gets fleshed out as we are still in the prep planing stages or this.

While working on the squad builder for X-Wing Companion I also came up with the idea to have a common X-Wing "squad file format" with QR code support. I was going to e-mail Geordan and Voidstate to see if we could collaborate on this, but I'm glad to see this discussion has already started

I love the idea of having a single spec. It would allow everyone to use the squad builder they prefer, but still be able to give their squads to their friends. Example: A friend of mine uses Voidstate's, but I prefer Geordan's squad builder. Having a universal X-Wing spec would allow us to view each other's squads in our preferred builder.

I like using JSON format. Most programming languages have support for this, and seeing that most builders are written in JavaScript, JSON makes the most sense.

I propose to use numerical IDs instead of text to identify cards. Using a number is shorter than using text, and several cards have the exact same name (R2-D2, Boba Fett, Han Solo, etc.) but they can still have a different ID. I'd rather use IDs instead of coming up with ugly names like "BOBAFETT", "BOBASCUM", "BOBACREW" to distinguish cards with the same name.

Ideally the spec should have a test suite which can be run against a squad builder to check compliancy.

Here's what I came up with:

{
  "name": "Han Always Shoots First",
  "faction": 1,
  "list": [
    [36, [12, 33, 21]],
    [3],
    [3]
  ],
  "builder": {
    "name": "(Yet Another) X-Wing Miniatures Squad Builder",
    "url": "https://geordanr.github.io/xwing/?f=Rebel%20Alliance&d=v3!s!36:12,-1,21,33:-1:-1:;3:-1,-1:-1:-1:;3:-1,-1:-1:-1:",
    "date": "1410099963"
  }
}

Ideally all squad builders get an 'export' feature so they export the JSON file above. This can then be imported in any other squad builder (or TO app) to view the squad. The next step would be to convert these JSON files to QR codes to allow easier sharing.

Instead of numeric id's, you could just hash the full name of each upgrade or pilot. That way everyone knows the id without having to look it up, but the representation would still be small (e.g. 32 bits should be more than enough).

Instead of numeric id's, you could just hash the full name of each upgrade or pilot. That way everyone knows the id without having to look it up, but the representation would still be small (e.g. 32 bits should be more than enough).

We already have upgrades and pilots that share the same name (like R2-D2 and Boba Fett) -- So going with card names alone wouldn't work.

I don't think anyone's going to look at the exported files, only open them with a squad builder or TO app. So I don't really see the need for adding card names.