FMod - Horrifying Code

Today, I was surveying the GalaxyGraphics code that will be extended for Gash to deal with CGA and VGA. I immediately noticed that it is a huge unreadable mess. There is stuff like this repeated all throughout the file, slightly modified sometimes:

Yep, that's a 5-deep for loop. There are all manner of crazy variables and bit twiddling (which really should have been done in C#).

I think I'll be rewriting this file/class to use these nice function calls that we have in .NET instead of copy/pasting difficult code. I may also take this opportunity to make the time-consuming stuff (decompression) not happen until the resource is called for.

Gash: The Superior xGAGRAPH Editor

There have been murmurings in the Keen community of bugs, limitations, and general shortcomings of KeenGraph. KeenGraph is the more modern replacement for the original ModKeen, and it is a very good tool. Sadly, it is written in QuickBASIC and is therefore difficult to maintain and extend. The main issue I find is that there is no way to give it custom chunk offsets - every time somebody mods another game, the program must be updated or forked to add configuration for that game's EGA arrangement. KeenGraph also does not support CGA or VGA graphics. (The main graphics file can be called EGAGRAPH, CGAGRAPH, or VGAGRAPH depending on the adapter supported.)

So, I plan on soon starting a replacement called Gash - xGAGRAPH Shell. I will address the following issues with KeenGraph:

