Strategic Primer assistive programs release, development report, and roadmap (0.4.9013)

In the weeks since the last snapshot release of the suite of assistive programs for players and Judges of Strategic Primer, there have many minor “fixes” and “cleanups,” a few “major under-the-hood” changes, a few changes that may affect players but they won’t see directly, and at most a couple actually “user-visible” changes. But it’s time for a new release. You can download the new snapshot from GitHub as usual.


There have been about 350 commits since version 0.4.9012; of those, all but about forty were warning fixes, “cleanups,” or the like, but that included two “campaigns” that touched nearly every area of the code and was split up into over a dozen commits: The first was removing use of the NullCleaner class (and then the class itself), which worked around a bug in Eclipse that I could now address via IDE configuration (if it hasn’t been fixed) even if I was mainly working in Eclipse anymore, and the second was adding initial statements to all the Javadoc comments that were missing one.

Here’s a summary of the other changes:

  • Most things in the code-base that have “kinds” or “names” now do not have mutable kinds or names. This includes animals, fairies, giants, dragons, ground, equipment, resource piles, and most other “tile fixtures,” but not fortresses, other towns, or units. Any kind of tile fixture that has a mutable kind or name can be changed by the user in the map viewer, via an option in the context menu, so some users might have experimented with this, but I doubt any user will really miss the feature.
  • All TileFixtures are now “events” with “DCs” to discover them, so the advantage of a more observant explorer should be more pronounced.
  • I fixed a bug that caused the report generator to crash if two fixtures in the map had the same ID number, and also the related bug (forests’ IDs not getting registered) that caused me to be unaware that there were any duplicate IDs in the map.
  • I made some changes to what happens when the user uses the “swear villages here” function in the exploration apps:
    • This now only affects independent villages; a player can’t take over another player’s villages in this way.
    • After doing this, the villages are now added to the player’s map(s) that is or are being filled in by the explorer’s movement. They would have been guaranteed to be noticed the next time the player moved to that tile, but this is no longer necessary, which saves movement points in some cases.
    • The villages reveal the surrounding terrain and primary forest (unless the known-world map included some forest there) for all neighboring tiles, and (unless there are none immediately nearby in the main map to discover) one animal and one field, meadow, orchard, or grove.
  • The apps’ model of herding now supports flocks of pigeons.
  • Ground can now have ID numbers; as I did with Forests when I made the same change to them, I assigned deterministic but high numbers to the “primary ground” of each tile, assigned “the first free ID” to other ground, and then fixed inconsistencies between the main world map and players’ maps.
  • The MapChecker command-line app now, in addition to reading map files with warnings turned on, runs various “content checks.” Some of these had been part of the XML-reading code, where they added complications to already-complex code, but one or two were from a program I had kept outside the repository (I wrote it, ran it once, and then left the file in my home directory). The current list of checks is:
    • Laterite stone should only be in jungle terrain.
    • Villages in ocean terrain shouldn’t have one of the standard land races. (My out-of-tree program suggested, and in fact made, replacements, but that’s no longer necessary.)
    • Workers should not have ‘suspiciously named’ skills as the sole Skill in a Job. (A Farmer job with the sole skill “farming”, for instance.)
    • A worker should never have a Skill level in “miscellaneous”. I often add hours to “miscellaneous”, but when the worker gains a level in the skill I assign it instead to one of the skills that “miscellaneous” was intended to include.
  • Finally, I redesigned the code of the About dialog somewhat, as a first step to making it not look ugly. While before the code had painstakingly constructed the HTML to show to the user, it now simply loads an HTML file and (after replacing “App Name Here” with the name of the current app) displays it.


The Pivotal Tracker backlog is currently fairly close to what I’m hoping to get done in the near future. (Other than getting QA warnings down to more manageable levels.) Notable items include:

  • Further improving the appearance of the “About” dialog.
  • Starting work on a “turn running” app to create results (or at least a skeleton of them to start with).
  • Fixing the bug that adds animal tracks to the main map when I run exploration using the exploration GUI (and perhaps the CLI).
  • Accepting files via drag-and-drop, not just command-line options and menu items.
  • Extending the model to allow maps to contain roads.
  • In the worker-management app, allowing the user to write orders to multiple kinds of units, or multiple units of different kinds, at once.
  • Allowing the user to add resource piles and equipment to a unit or fortress from the map viewer (or other apps besides the dedicated resource-adding apps).
  • In subset checking, treating location as a differing property when a unit has moved instead of saying that the unit is an “additional fixture” or “additional member” in the location where the player’s map has it.
  • Loading racial stat adjustments from file.
  • Extending the modeling of animals to handle animals’ young differently than adults.
  • Using workers’ relevant Skills to influence results in herding, hunting, gathering, and the like.
  • Loading data for hunting, gathering, trapping, and fishing from file.
  • Adding methods to simulate farming, so I don’t have to look things up and do all the calculations by hand.
  • Adding methods to simulate combat, for use in modeling hunting (and warfare when that becomes necessary, but it isn’t yet).
  • Making most “tile fixtures” have “discovery difficulty” to make explorers’ Perception and movement speed affect how likely they are to be discovered.

If you have any features you’d like me to add, or you run into any problems with the software, please let me know, perhaps using the issue tracker or contacting me directly.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.