On 3/5/2018 at 3:43 PM, Ardaedhel said:

Dice probability/damage modelling tool.

I hacked together something like this for my own use a while back here, but it's stale, unreliable, ugly, and not user-friendly.

@Akhrin's tool here.
@Undeadguy's here.
@rasproteus's SquidBot on the Discord does some.

These are all in various stages of roughness.

I should have just started with your script. It looks... professional. Comments? Really?

1 hour ago, rasproteus said:

I should have just started with your script. It looks... professional. Comments? Really?

Necessity. Scrub out all those comments and try working in that code, see how far you get.

If it'd been architected halfway competently (read: OOP), it wouldn't need all those comments. Instead, it started as an 8-liner and I just tacked **** on as it grew longer and more noodly.

I stalled out when I went to refactor it into something less terrible, so there it sits.

I've been working on a fleet builder app in React Native for several weeks now and glad I ran across this. Just found out about AFD as well. I am completely in support of a JSON standard for a fleet and I vote for only including the minimum necessary to reconstruct one in the backend. There really isn't any need to include more, and it preserves the option for those who desire to include more to do so without conflicting with what is needed.

I honestly believe the best way to avoid ambiguity and remove any sort of naming requirements is to officially assign every card a unique ID that is the value given in the export. This frees everyone to format and name their backend data however they like and they'll only need to conform to the list of ID's. I suggest one possible option of determining them as the SKU# where # is their place in alphabetical order for their expansion starting with 0. An ID isn't needed for human readability but for data linking, and the suggested method can easily be automated after entering the name using a simple sort and outputting id = SKU + index. I don't have ID's in my data yet so I'm not attached to any method of generating them yet.

// Javascript
{
  objectives: [...],
  ships: [
    {
      id: "id",
      upgrades: ["id", "id", "id", "id"]
    }
  ],
  squadrons: [...]
}
              
// I just wrote this off the top of my head
// without any testing so there may be errors
generateListFromID = (ListOfID) => {
  return ListOfID.map(item => {
    // depending on how you set up your backend
    const index = backend.findIndex(id =>
      backend.id === id)
    return (index > -1 ? backend[index] : {})
   })           
}

const objectives = generateListFromID(fleet.objectives)
const ships = fleet.ships.map(item => {
  return {
           ship: generateListFromID([item.id]), // unsure if adding [] is necessary
           upgrades: generateListFromID(item.upgrades)
         }
})
const squadrons = generateListFromID(fleet.squadrons)

I'm also curious what other people's backend data format is. I'll post what mine is like in the next couple days when I have the time. I'm also about to start scanning all my cards. I'm a bit picky about having uniformity in the image processing, dpi, and all that so I prefer to do it all myself. Assuming it doesn't break any sort of copyright I'm happy to provide them to the cause when I finish.

Finally, can anyone enlighten me about the apparent copyright issues with Armada apps? X-wing seems to be fine but Armada isn't, or was AFD removed for other reasons?

bump

@rasproteus @Green Knight

X-wing has a system for this.

Suggestion: reuse.

Should make it easier to base code on X-wing java custom classes.

Shrug.

Hey folks, glad to find this thread! I've started playing with some projects, so wanted to share here in case they can be made useful for others. In particular, I'd love to hear what problems y'all app devs have today around data interchange. Lots of good historical discussion here, but it's more than a year old at this point

Here's what I am working on, all on GitHub:

- star-wars-armada-data: Static JSON files for all the cards, with a schema similar to the X-wing data I found here: https://github.com/guidokessels/xwing-data. Also includes some card and icon images. Based on jmthompson2015's work--I just made a couple extensions (e.g., errata and multiple modifications), and added Wave 8 and RitR.

- armada-fleet-list-parser: Turn the text export from popular list-builders into a common JSON format. Works with Kingston's, Warlords, Flagship, AFD, and the iOS/Android Armada Fleet Builder. The output is JSON for a fleet list, specifically geared toward the data needed to represent the fleet in a printable form for tournaments. A JavaScript/Node module.

