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.

Thank you for illustrating my point.

If you try to cram too much information into a QR code, it won't physically be able to scan it and read it regardless of what error correction scheme you use. Additional error correction past a certain point will increase your bit error rate when you are bandwidth limited. Information theory 101.

The maximum ceiling to the QR specification is irrelevant. What is practically readable by the phone / webcase / etc is the limiting factor. The QR code spec assumes that you, the application designer, know the enviornment that it will be used inn. If you try and cram in 800 bytes into a 1" square, and read that on your webcam, it's probably not going to work. That's not the spec's fault. It's yours for using it wrong.

To make a cell phone analogy, my phone has 4G LTE spec to transfer 20Mbit+ / sec. But if you're out in the boonies with -120dB SNR (making up a number for illustration purposes) it won't matter.

A practical example: it needs to work with 300 point (possibly 400 point) Epic squads.

"Bandit Squadron Pilot + Concussion Missiles; " is 45 characters. You can field 12 of those for 192 points, which takes 540 characters to represent. Some quick googling says that the rough limit for smart phones is ~400 bytes. You're already over that, and you still have 108 more points to fill in your squad, and some header info like version number and the player's name. The stereotypical software solution which I was trying to point out, and that you conveniently demonstrated, is to just throw more hardware at the problem. But that won't work because you're bandwidth limited.

You can't guarantee that if you print an epic squad verbose that it will be read correctly. So you absolutely need some kind of encoding scheme. Whether shorthand will suffice, or if it needs to be numeric is yet to be determined. The system needs to be reliable. The TOs already have enough of a hassle just running the event, you don't want to make it more difficult for them to use the tool, otherwise they're not going to use it.

Regarding the future-proof argument: I make no claim at all to be any "authority" on software engineering. Had the entirety of Glentopher's response not been "Yes it is" we could have maybe had a discussion about this and his proposed format. Instead, he chose to ignore the issues I brought up immediately after the sentence he quoted.

(No one cares about my degree or years of industry experience either. Chin up.)

Anyway.

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.

No one agrees with your request more than me! We have a great ecosystem of tools, and no one should be forced to use just one of them. Which is why we're discussing a common interchange format.

And like Mu0n, I don't want to dilute my work on the builder by creating a TO helper app.

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).

I thought about this, but I have in my head this requirement that the software be able to recreate the list details without ever having to consult a Master List of cards (to serve venues that don't have net access or haven't updated recently).

I also agree with MJ that we can't just blithely dump data into a QR code and hope it's readable. In practice you want the TO to scan the code quickly and move on, instead of trying to get the camera positioned just right and it's not focusing perfectly and maybe it's too dark in here and oh god why.

...Maybe these last two paragraphs are at odds...

Maybe (someone suggested this earlier I think) we should LZW compress the JSON representation and QR encode that bitstring? I'll mess around with that and see if that gets us to a reasonably-sized QR code.

Oh, and I keep forgetting to link: http://shouldiuseaqrcode.com/

I already thought about building such a system. I imagined it would be nice to be able to plan your squads and register to a tournament with it including payment of starting fees from one place. Also, a lot of work tournament organizers have to do could be done by the system. You can automate pretty much everything so you only would have to put the results of the matches in. It could even display them nicely on a website. NO more need for paper! Whoever, this would be a big project I would not be able to do in my spare time. Question is, who would be willing to pay for something like this? I could think about a percentage of the registration fee for example. Or for the organizer to pay per organized event. Or premium accounts for the players where they can see statistics per card/list/event whatever? What you think?

I'm personally against paywalling the tool and the data; the way I see it, more people using a well-written set of tools means more smoothly run tournaments means MOAR X-WING!

Regarding compressing JSON: I took a combination of WickedGrey's and GKi's formats, minified them, and compressed them at http://pieroxy.net/blog/pages/lz-string/demo.html which resulted in compressing 1,148 bytes of minified JSON compressing to 410 bytes via LZMA.

Edit: grammar

I think its a labor of love by the community. I don't charge for access to Regionals stats. ;-)

I think its a labor of love by the community. I don't charge for access to Regionals stats. ;-)

"Buy this 1st place list on Amazon"

I think its a labor of love by the community. I don't charge for access to Regionals stats. ;-)

"Buy this 1st place list on Amazon"

Hate you~

