Access Macro Designer Needs AutoComplete

Those who work with Microsoft Access frequently know that it has a somewhat special macro system compared to the other Office applications. The default is a visual designer, allowing the user to insert control flow structures and some other common programming-ish tasks. Something common when creating advanced databases is the display of message boxes, such as confirmation dialogs.

The visual macro designer makes this incredibly difficult. By not having VBA-like autocomplete, it makes the message box property constants essentially inaccessible. (In fact, I'm not even sure if it accepts the textual constants.) To create a confirmation dialog, the macro writer must enter the numeric constants - which, in addition to being almost impossible to remember, need to be mentally binary-OR'd together to combine attributes (like having Y/N buttons and an exclamation icon).

That renders the macro designer considerably less useful. Please, if you require numbers to be passed as arguments and don't want to use a bunch of Boolean arguments instead, give some autocomplete functionality or at least provide a way to use mnemonics.

HigherPower - Oh, Right

While in the car today, a realization struck me concerning HigherPower's increased world generation time. (In the middle of all the crazy busyness going on in my life right now, I don't have time to actually write about important things here.)

A configuration file option tells the HigherPower world generators how many ores of each type to place in each chunk. If I remember correctly, 200 Fleexium and 2 Eethur ores are generated per chunk. It doesn't take a lot of time to pick 200 random locations and try to put an ore block there - but what does take a lot of time is continuing the pick random locations until 200 blocks are filled with ore. This takes even longer for Eethur, which has extremely specific spawning conditions.

Now I feel somewhat silly. Instead of trying to generate a maximum of 200 ores per chunk, I'm forcing it to place all 200 somewhere. With the 1.7 world generator bringing a lot more variety in the underground block types, this resulted in a huge slowdown for HigherPower, which only places its ores in regular stone. I suppose I'll soon be changing the code to use a maximum of some higher number.

Mental program optimization! Gedankenexperiments!

HigherPower - Network Time

Well, I decided it's finally time to look at some Forge tutorials and get HigherPower's custom packets and network functionality back together. Getting the infrastructure for it set up was a breeze; I love Netty! I still need to figure out how to actually move my data into The New Way, but I'm guessing NBT serialization hasn't changed terribly much.

Instead of doing what I planned to do, I tested some considerably less related stuff. The Furnace Sensor, one of the most difficult things to implement, surprisingly didn't have any huge problems. It did cause a crash, but that was because I had some something obviously silly with Block objects that caused a null pointer exception. After repairing that, the sensor worked just like before. (Even the incredibly inconvenient GUI continued to be inconvenient!)

The Lawn Mower, possibly the most hacked-up glob of code I've ever written, is another story. For some reason, it decided to pull stacks of pumpkin seeds, redstone torches, and various flowers out of nowhere. Inserting null checks at various places fixed that, but the machine remained the super buggy thing it always had been. While trying to tweak that, I did somehow cause it to create a huge, writhing, expanding wall of lawn mower blocks whenever one started moving. I fixed that and also the old bug that made it not drop its contents when destroyed while moving.

HigherPower - Legit Names

Today, I continued to clean up the HigherPower code base after the move to Forge for v1.7. This involved much renaming of files and a little bit of JSON file writing.

Really, most of the time I spent was replacing @ForgeSubscribe and @EventHandler with @SubscribeEvent and liberally decorating methods with @Override. More functionality is intact than I expected; even the super-hacked /genhere command still works. The wireless redstone blocks worked almost immediately, except that their Creative inventory icons were rotated the wrong way. There were a few inconsistencies with implementations of _HPBlockContainer versus BlockContainer, but those have all been made better.

It did take me a while to figure out how to fix the PSY music discs. (Those are really important to the mod.) Apparently, SoundManager is no longer publicly accessible; sounds should be registered with ResourceLocation instances and JSON files placed in non-obvious locations.

Advanced data blocks continue to be broken, but other containers with GUIs surprisingly still work. For some reason, it now takes quite a bit longer to generate a new world, but I don't see any obvious performance problems in HigherPower's generators.