These are both far from complete. For example, even my own parser lib is not yet totally aligned with the schema in star-wars-armada-data, and I haven't tested an extensive set of exported fleets from all the list-builders.

I can guess that some of the outstanding issues for apps in general might be:

- Updating apps quickly once new cards come out. Adopting a common static data source may help speed this up. APIs are great, but the card data set is small enough and changes infrequently enough that we can just ship the whole thing around, in particular for mobile apps.

- Fleet import/export from one app to another. Rather than ask everyone to agree on an export format, armada-fleet-list-parser would let any app import from all the other apps using whatever format they're exporting today.

- Unique identifiers for cards, in particular those with the same name but different upgrade slots (e.g., Darth Vader). Contenders for solutions appear to be a composite string key using the upgrade slots, or using the SKU name, or a per-vendor UID.

18 hours ago, ralphbod said:

Hey folks, glad to find this thread! I've started playing with some projects, so wanted to share here in case they can be made useful for others. In particular, I'd love to hear what problems y'all app devs have today around data interchange. Lots of good historical discussion here, but it's more than a year old at this point

Here's what I am working on, all on GitHub:

- star-wars-armada-data: Static JSON files for all the cards, with a schema similar to the X-wing data I found here: https://github.com/guidokessels/xwing-data. Also includes some card and icon images. Based on jmthompson2015's work--I just made a couple extensions (e.g., errata and multiple modifications), and added Wave 8 and RitR.

- armada-fleet-list-parser: Turn the text export from popular list-builders into a common JSON format. Works with Kingston's, Warlords, Flagship, AFD, and the iOS/Android Armada Fleet Builder. The output is JSON for a fleet list, specifically geared toward the data needed to represent the fleet in a printable form for tournaments. A JavaScript/Node module.

These are both far from complete. For example, even my own parser lib is not yet totally aligned with the schema in star-wars-armada-data, and I haven't tested an extensive set of exported fleets from all the list-builders.

I can guess that some of the outstanding issues for apps in general might be:

- Updating apps quickly once new cards come out. Adopting a common static data source may help speed this up. APIs are great, but the card data set is small enough and changes infrequently enough that we can just ship the whole thing around, in particular for mobile apps.

- Fleet import/export from one app to another. Rather than ask everyone to agree on an export format, armada-fleet-list-parser would let any app import from all the other apps using whatever format they're exporting today.

- Unique identifiers for cards, in particular those with the same name but different upgrade slots (e.g., Darth Vader). Contenders for solutions appear to be a composite string key using the upgrade slots, or using the SKU name, or a per-vendor UID.

Sounds awesome, haven't looked at the detail yet but feels like there's potential to integrate some of this with @Truthiness' data project spreadsheets, might make data collection easier for events where folk provide links to online builders (or even some kind of OCR of printouts?) and extraction of the lists entered into it?

12 minutes ago, Akhrin said:

Sounds awesome, haven't looked at the detail yet but feels like there's potential to integrate some of this with @Truthiness' data project spreadsheets, might make data collection easier for events where folk provide links to online builders (or even some kind of OCR of printouts?) and extraction of the lists entered into it?

That's the kind of thing that would be awesome to integrate into an online registration tool for tournaments; "Your fleet list is due 48 hours before the start of the tournament; you may submit it by either copy/paste of your fleet, or a link to it from within one if the following fleet-builder apps."

Lets the organizers more easily verify what people are bringing for their fleets, that they're flying what their sheet says, etc. I assume it might speed up set-up on the morning of the event. Have pre-generated lists of the first matchups of the day.

Thanks! I had a similar thought... but learned in brief chat with @Truthiness that most of the data he gets is photos of lists, some handwritten. I tried some existing OCR libraries but have had little luck so far with recognizing even printed lists. Maybe someone who has more fluency with that sort of problem could help?

