My light-hearted observation as an alliance leader is that EVE is 50% in-game, 50% discord, and 50% Google Sheets. The idea is to create a solution for organizing my online gaming community that meets my users where they are: Discord and Google Sheets.

Getting the discord part, with its support for bots, has come naturally. But what’s often missed is an integration between Sheets and Discord. For example, editing data through Discord usually means it is no longer easily accessible, or up-to-date in sheets as the tendency is to move it to a database. Granted that has a lot of advantages and seems like the obvious thing to do, but it does have two main trade-offs that I think should give people pause:

• Adding back the bulk CRUD operations that come easily in sheets once you’ve moved to SQL or another DB is added work and time.
• Google Sheets requires no maintenance and is free. This reduces my time spent as it/dev ops for my community.
• Everyone knows how to use sheets and build on them. It is easily extensible, and once again this requires no work or time from me.

So with that in mind, the solution that I’ve been prototyping for managing my alliance, corporation, and pilots in the game uses Google Sheets as as the primary user interface. That means that it is also a primary store of data. The goal is for both Discord and Google Sheets to allow for the writing of data, though it doesn’t mean they need to have all the same features.

What follows is a walkthrough starting with scenarios that lead to the why and how of implementing an MVP of managing my EVE community’s data via Discord and Google Sheets.

Scenarios

These are the scenarios that must be supported for this solution to fit my needs:

• Bulk Update from Google Sheets by admins.
• Updates of individual rows by discord users via discord commands
• Invidiaul users can update their corp, clone, or otherwise a row of data from Discord via a command.
• Enable some users to perform analytics over the data.

Requirements and Constraints

• The data set is small. It can fit in memory with no chance of ever growing beyond that.
• The expected peak requests per second are fractional. But let’s go with 10 to leave a lot of headroom.
• Latency is important, but to a point. I want to avoid incidental latency from bad choices, but I won’t go so far as to write the whole thing in C++ or deploy it to multiple regions.
• Durability: If an update comes from Discord, it should not be lost on crash. There may, however, be a caveat here for conflict resolution to still roll back the update.

Design

I’ll start by incrementally building the solution by adding the requirements one at a time, while minimizing the amount of work, and then see how it compares to a basic crud app.

Starting with just the requirement for discord users, we can start with a basic process and a store. Two boxes and a line, I won’t draw that. I will say that something like SQLite is enough for the store in this case, as it can be in process. And worth repeating that the entire data set can be held in memory.

Next, we add the requirement to bulk update and analyze data. Again, we can use a basic design here, with the store being any that persists beyond the discord bot, like a SQL instance, Cosmos, or a k/v store (none of the requirements have constrained that implementation yet). But, to keep the work to a minimum, and because I want to try it, we’re going to make the backend store a Google sheet. This gives us an admin view, authorization, and bulk edit, all for free. We can also do analytics over the sheet using… other sheets. And, if we update the sheet live, all that propagates as well.

How does this affect latency and other details?

• One, I’m going to assume, (though I have not tested it), that Google Sheets does add more latency than the other options, especially on read.  
• Two, Google Sheets has no atomic updates using optimistic concurrency. It has no etags in its API.

We’ll deal with two much later. But with one, we’re going add a second store to handle read/writes, and then sync them to sheets.

So, what have we arrived at? If you imagine a basic CRUD app, we’ve removed the (likely) js front end, replaced it with sheets, and added a sync to the primary store to compensate. Both arrangements have an additional Discord bot client to handle the Discord aspects. The bet is that using sheets but having the sync is cheaper in development and maintenance than a js front end. I’ve left the implementation of the store open-ended until the next section.

A diagram of the result, with some additional details of the interactions:

graph LR;
 User --Slash commands--> Discord
 Discord --API Gateway-->DiscordBot;
 DiscordBot--Discord Client-->Discord;
 DiscordBot <--??-->Store;
 GoogleSheets <--sync--> Store;
 Admin <--⌨️,👀--> GoogleSheets
 Admin --Slash commands--> Discord

