FMod - Wizard UI Done

Ah, today I finally finished the UI for Abiathar's New Project Wizard. All the screenshots for the left bar have been taken and mapped; all the Next button instances are appropriately wired up. It needs a little bit more testing to ensure that nothing terrible happens if the user selects strange options, but this marks an important milestone in Abiathar. That Dependency Collector was pretty much the last holdout from my time making dense, complicated dialogs - and now it's gone! Well, I'll probably leave it in as an advanced option for users who are used to it and want to get a project started quickly, without dealing with a long friendly wizard.

Next, I'll need to actually write some new code to process the generated dependency file. If I do keep the Dependency Collector, it will need to generate a dependency file as well, instead of just verifying the file names. And, of course, I'll need to implement all the new features promised by the wizard's options.

FMod - Slightly Complicated Wizard

I've finished laying out the New Project Wizard, and it is possible to have to configure a maximum of 12 different screens, 13 if you count the "finished!" page. This makes the wizard way more complicated and long than I had originally wanted, but its steps are fairly easy on their own. I might have to make the old Dependency Collector an option, maybe marked "(advanced)."

It was very difficult to figure out a good way to arrange the tileinfo options. There's the old choice of whether to get tileinfo from a separate file, the MapHead, or memory (or nowhere, I guess), but now there's the choice of how to start it if you're not loading an existing file. Like the level files, this will be doable from a blank, the defaults, or an actual file.

The wizard UI is almost done. I just need to put controls on the Tileinfo File screen and get two more screenshots for the left panel. After that, it's time to code up all these new features the UI promises.

FMod - User Driven Development

Besides the normal development on the New Project Wizard, which hopefully will be all done within a week, I executed a few changes as a result of talking with a very important modder on the #KeenModding IRC channel. This person is still using an old Windows XP computer with barely any RAM, so getting Abiathar to work on it is a challenge.

Abiathar v1.4.1, the last public release, was successful in that it let him open his mod. Of course, due to his RAM situation and general oldness of the computer, scrolling with the arrow keys was extremely laggy. I'm still not sure how this is possible (it should be pretty much instant unless it trips the memory manager), but I did find some optimizable things. First, I moved the scroll detection to the top of the key-down handler. That helped a little, but lag was still happening. I tried changing the repaint call from that handler to use Refresh instead of Invalidate (to force it to happen immediately), but it made stuff slower in some cases, and I reverted it. Eventually, I added a config option to set how many tiles will be shifted per key down event, which should reduce the number of repaints necessary.

Also mentioned was the non-appearance of translucent colors (non-black pixels without the mask bit set). Fortunately, FleexCore already preserved translucent colors, so it was very easy to allow them in the image converter. It's not exactly how the game renders them, but it gives a pretty good impression of translucency.

Finally, he mentioned that it's difficult to get used to the function key controls for the plane states, especially having used other editors for a long time. Since this was also a problem for people whose function keys are permanently bound to other actions, I decided it was time to do something about it. The default is now TED5-style numbers for changing plane states, with the exception that 7-9 call the tilesets instead of the weird Space+number way. The old style can be enabled in the config file.

FMod - Further Wizardry

Wow, the New File Wizard is turning out to be a very challenging thing to implement. Today, I added a lot more of the necessary steps to the wizard, finishing the advanced settings and moving into the normal (easy for the user) configuration. All the new features I want to add are requiring a lot of new options.

The temporary CreationInfo substructure in the file config now uses an enumeration for the initial source instead of just a dump vs. open Boolean; it will eventually allow creating a blank level set in that format, which is easy for me to implement because they all accept the same type of individual level file. The GraphicsFiles structure has fields to hopefully support loading tiles from bitmaps.

Here are the new screens:

Configure tile counts and infoplane allocation, default for Keen Dreams (advanced)

Choose the dependency file's directory

Choose how to start the level project (the dump option only appears if using a template that supports it)

Choosing names of level resources

In that last screen, the names of the resource types change depending on the type of levels. (For example, had "TED5 MapTemp" been selected on the Level Format screen, "GameMaps" would be "MapTemp.") Of course, the MapDict row disappears when not using a level format that requires it. File existence checks are only done if starting from existing files.

FMod - Better Exporter

In addition to making small progress on the New Project Wizard, I did some major improvements and additions to the bitmap exporter! In fact, those additions necessitated the addition of a configuration substructure for it.

First, I added an option to preserve the zoom level. By default, Abiathar will export the level as if it was zoomed to the 16 pixels per tile level. Since one might want to make it look more pixellated (or get a farther-out view), they can now switch BitmapExporter.PreserveZoom to True and do the image export as normal.

