Mobile Solution, and (Re?)inventing the Wheel

I've settled on an IDE called tIDE. It doesn't seem to be very popular, but I find it to be amazingly quick when set up on a flash drive, it's remarkably small, and it works quite well for everything I need. It's not Netbeans in terms of some convenience features, but it's actually survivable to use it for programming on the go. Compiling and running take a little bit of time, but that's because I'm running the JDK and JRE off of the same flash drive, which is not an inherently quick method for it.

Overall I'm quite pleased with the result, but I'll keep you posted if something happens to change my mind.

Now, I know, I was almost done, right? But no, I've decided to go back and play with the Matcode Interpeter I've nearly finished. In terms of hard stuff, I'm not doing too much. I've decided, however, to use a Material class rather than a string for the Matcode it edits. What's this mean? Well, a number of things:

• Editing a single character in the MatCode is a bit easier and mostly more accessible, as the method is stored within the Material class.
• The eventual creation of Materials will be easily managed through just the MatCode Interpreter (/editor), as the new Material object will be made and then uploaded to the database.
• The graphic panel displaying a material's stats will be accessible by any and all objects that need to reference it, quite easily.
• By moving all the buttons and panels I've been making to within the Material class, any panel throughout the entire simulation that needs to view or modify a Material can easily access all the tools that can be used for it.

In all, it's a more thorough form of isolation and encapsulation. It's also the general strategy I'll be following for all of the objects in the game from this point forth. In hindsight, it's blaringly obvious, but, well, hindsight's always 20/20.