An update from Discord, to show that updates to Google Sheets are eventually consistent, not atomic.

sequenceDiagram
 Discord User->>Discord Bot: Update Corp
 Discord Bot<<->>Data Store: Update
 Discord Bot->>Discord User: Update Complete
 Data Store<<->>Google Sheets: Sync

We have potentially created an issue. We’ve traded off consistency for reduced latency. It is now possible to temporarily see different results in sheets than in Discord until the sync happens. It is also possible, without a lot more work,  to create conflicts if both are updated simultaneously.

For the moment, I’m going to say that this is ok. I say this given the context of the small number of users, and the available resources (that is to say: none), and that the users themselves can easily fix any issues that come up from conflicts. The next step is still to create an MVP and see if this is a problem at all in this context. If this is for a Fortune 500 company with a well-funded dev team, my answer would be very different. And that’s the point.

MVP

For the MVP, the thing I choose to focus on is my admin users and getting the correct data in bulk. That means: Discord is read-only to start with. This avoids needing a sync, for the moment. However, to choose the store I do need to plan ahead.

For the choice of the store: It looks a lot like a cache. So Redis is an option. It can also be an SQL instance. Revisiting the requirements: durability is important here, and it needs to sync updates back to the Google Sheets store. With that in mind, I came up with two options that kept the maintenance down by avoiding standing up a Redis cluster or SQL instance:

1) The process running the DiscordBot uses Raft.Next consensus to build an in-memory distributed K/V store. https://dotnet.github.io/dotNext/features/cluster/raft.html. Ensures availability, and that no updates are lost (assuming multiple nodes)

2) Cosmos. Free for this scale, and has a change feed processor to ensure all updates are eventually processed. And this almost certainly uses a consensus algorithm, like Raft, under the hood (as does SQL in replication scenarios).

I got fairly far with 1), but decided that if I ever wanted anyone to help me 2) is the more maintainable option. Finally, the sync from sheets to cosmos, for the MVP, is triggered via discord command. So for the MVP we have:

graph LR;
 User --Slash commands, read-only--> Discord
 Discord --API Gateway-->DiscordBot;
 GoogleSheets -.Via Bot.-> Cosmos
 DiscordBot--Discord Client-->Discord;
 DiscordBot <--Cosmos client-->Cosmos;
 DiscordBot <--Sheets client-->GoogleSheets;    
 Admin <--⌨️,👀--> GoogleSheets
 Admin --Slash commands, read-only--> Discord    

I will end here for now. The next updates will be about what this MVP showed, and iterating the design from there.

Disclaimer:

Not generated using AI. Edited with the help of Grammarly.

Acknowledgment

Mermaid integration achieved with help from: https://jackgruber.github.io/2021-05-09-Embed-Mermaid-in-Jekyll-without-plugin/ and https://mermaid.js.org/config/usage.html#simple-full-example

Rivals is a Command and Conquer game for mobile that came out a few years ago. I’m going to skip right past discussing that as a concept. It does have a tight-knit community of players. Rivals was the first game I really used Discord for interacting with other players. Thanks to Davo (another member of the Rivals community) it also became the first scenario I ended up writing a Discord bot for. This was early Discord bot days. So before intents, and before slash commands.

The simplest use case for a bot for Rivals is to show a map. Rivals has 48 maps you can play on. And of ccourseyou can challenge other players to a game. So it makes sense to want to look up the map ahead of time.

This is probably my favorite map (the only map I’ve beaten 13lade on, that’s a story for another time):

While Rivals has a random map feature in game it’s revealed at the last moment when a match starts. For tournaments it helps to pick a map at random, but ahead of time so that both players know what map to expect and can pick thier decks accordingly. Finally, despite what looks like on the surface to be a small map and therefore simple, it turns out there is a lot of nuance to maps. Some are not at all fun to play on and poorly balanced. I’m looking at you:

Features