I already thought about building such a system. I imagined it would be nice to be able to plan your squads and register to a tournament with it including payment of starting fees from one place. Also, a lot of work tournament organizers have to do could be done by the system. You can automate pretty much everything so you only would have to put the results of the matches in. It could even display them nicely on a website. NO more need for paper! Whoever, this would be a big project I would not be able to do in my spare time. Question is, who would be willing to pay for something like this? I could think about a percentage of the registration fee for example. Or for the organizer to pay per organized event. Or premium accounts for the players where they can see statistics per card/list/event whatever? What you think?

As soon as you add a fee to it you automatically limit the user base. I'm also not a fan of collecting registration fees through the app. We will be playing close to the line on FFG'S and Disneys license and the inclusion of money would certainly cause problems.

Proof of concept converting a YASB permalink to QR code of compressed JSON: http://codepen.io/geordan/full/HvtsC/

Cool! What are you using for compression?

Proof of concept converting a YASB permalink to QR code of compressed JSON: http://codepen.io/geordan/full/HvtsC/

https://github.com/pieroxy/lz-string

I go on vacation to Las Vegas for one week and the whole community decides what I should be doing...

So, for those of you who do not know me, I'm the creator of Cryodex. Feel free to ask questions and make suggestions, I love to hear them. Especially negatives, I don't hear enough negatives. I know they're out there.

So what's going on with Cryodex?

Before this thread was made, I was already in talks with MajorJuggler about getting him statistics. Part of that was recording player lists so that it was easier for him to get information. Here's how I'm adding this in.

Every card gets an ID number and the output format is something like [shipID][pilotSkill],[upgradeIDs]

So, assuming the falcon is ship 7 and Han is PS9 and it has c3po(23), MF title(17), and Predator(35) would turn into 079,231735. Then add 3 naked Talas(PS4) with a ship number of 17. The whole squad could be represented as...

079,231735;174;174;174

This isn't very readable, but it is very quick for a TO to enter into a program. I'm still working on an idea for people who come in with no code like this. I do not plan on writing a whole squad builder into the app. It's just too much and it's already been done. Using a QR code for that string of numbers is perfectly acceptable, but I'm not in a hurry to drop a QR reader directly integrated into my app. We'll see, I'm really lazy and you people don't pay very well

If you don't like any of these ideas, I'm sorry. If you're a major developer on a squadron builder or run events with more than 30 players then I'd love to discuss these things with you and hammer out something "perfect" for us all. If you don't fall into that category, then it just turns into a "too many cooks in the kitchen" situation and you end up with a 5 page thread and no answers. No offence, it just makes it really difficult.

I'm also making significant changes to the tournament generation so people can run things other than standard games. It was a very easy "one size fits all" before they changed to MoV, but now escalation and epic tournaments don't work too well in my program. This will be fixed. Also hoping to add things to help run week to week leagues where different numbers of people will show up each week. If you run a league, I'd love to hear how you run things so I could get some ideas.

General Cryodex Info

-Runs on Java 7 so it works on any operating system

-Runs Java Swing so you don't need any internet connection (i'm also too lazy to make it all web based and support a database)

-Want to see the code? Send me an email and I'll get you a cut of the last version.

-I have a wife and 2 kids (4 and 1) who take up a lot of time, don't expect things to happen quick.

Before this thread was made, I was already in talks with MajorJuggler about getting him statistics. Part of that was recording player lists so that it was easier for him to get information. Here's how I'm adding this in.

Every card gets an ID number and the output format is something like [shipID][pilotSkill],[upgradeIDs]

So, assuming the falcon is ship 7 and Han is PS9 and it has c3po(23), MF title(17), and Predator(35) would turn into 079,231735. Then add 3 naked Talas(PS4) with a ship number of 17. The whole squad could be represented as...

079,231735;174;174;174

To expand on the encoding, I would suggest using a prefix before each number to indicate the type.

For example:

S = Ship

P = Pilot

Ti = Title

E = Elite Pilot Talent

Mi = Missile

To = Torpedo

Ca = Cannon

Tu = Turret Weapon

B = Bomb

A = Astromech

SA = Salvaged Astromech

Sy = System Upgrade

Mo = Modification

Cr = Crew

Il = Illicit

So for example "T1" would always be Proton Torpedo. "S1P1" would be an Academy TIE Fighter Pilot. (Ship 1 = TIE Fighter, Pilot 1 = Academy Pilot). Just a general idea, specifics could get worked out later. Some ships have multiple pilots at the same PS, (X-wings and TIE Interceptors) so you will need a specific identifier for each rather than just PS. You could use the same encoding scheme in the squadron builders and they could print the QR code there.

