Version 0.9.0, a GUI, and (finally) a website

TL;DR:

• FcomClient update
• New graphical interface (GUI), and new instructions for it
• Finally, an actual website for FCOM!
• If you’re coming from an older FcomClient version, see here for a crash course on the new GUI

---

 

I am pleased to announce that, after over 5 months since the initial release, the first update for the client is out!

Spoiler: absolutely nothing was done on the client between October and February. Much of the work on 0.9.0 started at the beginning of February (yeah, I’ve been busy).

 

Finally, a gooey GUI!

Anyway, perhaps the biggest thing about this version is that there is finally a nice graphical interface (or GUI). You will no longer need to type inside an ugly command-line interface 78%* of the time.

Finally, an GUI. Because it’s 2019.

*I’m still new to this whole WPF thing, so I haven’t been able to port the connection selection bit to the GUI yet. But given how most people don’t seem to get the existing prompt anyway, and that CTP is today, I’ve opted to release it anyway so I can finally push FCOM to a larger audience.

 

New interface, new instructions

Here’s the updated instructions on how to use it. If, for some bizarre reason, you prefer the old command-line interface, you can still open FcomClient.exe as before. I don’t know why you would prefer that though.

Also, the “verification code” is now known as the “Discord code”. Same thing, but shorter name. Less confusing and less typing. Why waste time say lot word when few word do trick?

 

If you’re coming from an older version of FcomClient…

The GUI is more or less just a “wrapper” for the existing (and also ugly) client. Functionality under the hood is largely the same. Because of this, the workflow largely maps one-to-one to the GUI, as follows:

GUI button	Old workflow
Start forwarding	Opening FcomClient.exe No need to enter the callsign and Discord code again, however The connection selection prompt is unchanged, and still needs to be done in the console window that pops up
Pause	Closing the FcomClient.exe console window
Stop	Closing the console window, then sending “remove” to the bot

 

Changelog

The FcomClient changelog can be found on the GitHub releases page for 0.9.0, but because the bot and client are so tightly coupled to each other (but not necessarily updated simultaneously), here’s a high-level overview of the changes that you’ll see:

• Graphical interface. ’nuff said.
• The callsign you enter into the client is now auto-capitalized
• Forwarded messages received over frequency will now include the frequency in the bot message. Sure, it had already been included before, but it’s now nicely formatted (e.g. 123.45 MHz instead of just 12345).
• Some additional logging in log.txt for improved bug-squashing abilities.
• The ability to deregister (i.e. the bot “remove” command) via the GUI

Minor server-side stuff:

• The Discord code is now guaranteed to not contain underscores (“_”) and dashes (“-”) – double-clicking on the code will highlight the entire code
• You’ll now receive a bot DM once you’re registered through the client
  • If a new client update is availble, this DM will also include a link to the GitHub releases page

 

GUI source code

To be frank, the GUI code is an absolute mess. It was quickly hacked together, and it mostly just passes the callsign and Discord code to the existing FcomClient.exe.

Because of this, it’s not on GitHub (it’s not quite ready yet), but for the purposes of transparency, you can find them at https://studentweb.uvic.ca/~norrisng/fcom/FcomGui-src/.

I’ll be zipping the entire Visual Studio solution and uploading them here until I can figure out how to bring the GUI and underlying client together into a single, unified repository.

 

Website

A website has finally been setup for FCOM. It’s at https://norrisng.ca/fcom. The dev blog here will continue to be updated.

Currently, it’s hosted on my university webspace, and is therefore just a redirect. However, it’ll eventually be moved, so please share the link I’ve given, and not the webhome.csc.uvic.ca link.

 

Download

Available at the same place, as always:
https://github.com/norrisng/FcomClient/releases

 

And finally, I’ve switched over to PayPal.me for donations: https://paypal.me/norrisng
Always appreciated, but never mandatory. But it certainly helps pay for programming fuel coffee and server bills, among other things 🙂

Advertisement

Teaser: a new graphical interface is underway!