The basic use case is perfect for getting started with a bot. There’s no calculation, no state. The functionality is simple: a command that just picks a map at random, and has no arguments. In the first days that would be a “~map” command, that would go through the message received handler. Legion uses the “~” prefix to identify commands. This of course means for a simple use case this bot would need to read message content. Uou could limit it to a specific channel at least. This was the typical model for those of us that were vigilant about security.

I looked over the code yesterday, and I forgot just how much more there can be to it after the basic use case. I completely forgot that the bot supports localization in Russian and German (translations provided to me by members of the community). As one small touch, for example, it responds to ~karte for German as well as ~map.

Beyond picking a map, players often want to see a particular map ahead of time. So you want something like “~map orbit”. This immediately brings up the observation that bots start to make Discord look like a command like shell, but is missing auto complete and tool tips. Discord’s App Commands helped address that once they were introduced. But until then the bot needed a way to get the map that was closest to what was type. Cause if you typed ~map <name> you clearly wanted a map, so it should always return the best guest at a map even if there was no perfect match.

Finally, for tournaments, or just for fun, you could create and store map groups. It’s a named list of maps that could also be used to supply the valid maps used for a tournament.

Edit Distance

For making sure the command always returned a map I started with https://www.nuget.org/packages/Fastenshtein. Given an input it would return the closest localized map name. One trick it would do is remove “the”, or “das” and “der” if in German, from the map name as this would create some noise in the edit distance. Looking at the code now I found a small bug. I used the wrong normalizer for one of the languages so the wrong words would get removed before looking up edit distance.

Because the command ALWAYS returns a map now based on edit distance, there was some brief fun around looking up what maps a particular player name would result in. For example, “Sarpedon” has the smallest edit distance of all the maps to “Caged In”

Using a Slash Command

So now there are app commands, and “map” makes for a great global command. This is the snippet for adding the command:

        SlashCommandProperties guildMessageCommand = new SlashCommandBuilder()
            .WithName(CommandName)
            .WithDescription("Picks a map at random")
            .WithDMPermission(true)
            .WithDefaultMemberPermissions(GuildPermission.SendMessages)
            .Build();

await client.BulkOverwriteGlobalApplicationCommandsAsync( new ApplicationCommandProperties[] {guildMessageCommand});

This is a snippet of the handler:

    private Task _client_SlashCommandExecuted(SocketSlashCommand arg)
    {
        if (arg.CommandName == CommandName)
        {
            return arg.RespondAsync(embed: ShowMap(this.maps[R.Next(this.maps.Count)]).Build());
        }
        return Task.CompletedTask;
    }

    private static EmbedBuilder ShowMap(MapValues map)
    {
        EmbedBuilder builder = new EmbedBuilder();
        builder.WithTitle(MapLookup.GetMapName(map));
        builder.WithImageUrl(MapLookup.GetUrl(map));
        return builder;
    }

And using application commands makes it really easy to add this command to a server: https://discord.com/api/oauth2/authorize?client_id=1043771859159756840&scope=applications.commands

There is some boilerplate to a bot, however. For example:

• Logging
• Storing the secret

As part of creating this command I think I have a good template I can leverage in the future, and share.

Options

I might be able to make it easier to look up a name by showing a list of all names as part of the slash command. Discord commands can be created with pre-set options for the arguments. Unfortunately the limit to options is 25. But there is grouping, so I can break down the 48 maps into some grouping (maybe alphabetically) so each group would have less than 25 options.

Finally, there is an auto-completion capability as well: https://discord.com/developers/docs/interactions/application-commands#autocomplete. Lots of way to improve the simple command with Discord features.

So that’s a brief random walk through bots, maps, Legion, and Rivals. The intent is there will be a few more Legion related posts!

Visit 13lade’s Twitch: https://www.twitch.tv/13lade There’s a Rivals tournament facilitated by Legion today on this channel!

Please support Legion and other tech:

Killmail OCR Development