The key is to make it easy for the TOs to enter squads. Either by scanning it in via QR code, or an easy to use squad builder. It's totally understandable for you not to want to add these in, but maybe someone else could code these modules that could then compile into your Cryodex software.

To expand on the encoding, I would suggest using a 1-letter prefix before each number to indicate the type.

For example:

S = Ship

I = Title

P = Pilot

E = Elite Pilot Talent

M = Missile

T = Torpedo

C = Cannon

W = Turret Weapon

B = Bomb

A = Astromech

V = Salvaged Astromech

Y = System Upgrade

O = Modification

R = Crew

L = Illicit

So for example "T1" would always be Proton Torpedo. Just a general idea, specifics could get worked out later. Some ships have multiple pilots at the same PS, (X-wings and TIE Interceptors) so you will need a specific identifier for each rather than just PS. You could use the same encoding scheme in the squadron builders and they could print the QR code there.

I really wanted to keep the code down to only integers so someone with a quick hand could hammer in a squad lightning fast, but something may have to be sacrificed to make manual creation easier.

**** pilot skill not being unique. Might go down to an index like everything else just to keep it simple.

And yes for you manual people, I plan on having a printable page of all codes and their mapping.

This is it. Making things easier for TOs, well and you MJ. If someone wants to make me an example of a button that will scan a QR code and put the text into a text box that would be great. That would be simple to ingest.

I really wanted to keep the code down to only integers so someone with a quick hand could hammer in a squad lightning fast, but something may have to be sacrificed to make manual creation easier.

**** pilot skill not being unique. Might go down to an index like everything else just to keep it simple.

And yes for you manual people, I plan on having a printable page of all codes and their mapping.

The key is to make it easy for the TOs to enter squads. Either by scanning it in via QR code, or an easy to use squad builder. It's totally understandable for you not to want to add these in, but maybe someone else could code these modules that could then compile into your Cryodex software.

This is it. Making things easier for TOs, well and you MJ. If someone wants to make me an example of a button that will scan a QR code and put the text into a text box that would be great. That would be simple to ingest.

Yes, give the TO a gigantic Easy Button:

Also, I edited my post, realized some letter collisions really require 2 letters for the prefix. "Lightning fast" is a little scary, because the Human Error Rate will go up, especially with a strictly numerical encoding scheme.

I think if we come up with a "standard" for the squad details encoding, then we will be headed in the right direction. It needs to be easy enough to use that if the TO wants to, they can manually enter it in as you suggested. This would also require giving them a lookup table within the Cryodex software somewhere, so they can reference it.

Welcome back from vacation, Killerardvark! ...Sorry about the mess.

Have you finalized the format you're using to store the data for MJ? Because if you can afford to store and send more verbose data (instead of using IDs, use the card name and type spelled out) then you won't have to maintain a mapping from card to ID. And then we squad builder devs won't need to have to consult and collaborate on that mapping. (I'm with you on laziness.)

I agree that Cryodex (or any other TO software) does not need a squad builder embedded in it. At the end of the day, it's the human TO's responsibility to verify the legality of the lists submitted; just because a squad builder app created a list doesn't mean it's tourney-legal. All we're concerned about is rapid entry.

In terms of rapid entry, having to type in an opaque serialization is prone to errors (and suffers from that Master List problem above). Perhaps you could have a screen where the TO can enter text into text fields that have aggressive autocompletion for cards the software knows about (e.g. typing in "Red" autocompletes "Red Squadron Pilot"), and each pilot can have one or more associated upgrade card text fields? You won't have to check the legality of any of it. And for cards that may have been recently released but the running version of Cryodex hasn't been updated for it, it just accepts the new card name (if the TO types in "Redbeard McShootington" as the pilot, more power to them).

Hopefully there's a Swing widget out there for this sort of thing. (Last time I wrote any Java UI stuff, it was with AWT, so...)

Welcome back from vacation, Killerardvark! ...Sorry about the mess.

Have you finalized the format you're using to store the data for MJ? Because if you can afford to store and send more verbose data (instead of using IDs, use the card name and type spelled out) then you won't have to maintain a mapping from card to ID. And then we squad builder devs won't need to have to consult and collaborate on that mapping. (I'm with you on laziness.)