Ignoring such issues and instead being upset at blocks having wrong or default names, I embarked on a task of migrating the block constructors to the new string ID system. (It was actually at this point when I discovered the inconsistent class hierarchy.) Now, all of HigherPower's block classes register themselves in the constructor, saving me the hassle of doing that every fourth line.

The recommended way of gathering Nether Noir: a few stacks of glass and a diamond pick

HigherPower - A Huge Mess

With the switch to the Gradle build system and all the changes in vanilla Minecraft that came with version 1.7, HigherPower's code base became a huge mess of errors. I spent a couple hours today going through the at-least-sixty files and trying to get the project to build. Right now, I'm not concerned very much with things actually working; I just want it to run and not crash.

Most of the fixing was just mindless prepending of the letter I onto Icon and IconRegister. There were of course a bunch of things concerning the move towards string IDs, but I just had to change some variable types and some method calls.

What was really terrible, however, was the removal of public iterators in NBT tag objects. (They also, for some unimaginable reason, moved tag names into part of the parent tag's child map. This makes my life considerably more difficult when serializing.) It is no longer possible to just get a general list of all the subtags in an NBT list tag. I can get the number of items in the list, but I can't pull one out without knowing what type of things it contains - the methods are all specialized.

Also, the move to Netty for network handling has totally broken my advanced data machines, so I ended up commenting out pretty much everything about those. I'll deal with that later, once most everything else is actually functional again.

Registering items is mandatory now, so I had to put that registration instruction in the constructor for my items. I'm very happy that I have a class for such things. There are a lot of missing textures, but I can fix that by renaming the files to suit the new style.

FMod - Consolidate Project

I have decided that the Abiathar project format is a go-ahead. Managing dependencies in a binder file is confusing for new users and mildly inconvenient for advanced users. It is literally the only system in Abiathar that I don't like. So, I'm going to fix it, because that's how I roll.

I took some time today to sketch the IO methods for the Abiathar project file class. The file will contain a bunch of headers denoting types of resources, user-friendly names for managing things in UI forms, and of course the disk representation of the various resources. The goal of the format is to be forwards-compatible, allowing old versions of Abiathar to load and save newer-version projects without wrecking everything. All resources needed to render the levels will be saved in the project file for easy mobility. Paths to reload the resources from can be specified to update them if on a computer with the appropriate files.

Once this format is done, I'll have to totally redesign the Dependency Gatherer. I'll likely end up making it a more user-friendly wizard with some resource management options sprinkled throughout the Edit menu. It might be necessary to get some kind of migration wizard going to move the dependency binders over to project files, but it should be pretty easy to just create a new project file with the edited levels.

This will also make it massively easier for me to add things like palette remaps or custom infoplane icons. Change is exciting!

HigherPower - Back to It

The Forge team decided to move to Gradle for code management. Therefore, every modder is forced to use that system, whether they like it or not. Until today, I could never get it to work - there was always some setup error or Eclipse couldn't find the files necessary to run the project. Somehow, everything lined up just right and Gradle built everything smoothly today.

Of course, like every Forge update, the update to Minecraft 1.7.2 broke everything. Literally all of my mod files have some sort of error in them. HigherPower is nowhere close to compiling, and a huge amount of its dependencies in Forge for 1.6.x are no longer extant or have changed names. (IconRegister, I'm looking at you.) Instead of the old way of doing packets, through the Forge networking infrastructure, it's integrated with Minecraft's Netty streams. That might actually make creating advanced GUIs less painful, but we shall see.

Message to Forge team: This is totally unacceptable. I understand you need to get compatibility with the new Minecraft versions, but you don't need to rename everything. Seriously, just a one-character change you made, probably with one keystroke, is going to require me to go through uncountable files to deal with. I had to go search the Internet and ask for help on IRC to figure out that the Configuration class moved namespaces. Your product, even though you don't get paid for it, is in use by hundreds if not thousands of developers around the world. Any minor inconvenience you cause is multiplied by that.

I know what I'll be doing the next few weeks. Isn't forced refactoring fun?