Killmails are many things in Eve - they can be bragging rights, ways to track enemy movements, tactics, and fits, or just a mess that everyone wants to gather around and stare out. Eve Online provides a killmail API that allows players to develop a rich set of 3rd party tools that have access to all of this data. Unfortunately, the best we can get in Eve Echoes is player-submitted screenshots. Screenshots are nice to share with your friends, but it’s impossible to glean anything from them on a larger scale. So the solution has become creating software that can read these screenshots and extract the data we need.

I have set out to build a free and open-source killmail parser for Eve Echoes.

Many other parsers are using machine vision APIs from cloud services to pull text from images. This is fast, easy, supports more types of scripts and languages, and can be very accurate. However, it costs money and locks you into a specific cloud provider. We want something that we can tinker with and reliably self-host without worrying if a service will increase in price or a third party bot will go down.

Using Tesseract

Tesseract is a free Optical Character Recognition (OCR) engine. You feed it a picture and it spits out text. There are 3 basic steps when processing an image using OCR:

1. Image Pre-processing
2. OCR Execution
3. Text Post-processing

Image Pre-processing

Tesseract uses an LSTM neural network to transform images into text. There’s a bunch of fancy math behind it, but practically it means that you need a model to tell the software how to translate an image of text into the actual characters it contains. OCR is widely used to digitize scans of printed text, and so these models are trained to recognize black text on a white background. This is nearly the exact opposite of what we get in killmails. Most text is white or lightly saturated colors, on a dark or patterned background. Cleaning this up first helps us get better results.

Here’s a killmail header. The background is fairly clean, but the color scheme is not quite right.

# convert our image to grayscale
img = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)
# invert the colors so the text is black
img = cv2.bitwise_not(img)

And viola!

Here’s a more complex example. The victim name is pure white text on a background with a space pattern that changes colors based on the type of ship that was killed. This variation in the background can really confuse OCR.

# Convert our image from BGR (Blue-Green-Red) to HSV (Hue-Saturation-Value) to make this kind of filtering easier.
cv2.cvtColor(img, cv2.COLOR_BGR2HSV)
# Define an HSV range that the text we want to parse falls inside, while the background falls outside
low = (0, 0, 180)
high = (255, 80, 255)
# inRange returns a 255 if the source pixel is inside the HSV window and 0 when outside.  This will result in white text and a black background
img = cv2.inRange(img, low, high)
# invert our image to get black text on a white background
img = cv2.bitwise_not(img)

With a little cleanup, we get an image that looks a little rougher but is very straightforward to identify what is text and what is not. This is called binarization - reducing an image to only 2 values - black and white.

OCR Execution

Using Tesseract is really straightforward - you give it an image, and it gives you text back. There are a few knobs you can tweak to get better results.

import pytesseract as pt
pt.image_to_string(img, lang="eng-shentox", config="--psm 7")

First, Tesseract offers script detection - given an image of text, it will attempt to tell you the written script (such as Latin, Han, Hangul, etc.) that the text is using. This allows us to then choose the best model to parse the text.

Tesseract has a variety of runtime config options, including page-segmentation mode. This is essentially how Tesseract will chop up the image into pieces when looking for text characters. Trying different options can yield better results.

Tesseract is optimized to recognize whole words from a dictionary. Because much of the text we are trying to recognize is either nonsense (character names) or non-word phrases, we can disable the default dictionary or substitute it with our own list of Eve terms that we expect to see.

In addition, you can ask Tesseract for detailed information about the locations that text was identified, and how confident it is that the text was correctly transcribed. It may be useful in the future to look at confidence levels and attempt different methods to see if a more accurate result can be achieved.

Text Post-processing

Now that we’ve processed our images, we’re left with a bunch of text.