Recently, I’ve been working on a graphical interface (also known as a GUI, or “Graphical User Interface” in more technical terms) for FCOM. No longer will you need to type stuff inside an ugly command-line window. MS-DOS? Command Prompt? Ick!

A quick preview of the GUI. Appearance may vary on release.

It’ll be a separate *.exe file (and possibly some additional DLLs) placed right beside the existing FcomClient.exe (though I’ll be bundling everything in a single handy *.zip file). FcomClient will also need to be updated for this GUI to work – the required code changes have already been pushed to the codebase, but I need to push a few more before releasing version 0.9.0 (which will contain these required changes for all), in addition to the completed GUI itself.

Hopefully this will be the thing that finally pushes FCOM to the mainstream. I had actually been in talks with a FSElite writer leading up to the release of the closed beta back in October 2018, but they ultimately decided against publishing their article on the grounds that it was still a little too complicated.

More coming soon!

Status update: 2-months-of-nothing edition

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 open beta

TL;DR:
If all you want to do is download and use FCOM, skip to “Getting started” and “Bugs and suggestions”. Nevertheless, it would be much appreciated if you could go through this entire post 😀

---

 

FCOM is finally ready for open beta!

Yeah, unfortunately it doesn’t have a nice user interface yet. That’ll come later.

Okay, there’s still quite a few kinks here and there, but I really want to see how the server performs under load before the Big One (CTP) rolls around, so that I can improve performance before everything comes crashing down, right when everyone needs it.

In the meantime, please try FCOM out and try to receive as many messages as you can. Okay, perhaps it would be nice if you could be a little more considerate on the day of CTP (not that I can control you anyway), but for now, it would be nice if I could simulate the amount of traffic my poor bot would get hammered with on that very day.

Getting started

First, you’ll have to join the Discord server (invite link). This is where the bot lives for now.

Once you’re in, please take a look at the #announcements channel (in particular, the pinned messages) before going anywhere else (yes, there aren’t any pins right now, but I’m working on it).

Download the FCOM client here: FcomClient-0.8.0.zip

Requirements:

• Windows 7 or newer
• .NET Framework 4.7.1 or newer
• WinPcap

Some reading material:

• How to use/install
• FAQ

Bugs and suggestions

Please take a look at the GitHub issue trackers (FcomClient, FcomServer), before using the #bugs and #suggestions channels on the Discord server.

Unfortunately, the bug I mentioned in my last blog post still exists. I haven’t been able to get around to it. In case you’ve missed it, forwarded messages will sometimes contain random code attached to them, such as the following:

AAL123:
Here's a test message
$CQLAN2250:@94836:ACC:{"config":{"lights":{"strobe_on":true}}

In case you’re curious, that’s information regarding the state (i.e. flaps, lights, landing gear) of nearby aircraft, which is then used by network clients (e.g. vPilot) to render aircraft inside the simulator.

Source code

Source code if you’re interested (yes, it’s a mess, but it will have to do for now):

• FCOM client
• FCOM server

Credits

A special thanks to all of the early volunteers:

• Early testers
  • Britannia
  • Grant
  • Mark Doyle (Pritt)
• Logo
  • Britannia
• Closed beta testers
  • Agera
  • AidasP
  • Avalanche
  • Barbate Brandon
  • Elias
  • flightcode
  • Ka Hei Zheng
  • Pronoun
  • Sterling P. (bantha121)
  • Tafia
  • Tivec
  • triplesevenbob
  • Vikaas
  • Zack

Also, thanks for all the shitposting encouragement over at the /r/flightsim subreddit and the /r/flightsim Discord server. But no, seriously, I wouldn’t have taken FCOM this far if it weren’t for all of you.

Also, a special shout-out to Hubok over at the /r/flightsim Discord server for walking me through on how to set up MariaDB. It’s saved me from having to Google it, which would’ve eaten into what limited dev time I have (I’m not a sysadmin, nor do I have any devops experience prior to this).

Happy flying! And may the odds be in your favour if you’re planning to furiously mash F5 book a slot for CTP.

Oh, and if you like what I’m doing, consider donating. Aside from showing your support, it also helps keeps the lights on for the server/bot 😉

Weekend update

Unfortunately, I’ve been pretty busy with school for the past week, so I haven’t had much of a chance to work on FCOM. I should be able to get some more work done on it this coming week though (key word being “should”).

Anyway, here’s a progress report.

 

Database migration

I’m currently working on migrating the backend database from SQLite to MariaDB (if you’ve heard of MySQL, that’s more or less what it is). I originally planned to do this after initial release, but the sudden realization that CTP would mean 1000+ users hammering my server with multiple messages all at once was enough send my ass into high gear to get it into the initial release.

Currently, while multiple messages can “enter” the message forwarding queue (which sits inside a database), only one message can actually be inserted into it at a time. Upgrading to an actual DBMS (database management system, which is what MariaDB is, along with other names such as PostgreSQL, MySQL, Oracle, etc etc….) will allow for multiple messages to be inserted simultaneously, and therefore, much better scalability.

It’s not particularly difficult (after all, a database is a database), but there’s so many little things here-and-there that have to be dealt with. While I’ve had some experience with databases, I haven’t really been in the deep end and actually implemented this stuff before (yeah, they don’t teach that in school), so I am – to a certain extent – learning much of this as I go.

TL;DR: I have to setup new stuff and rewrite existing code so I can handle way more users simultaneously.

 

The IVAO bug I mentioned earlier

That IVAO bug I mentioned earlier might be a user-specific issue. The tester that reported it had all sorts of other issues as well (which another IVAO tester did not encounter so far), so I’m gonna file it under “cannot reproduce” and ignore it for now.

“Can’t and shouldn’t.” (xkcd)

That being said, in the midst of higher-priority issues and a lack of IVAO testers, I haven’t really had a chance to actually look into this. I’m not sure if I’ll be able to get around to this by CTP either, so it might have to wait until after initial release.

 

Weird stuff being appended to forwarded messages

Meanwhile, another bug has popped up. Forwarded messages would occasionally have extra stuff appended to them. Here’s an example of such a forwarded message, as seen in Discord:

AAL123:
Here's a test message
$CQLAN2250:@94836:ACC:{"config":{"lights":{"strobe_on":true}}

The last line is actually information regarding the state (i.e. flaps, lights, landing gear) of nearby aircraft, which is used by network clients (e.g. vPilot) to render aircraft inside the simulator. I have a pretty decent idea of how to get them to not show up, but I haven’t been able to get around to it. This will happen once I finish up the database migration stuff.

While rather annoying, this isn’t exactly a critical bug, so it might still be present at public beta, workload depending.

 

Release timeline

At this point, I’m still aiming for a release by CTP on October 27. Ideally, I’d like to open this to public beta next weekend so that I have an idea of how well (or not) the server handles the load.

In any case, while the extra-stuff-appended-to-messages bug is annoying, it’s not critical, so it might still be present at public beta if I can’t get around to it. As for the IVAO issue, given how CTP is getting increasingly closer, I might even hold off on officially supporting IVAO till after initial release if I can’t get around to it.

We’ll see what happens.

Closed beta time!

After 6 months of wildly varying levels of commitment, FCOM is finally ready for closed beta! It’s come a very long way since.

The initial proof-of-concept. PMs were displayed in a browser.

Here’s how it looks today:

As of the time of writing, everything works, though there’s a bug with receiving IVAO messages. The main purpose of the beta is to bash more bugs, see how well the FCOM server handles the load, and – of course – fix that IVAO bug.

A website is also in the works (some early testers are currently working on it), but for now, this blog will have to do.

If you’d like to help out with testing, hit me up! You’ll (obviously) need to be an active IVAO or VATSIM member, and have a Discord account.

Why now? Well, I hope to release this in time for VATSIM’s Cross the Pond by October 27. I was hoping to fix the IVAO bug prior to this, but Matt Davies announced at Flight Sim 2018 at Cosford that they have started working on a ProjectFly app that notifies the user of network messages, which has somewhat forced my hand. At least I have a 6-month head start on this, I guess.