AbiathRPC - Last-minute bug fixes

In anticipation of the first release of AbiathRPC today, I did some quick testing to make sure everything worked. To my surprise, I found a few rather serious problems:

• Connecting could fail across a network with a security-related exception. I set the security mode to "none," which is what it should have been all along.
• Any operation that replaced a level crashed all connected clients if and only if there was more than one person online at the time. Somehow this was caused by an attempted call to a nonexistent method, though I don't understand why it only caused problems when there were other users available. Fixing the call definitely fixed the problem.
• Changes to foreground tileinfo always wiped away that tile's foreground-specific properties on all machines except the source. A numeric typo caused this by always making an important conversion step get skipped.

I also noticed that I had forgotten to update the server to use the new VeriMaps certificate repository; that was an easy change. After all of that and a bit more testing, I released AbiathRPC 1.0 for Keen Day 2017.

AbiathRPC - Little touches

I plan to release the first version of AbiathRPC tomorrow (Keen Day 2017). To get it ready for the unveiling, I made a couple small tweaks.

Since undo/redo doesn't work for remote level sets, it doesn't really make sense to have the Undo and Redo menu items appear enabled. Those are now disabled.

It could be useful for server operators to have the IP addresses of connecting clients logged. I added a bit to the sign-on procedure to record that in the "User connects" log entry along with the IP address.

AbiathRPC - Tileinfo download

Yesterday I added full tileinfo support to AbiathRPC, minus support for it in the Download Levels feature. Today I filled in that gap. Since downloading the project might now get more than just levels, the menu has been renamed to simply Download. If and only if the current server has tileinfo, the export window has an extra field for the tileinfo file's name. As expected, that file is now saved right beside the levels.

AbiathRPC - Tileinfo

Abiathar's ability to show tile properties is extremely useful in my opinion, and it's especially important when testing the level requires an extra step like it does with AbiathRPC (seeing as the level set is remote). Obviously, Abiathar can't show tileinfo that it doesn't have, so I today I added support for tileinfo reading and writing in AbiathRPC.

It was less difficult than I expected. The server loads a tileinfo file if indicated in the configuration file. Clients request that when they connect. When a user alters a tile property, the change is noticed when the tool calls MarkChangesMade. The client extension keeps track of the previous ATP IDs so it doesn't have to reupload all the tileinfo. On the network, the properties are transmitted as an array of bytes - 2 long or 8 long for background and foreground, respectively. (I would have used ATP IDs there, but the server application doesn't have a reference to any Abiathar component and therefore can't process those numbers.)

I have yet to incorporate tileinfo into the export feature, but that shouldn't be hard at all.

AbiathRPC - Little bugs

While combing through AbiathRPC, I found a couple small bugs which are now fixed.

First, authentication wasn't actually being checked in the WCF method that updates a batch of tiles. Fixed by adding the appropriate login-checking call.

The Abiathar client with the AbiathRPC state wrapper would crash when updating tiles when not connected to a server. This was caused by the replacement state wrapper trying to submit updates from a list that didn't exist to a server that didn't exist. Fixed by checking that there's actually an RPC connection and stopping with the vanilla behavior if there's not.

(Also, merry Christmas from Abiathar - from now until sometime tomorrow night, the Abiathar splash screen is Christmas-themed.)

AbiathRPC - Anonymous is not a person

Today I realized that the usefulness of the VeriMapsApproved setting (which allows any VeriMaps-authenticated user to connect) for the AbiathRPC server is undermined by the public availability of the Anonymous key. Server operators might enable that option think it will allow in known members of the community - since only I can issue new certificates - but it actually allows anyone who bothers to download the Anonymous key. Therefore, I made that account an exception to the approval granted by that server option.

If server operators want to allow the Anonymous certificate to be used for authentication, they can still add it as a normal account without a password.

AbiathRPC - Save levels locally

If you're working on a leveling project with some people, it's great to have a centralized copy of the levels (on the AbiathRPC server), but you also need to be able to get the newest version so you can test your changes in a game. Today, I added an option to the RPC menu that saves the current state of the levels to local files. Its implementation is very straightforward; the only special thing it does is check for the presence of a GAMEMAPS file in the current folder and fill the suggested file names with that file's extension.

AbiathRPC - Administration GUI

Yesterday I wrote the AbiathRPC server functions for user management. Today I put together the client UI that actually uses those.

In the above screenshot, Anonymous can only authenticate with VeriMaps; it has no password set. It is also a server administrator. The Test account can authenticate with a password, but it is not an admin.

The buttons are fairly intuitive: New Account adds a user, Set Password adds or sets a password for a selected user, Disable Password removes a user's password (allowing VeriMaps only), Promote/Demote toggles administrative privileges, and Delete Account removes the account from the server's configuration.

Changes to user configuration are saved to disk when the server shuts down.

AbiathRPC - Administration APIs

There should definitely be a way for AbiathRPC server operators to manage their servers without having to actually remote in to the host machine, stop the server program, fiddle a textual config file, and restart the program. I think it makes sense for some management tools to be included in the Abiathar extension itself. So today I added a few WCF endpoints on the server: to get the allowed users, to delete a user, to create a user, to reset a user's password, and to set a user's access level. Those are all implemented, but I haven't yet put together a GUI on the client to use them.

I also adjusted the part of the server that decides a newly connected user's authentication plan. Now, even on an open-access server, users with a definite password will actually be required to enter their password if they use their registered username. Users without accounts are still free to pick whatever name they want and use it with no special access or authentication.

AbiathRPC - Clean up old WCF instances