Corp tags are one of more frequent culprits for errors. Tesseract often returns text that looks like [ABCJPilot or (ABC]Pilot. These can be cleaned up with some simple find and replace operations.

System names can be difficult to get exactly right. The good news is that we know what all systems in the game are named. So instead of returning the raw text from the image, we can pick the closest-matching actual system and use that value.

from thefuzz import process
# a list of all system > constellation > region pairs in New Eden
systems = load_systems()
# the raw location parsed from the image.  There's two incorrectly identified characters here
location = "E1UU-B < 3WN-IT < Esoteria"
# perform a fuzzy text lookup to recieve the closest match and its score
actual_location, location_confidence = process.extractOne(location, systems)
print(f"{actual_location}, {location_confidence}")
> "E1UU-3 < 3WN-1T < Esoteria", 92

Fine Tuning Tesseract

Tesseract has a high level of accuracy on common fonts that you would expect to see in print. It does fairly well with screenshots of text, but the model can get tripped up on specific characters or combinations with a new font that it hasn’t trained on. Is that H or |-|? The brackets in corp tag like [ABC] can be confused with any of these characters: Il|i1)}J.

Creating a model requires a set of training data. This data consists of questions (images containing text) and answers (the exact coordinates of every single character and its value). This can be a very labor-intensive process if you are training on photographs. Some poor person has to draw a pixel-perfect box around every character separately and type in the correct value.

Thankfully, if you have a copy of the font you are trying to recognize, there’s an easier way. Tesseract provides scripts that will generate images and boxes given any sample text and a font. This data can then be used to refine the existing models - taking most of the performance of the original, but cleaning up some of the edge cases. This process is described in detail in their documentation. Eve Echoes uses the Shentox Light font.

You can support VOID’s PPK and other tech:

But the free stuff is pretty good. And even better when you actually use it effectively. Which is why I was so embarrassed it took me THIS long to figure out a simple way to organize VOID google sheets. We use a lot of google sheets. That means a lot of permissions. In EVE we want secret things to remain secret, so not having open permissions is important. And people come and go, so updating permissions is important and also time consuming if you have to do it for every sheet every time someone joins or leaves. Another issue was having to get myself, as Executor, added to just about everything.

Google Drive is all it took. I don’t know why I didn’t over a year ago. The trick is folder and files inherit the permissions of their parent folder. So you can effectively edit many permissions at once. This is the exact screenshot my post to my alliance had when I described what we were going to do. It seemed pretty obvious in retrospect.

As a bonus point it was then very easy to add a Google service account later to help facilitate Discord to Google Sheet integrations.

It’s the little things!

There are primarily three things I am optimizing for:

• Monthly dollar cost of running the bots
• Time cost of maintaining the solution.
• Time cost to implement the solutions. This is incurred once.

From a technical point of view : I will seek to make reasonable choices between cost and reducing bot latency to respond to users. This, for example, may inform choices between using a VM or using Lambdas as the main way of interacting with Discord. The VM has much more predictable latency. The details of that are probably a different post.

I will not seek to make my solution infinitely scalable. We have a small number of users, so I can do things like hold all of them in memory easily if I need to and not feel guilty about it.
Things like Disaster Recovery are, however, important to me.

Ok, so breaking it down, we have the usual suspects:

• Compute cost of a background worker. Example is the bot responding to Discord events.
• Cost of hosting a front end
• Cost of storage.

There are other costs, like domain hosting, but there’s very little if any interaction with the code and tech choices which is why the post is focussed on cloud provider prices.

Finally, I will ignore any free-trial options or credits. I want to know what I will be paying per month in the steady state.

Baseline VM

So first, you can get both a front end and storage for $5 a month by getting a VM from Linode or Digital Ocean. That’s for 1GB and 1 shared CPU. Then put a web server and mysql on it. There are some drawbacks here: You are responsible for backup and disaster recovery. (Something we’ve already had to deal with once). It’s up to you to make sure you can rebuild the VM and not have lost any data. We do use this to host our alliance’s credit system, and it’s already pushing the resource limits of one cheap node despite not having anything complex in what it does. And interestingly, hosting the SQL and site on the same site led to some questionable design shortcuts which made it harder to extend the solution. This wasn’t my choice (we inherited the solution), but it was an observation I wanted to note.

You can get similar offers free from Google or Oracle. The 0$ to $5 options are a good baseline to compare against.

Front End