I agree that Cryodex (or any other TO software) does not need a squad builder embedded in it. At the end of the day, it's the human TO's responsibility to verify the legality of the lists submitted; just because a squad builder app created a list doesn't mean it's tourney-legal. All we're concerned about is rapid entry.

In terms of rapid entry, having to type in an opaque serialization is prone to errors (and suffers from that Master List problem above). Perhaps you could have a screen where the TO can enter text into text fields that have aggressive autocompletion for cards the software knows about (e.g. typing in "Red" autocompletes "Red Squadron Pilot"), and each pilot can have one or more associated upgrade card text fields? You won't have to check the legality of any of it. And for cards that may have been recently released but the running version of Cryodex hasn't been updated for it, it just accepts the new card name (if the TO types in "Redbeard McShootington" as the pilot, more power to them).

Hopefully there's a Swing widget out there for this sort of thing. (Last time I wrote any Java UI stuff, it was with AWT, so...)

As requested by others, I'm planning on having a total print out of squad lists on match papers and the final tournament results. This will require me to have prolly an XML file of card ID, Display Name, and Cost. The idea of having IDs is only to allow for rapid input of squads. A series of numbers will be typed and then the user hits "ok" and it displays the list with cost so you can confirm that there were no errors. The slow way of having an autocomplete box is a good idea, but secondary. My goal is to get a version of this out as fast as possible then incremental versions making it better and better. I build my programs to be very easily updated and so making marginal updates (like new cards) is extremely fast. The problem of "but I didn't download the latest version before I went to my event" is something to be addressed.

My priorities...in order:

1) It has to be easy so people use it.

2) It has to be readable so it can be confirmed.

3) The output has to be useful (right now this is 99% for MajorJuggler and 1% for round sheets).

4) It has to be idiot proof. This lumps together old versions, players without their "squad code", bad typers, etc.

My 2 cents on an old argument... future proof is impossible, but the better you design your program can make dealing with the future much easier.

I think there are multiple issues going on here.

1. Representing squad data in a standard format that can be stored in a QR code
2. Inputting squad data manually at the time of the tournament

The problem is that if you want to fit it into a QR code, then you have to use encoding of some kind to make it reliably fit.

A practical example: it needs to work with 300 point (possibly 400 point) Epic squads.

"Bandit Squadron Pilot + Concussion Missiles; " is 45 characters. You can field 12 of those for 192 points, which takes 540 characters to represent. Some quick googling says that the rough limit for smart phones is ~400 bytes. You're already over that, and you still have 108 more points to fill in your squad, and some header info like version number and the player's name. The stereotypical software solution which I was trying to point out, and that you conveniently demonstrated, is to just throw more hardware at the problem. But that won't work because you're bandwidth limited.

You can't guarantee that if you print an epic squad verbose that it will be read correctly. So you absolutely need some kind of encoding scheme. Whether shorthand will suffice, or if it needs to be numeric is yet to be determined. The system needs to be reliable. The TOs already have enough of a hassle just running the event, you don't want to make it more difficult for them to use the tool, otherwise they're not going to use it.

And then we ALSO have the issue of TO's entering squad data. I have entered squads by hand, and will tell you that it takes a long time even if you are a fast typer. I don't see this happening very smoothly during registration unless you can easily scan a QR code in, and the data essentially automatically populates itself.

Ideally we want to make the TO-ing process easier, not harder. At the same time we also want to let the TO manually change squad details if he wants. I'm still just brainstorming. What we really need is a list of requirements going forward, for all the various pieces. (Squad builders, TO software, etc).

And the unfortunate part about all of this, is that FFG uses their own software for Nationals / Worlds! But maybe we could get them on-board eventually.

I'm still thinking about all of the above. In order of preference, players submit their squads by:

1. Coming to the event with a pre-printed squad, complete with QR code.
2. Players make their squad at the venue on the spot, and print it out, complete with QR code.
3. Players make their squad at the venue on the spot, and write it in by hand on a piece of paper.

If you are worried about compensation, you can always do a kickstarter to get some cash to do it.

I don't see QR codes as being any bit of difficulty from the perspective of converting an coded string into a visual thing that is readable by a camera. You can make anything into a QR code. The only limitation is the character limit which shouldn't occur unless we go for an obnoxiously verbose code which feels ridiculous when it is being output and ingested by a computer program.

I just can't accept having only a QR code being acceptable because not everyone will have QR code reading capabilities. That's why I think slamming out a quick comma separated number is acceptable.

