The first thing to mention is that I fixed some bugs with the hierarchical view in the worker-management app, which I introduced in the last release.
- In the last release, the tree had not updated when a unit or member was renamed or had its “kind” changed.
- when the last unit of a “kind” was removed or moved to a new “kind” that entry in the tree remained
- New units were added to the tree at the top level, rather than under their “kind.”
- Drag and drop of workers between units didn’t work
I also made a few other improvements to that program’s user interface:
- The “orders” field now wraps long lines rather than requiring the user to scroll right to see its contents.
- The “visual warnings” showing when a unit’s orders contains “TODO” or “FIXME” now also applies to the top level of the tree (the “kind” or category of unit) if any unit under it is affected.
- Since units’ “kinds” are given by the place they are in the tree, describe them only by their names rather than repeating their “kind” again.
- In case the user (usually me) gets the tree into an inconsistent state, there’s now a menu option to make it reload its data model.
- The tree of units and workers (and the tree of Jobs and skills in the advancement program) now starts out fully expanded, rather than fully collapsed.
I’ve long had in mind to implement a “Window” menu, and make other improvements to fit the Macintosh Human Interface Guidelines when on that platform, but before this month I had made no headway. However, this month I figured out how to make it work, so every major window now has a “Window” menu that lists the other open windows (in the same process; if you open another instance from the operating system, its menu will be separate) and tries to indicate minimized windows. I also tried to make it indicate which window is current, but failed on that so far. Moreover, for the sake of the usability of that menu and to comply with the Macintosh guidelines, I made each window’s “title” start with the name of the file it’s operating on, which I also store in a “property” that the Macintosh guidelines say to use.
As part of that last change, I made one breaking change throughout the API (which is not considered particularly stable yet), to use File objects rather than strings to represent filenames wherever filenames were stored.
Other changes mainly focused on programs that players probably won’t need to use:
- I added an option to the “query” command-line interface to calculate herding results, to save me time looking up the formula and doing the calculations.
- I made yet another attempt (I think I was successful …) to fix a longstanding and frustrating bug that made the exploration GUI not copy the terrain type of explored tiles to the player map.
- In the advancement GUI, I added a way to add hours of experience to all workers in a unit at once. However, this still has a bug that makes every worker in the unit have every Job (not a level in that Job, just a reference to it) that any worker in the unit has.
- In the subset-checking programs, I added logic to compare “corresponding” (equal-ID-number) units in fortresses or out in the map in much more detail (down to skill level or hours of experience) rather than treating them as “extra” fixtures.
The list of “planned” features (which has debatable correspondence with the Pivotal Tracker backlog, remains largely unchanged from previous months except for the features I’ve finally been able to cross off.
The first item is to make the apps behave like native apps (following human-interface guidelines, etc.) on the major platforms, starting with Mac OS X. I’ve something of a start on this, but getting any farther will be tricky.
Second, with it possible for players to make changes to a known-world map using the “helper apps” (rather than just a text editor) and send it back, changesets need to become a priority.
Third, I want to “finish,” test, and switch to (once I’ve demonstrated it won’t lose data) the new map API; this may make developing changesets easier, and it’s possible it’ll bring performance improvements, but we’ll have to see.
Fourth, I want to write programs to automate the more tedious parts of running a turn, such as agriculture, herding, food gathering, and hunting—the latter three are much better now, but how much meat any given animal produces, for example, still has to be looked up by hand.
That ties into the fifth item on the list, “resource management,” eventually including modeling resource production and resource accounting.
Sixth, I hope to add larger images (“portraits”) for units and some other kinds of fixtures.
Among other planned features.