Both Google and Azure have free web hosting:

https://azure.microsoft.com/en-us/pricing/details/app-service/linux/#pricing https://cloud.google.com/free/docs/free-cloud-features#app-engine

While it is also free, the real win for me here is the potential of less maintenance, I don’t need to manage the VM in any way.

This only saves money if I have a place to get storage for $5 or less.

Storage

SQL

The basic SQL options exist in AWS, Azure, and GCP. The lowest I could estimate was probably $7 a month.

Cosmos

There’s a free tier of Cosmos now. Legion actually uses Cosmos DB. It pre-dates the free tier and I will have to move all the data to take advantage of this (kind of annoyed by this actually). A future blog post, maybe. Here’s the free tier: https://learn.microsoft.com/en-us/azure/cosmos-db/free-tier#best-practices-to-keep-your-account-free

I do have some reservations here as I’m not confident that Legion and Orphyx will predictably stay in the RU limit. But it is actually a very tempting offer because it is also easy to code against since it has something that SQL has, but the next option lacks: Secondary Indexes.

NoSql

Finally, there’s the NoSQL stores. Dynamo, Azure Table and Firestore or other equivalents. Orphyx is actually currently on this. And it runs me $0.01 a month right now. Google and AWS would have similarly priced (free) solutions. The major disadvantage is that without features of SQL that even Cosmos has there are some extra design constraints to navigate that often result in extra code you have to carefully write. And that will absolutely be the topic of future posts.

Summary

Currently where we are at is that we have one lineode for $5, and actually one Windows Azure VM with a reservation to bring it to $11 a month. The linode should eventually melt away into a free front end option and one of the storage options. Legion uses Cosmos, and Orphyx uses table storage. After moving Legion to the free tier of Cosmos or moving Legion to a NoSQL option the price of that will also be in range of a few cents a month. Maintenance costs and single points of failure (a VM) are minimized.

EVE runs on Google Sheets and Discord. I’ll get more into Discord particulars later. But PPK systems are one reason. A central part of EVE Echoes is a kill mail. Here’s one for reference:

Overview

The game, unlike EVE Online, does not have a KM API. Most alliances therefore have to implement some work around. And Discord is often central to that work around. It starts with OCR of the KM above when shared. I won’t go into that here, because that’s not a part I am familiar with. Though I thank the devs that do that portion. Suffice it say after OCR you have the various fields from the image available. Things like:

• The victim and victim’s corp.
• The value.
• The Final Blow and Top Damage participants.

The typical flow for building an alliance PPK program goes like this:

1. User grabs an image of the KM from the game, and posts an often cropped version of it into a Discord channel dedicated to kill mails.
2. A bot picks up the image, runs it through OCR, and outputs the information parsed into some schematized store.
3. Some analytics are run and output somewhere for alliance members to see.

PPK Events

For VOID, I wanted to expand on what PPK means. Typically PPK is for final blow. The person gets some % of the kill in ISK back. So in VOID’s system, I have a KM still, but also added a separate PPK event. A typical KM already has three PPK events:

• Damage
• Final shot
• Participants.

All of these we can give PPK for. On top of that, things that don’t appear on the kill mail, but we can add as PPK events:

• The FC (Fleet Commander)
• All Logi (EVE healers)
• Tackle, and interdiction
• Scouts

This will look like a DKP system for anyone familiar with DKP (Dragon Kill Points) from other MMOs. But the DKP is backed by ISK, which is obtained in-game.

Pilot Workflow

The workflow, from a Pilot’s perspective, looks like this:

1. Get a KM
2. Post the KM to dedicated Discord channel
3. Other pilot’s involved in the KM can then added their own PPK events. FCs, tackle, can add PPK events through commands or buttons createed by a Discord bot. Because its in a visible channel there’s very little risk of someone lying.
4. A summary is created run at some point, and through some manual method the pilots are given the PPK for the week/month or for each individual PPK event through a ticket bot.

Storage for the Workflow