• Language. Gash will be written in .NET to take advantage of existing FleexCore2 (FMod) functionality. This will greatly help debuggability and extensibility.
• Output format. KeenGraph only exports BMP images, which do not support transparency. Masking is done with a designated "transparent" color. Translucent colors are produced using a strange color-shifting system that I haven't been able to use successfully. Gash will support the export and import of PNG images, interpreting a transparent pixel to be an invisible black pixel (transparent) and a translucent pixel of any color to be that color unmasked.
• Tolerance. I personally enjoy the Paint.NET editor very much, but it butchers the 16-color bitmaps into something... not 16-colored. This causes corruption when the images are imported by ModKeen or KeenGraph. Gash will use the .NET image loading routines to accept any bit depth. If slightly wrong colors are used (I'm still not sure whether EGA white is supposed to be $FFFFFF or $FCFCFC), it will look through the palette for the closest match, use it if it is found, and warn if it's really far off.
• xGA format. KeenGraph only deals with graphic-planar EGA, as far as I can tell. Gash will support CGA and VGA as well, and row- and byte-planar EGA if any Keen-ish games actually use it.
• Configurability. KeenGraph does not support the use of custom chunk offsets. This is a very simple thing to do with FleexCore2, so Gash will support it.

Work on this may start tomorrow. I hope to have this done will all these features by Keen Day 2015.

FMod - v2.3.3

I performed further testing of the Dreams audio changes. I noticed that the patch generator was not adding the MAPDICT patch command - it was checking the old HuffCompressedMaps flag rather than the new (v2.0) MapType field. Additionally, I noticed continued problems with the Project Settings dialog. Some careful rereading of the code determined that it was operating on the same instance of AbiatharFileConfig that was held by the main form - it was writing changes immediately to the actual dependency file. So, if the user made changes and then clicked Cancel, no reload would occur, but changes would be written to disk at the next save. I made it duplicate the core configuration so as to not modify the main instance.

These changes and previous ones were released on the PCKF as v2.3.3.

FMod - Dreams Audio

During my study hall today, I made a big push toward Abiathar v2.3.3. I added code to the AdaptVersion routines on file configuration and templates configuration to copy over the new audio flag that disables level song assignment while allowing other audio management. I added the audio file patches for Keen Dreams and made AdaptVersion copy them into existing files. (This kind of thing almost makes me want to go back to the disastrous "profile" system from pre-1.4.)

Default audio files were added for Keen Dreams. Music Mappings now disables the left pane if song assignment is disabled, but IMFs can still be imported (if ImfStart and ImfEnd are modified appropriately - Keen Dreams doesn't have audio slots for IMF songs). Import/export works just as it does for other episodes. I also fixed the bug that causes the default song name to come up blank when importing an IMF. The fix was the addition of a single comma.

Some more testing is required, but v2.3.3 is almost ready.

Robotics - Looking Back

For team 7727, the 2014-15 FTC robotics season (Cascade Effect) has ended. We didn't do all that well, and I would like to take a moment to consider why it was so.

First, we didn't have very many parts to start out with. It looked like we had a lot of inventory because there was so much junk in the mess that was everywhere, but the number of useful parts was quite low. We also didn't have (and never got) all the parts of the field, so we never had a complete game set on which to practice.

Speaking of the field, its construction was something of a disaster. It took way too long (almost two months to become complete-ish) and we made a lot of mistakes. Those could have been avoided had we read the instructions instead of, say, drilling holes through the kickstand pipes and riveting them to the inside of the center assembly when there were small pipes with pre-drilled holes for that purpose. Near the end, there was the whole debacle of the ramp; we never did get that fixed. (Tape for the win!)

Another serious problem was that people couldn't come to meetings. Most of the builders were at some sort of sports thing during a bunch of robotics practices and some people skipped some meetings. I probably had the best attendance record of anybody, but I can only program and it takes more than code to make a robot. (I did compose and compile the entire engineering notebook, though.)

Returning to the problem with the lack of parts, we waited way too long to get critical pieces. This was not helped by the school administration busting into the robotics program this year; they required purchase orders before we could get stuff with our budget. These took days to process. The linear bearings we needed for the lift - a super important part of the robot - were 3D-printed, but it took almost a month from when we started needing them to when we got them. The AEA's printer turned out to be a waste of time and distraction.

Speaking of school administration and bureaucracy, the team rosters got all shuffled around a month or so into the season. Originally, they were chosen by a panel of teachers (who probably didn't know much about how the people interact or what their skills are) to make roughly equal teams. The coach reshuffled them to form a veteran team - my team - and a newbie team. This turned out to be a nice arrangement, but it really messed up our plans/relationships/expectations for a while after it happened.

With the lack of builders present at meetings, the robot was constructed very slowly. We had barely any time to test-drive it, let alone develop an autonomous routine. The lack of drive testing caused us to have unexpected problems - like breaking apart and/or getting stuck - during competitions. Though I had written some autonomous routines, our questionably-constructed field made them act differently at home than at meets. Of course, they weren't tested much in the first place because the robot was almost always on the build table being tinkered with, apparently inefficiently.

Maybe we'll do better next year. The coach said he would make a lot of changes. I hope those changes don't involve more bureaucracy or "team meetings", because those will do more to create problems rather than solving them.

Rickety Computer Name Resolution on Domains

Sometimes, Windows domains just aren't able to resolve the names of computers to IP addresses via NetBIOS. (This usually happens when the DNS server gets confused or out of sync with DHCP.) To fix this, I find installing the WINS role on a domain server helps. It maintains a central list so computers don't have to rely on the normal DNS system or SMB master browsers.

FMod - Some Issues

A few days ago, I had a conversation on IRC with an Abiathar user who was experiencing some problems. Apparently, the Project Settings dialog is quite broken in that moving to the Containing Folder step sets the dialog to the mode that initializes data to default values when a page is moved to. (That mode should be only used at the start of the New Project Wizard, which is actually the same dialog invoked differently.) Also, the function that checks whether a path is inside the residing directory does not handle blank paths, so if a filename box is left blank, Abiathar will crash when Next is pressed. This has been fixed, but not released publicly.

Also, it turns out that .NET refuses to reflectively load on-disk assemblies that have the NTFS Alternate Data Stream that says they came from the Internet. All major browsers leave that mark on downloaded files, and some ZIP extractors propagate it to the files in the archive when it is extracted. So, unless "Unblock" is hit on the Properties page, Abiathar will fail to load the ImfPreview extension. I can't do anything about this besides warn people.

Finally, I noticed that the default name (involving the chunk number) is no longer filled in when importing IMFs. I'll fix that and then release v2.3.3.