I believe it would take a change in how TOs do things to make electronic data collection easier. Maybe if there were an incentive for players to submit lists electronically?

9 minutes ago, ralphbod said:

I believe it would take a change in how TOs do things to make electronic data collection easier. Maybe if there were an incentive for players to submit lists electronically?

I reckon you need to really work with the individual events (unless you or Truthiness wanted to hold a raffle for people who submit lists, as an incentive) because for the most part each one is individually run, operated, etc. there's no standard way of doing things at all - including getting lists, verifying them (if done at all), etc.

That's why I'd suggest tailoring work like this into something that helps the organizers of an event *organize* it. Registration tools, Swiss-matching tools, ability to pre-plan how many table you need for an event. These are the kinds of things where helping people do things helps the community by both making it easier to host events (hopefully meaning more events get hosted, on local levels, etc) and making the running of events more systematized, making it easier to look at events, compare events, go to events, etc.

FYI: I updated the JSON card data archive to version 1.8.1 for the latest FAQ (just two card errata): https://github.com/rkbodenner/star-wars-armada-data

On 2/19/2020 at 12:11 PM, Benmartin said:

That's the kind of thing that would be awesome to integrate into an online registration tool for tournaments; "Your fleet list is due 48 hours before the start of the tournament; you may submit it by either copy/paste of your fleet, or a link to it from within one if the following fleet-builder apps."

Lets the organizers more easily verify what people are bringing for their fleets, that they're flying what their sheet says, etc. I assume it might speed up set-up on the morning of the event. Have pre-generated lists of the first matchups of the day.

I know a lot of players, even at high levels, do not have fleets chosen even the morning of tournaments at breakfast. You are also making assumptions (generally applicable but not universally true assumptions) about regular access to Internet tools to make this work.

As someone who has TO’d a Regional/Prime by himself and been an aide at other similar events, the assumptions that it will speed up round 1 pairings is absolutely not true. People will not show up on no notice whatsoever, and same for walk-ins. Even 1 of either requires at least an edit of the tournament software for round 1 pairings. This remains true even at large events like Regionals/Primes. If I’m printing off lists to check, that’s more printing I have to do in a central locations rather than allowing the players to deal with it, or if it’s electronic it’s another network connection that must work. Are these possible? Absolutely. They are not sure-fire things though.

That is my experienced intended user critique of this idea. Use it as you will.

You're describing the state of things as they are now. My question is - can it be better?

I'll be honest, for most events (10, 15, 20 people show up), the gains might be pretty marginal. On that I agree with your overall point. But I do have a couple more specific thoughts:

2 hours ago, GiledPallaeon said:

You are also making assumptions (generally applicable but not universally true assumptions) about regular access to Internet tools to make this work.

If I’m printing off lists to check, that’s more printing I have to do in a central locations rather than allowing the players to deal with it, or if it’s electronic it’s another network connection that must work. Are these possible? Absolutely. They are not sure-fire things though.

What I'm suggesting things that are in no way abnormal for sporting and gaming events worldwide, in a large variety of types of competition.

2 hours ago, GiledPallaeon said:

the assumptions that it will speed up round 1 pairings is absolutely not true. People will not show up on no notice whatsoever, and same for walk-ins. Even 1 of either requires at least an edit of the tournament software for round 1 pairings. This remains true even at large events like Regionals/Primes.

I disagree. Software (generally) makes it easier than by hand. What are you using now to build pairings?

I was the tournament director for what was at one point the largest competitive 'Historical Fencing' event in the world. http://www.fightlongpoint.com/ We had walk-ins, we had drop-outs, we changed the competition pools on the fly. I did it using Excel. Better tools are possible. I printed off the pairings sheets each time I changed the parings - printing isn't the important part; having the ability to inform the competitors of changes in the plan is.

We checked the gear of every competitor before they could compete. Checking an Armada list could be as simple as sitting there with a cell-phone and asking each competitor to arrive that day with a link ready to show you their saved list in an approved fleet-builder program. Better if they send it in early (with their registration a week before), but it doesn't strike me as actually that arduous.