I just noticed that the AbiathRPC server never properly disposed of communication objects for clients that had abruptly disconnected; they just hung around in the list of server object instances. Since they're in that list, the server always tried to notify them of new events. Today I added some code to the routine that runs every ten minutes to save the levels if necessary. It now goes through all the current connections and removes the ones that are no longer working.

I also found that non-authenticated clients received event notifications because they were in the list, so I made the "notify all the other clients" routine only send the data to authenticated users.

AbiathRPC - Password hashing

AbiathRPC server operators can allow users to authenticate by password or VeriMaps certificate. The VeriMaps certificates themselves are never seen by the server, but servers did store the plaintext passwords. Today I made the password authentication system using hashing, so people's passwords aren't on disk. This has the added advantage of stopping bizarre characters in new passwords from breaking the configuration file.

Server operators can still easily give people initial passwords; there's a PasswordIsHashed field that determines whether the user record's password field should be considered a hash instead of a plaintext. A plaintext will be automatically hashed at startup.

AbiathRPC - Reconnection crash fixed

Yesterday I mentioned an AbiathRPC bug that caused the opening of a remote level set to fail after closing one that was opened successfully. I found that the crash occurred when setting up the watchdog render planes; an original GalaxyLevel was incorrectly cast to a TaggedGalaxyLevel in the method that looks up a level ID for a given level wrapper.

The problem was that the bookkeeping on level substitutions wasn't nullified at disconnection. That made the ID lookup function think the connection was complete when it's wasn't. The old level objects were also kept around, which is less than ideal. I added a single line to the connection-closing method to fix the problem.

AbiathRPC - Change password

Today I added a way for AbiathRPC client users to change their passwords on the server. There is a new "RPC" menu that is only visible when connected to an AbiathRPC server; currently, its only item is Change Password. The resulting form has the user enter the current and desired new password. The server verifies the existing password and updates the user record with the new password. The password changes along with other configuration changes are committed to disk when the server exits.

I noticed that the AbiathRPC client crashes when reopening a remote level set after having closed one, so something isn't quite right with the disconnection routine.

AbiathRPC - Make sure the connection gets closed

When a remote level set is closed, it's important that AbiathRPC clean up and realize that it's no longer supposed to be talking to that server. I already had an event handler on the Close menu item, but a level set can also be closed in the process of a new one opening, which bypasses that event handler. Fortunately, the level label is updated during the close process, so I added a check for the current level set being gone to the existing handler. If the main level set is missing, it initiates AbiathRPC disconnection, which cleans everything up.

AbiathRPC - Version check

I might eventually want to add some features to AbiathRPC after its first public release. Therefore, it'll need some sort of versioning system. I added an operation contract to the server's service contract that gets a string describing the server's version. If a client connects to a server with a different version, it warns the user about possible bizarre behavior. Since the client reports its own version when asking for the server's, the server has the opportunity to lie about its version if it decides it can accommodate the client despite their differences. That ability may or may not prove useful as I add more features after a release.

AbiathRPC - Remote ADEPS fragment

AbiathRPC level sets can't have all the fancy configuration available to local level sets because there isn't a real ADEPS file to load. For example, there isn't a way to set the number of infoplane tiles, which is kind of a problem because it's different for different episodes. So I added a server configuration option that has it load an ADEPS fragment from a file. When a client connects, it asks for that fragment and if it's found, the connection routine has the core configuration object load that text. Servers can now share these extra properties - e.g. path tile IDs, Level Inspector and Resource Accountant configuration - with clients.

AbiathRPC - Keep unnecessary menus disabled

Though I had already added code to AbiathRPC's connection routine to disable the menu items that don't make sense for a remote level set, I found today that they get re-enabled when the user switches levels. That's because Abiathar's SetCurLevel looks through the list of lockable menus and sets each to an appropriate state depending on whether there is a level set and whether there are any levels in it. I added an event handler on the TextChanged event of the level name label (which is fired after the level name indicator is updated, which is after menu re-enabling part) to disable those menus again.

AbiathRPC - Debugging level creation

I noticed today that though creating levels in AbiathRPC worked, trying to edit the new ones in the instance that created them would cause a crash. The old level wrapper (one around the plain GalaxyLevel) was still held in the current tool. Even after I made ScanForLevelSetChanges refresh the current tool when necessary, the watchdog render planes were still holding onto the wrong wrapper. There isn't a convenient way to make sure they always have the right kind, so AbiathRPC now keeps a table of plain level instances and tagged ones, updating it when a new level is created and consulting it when looking for a given level wrapper's level ID. Editing new levels now works.

AbiathRPC - Level creation message size

While testing AbiathRPC's new ability to replicate newly created levels, I found that the client "received no meaningful response" from the method call that sent the level's contents to the server. I recalled that this had also happened when downloading the initial levels from the server, I remembered that I need to adjust the MaxReceivedMessageSize on the server end as well to allow it to handle the big packages that include full levels. With that done, the crash went away.

AbiathRPC - Scan for level set changes

Today I wrote all the parts of AbiathRPC that are involved in level creation and deletion. When the level set is marked as changed, AbiathRPC compares the current level set against its internal bookkeeping to see if any levels were deleted or added. If anything is found, it notifies the server. When a notification comes in as a result of another client doing something, AbiathRPC pokes at the main form to insert or delete the level as appropriate, then updates its bookkeeping.

Noticing deletion was more difficult than expected because with explicit interface implementation and inheritance, callers that know a real class that implements the interface will always call the original method. Therefore, I had to add an event handler to the level deletion menu itself to run the scan for changes.

I also disabled the Reload Graphics menu item for remote level sets because it would just break things.