For design of storage, most systems have an OLTP and OLAP system. For VOID Azure Table backs the initial ingress of KM and PPK events. I’ll leave the schema for a different time. And we creatively use Google Sheets as the OLAP store. The reason for these two picks is mainly due to cost and ease of maintenance. Each PPK event is eventually written to a google sheet dedicated to a specific month for all VOID, and a separate sheet for the pilot’s corp. This allows corp’s to build thier own unique systems without having to re-create all the other parts.

Adding PPK Events via Discord

For steps 3 in Pilot Workflow the Discord bot listens for KMs, creates a row for the KM, then creates PPK buttons. Note that PPK is assigned to an in-game clone, not a Discord user.

// Wire up events to process messages and button clicks
_client.MessageCommandExecuted += handlers.ClientOnMessageCommandExecuted;
_client.ButtonExecuted += handlers.ClientOnButtonExecuted;

   internal Task ClientOnMessageCommandExecuted(SocketMessageCommand messageCommand)
    {
        // Code omitted to check certain things about the buttons. The killMailId is parsed from the message.
        
        this._logger.Log($"Creating buttons.");
        ComponentBuilder builder = this.CreatePpkButton(killMailId);
        messageCommand.RespondAsync($"Add a PPK Event to Killmail ID [{killMailId}] [<{messageCommand.Data.Message.GetJumpUrl()}>]:", components: builder.Build());
        return Task.CompletedTask;
    }

 internal ComponentBuilder CreatePpkButton(string killMailId)
    {
       // Note the use of the custom Id to plumb through the killmail Id.
        return new ComponentBuilder()
            .WithButton("PARTICIPANT", $"{KillMailParticipantType.PARTICIPANT}-{killMailId}", ButtonStyle.Primary)
            .WithButton("TACKLE", $"{KillMailParticipantType.TACKLE}-{killMailId}", ButtonStyle.Danger)
            .WithButton("DICTOR", $"{KillMailParticipantType.DICTOR}-{killMailId}", ButtonStyle.Danger)
            .WithButton("LOGI", $"{KillMailParticipantType.LOGI}-{killMailId}", ButtonStyle.Success)
            .WithButton("SCOUT", $"{KillMailParticipantType.SCOUT}-{killMailId}", ButtonStyle.Danger)
            .WithButton("FC", $"{KillMailParticipantType.FC}-{killMailId}", ButtonStyle.Danger);

    }
    
    internal Task ClientOnButtonExecuted(SocketMessageComponent messageComponent)
    {
        // Get the KM Id, and the PPK Event selected by parsing the custom Id
        string dataCustomId = messageComponent.Data.CustomId;
        this._logger.Log($"{messageComponent.User.Mention} has clicked the button with id [{dataCustomId}]");
        DiscordId pilotId = (DiscordId)messageComponent.User.Id;
        string[] result = dataCustomId.Split("-");
        string type = result[0];
        string killMailId = result[1];

        this._logger.Log($"[{type}]-[{killMailId}] button pressed.");
        
        // Look up the clones to assign PPK to
        IEnumerable<Clone> clones = this._cloneRepository.GetClonesByDiscordId(pilotId);
        IEnumerable<Clone> enumerable = clones.ToList();

        if (enumerable.Count() == 1)
        {
            Clone clone = enumerable.Single();
            this._logger.Log($"Pilot with single clone {clone.cloneName} being added to PPK");
            
            // Store the PPK event
            return this.AddPpkForClone(messageComponent, clone, type, killMailId, pilotId);
        }
     
     // Some more code ommited for brevity to deal with when the user has more than one registered clone.    
    }

Further Discord Commands

Because things can go wrong, you also need commands for the following locked to certian discord user considered admins:

• Re-parse and re-create the buttons for a KM message.
• Manually override any values parsed wrong.
• Manually remove or add a PPK event on behalf of another pilot.

So that’s a highlevel overview of VOID’s PPK Events, with some details about selecting PPK Events via Discord.

