It’s been four weeks since the last snapshot release of the suite of assistive programs for players and Judges of Strategic Primer, and unlike the previous month there haven’t been many significant changes. But it’s still time for another development report and another snapshot release, which you can download from GitHub as usual.
As usual, most of the month’s changes were warning fixes, suppression of unwarranted warnings, and other such “basic code maintenance.” But there were some other items of note:
- I added a new helper program to produce a set of “tabular reports” (in CSV format) from a map, listing (for example) the location and distance from HQ of every animal population the player knows about.
- I changed the command-line options for the report generator and the “query app,” so that
--cli --mapnow invokes the report generator (previously it was
--cli --worker), and the query app is now
--cli --queryinstead of
- In the drawing code used by the map viewer (and the exploration GUI), if a tile had a “terrain fixture” (such as a forest, mountain, or oasis) “on top” but also another “terrain fixture” beneath it, the feature to change the background color to represent the hidden “terrain fixture” previously didn’t get triggered. I fixed this, so that the test for “a hidden terrain fixture” now works even if a different “terrain fixture” is “on top.”
- The map-readng code now warns if a tile contains a laterite stone deposit but is not a jungle. (Reading that article reveals that this isn’t quite right, since laterite is found in tropical plains and steppes as well as rainforests, but I consider this close enough.)
- I switched the “map reader adapter,” which is the central class that everything except test code uses to read map files, to use the new reading code (as I thought I had done weeks before).
- I adjusted the “Z value” of ground slightly, so that an exposed piece of ground is always visually “on top of” any unexposed ground.
- I ported all test code from the “deprecated” JUnit API (
assertEqualsetc.) to the “preferred” way of writing tests, using “matchers” and
- I expanded the tests of the map-conversion code, as the first step in improving test coverage generally. That project continued to a few other areas of the code, though it did not get nearly as far as I would like.
- While doing that, I fixed a bug in the version-1 to version-2 converter, that declared a subtile open for a new fixture if any of its fixtures was a “background” fixture (forest, hill, etc.), instead of if all of its already-placed fixtures were, as I’d intended.
- There was also another bug in the version-1 to version-2 converter, that it made some modifications to the map it was asked to convert; I fixed that by having it immediately make a copy of the map and modify that instead.
- In the original-to-version-1 converter code, I fixed a bug that made the converter noisily break if the XML used namespaces; this took me a good while to figure out how to do.
- I’ve had “maybe use Guava‘s multi-maps” on my mental to-do list for several places in the code, but have resisted adding that library as a dependency. As a stop-gap solution, I added a not-quite-
MultiMapthat works moderately well for those places.
The Pivotal Tracker backlog is currently fairly close to what I’m hoping to get done in the near future.
One item that would be at the top of the list if I had any idea of where to begin is making a Mac-native “application bundle” that actually works (I would say “fixing,” except none of the versions I could test worked at all), followed by other adjustments to make the suite behave like a native app on the Mac platform.
Other items on the roadmap are:
- Adding a mining-model generator that fits products like sand better than the “vein-oriented” current model.
- An app feature to suggest combining resources in a single tile that are identical in “kind” and “name” and use identical units.
- An app to allow the user to view and manage his treasury, armory, etc.
- In the worker-management app, the user should be able to apply orders to multiple kinds of units, or multiple units of different kinds, at once.
- Change the way unit orders are represented so they can be set per-turn
- Add support for unit results to the map format
- Make subset checking treat location as another property, instead of treating a fixture that moved as a ‘new’ fixture in its location in the subordinate map.
- Fix the performance maybe-issues: that I use Swing APIs that “best practice” (according to my reading) recommends not using for loading images, drawing images, and limiting the drawing area
- Make the GUI execute some operations in parallel to the GUI-update thread
- Anywhere the GUI allows the user to cause a fixture to be created, allow the user to enter an ID #.
- Add a way for the user to preseed the ID-numbers-in-use cache with a map without actually opening that map. (That is, without leaving the map open—I don’t intend to reimplement, or shell out to call,
- Convert the “Display …” menu to a panel containing checkboxes that the user can drag to set a custom display-sort order to control what appears on “top”.
- As a user requested, when zooming in using the mouse scroll wheel, the zoom should center on the mouse cursor. (The ‘center’ menu item and hotkey help with this, but it’s still a good idea.)
- Make the apps behave (more) like native apps (following human-interface guidelines) on the major platforms, starting with Mac OS X. The Window menu is a good start, and finally works, but there’s more to do. I need to enumerate what more needs to be done …
- Changesets need to become a priority, because maps are no longer immutable from the players’ perspective. First, I need a list of operations that need to be supported.
- The turn-running helper apps should be able to tell me such facts as how much meat any given animal produces, how much grain should be produced in a harvest, etc.
- Related to that, “resource management,” eventually including modeling resource production and accounting in the map and the helper apps.
- Something like the mine-model-generation program for stone deposits. However, I currently make do with the existing model, just with different proportions for each level.