2 hours ago, GiledPallaeon said:

I know a lot of players, even at high levels, do not have fleets chosen even the morning of tournaments at breakfast.

The player base I've dealt/worked with for that is not all that different from what I see here - maybe, though by no means definitively, slightly more athletic geeks - but we're all doing hobbies well within the realm of niche/nerd... Implementing some of these things absolutely requires the player-base to buy-in to using the system for a given event. My point is that it's been done before - it's not -that- crazy a thought.

Implementing something like this *may* mean a little more work for the organizers. But the pay-off can be smoother events, more fun for everyone day-of. If we're talking about software particularly, the point of writing it is that you get some gain - either ease of use for the organizers, or more utility and making better events. For example, if the lists had been previewed for the Portland, Oregon Prime recently, would the minor mistake in the (eventual winner's) list have been caught, and corrected, before playing the games? Would that have been worth it, or is 'good enough' good enough?

I am glad to see this thread!

I need to read all this before anything else.

21 hours ago, Benmartin said:

You're describing the state of things as they are now. My question is - can it be better?

I know your question is whether or not things can be better. I am describing things as they are to make the point that the margins are either exactly that, marginal, or unachievable period.

I'll be honest, for most events (10, 15, 20 people show up), the gains might be pretty marginal. On that I agree with your overall point. But I do have a couple more specific thoughts:

I’m going to take this a step further: only on the largest events will you see real gains where you aren’t adding PITA for someone, and those are all typically run by someone (or rarely a couple someone’s) who have well established personal systems you will be hard pressed to replace.

What I'm suggesting things that are in no way abnormal for sporting and gaming events worldwide, in a large variety of types of competition.

Yup, I know that. That doesn’t mean that what we already have isn’t a perfectly reasonable setup.

I disagree. Software (generally) makes it easier than by hand. What are you using now to build pairings?

I do use software right now, everyone does. Swiss by hand is easy for four or five people. Past eight to ten the vast majority of people can’t do it in their head, and paper gets messy.

Specifically I use TOME, as do most since Cryodex went and got buggy.

I was the tournament director for what was at one point the largest competitive 'Historical Fencing' event in the world. http://www.fightlongpoint.com/ We had walk-ins, we had drop-outs, we changed the competition pools on the fly. I did it using Excel. Better tools are possible. I printed off the pairings sheets each time I changed the parings - printing isn't the important part; having the ability to inform the competitors of changes in the plan is.

Again, you missed my point. What is the point of pre-setting these entries when I will have the time to do it day of, and not have to worry about checking who did or did not show up from the preset list, instead of dealing with whatever is happening at that moment? I don’t see where I as the TO have gained anything here.

Obviously I can reprint pairings, and I can reset the pairings an infinite* number of times before I print them, but that does not reduce the amount of interaction I have to have with the software to verify who has or hasn’t shown up with what.

We checked the gear of every competitor before they could compete. Checking an Armada list could be as simple as sitting there with a cell-phone and asking each competitor to arrive that day with a link ready to show you their saved list in an approved fleet-builder program. Better if they send it in early (with their registration a week before), but it doesn't strike me as actually that arduous.

If you’re willing to build a widget or an app where I can have every player walk into a tournament, scan something that automatically enters them into the pairing software, and checks their list for tournament legality, and then you are able to distribute that app or that universally standard output to every fleet-builder used by every player, I will gladly use it. In the meantime, I will continue to use the paper/keyboard/TO combo that has worked to date.

The player base I've dealt/worked with for that is not all that different from what I see here - maybe, though by no means definitively, slightly more athletic geeks - but we're all doing hobbies well within the realm of niche/nerd... Implementing some of these things absolutely requires the player-base to buy-in to using the system for a given event. My point is that it's been done before - it's not -that- crazy a thought.

