I’ve reached a milestone with the S.A.D.I. Discord bot, so its development is going on hold for the remainder of the year.

Database Woes

I ended up spending too much time fiddling with the database construct so I kicked it all to the curb. Although it’s “good on paper” to have database operations run asynchronously, having to deal with a chain of async operations when making decisions is in and of itself a hell whether it’s via promises or via callbacks. In the end, the data I was storing in the database was ancillary to what I really considered to be the core functionality of the bot, and I am still unsure if I want to expand functionality to push deeper into corporate integration.

File Fixing

Instead of using the database, I have opted to rely on data files. One reason for approaching the database was so that I could download and “massage” data from the Star Citizen API. Although the purpose of an API is to pull data on demand without having to maintain a local data store, I never really liked the idea of having to “reach out” for all of the data I might need to achieve a goal. Instead, having the data local in some form was a much better prospect for me.

Now, the bot downloads a full manifest of data from the API for ships, star systems, and objects within those star systems. I extract only the properties that I need for display and create some local “master files” in a flattened format. For ships, this is pretty straightforward but systems required a merge of three different feeds: systems, “tunnels” (jumpgate paths), and objects that could be found in those systems. The last feed was a bit of a headache to merge because I had to translate the foreign keys (format, not linguistically) in order to make associations, deal with a nested structure, and parse out duplicate records. Now, I can load and query the data file quickly and easily. At the end of this process, I had to create a method that occasionally pings the API for refreshed data (in terms of days, not minutes or hours), but I feel better knowing that I’m not adding to the API traffic every time someone performs a query.

Queries

Users can query for ships, star systems, and objects within a star system. In order to gain flexibility, I opted to use a “switch” system which will be familiar to anyone who has worked with a command line.

!sadi -n [SHIP NAME]        //Query ships
!sadi -s [SYSTEM NAME]      //Query star systems
!sadi -s -o [SYSTEM NAME]   //Query system for list of objects
!sadi -o [OBJECT NAME]      //Query objects

-n (name) will allow users to query for a ship. They can either query a model or variant (Mustang, Taurus, etc) or use quotes to query for a proper name (“Constellation Aquila”, “Aurora ES”). Queries are case insensitive, but I am not. If your query returns multiple results, you’ll get a list of variants (currently misspelled, natch) which you can examine to discern a more specific query criterion.

-s queries systems. There are a surprising number of systems in the data feed, despite the fact that we only have Stanton currently available and Pyro (at least) waiting in the wings. Right now you have to know about a system to query it by name, although once you query system you will receive a list of jumpgates in that system, and where they lead. You will also get a count of the objects in that system with a reminder on how to frame a query to get a list of those objects.

-s -o is what you’d use to get that list of objects. Objects in the feed are categorized by type and classification, some of which make sense and some are “Huh. OK” moments.

-o will get more detailed information on a specific object. This doesn’t need you to specify any particular system; once you know the name of the object, you can query for it.

Obviously some of the presentations are lacking. I don’t have data on the “price” of ships, for example, although I’ve seen SC bots out there which have it (I suspect it’s from another API feed). Ships and systems have images, but objects do not. Also, there’s a specific operational thread that must be followed to discover some of the data, and the querying isn’t always as “fuzzy” as I’d like it to be. Right now, searching for mustang will present the first (and always the same) Mustang variant, but shows a list of other variants that you must query manually; Ideally, I’d like to offer a reaction-based control panel which would allow users to scroll through matches to their query, but that’s a Discord Bot 200 level course. It was more important to me to get this basic yet informative functionality out the door.

What’s Next?

I could leave things at this and be content. Just content. S.A.D.I. is currently in operation on a small Discord server I operate where we have a few Star Citizen players. Although I don’t plan on offering this implementation to the public, I might point to the Github repo or the repl.it source for those interested in trying it out or forking it for their own purposes.

The original plan was to use the bot as a “human resources” fulcrum, registering users on a Discord server with a data store that could be coded against when creating a corporate presence website. This would allow users and administrators to define and work with member rolls, schedule events, and manage their fleets either through the site or through the Discord, and have those constructs available in both. With the demise of the database approach, though, I’m not sure that I’ll be getting that far. Also, since I do not run a corporation, nor do I have concrete plans to host this for others, I don’t know if there’s a point in going forward with this plan. I guess if I am bored, I might take a stab at it.