To be frank, I hadn’t really worked on FCOM since November. Between school projects, exams, and a 2-week trip out of the country, I haven’t had the chance to work on it at all. And then there was the jet lag after said trip (yeah, it was literally on the other side of the world…go figure).
Anyway, enough excuses. I’ve since managed to return to coding FCOM late last week. To be precise, I’ve been mainly working on the server-side code, and here’s what I did (it’s actually all on GitHub, by the way, though admittedly more verbose):
Server hotfix
Whenever a Discord outage occurs (boy, are they frequent), the bot had a tendency to not reconnect after the outage was over, and forwarded messages would pile up in the server queue. I think I’ve managed to get the bot to restart on its own; once I can test it on my own computer for a little longer (in order to test said reconnecting ability), I’ll push the code to the server (or, as they say in the industry, “production”) sometime in the next few days.
Easier-to-copy verification codes
A tester suggested the following back in mid-October last year, when FCOM was still in closed beta:
I’ve got a suggestion, but I’m not sure how hard it would be to implement; would there be a way to exclude special characters from the registration token? As it stands now, if the token contains special characters, I have to manually select the entire thing, whereas when it doesn’t, I can just double click to select the whole token
I’m pleased to announce that this feature has now been fully implemented! You’ll no longer see underscores and dashes (which prevents one from highlighting the entire verification code with just a double-click). It’ll be pushed to the server once I implement one more feature, before working on bugfixes prior to the next major server update (the hotfix is merely a minor update).
So, what’s next?
Currently, I’m writing code that records the client version being used by the user. FcomClient already includes this information when it communicates with my server, so it’s just a matter of implementing this server-side. This allows the bot to notify the user when a new client version is out. Rest assured, this notification is not going to be intrusive – it’ll either be tacked onto forwarded messages in Discord (but only once), included as part of the response to the “status” bot command, or displayed in the client software.
Once that’s out, I’ll be pushing a major update to the server, and this “update information” feature (along with the easier-to-copy verification codes mentioned earlier) will be available.
What about the client?
Now that I’ve finally reinstalled P3D, testing the client is going to be much easier. From a technical standpoint, there’s little difference in network traffic from an ATC client (which is what I’ve been testing with the whole time) versus a pilot client, but it’s much easier to have a “feel” of how the entire FCOM experience is like. Are there any parts that are particularly intuitive (or not)? How about scenarios and use cases that I’ve never been able to come up with? In any case, it’ll be easier to improve on the client.
But what about the gibberish code at the end of my forwarded messages? You promised to fix this a long time ago!
Yeah, this is where the easier-to-test-with-a-pilot-client thing comes in. It’ll be easier to replicate this (it wasn’t as prevalent with ATC clients) and test it. But when? Probably after the major server update I mentioned earlier above.
Hate the radio silence here on the dev blog?
If you’re impatient and don’t want to wait for these dev update posts, you can always take a look at the GitHub repositories (client, server) for a “raw feed”. I try to keep detailed records under the “Issues” page as well, so feel free to take a look there if reading Git commit messages is a little too tedious and/or complicated. I try to keep the language there a little less technical. Or at least that’s what I think I’m doing.
FCOM dev blog 