FoaS

Members
  • Content count

    990
  • Joined

  • Last visited

About FoaS

  • Rank
    Member
  • Birthday

Contact Methods

  • Website URL
    http://www.kdyards.com

Profile Information

  • Location
    Central NJ

Recent Profile Visitors

524 profile views
  1. Office is down because of power outage so I got sent home for the day. Found out how to parse and validate SVG files server-side, so now I KDY2 will properly support user-added icons for things like keywords or upgrade types.
  2. Woe be the ship I get 4 raid tokens on.
  3. Listening to the new episode now. I actually nearly fell out of my chair at Ackbar's armada advice.
  4. They are game changers. It's changed the game. Literally. Without knowing how long the last or if there is any mechanism to remove them (or if there even IS a way to remove them) we won't know how much they are going to shake things up.
  5. Work continues on the API. I'm finding it difficult to really design the endpoints, though. Taking, for example, the Genre collection and resource. For those of you who are familiar with web APIs using HTTP requests (think RESTful), this is what I mean: let's say I have two endpoints for genres: get api.kdyards.com/v1/swa/genres/ get api.kduards.com/v1/swa/genres/{someId} Should the first one, the collection of genres, just return an array of IDs, or should it return an array of trimmed down objects that describe the genre? If I go for an array of just IDs, that means that people will need to query each individual resource to get any kind of useful information to display a genre, such as it's name, it's canocity, etc - which means lots of queries - one for each ID returned from the collection, plus getting the collection itself. If I go for the idea that the collection endpoint returns an array of objects that describes the genre in some detail, then the {someId} endpoint becomes redundant. It's not like there is a large amount of data for a genre that would be included on the resource that isn't in a detailed collection. (granted, this isn't always the case. for example: if you GET api.kdyards.com/v1/swa/ships/ you won't know ever ship's speed chart from that collection, but you'd get it's name, it's id, and so on. I guess I should go for the semi-detailed collection, just to make queries a lot easier.
  6. Got the account site pretty much developed, just need to hand it off to my buddy for QA. Now on the API itself.
  7. Amazon reports that it will be available March 20th. I expect that local stores will have it several weeks sooner than this, if that date is accurate. Truthfully, I anticipate "on the boat" within two weeks and release six weeks after that.
  8. Indeed it is... I still hope that's not the final thing, because that's going to wreak havoc with KDY's current database schema. I think I'm going to wait until I see what the back of the card looks like before I plan around including the specific aurabesh icon, or they might change it by release.
  9. I'm really curious about the Exodus Fleet card. That's an odd upgrade type icon.
  10. Mark me under the "Separate Faction" category as far as desires go, but for myself, I intend to use them as a campaign item instead. Same goes for New Republic and First Order as well.
  11. Very interested in that faction wheel. Let me know if anyone digs it up?
  12. I'm almost done writing the account management and developer's portal. Application makers will be able to hook into the API (if they get a key, of course) in an anonymous state, much like browsing the site as it exists now. However, if you allow users to log in and get an access token for them from the API, they will enable that user to access their private content through the app. However, an application will not be able to register a new user directly. They will instead need to have the user register on the KDY Account Management site (I hope to streamline this as much as possible) and that user will need to grant access to that application within their account. A user will be able to set an application-specific password for each app that they grant access to, and revoke the permissions at any time they so wish. But, again, this only really applies to people who want to make use of elevated features of the API. Once you have an API Key you'll be able to browse public data to your heart's content. Edit: Also exciting news. Tabletop Simulator now supports HTTP requests in scripting, so I'll be able to revisit my efforts to make the TTS integration an actual thing.
  13. Finally laying out the spec and scaffolding for the API. To be honest, I have no idea what I'm doing except making DB queries to the MySQL database backing everything and outputting JSON in the response header. I have a couple questions for those who may have had experience with such things: - Is it better to use the HTTP Response Codes as my error codes or can I get away with just inserting error codes and messages into the response? - Should I have users send the API Key (and user token if the endpoint requires elevated user status) in the header or in the URI? - How common is it to send Warning messages in the response body. For example, if it turns out that I'm going to deprecate a method, should I send warning messages in the response, or should I just rely on people to watch the blog on the Developer site (once that gets put up)?
  14. Thanks! Wait until you see version two. You'll be able to design how you design cards. The page size is, I think, the smaller of either in each dimension, so it should fit on both.
  15. Today on things I hate in the current KDY user interface: I absolutely loathe that I did this. Whilst it's fairly intuitive, it's not exactly the most extensible thing I've ever made. Since people will be able to add their own defense tokens, how do I make it so that people can find their own content, or someone else's content easily? Introducing the Picker. I know people don't generally like modal dialogues, but this is really a very good case use for them. Imagine that you'll be able to click on "edit defense tokens" and you'll get a dialogue that lists out the available tokens. Not only that, but you can filter in or out types of tokens, like Official, Community-endorsed, those that you yourself have made, or even ones that you have chosen to be your favorites. Plus a search box so you can filter by defense token names. Once you click "Apply" it will update the list on the ship edit page and close the modal dialogue. I feel like a lot of things will be making use of this, from Dice to Faction selectors, and so on.