This is i think our primary disagreement: you are much more optimistic about buy-in than I am. The Armada community is quite laid back. Part of that is that we are lazy, usually in a good way. However, in this case, it will combine with stubbornly formed habits (also a pretty widespread Armada trait) to create resistance to this implementation.

Pre-empting your reply, I am well aware that the above traits are in no way unique to the Armada community. However, they are present, and they will present issues for someone trying to implement in a community as small and as casual as Armada.

Implementing something like this *may* mean a little more work for the organizers. But the pay-off can be smoother events, more fun for everyone day-of. If we're talking about software particularly, the point of writing it is that you get some gain - either ease of use for the organizers, or more utility and making better events. For example, if the lists had been previewed for the Portland, Oregon Prime recently, would the minor mistake in the (eventual winner's) list have been caught, and corrected, before playing the games? Would that have been worth it, or is 'good enough' good enough?

I have absolutely no doubt that it isn’t a May, it’s a Will. If more events were hitting major snags that weren’t just specific organizers with alternative priorities, and if events were not running perfectly smoothly under dedicated people as it is, I would be more interested. I don’t foresee either ease of use or utility significantly outstripping the current systems, so I am inclined to advise against the effort.

Apologies if for some reason I come off as hostile or otherwise unwelcoming. It is not my intent, merely direct and actionable feedback. As it is, I don’t see the need, and I doubt the community will either, making implementation challenging at best. However, I greatly appreciate the effort and thought put into it, and if you continue with it, I’ll be more than happy to help test and refine it.

11 hours ago, GiledPallaeon said:

Apologies if for some reason I come off as hostile or otherwise unwelcoming.

Not at all.

I will say that for a person who tends to really want to jump in and help, it's a bit weird to be told "No, we don't actually want help", when things are so obviously being run on shoestrings and so few people's significant and obvious efforts...

11 hours ago, GiledPallaeon said:

stubbornly formed habits (also a pretty widespread Armada trait) to create resistance to this implementation.

...but I totally get this. Working within the constraints of community standards is actually a significant part of designing a good system (as opposed to one that nobody ends up wanting to use).

Having said that, if something gets designed that organizers like and want to use, generally my experience is that the player-base will adapt - you are the guys putting in the work, and you are leaders of the community, and if an event is being run a certain way, the players can conform or DIE run their own event the way they want.

12 hours ago, GiledPallaeon said:

something that automatically enters them into the pairing software, and checks their list for tournament legality, and then you are able to distribute that app or that universally standard output to every fleet-builder used by every player

That's pretty much exactly in-line with what I was pondering.

I was, for example, able to create a parsing of any list into its components from the text-output that each fleet builder is able to do (still probably needs some work) https://docs.google.com/spreadsheets/d/1-IQD6GJIuxthRH-dY7aVzqInClKj64rTN0rlGP1JRqg/edit?usp=sharing and that's a different thing, but it shows that if you can find/figure out each fleet builider's API, it should be possible. I don't know how close that is to what @ralphbod was/is working on - programming an app is above my level...

1 hour ago, Benmartin said:

you are the guys putting in the work, and you are leaders of the community, and if an event is being run a certain way, the players can conform or DIE run their own event the way they want

*Cackles approvingly*

Oh man I love this discussion. I’ve been thinking that it may be more work than would pay off to try to make TOs’ jobs easier. Thanks @GiledPallaeon for so clearly laying out reasons this could be the case. Other TOs I’ve talked to have had similar points of view. I’m a product manager at a software company by day, so I understand well that software is terrible and there’s hardly ever a good reason to use it I’m only joking a little.

I still hold out some hope that something could be done that’s worth the effort. I personally want to see data to back up discussions on what fleets/cards are doing well, and that data comes from tournaments. Maybe TOs aren’t even the right people to collect data from.

@Benmartin Your spreadsheet sounds great. It does a similar thing to my code that parses all the fleet builders’ output into one common format. But in a way that’s consumable by any software tool. I don’t see a need to build yet another app, since there are fleet builders and things like TOME. This library could just plug in to those things. It wasn’t much work to build and fun to do it, so that effort was worth it just for my own self

