Strategic Primer assistive programs release, development report, and roadmap (0.4.9014-rc4)

It’s been nearly a month since I marked the last “release candidate” of the suite of assistive programs for players and Judges of Strategic Primer, so as I’ve continued to work to improve the code, it’s time for another. You can download the fourth release candidate for version 0.4.9014 from GitHub as usual.

Changes

  • There were a couple of bugs in the worker-skill-advancement CLI:
    • First, it reported that a worker had gained a skill level when, and only when, the worker had in fact not gained a level.
    • Second, this notification was formatted so that it ran into the next prompt, instead of ending the line and making the prompt start a new one.
  • The converter from map version 0 to map version 1 now writes converted maps to files, not the standard output, so it can be safely run on multiple maps at once. Not that we should ever need to run it again.
  • Despite my statements in game-mechanics-explanation blog posts in the past that a worker has a chance of gaining a skill level after every hour worked, the assistive programs only checked once no matter how many hours were added. They now check after every hour. This is still not ideal—in some circumstances a worker can get multiple “effective hours” of experience for only a single hour of work or study, and should only check for a gained level once per actual hour—but is much better.
  • The code to let users drop files on an app’s Dock icon on the Mac platform caused irrecoverable crashes even in CLI apps on other platforms. This is now fixed.
  • The stat-generating app mistakenly only offered units containing any workers that didn’t have known stats as candidates to add new workers to. This is now fixed.
  • The stat-generating app, when reading workers’ names from file, now trims any whitespace from the beginning and end of each line, so as to not end up with spaces at the beginning or end of a worker’s name.
  • The report generator sensibly warns about items it can’t report on because its data structure already had something else in that “spot” (i.e. something else had the same ID number) and had to discard them, but sometimes these warnings were spurious, warning about the same item coming up a second time. It now no longer prints this warning when the discarded item is identical to the one that is kept.
  • In every CLI, when an app prints a prompt that doesn’t end in whitespace, it adds a space.
  • When asking the user to choose a CLI app, the program now only lists each app once.
  • The “expansion” app, which adds features that a player’s allied villages can see to his or her known-world map, had a bug that “zeroed out” possibly-sensitive information (only!) in fixtures belonging to the player whose map it was (including his or her headquarters’ contents!) instead of only in fixtures not belonging to that player. This is now fixed.
  • Whenever a unit is tested to see whether it’s equal other than by ID number to another unit, it will now use that test on all members of both units, instead of simply ignoring members.
  • The report generator now combines “like” animal populations inside a unit. (For reporting purposes only; the original map is unchanged.)
  • The report generator now sorts villages (within each section, i.e. among those allied to the player, those that are allied to other players, and those that are independent) by their distance from the player’s HQ.
  • Several of the XML I/O tests now randomly generate ID numbers instead of using numbers I chose.

There were also a string of changes that shouldn’t change behavior, but reduced the length and visible complexity of the code. This is a sprawling code-base, and I’m trying to bring the complexity down without removing any features the current campaign relies on.

Roadmap

As I mentioned before, I’m again declaring this a “release candidate”; if I get a chance to test it on each platform I’m concerned about, unless bugs surface, I’ll probably release version 0.4.9014 soon. (I would have made this “0.4.9014 final” if I’d had a chance to test it on Windows.)

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.
  • Creating an app or apps to manage players’ advance lists.

I’m not currently planning to spend much time on adding new features soon, however.

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.

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s