It’s again been two months since the last snapshot release of the suite of assistive programs for players and Judges of Strategic Primer, and there are again some noteworthy new features, so it’s time for a new development report and snapshot release, which you can download from GitHub as usual.
There is one major new feature, one bug fix of a minor but lingering and annoying bug, and one new feature that’s almost as important to me but less so for most users.
The “headline feature” is that the “stacking order” that determines what fixture is “on top” in the map viewer is now dynamic, determined by the placement of items in a panel, items that the user can drag and drop as well as check or uncheck to control whether the kinds of fixtures are visible at all.
The other feature is that drivers can now take options (which have to start with
-, but can have parameters, with later invocations overriding prior ones), and multiple drivers can now be specified on the command line (including one driver multiple times …) If using this feature, give the option for a driver, then the parameters to pass to the driver. Options are reset to the defaults for each new driver, with maybe an exception or two.
The “headline bug fix” is that I think I’ve finally fixed the problem that was causing GUI apps to stay running even after the user closed the last window.
Other changes include:
- In the advancement CLI:
- The driver tries to report when a worker has gained a skill level. (This still doesn’t work consistently or very well.)
- The list of units to choose from now omits all units that do not contain any workers.
- When adding a new Job or Skill to a worker, the driver tries to select it automatically, instead of saying “select the newly created Job at the next prompt.”
- The user can choose whether to advance workers individually or all in a unit at once at the unit level, not just for all units or none.
- Units can now know results, and also orders and results from more than one turn at once.
- In the report generator, in the sections that produce the “report tree” for the worker management driver:
- The unit and fortress sections try to avoid generating “spurious parents,” nodes with no content of their own and only one child.
- The version of the report that is used for the “report tree” now includes resources and equipment, and resources are grouped by kind.
- Reports describing units that include orders and/or results now include those.
- I fixed a nasty crash in the exploration GUI when it was given only one map.
- When a player discovers (the existence of) a portal to another world, the portal’s destination should now say “unknown” at first, instead of being copied from the main map verbatim.
- Similarly, foreign fortresses’ names are “zeroed out” to “unknown” when first discovered.
- Fortresses can now be any size (of “small”, “medium”, and “large”, I think, with “small” still the default)
- In exploration programs, explorers now always “notice” any “owned” towns (including villages), not just fortresses. (This feature is to help me run a journey to a known location, which otherwise would include some wasted time trying to find it.)
- On the other hand, when an explorer swears all villages on a tile to its player’s service, we now ensure that all the villages are in the player’s map after doing so.
- In the stat-generating app:
- I fixed a bug that caused workers who had been assigned multiple levels in the same Job to have only a single level recorded.
- The user can now assign the human racial stat bonus (“to a stat of your choice”) to the lowest stat.
- When new workers are added to a unit, if the unit doesn’t have any orders, its orders are set to “TODO: assign”
- The strategy-exporting feature of the worker management driver uses orders from previous turns if there are none from the current turn, but marks them as such.
- Forests now have unique ID numbers in the XML. Unlike pretty much everything else, they are not assigned “the first vacant ID” when reading from XML if they don’t have one, but instead are given the same “-1” that they used to have, and the EchoDriver assigns the first Forest in a tile an ID based on its location in a range that, until I did this, was above every ID number in the main map. (It assigns “the first vacant ID number” to other Forests on tiles, but after everything has been loaded.)
- The report-creation driver now can take an option (
--out=/path/to/file.xml) to specify the output filename.
- The worker-management driver can now take an option (
--print-empty, passed on to the strategy-export feature, which is fairly self-contained) to include empty units (containing no workers or other members) in the generated proto-strategy.
- I made subset checking more robust in the face of ID number collisions (it broke badly when such collisions were pervasive, as I found when I changed all IDs in a test map to -1 to fix “magic number” warnings in test methods)
- Most drivers now accept an option (
--current-turn=##) to override the current turn that is stored in the map files; if a map is written back out to file, it contains the turn number that was passed on the command line.
- Drivers can now customize their usage statements (describing their arguments as, for example,
playerMap.xmlinstead of just
filename.xmlfor all, and listing the options they accept)
The Pivotal Tracker backlog is currently fairly close to what I’m hoping to get done in the near future. Notable items include:
- 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.
- 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 remaining 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,
- 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. A working Window menu is a good start, 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.
- I’m trying to increase test coverage to as high a level as possible.
- Now that there’s a Ceylon plugin for my IDE, I want to either update the Ceylon port, or start porting to Ceylon again from scratch.