17 minutes ago, ralphbod said:

I personally want to see data to back up discussions on what fleets/cards are doing well, and that data comes from tournaments. Maybe TOs aren’t even the right people to collect data from.

Speaking again as a dude who's run events - I don't know who would be better from whom to collect. I certainly don't trust the players to do it

That's why my suggestion was to try and work with TO's...

22 minutes ago, ralphbod said:

Your spreadsheet sounds great. It does a similar thing to my code that parses all the fleet builders’ output into one common format. But in a way that’s consumable by any software tool.

I'll be honest - I've never really been able to really get how to use things on GitHub - download it, compile somehow, and there's a program there? I design ships for a living; I just use software (I learned to code FORTRAN once upon a time)... Excel on the other hand I can do...

How much harder would it be to get your work to be able to take a shared link from one of the builder apps and output the common format? Is that already within the operational bounds?

17 minutes ago, ralphbod said:

I don’t see a need to build yet another app, since there are fleet builders and things like TOME. This library could just plug in to those things.

I wonder.... I assume TOME will no longer be supported as FFG cut their software development group at the beginning of the year?

Certainly it would take some significant work to get something that could replace it - it looks good and works smoothly. I hadn't seen it prior to today.

Would it be worth asking FFG if the TOME source can be opened up to users, to be able to add functionalities along the lines of what's been discussed here - pulling list parsing at an event into the program so it doesn't need to be done by hand separately? (I mean, I'd be surprised if they said yes, but....)

18 minutes ago, Benmartin said:

Speaking again as a dude who's run events - I don't know who would be better from whom to collect. I certainly don't trust the players to do it

That's why my suggestion was to try and work with TO's...

TOs are absolutely the right people. There's nobody else who collects and checks all lists at a prime level event. It's a key part of why they're there.

On 3/5/2020 at 10:54 AM, Benmartin said:

Not at all.

I will say that for a person who tends to really want to jump in and help, it's a bit weird to be told "No, we don't actually want help", when things are so obviously being run on shoestrings and so few people's significant and obvious efforts...

...but I totally get this. Working within the constraints of community standards is actually a significant part of designing a good system (as opposed to one that nobody ends up wanting to use).

Having said that, if something gets designed that organizers like and want to use, generally my experience is that the player-base will adapt - you are the guys putting in the work, and you are leaders of the community, and if an event is being run a certain way, the players can conform or DIE run their own event the way they want.

It's not that I don't want help. It's that I know the system I have works, and I have no idea how long it would take for yours to work, and how many events that would effect. If I'm running them in parallel until the bugs are sorted, I'm easily doubling my workload until I trust the new system.

By all means, pursue the project. I am more than happy to help beta or alpha test it (I know those go in the other order). But I want you to be aware of what you're signing up to deal with.

On 3/5/2020 at 10:54 AM, Benmartin said:

That's pretty much exactly in-line with what I was pondering.

I was, for example, able to create a parsing of any list into its components from the text-output that each fleet builder is able to do (still probably needs some work) https://docs.google.com/spreadsheets/d/1-IQD6GJIuxthRH-dY7aVzqInClKj64rTN0rlGP1JRqg/edit?usp=sharing and that's a different thing, but it shows that if you can find/figure out each fleet builider's API, it should be possible. I don't know how close that is to what @ralphbod was/is working on - programming an app is above my level...

@Ardaedhel

@Benmartin you wouldn't happen to know anything about website development would you?

11 hours ago, GiledPallaeon said:

@Benmartin you wouldn't happen to know anything about website development would you?

I know just enough about it to understand the interactions of back-end vs. front-end, how a database interacts with a GUI on the theoretical level, etc... I've never done my own coding though. If I had no kids and fewer hobbies, I would have done.

18 hours ago, Benmartin said:

If I had no kids and fewer hobbies, I would have done.

Preach.