Then, I added an option to remove the two-tile-wide level borders, which usually just have bunch of ugly "edge of map" tiles, present only to appease the in-game renderer. When that is turned on, Abiathar will render the level as normal and then grab the appropriately sized rectangle out of the middle.

Finally, I added a way to export the level image without having to type a filename. If BitmapExporter.AutoFilename is not blank, it will be used as a template for the filename. There are a few special "entities" that Abiathar will replace before saving:

• %l is the current level's name
• %n is the current level's ID
• %p is the Abiathar residing directory
• %d is the dependency file residing directory
• %f is the dependency file's name without extension

So, the AutoFilename string %d\%f_%n_%l.bmp saves the file in the dependency file's directory with the depfile's name, level ID, and level name in the file name.

FMod - Wizardry

Despite important things like college happening, I have made some progress on Abiathar. The current focus is the New Project Wizard, which will serve two hugely important purposes: improve ease of use and make it easier for me to expand to new formats.

Today, I eliminated the Back button, which was causing huge headaches for me because users could go back and prompt total reorganization of settings, which could totally blow up everything they had set up. I personally think that the occasional use of a Back button in creation wizards does not justify the huge pain that it is to make work properly through all the possible paths.

I also filled in three steps: Template, Level Format, and EGA Layout. All the format/layout steps will not appear unless the user chooses to start from a blank slate.

This is what they look like:

The default view of the Template step

Default view of the Level Format step after selecting "Keen 4" and "inspect advanced settings" in Template

Default view of the EGA Layout step with the aforementioned Template settings

You'll notice a large "From GFXINFOE" button on the EGA Layout step. This allows users to take a TED5 graphics accessor instead of typing in strange numbers. (This is designed for Bio Menace.)

Also, I added a new menu option under View: "Export Image." This allows the user to save a .bmp of the level being viewed in Abiathar, with all the current view settings except offset, zoom, and grid. Things are rendered in the bitmap only if they appear in the level view - there is no code duplication.

The Race to Artificial Intelligence

Here are some things I know:

• In computer security, there are two groups: the good guys and the bad guys.
• People are trying to develop artificial intelligence.
• Intelligence-singularity machines can modify and adapt themselves.

It hit me while thinking about these things that the race to artificial intelligence is more important than which people/companies are going to get super rich. I believe that the first infosec "side" to acquire real, adapting AI will be able to claim total victory.

It's very well established by now that every piece of software contains bugs. In fact, entropy pretty much guarantees that something is going to go awry if you run a process long enough. And as we saw in Heartbleed, little issues can explode into big trouble when exploited. One vulnerability opens another, and pretty soon you've got everything compromised. (The Walmart credit card stealing malware got in through a noncritical system.)

Artificial intelligence is going to be really good at understanding binary files, even obfuscated ones if it's smart enough. It's also going to be really good at crunching large amounts of information, correlating data with other data in nontrivial mappings (understanding context), and checking every contingency.

The way issues are found (both bugs in a process and errors in code) is by trying every possible path of input to see if it ever does something it shouldn't. Eventually, we will have AI sufficiently advanced to analyze a piece (or a bunch) of software and figure out all the bugs, including a lack of detection by a monitoring application (it'll figure out what causes a malicious program to not trip a virus scanner). This is what the race is towards.

If the good guys get it first, they'll get to analyze every program for holes that would allow an attacker to get it where it shouldn't be possible. Now, since bugs are always going to happen, things are still going to be tough for the heroes. The only way I see them winning is to have perfect integration between the user's definition of "working properly" and virus detection. This is a different application of AI: it needs to be able to tell what is going to produce a state that the user does not desire. The brute-force aspect of decision analysis comes in again: it has to figure out what the change in state will do to every aspect of the system.

There's also the in-betweenish case of the good guys who will be good by virtue of eliminating the bad guys. Basically, fighting fire with fire: use the AI to detect security holes, exploit them to get into the bad guys' stuff, and make it impossible for any computer to run another AI ever. It sounds Communist, but it might be the only way to win.

If the bad guys get it first, they'll be able to (again) analyze all the things, but they're not interested in fixing it. Instead, they'll set up vast networks of zombified computers, analyzing every program ever to break into everything. Once every vulnerability is cataloged, the AI can create programs to exploit it. Mass information theft, large-scale denial of service, and general badness ensue. Since they got AI first, they can analyze the problems that will be in the good guys' AI, thereby staying a step ahead. (I'm assuming that computational power is equal.) This is why time matters: AI needs time to adapt.

Alright, stop reading my blog and go develop AI for the good guys. Time is of the essence!