In EVE a lot of things are kept secret for what is called op-sec reasons, and there will be a lot of that in this blog. So I won’t go into the why of it. Another thing about EVE Echoes is that I call it the greatest text adventure game ever. As an executor, for better or worse, a great deal of my time spent playing EVE Echoes is spent on Discord. And for a lot of people another part of it is spent in google sheets. EVE is sometimes referred to as a heavy weight Excel client. Which is why things like this happen: https://arstechnica.com/gaming/2022/05/eve-onlines-ms-excel-partnership-makes-spreadsheets-in-space-official/

And now, with the help of Discord bots, the two can meet. Discord bots will be a common topic here. The basic thing I needed to do was get a bot to list something for a user. And I realized they were going to just dump it into google sheets anyways. So, it makes sense to just create that sheet. On top of that, the user would want a column full of checkboxes to go with the data. Now that on its own is pretty easy to create in the UI:

But it wasn’t so obvious from the API perspective. I had to do with any seasoned developer does. Search on google for stackoverflow answers.

Now our bot is in C#, and the google API docs don’t cater to C#. This is the link I got the most use out of: https://webapps.stackexchange.com/questions/121502/how-to-add-checkboxes-into-cell-using-google-sheets-api-v4.

A careful inspection of this will help once you know that you need a batch update for a conditional formatting request: https://developers.google.com/sheets/api/reference/rest/v4/spreadsheets/request

And this is what the C# code looks like:

            BatchUpdateSpreadsheetRequest request = new BatchUpdateSpreadsheetRequest
            {
                Requests = new List<Request>(
                new[]
                {
                    new Request
                    {
                        RepeatCell = new RepeatCellRequest()
                        {
                            Cell = new CellData
                            {
                                DataValidation = new DataValidationRule()
                                {
                                    Condition = new BooleanCondition
                                    {
                                        Type = "BOOLEAN",

                                    },
                                },
                            },
                            Range = new GridRange()
                            {
                                StartColumnIndex = 0,
                                EndColumnIndex = 1,
                                StartRowIndex = 1,
                                EndRowIndex = cellValues.Count,
                                SheetId = response.sheetId,
                            },
                            Fields = "dataValidation",
                        },
                    },
                })
            };
            SpreadsheetsResource.BatchUpdateRequest updateRequest = this._sheetsService.Spreadsheets.BatchUpdate(request, response.spreadsheet.SpreadsheetId);
            BatchUpdateSpreadsheetResponse? response = updateRequest.Execute();

Some notes:

• To get one column of checkboxes, you need to pass a start and end index that are different by one. Setting them both to 0 in the above example yieds no checkboxes.
• They are unsurprisingly indexed at zero, despite the label of the first column being “1”.

So there we go. This was a small piece that made the entire command much more user friendly. With a simple command the user got a ready-to-use sheet shared with them. And I made sure they didn’t even need to click a few times to add a checkbox column. As always, that last detail took the most time to do out of the entire feature.

One of my more recent projects is a tournament bot, Legion, used to run tournaments on Discord for the mobile version of C&C: Command & Conquer: Rivals. Rivals is how I met JadeXyan (co-creator of Legion), and Captain Benzie. That set off a chain of unfortunate events that led to me becoming one of the executors of an alliance in Eve Echoes: The VOID Federation.

As part of VOID the software projects include:

• Working on a team to maintain a credit system for the alliance members: www.voidcoin.app.
• Creating another bot with JadeXyan caled Orphyx to maintain in-game character information for the 1000+ members of VOID.

This is the first time I’ve created a blog. Though I’ve often wanted to create a blog, or a software blog. What has stopped me is I’ve never felt I had anything to write about. The blog itself a bit of learning for me. It was quickly created using github pages as well as the template and steps found here: https://chadbaldwin.net/2021/03/14/how-to-build-a-sql-blog.html

I’ll be writing about these projects and delving into the technical details of them in this blog.

But really, the idea is to create semi-regular content as a way to shamelessly plug my buymeacoffee site. This is then used to then pay for the various tech tools of my current alliance, VOID.