It’s been more than two months since the last snapshot release of the suite of assistive programs for players and Judges of Strategic Primer, so it’s long past time for a new development report and snapshot release, which you can download from GitHub as usual.
The headline feature is that I think I’ve figured out why no Mac OS X package I built ever worked, and “fixed” it, so the
.app (and the DMG, which just wraps that) should work now. (I put “fixed” in quotes because the problem was that the third-party script I use to avoid bundling the JVM doesn’t handle an app “short name” with spaces in it properly, so I simply took the space out, so you’ll see “SPHelpers” instead of “SP Helpers”.)
Other changes include:
- Additional and improved tests to improve test coverage.
FileChooserclass, which the suite uses to wrap Java’s awkward file-chooser API, assumed that a result of a file that didn’t exist meant the user didn’t choose a file; this meant the normal procedure of exporting a proto-strategy, for example, to a new file didn’t work. This is now fixed.
- As usual, I fixed many IDE warnings.
- In the query CLI:
- I extended the model of herding to include more possibilities, primarily in the area of poultry.
- I added a command to find the nearest obviously-reachable unexplored point.
- I changed the exploration CLI to use its driver model more directly, such as always moving the unit the model has selected instead of taking the unit to move as a method parameter.
- I moved the notion of statistics from the
Workerclass up to the
IWorkerinterface; some of the simplification this allowed me to do may have fixed the problem of dismissed workers still remaining in the map when “proxies” are being used in the driver model.
- If the user chooses “Save” or “Save All” from the menu, but a map that is to be saved wasn’t loaded from a file, this gets converted to “Save As” (which asks the user to choose a file). Unfortunately, this new filename doesn’t get recorded, so the user will be asked again if he or she chooses “Save” or “Save All” again.
- I fixed one of the potential performance issues (not that I’ve done the profiling, but the nominal-experts I’ve read say the method “has poor performance”): the
ImageLoaderclass now avoids calling
- Everywhere we construct a filename in the UI or in logging code, we now use the platform-specific path separator, instead of always the forward slash (
- I added, and now use throughout, a wrapper class to prevent the standard input stream (by which the user inputs anything on the command line) from being closed.
- I changed the current XML I/O implementation to use the Java XML-output API instead of writing the XML “by hand,” so that my two implementations are not essentially identical.
- I fixed a bug in the exploration CLI that caused it to crash when the user selected Quit.
- The exploration GUI now requires at least two maps; this is not ideal, but internally it assumes there are at least two, and breaks badly if that assumption is not met, so the code now makes it explicit and up-front.
- I significantly reduced the amount of information that gets logged to the console by default.
- The report generator now groups resources, equipment, and animals separately from other unit and fortress members.
- In the exploration GUI, if the user presses Enter while the cursor is in the movement-points field in the explorer-selecting panel, the app treats that as if he or she had clicked the button to advance to the next part of the app.
- In the duplicate-fixture-removing app:
- I split the functionality into a separate class from the “app” part
- I made it ask for confirmation of each action it takes
- I made it offer to combine “like” resource piles (in the same unit or fortress, created on the same turn, of the same “kind” and “contents,” having the same units) in addition to removing duplicate-but-for-ID fixtures.
- Nearly everywhere a CLI asks yes-or-no questions, the user can now say “always” or “never” and have this “yes” or “no” answer be taken automatically (without further input) for every similar question for the rest of this session.
- In the code to support the old exploration model (encounter tables, etc.), which are retained mainly so we could at need reproduce the process by which the current map was produced, everything now takes the dimensions of the map instead of operating on an assumed map size.
TableDebuggerclass, a support program for the old exploration model, now implements the
ISPDriverinterface instead of having its own
main()method. It is not, however, available from the
- The mining-model generator now offers a way (at the moment, make the initial state number negative) to try to produce a “banded” or “layered” mine, which is a somewhat better model of, say, sand or clay.
- The big “dist” tarball, which contains full source plus the binary “class” files and the generated documentation, now includes more of the repository’s files that aren’t Java source, most notably the configuration files for the IDE I’m now using.
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.
- 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 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,
- 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. 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.