In the four weeks since the last snapshot release of the suite of assistive programs for players and Judges of Strategic Primer, I don’t think I’ve made many major changes. But development has continued, so it’s time for another development report and another snapshot release, which can be downloaded from GitHub as usual.
There have been a fair number of changes to the code, though development was fairly quiet in the past month. Very few of the changes should be noticeable to users.
As usual, the majority of the changes were attempts to fix warnings, or to suppress spurious warnings. I also, for once, had to revert a warning “fix” that had changed the semantics of the program, causing exploration to report the contents of a tile as being the contents of one tile over.
Many of the changes this month were in the exploration-running programs:
- In the exploration GUI, the list of units to select the explorer from is now scrollable, in case it exceeds the size of the window.
- I fixed a longstanding bug that caused a player’s headquarters fortress (which is always visible to and “discovered by” explorers, for the user’s convenience when using the command-line UI) to almost always appear twice in his known-world map after running exploration. To do this, I added checks in the code handling any attempt to add a fixture to a tile in the map that test the new fixture against any existing fixture on the same tile that has the same ID number to see if either is a “strict subset” of the other, and if so replace the original with the new.
- Similarly, I made that same code silently drop a Forest or Ground that is the same as that which is set as the primary Forest or Ground for that tile, to prevent duplicate fixtures in the map files.
- I adjusted the algorithm for deciding what an explorer discovers. Previously the programs chose one “fixture” at random (as well as certain things that are “always visible”); now, for any fixtures that have a numerical discovery difficulty, the program compares that to a baseline plus any modifiers from the explorer’s stats and Skills, and prevents the explorer from discovering anything that he or she couldn’t discover even with a perfect die roll.
- I made it impossible for a moving unit to “discover” itself.
I also refactored the “driver” code that loads the app the user has selected.
- I moved the reporting of incorrect usage (including describing what is correct usage) from where it is detected in every app to one central location in the code.
- I also centralized the code that asks the user to select the file to open if not enough files are specified on the command line.
- I improved the list of possibilities for the number of arguments desired.
- I added rudimentary support for drivers that don’t need to operate on a map file at all.
Other changes included:
- In the stat-entering and stat-generating program, I made the stat-generating function adjust generated vital statistics based on a worker’s race (elf, dwarf, etc.)
- I added icon images for resource piles and implements.
- I split most of the interfaces representing having a particular property (
HasKind, etc.) into two, one for having the property and one for being able to change it.
- In the map-reading code, I added a warning to tell the user if a Job contains only one skill and that skill has a “suspicious” name, by which I mean one that I used to use as a catchall for everything that Job does. (For example, “hunting.”)
- The About window, in its window title, would always say it was for the exploration app; this title is now based on the app from which it was called.
- I changed my wrapper around the standard output stream from one that merely asserted that it isn’t null to a slightly-more-heavyweight wrapper class to prevent it from ever being closed.
- I fixed an obscure bug that caused maps to sometimes never get updated or written. I had been storing maps in the driver models in a
Mapfrom the game-map to its filename, but the
Mapdata structure doesn’t support different entries with “equal” keys, so if two maps were “equal” one of them would silently disappear.
- I added rudimentary support for fixture (primarily unit) portraits. They are now shown in the map viewer and the worker-management GUI when a fixture with a portrait is selected.
- In the “query CLI,” which includes “turn-running” features for running hunting, fishing, trapping, and herding, I added code to optionally run food-gathering after herding with the Herders’ remaining hours.
- In the worker-management app, multiple workers (or any kind of unit members) can now be dragged and dropped at once. Note that if the selection also includes a unit or a group of units, these are ignored.
- Also in the worker-management app, dropping no longer needs to be so precise; if a worker (or multiple workers, per the just-mentioned new feature) is dropped on a unit member, it is added to the unit that contains that member, instead of the drag-and-drop operation failing.
- After discovering that the test API I use has built-in support for “parameterized” tests—tests that run the same code for each of the given “parameters”—and revised the tests that iterated over enumerated types (sizes and statuses of towns, for example) to use that feature instead.
- I fixed a bug where the menu item that was supposed to allow the user to change the current player was always ignored.
The Pivotal Tracker backlog is currently fairly close to what I’m hoping to get done in the near future.
At the top of the list 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:
- 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.)
- The worker stat generator should apply racial stat adjustments.
- 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.