If you are worried about compensation, you can always do a kickstarter to get some cash to do it.

I'm not worried about compensation and don't ever want this to be about that. A hardy thanks from the users is everything I need. My wife on occasion will say "are you even getting paid for this?" when she's agitated that the dishes are piling up or a diaper needs changed.

In the about section of the program I have my personal email which you can use to ask questions or if you feel so inclined, send me a donation via PayPal. I did have 1 person send me $10 and it was freaking awesome. It's never required, but I can say I listen to his opinion slightly more than anyone else, lol.

I don't see QR codes as being any bit of difficulty from the perspective of converting an coded string into a visual thing that is readable by a camera. You can make anything into a QR code. The only limitation is the character limit which shouldn't occur unless we go for an obnoxiously verbose code which feels ridiculous when it is being output and ingested by a computer program.

I just can't accept having only a QR code being acceptable because not everyone will have QR code reading capabilities. That's why I think slamming out a quick comma separated number is acceptable.

Duh. I just had an idea.

The squad builder prints out 2 additional things:

• QR code
• Text that is contained in the QR code

When you enter the squad details manually, then the Cryodex software can give you a quick confirmation screen of the squad that you just entered. So you can be sure that you didn't accidentally enter Mauler Mithel instead of Howlrunner, for example. The output here only needs to be the full verbose text.

Problem solved?

I don't see QR codes as being any bit of difficulty from the perspective of converting an coded string into a visual thing that is readable by a camera. You can make anything into a QR code. The only limitation is the character limit which shouldn't occur unless we go for an obnoxiously verbose code which feels ridiculous when it is being output and ingested by a computer program.

I just can't accept having only a QR code being acceptable because not everyone will have QR code reading capabilities. That's why I think slamming out a quick comma separated number is acceptable.

Duh. I just had an idea.

The squad builder prints out 2 additional things:

• QR code
• Text that is contained in the QR code

When you enter the squad details manually, then the Cryodex software can give you a quick confirmation screen of the squad that you just entered. So you can be sure that you didn't accidentally enter Mauler Mithel instead of Howlrunner, for example. The output here only needs to be the full verbose text.

Problem solved?

This is exactly what was in my head. I apologize if I did not make that clear.

I go on vacation to Las Vegas for one week and the whole community decides what I should be doing...

I guess I get some of the blam on the deciding what you should be doing. I'm a big fan of your software, haveing both used it for running events and playing in events that have used it. Although the events I run are less then 30 people I still run into some of the same issues larger events do.

The MOV proved to be a challenge when the players were filling out the match slips during nationals. It only took until round 3 where all the players were told to abandon doing the math themselves and to just put down the points destroyed by each player. The rest of the math was let. To the TO's. I'm sure this lead to the longer then expected lags between rounds. I have played in events that had 1200+ players and even there it was never longer then 10 mins between the last game that finished to the next round pairings. This is where the most help to events for X-Wing is needed. In both larger events I've played in I found the time between rounds to be way to long. The MOV will only help to contribute to this problem.

A match slip that looks like this will make the event both easier for the players and the TO. No long will the players have to break out a calculator to figure the match out. They could just simply mark the ships that were detroyed during the match and the software would do the math. This can only happen if the tournament software recognized each ship and upgrade as a point value. That is why I suggested the software have a builder in it.

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.

I go on vacation to Las Vegas for one week and the whole community decides what I should be doing...

I guess I get some of the blam on the deciding what you should be doing. I'm a big fan of your software, haveing both used it for running events and playing in events that have used it. Although the events I run are less then 30 people I still run into some of the same issues larger events do.

The MOV proved to be a challenge when the players were filling out the match slips during nationals. It only took until round 3 where all the players were told to abandon doing the math themselves and to just put down the points destroyed by each player. The rest of the math was let. To the TO's. I'm sure this lead to the longer then expected lags between rounds. I have played in events that had 1200+ players and even there it was never longer then 10 mins between the last game that finished to the next round pairings. This is where the most help to events for X-Wing is needed. In both larger events I've played in I found the time between rounds to be way to long. The MOV will only help to contribute to this problem.

A match slip that looks like this will make the event both easier for the players and the TO. No long will the players have to break out a calculator to figure the match out. They could just simply mark the ships that were detroyed during the match and the software would do the math. This can only happen if the tournament software recognized each ship and upgrade as a point value. That is why I suggested the software have a builder in it.

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.