It’s been four weeks since the last snapshot release-cum-release candidate, and in that time I’ve fixed several bugs introduced by the port to Ceylon, added a few new features, and done what feels like a great deal of refactoring. Because the first “release candidate” has seen only minimal testing, and I have introduced new features, I’m labeling this a second release candidate. Players, please try it out and let me know of any issues you run into! You can download it from GitHub as usual.
Since the version 0.4.9014-rc1, I’ve fixed a few bugs that were introduced during the port to Ceylon:
- The “short description” attribute of meadows and fields described wild fields and meadows as cultivated, and vice versa.
- The worker-management driver crashed instead of loading properly because the
BorderLayoutlayout engine is controlled using Java
Stringconstants, which Ceylon wrapped in Ceylon
- The report generator (which is always called, though in a separate thread, by the worker-management driver) could in some situations get into an infinite recursion, or conversely crash with a null-pointer exception.
- The worker-management driver would set the background color for painting nodes to yellow or red if units’ orders warranted that, but then left that as the background color for other nodes, so if any unit had
TODOin its orders, everything was highlighted yellow.
- In the worker management driver, the member-detail panel didn’t actually work; it never got passed any unit members, and so never showed their details.
- In the Ceylon implementation, rivers didn’t always get written to XML in the same order they had been read. They’re now capable of being sorted, and the XML writing code sorts them before writing.
I also added several new features:
- A new driver to enter or generate the contents of towns and villages (initial support for which was introduced last month
- The map checker warns about resource piles with placeholder data (which the town-contents generator app is likely to create)
- When a GUI asks the user to choose a file, the user can now choose more than one file, and the app will generally do the right thing. (I say “generally” because I’m not exactly sure what “the right thing” is if an app needs exactly one file and the user chose two, or it needs exactly two and the user chose three.)
- In the old table-based “encounter” generator system, which is still used in some places (including the new town-contents driver), a “terrain table” now sees a “plains” tile with a forest on it as a “temperate forest,” which is what that tile certainly was before the last change to the map format. And similarly for the other equivalents.
- In the worker management driver and all other drivers that use the same tree of units and unit members, the units kinds are now sorted alphabetically, and within them the units are sorted alphabetically by name.
- The XML formerly relied on a few in-retrospect-dubious idioms where the mere presence of a given parameter meant something and its value was not checked, and in one case the value written back was the empty string. While I’ve done my best to make sure that existing maps will be read with no change to the data they represent, the code now writes more standard XML, and handles (for example)
rows="false"properly instead of only testing whether a
rowsparameter is present.
- I extended the functionality that allowed a map to store an animal’s age by treating “young” animals differently in the report generator and tabular report generator and only writing the animal’s turn of birth to XML if it’s actually a young rather than an adult animal (or we don’t know what turn is the current turn, so we can’t calculate that)
- Animals in the map, which when not inside units represent populations rather than individuals anyway, can now include a population count.
- The duplicate fixture remover now offers to combine like animals into a single population.
- When having an explorer “swear” villages, the details about the surrounding area that get added to the player’s map now have any potentially-sensitive details zeroed out in the player’s map, just in case.
- The fixture-editing popup menu now includes all the items all the time, just disabled (grayed out) when they’re not possible, instead of just showing “Fixture not mutable” if something couldn’t be edited.
In addition to these bug fixes and new features, I did a bunch of refactoring. Some highlights include:
- Redesigning the map APIs somewhat so that, if not for a bug in the compiler, would allow callers to use a much less verbose syntax (aka “syntax sugar”)
- Using “stream operations” (functions on the
Iterableinterface) instead of “comprehensions” (for performance reasons) or loops (for reasons of readability and verbosity) where possible
- Moving the tile-contents generator and the TODO-fixer driver from the same file as the stat-generating driver into their own files.
- A number of changes that should improve performance, starting with turning of the sorting of sorted sub-reports in the worker management driver until the report is complete.
- I moved the Ceylon code from a
viewer-ceylonsubdirectory out into the main repository.
- One of the libraries I use was hosted on
java.net, which (as was apparently announced a year before) shut down permanently; I changed my build apparatus to download a newer version (which hasn’t been put into a GitHub release or uploaded to Maven, just checked into version control as a binary …) from the author’s new repository, and updated my code to compile again (because with the upgrade the names of the packages changed, though apparently not any significant functionality).
- I redid how the map keeps track of the current and independent players, aiming to improve both performance and correctness.
As I mentioned, I’ve again declared this a “release candidate.” Ceylon requires “modules” to have a version attached to them, so I’m slowly adopting versions as more than just a monotonically increasing snapshot number. I’ll mark “version 0.4.9014” once I’m more sure (preferably because another user has tested the apps) that there aren’t any significant bugs introduced during the port to Ceylon.
The Pivotal Tracker backlog is currently fairly close to what I’m hoping to get done in the near future. Here are some notable items:
- On Mac, making the program stay open, showing a menu bar with suitable options available, when all windows are closed, as is usual on that platform.
- Extending the “community population” modeling to cover former contents of non-active communities, and adding a similar data structure for battlefields.
- Making sure that the test suite is sufficiently complete.
- Adding a feature to allow a user to edit results of unit orders (which can be stored in the map format, but not edited in an app)
- Extending the map format to include roads.
- In the worker management app, allowing the user to apply orders to multiple units of different kinds, or multiple kinds of units, at once.
- Adding a resource-entry feature to the map viewer.
- In subset checking, reporting moved units (or other fixtures) as such instead of “extra” in their new location.
- Creating a “fortress-design” or “tile-planning” app.
I’m not currently planning to spend much time on adding new features soon, however.