Workaround for Slime Spawning Bug in Minecraft 14w21b

Minecraft 14w21b, the newest snapshot most server administrators trust to not ruin all the worlds, has one annoying bug: Slimes don't spawn. This is actually a really huge problem if you need sticky pistons, which are necessary for automation. Fortunately, using /summon to create Slimes still works.

So, you can use this fact to create an administrative contraption to simulate normal Slime spawning. Do something akin to this:

• As a server operator, switch into Creative mode
• Find an unobtrusive spot in a spawn chunk for a small box
• Create a multiplicative hopper-dropper clock
• Configure it to pulse every two hours (or whatever you'd like)
• Hook it up to a command block with the following command:
• /execute @e[type=Creeper] ~ ~ ~ /summon Slime ~ ~ ~

This command will spawn one Slime at each Creeper. You could change the type, but I recommend Creepers because they are only found in the Overworld and are not spawned from any spawners. So, with this device set up and operating in a spawn chunk on your server, you'll be able to hunt Slimes in a fashion similar to the non-bugged behavior.

FMod - Reported False Positive

Just a few minutes ago, I reported the Abiathar v1.5 files to Avast as a false positive. They actually have a really nice contact form with a simple file uploader to give them things. Hopefully, they'll figure out some way to make the antivirus not freak out.

FMod - Antivirus Issues

I have received reports from members of the Keen modding community that Abiathar is setting off antivirus alerts and generally being misidentified as malware or a PUP. I wrote a little post on Keen:Modding about it, which has been adapted here.

I did a VirusTotal scan of it which came up fully clean, except for the Heuristics thinking that it's possibly a PUP. This is due to it packing executables (the updater, but mostly the DOS programs, especially CKPatch, in the File Emitter). 

FMod.dll (FleexCore) contains a whole bunch of bit-twiddling methods necessary to open the graphics, levels, and tileinfo. It's doing low-level operations from a format spec standpoint, but from a managed environment, so this probably isn't the issue. 

The new memory manager might also be causing trouble - there is a possibility that what I'm doing with the memory manager to throw out my cached view states is similar to the way some viruses get into protected memory. 

Antivirus hates the updater because it is, in essence, a benevolent and non-controlling remote access trojan. It works by checking my Dropbox for a newest-version file, using that to find that version's update script, and then running that script according to some very specific and safe rules. The AV programs are right to be suspicious of such activity, but I promise that the updater only updates Abiathar. 

The config files are probably disappearing because Avast likes to place (without telling you) suspicious programs in a "sandbox", which restricts their ability to create files. 

Finally, it now comes to mind that by loading extensions (did I mention the program has an extension API?) from appropriately named dynamic link libraries in the residing folder, Abiathar transfers control out of my safely engineered code. Please don't install Abiathar extensions if you don't trust the publisher. 

So, I'm sorry about this. There are a lot of things that AV can be paranoid about, but it's all quite legitimate. Please trust me :/

Copying Drives without Expensive Software or an Extra Drive

Just now, I needed to duplicate a drive, and so I did Internet research and came up with a nice-looking utility to do it for me. The one I found was free, but there were a whole bunch of super expensive ones (even recommended by PC Magazine). I installed it, fired it up, and found that it would not let me copy the current (OS) drive onto the blank drive I had just inserted. It's apparently not going to let me have cloning access to the OS disk because the files are in use. To use that approach, I would need to boot from a different media and copy that drive to the blank one.

So, I thought of another approach, taking advantage of Windows's awesome RAID capabilities. In Disk Manager (after booting from the drive I wanted to clone), I set the blank disk, which is of the same size, to be a mirror of the OS drive. It's currently "resynching" the RAID-1 arrangement, but when it's done, I'll have a perfect copy of the drive. To make sure the new drive doesn't try to assimilate others that it finds, I will disconnect the RAID when it's finished. Since using Disk Management to remove the mirror would erase the drive, I will reboot the computer physically removing one drive from the machine, open Disk Manager to verify that it says "Missing" for the other drive, and remove the mirror. This will be done again for the new disk.

Once this procedure is complete, I will have a perfect copy of my drive - done without expensive software or a third boot medium.

FMod - Infoplane Override

Today in Abiathar, I got to hunt down a really awful level-corrupting bug! After the refactor, saving Keen Dreams levels with tileinfo in the map header caused the levels to become totally corrupted (unrecognizable even in a hex editor). It turns out that I had totally misused the optional parameter on DreamsLevels.ToFiles method, thinking it was a flag on whether to save tileinfo with the levels; it was actually the flag to force Huffman compression. Since Abiathar tried to avoid doing the expensive Huffman compression and hadn't set up the levels for recompression, it proceeded to totally mangle the data (really slowly too - it took almost 20 seconds to "save"). After using the correct positional optional parameter (inserting one comma in the code), everything was fine. Programming is hard!

Then, I found that the "changed" events don't fire on UI controls when the value property is set but actually sets what is already in the control. This is actually a massive pain - I was trusting that the event would trigger the controls to save their data into the dependency file in the New Project Wizard. This caused dependency files created on the second run (in one launch of the main application) of the NPW to be missing default data. It was annoying, but I fixed the problem by manually triggering each event in the appropriate Next button press.

Most interestingly, I implemented a new feature! Gridlock's Infoplane Override - having a different tileset for the foreground than the infoplane that uses the entire foreground ID range - is now officially part of Abiathar! It took a little bit of debugging to get right (mostly due to my thinking at first that the bitmap tile sheets are 13 tiles wide instead of the actual 18), but all the tileset components actually work really well with it. It was very simple to make the necessary adjustments to negate the infoplane division and ignore Assimilate Infoplane in the tileset wrappers. I suppose this is the benefit of having a good object model and API!

FMod - Actual Bio Menace Support

Ah, today I finally got to write the new unified dependency file loader. This was actually a lot easier than I expected. There were about three pages of code that the function replaced, and it is about two pages long. The Open and New menu items now call this with a minimum of stream shuffling. That's all great, but the new features it allows are really awesome.

Testing is not fully done, but it should be able to understand the two new level formats (MapTemp/MapHead and MapTemp/MapTHead) and bitmap tile sheet graphics. I have confirmed that Bio Menace is fully supported! Abiathar is able to load its levels, graphics, and tileinfo; modify the resources like it could Keen; and save it - the game will use it! Now, I just need to implement Infoplane Override, test more things, and Abiathar v1.5 is ready!

The first level of Bio Menace 2, loaded in Abiathar

FMod - Another Refactor

Yay, Abiathar's New Project Wizard is finally complete! I made a few minor adjustments to it today, mainly incorporating the old Dependency Collector as an option. That actually required quite a bit of code to be added to the DC's finish procedure (to convert it to the new way of storing creation information), but it's now a valid third path on the NPW. With that finished, I can move on to refactoring the file loader to use a dependency file instead of a bunch of streams.

That is turning into quite the task. Besides what I expected - the level and tileinfo loaders - the graphics handlers everywhere need to be rewritten. With the promise of bitmap loading (and the infoplane override), I can't depend on the EGA graphics object to provide the tile counts. The settings, however (by some weird placement on my part), are still stored in the chunk settings structure. So, with a little adjustment to the state wrapper and some redirection to use that state wrapper, the tile counts should work again.

I don't think a lot of things use the graphics object directly, so that's nice. I'm replacing it with an interface, IAbiatharGraphics, that simply serves Bitmap objects from a tile ID and plane. Most of the logic from GetCachedTile has been moved into the EGA implementation, leaving that function appropriately named. The bitmap implementation is proving to be more tricky. Thanks to the multiple graphics exporters (mostly ModKeen and KeenGraph) and their various switches and add-ons (grouting for KeenGraph and the KeenGrout utility for ModKeen), there are quite a few configurations of tilesets. My loader has to detect and understand them all, which thankfully can be done simply by looking at the width of the image. It uses that to select a function to find the position of a tile in the tileset image and then uses Graphics.DrawImage to copy that tile out of the set. There are also various transform functions in use to make everything be transparent in the right places (yay, explicit masking).

Currently, it can't do anything because the file loaders and graphics managers are totally broken. I think I'll be able to get most of the pieces tied together tomorrow, and then I just need to clean up the edge cases.