Strategic Primer assistive programs development report and roadmap (#27)

In the weeks since my last report on the development of my suite of assistive programs for players and Judges of Strategic Primer I’ve fixed several bugs (a couple of which were truly egregious) and added some major new functionality.

As usual, you can download the new version from Bitbucket, and if you want to know more details than I list below, you can see the full history in the Mercurial repository.

Changes

First, the major bugs I fixed:

  • The report generator failed to include the section about towns. (I count this a bug rather than a missing feature because the feature was there, just disabled because of a logic error.)
  • Second, in the exploration apps explorers have vanished from the player maps, and tiles have gotten copied to those maps without any terrain information. I had done some work to try to fix this earlier, but it still persisted; however, I now think that I’ve finally tracked down the cause and fixed it.
  • In the exploration apps, the test for whether a unit moving northeast (all other directions used correct calculations) compared the unit’s column to the maximum row in the map, not the maximum column.
  • The “fixture filter” menu, added many months ago, has never really worked (giving very odd results!), because I always made the test for whether a fixture should be displayed using the previously-passed fixture (usually a “null object”) instead of the fixture itself. (This was caused by two variables with too-similar names.) The feature now works.
  • In the command-line exploration app, each prompt said that the explorer was one more tile in the direction it moved last, instead of its actual location. This is now fixed.
  • My changes to the subset-checking programs last month broke some parts (“corner cases,” for the most part) of the subset-checking code rather badly; I fixed them as properly as I could.
  • I mentioned last month a bug that caused all workers in a unit to have the Jobs of all the other workers added whenever the user clicked on the unit in the advancement GUI. While I didn’t fix it “properly,” I minimized the effects by making the XML saved to disk not include any Jobs that have no levels and contain no Skills.
  • Whenever something was renamed in a GUI (perhaps just the worker-management GUI), the display didn’t update its name properly. This was caused by an off-by-one error, which I have now fixed.
  • In the map viewer and exploration GUI, while the map itself only tried to load any given image file once even if the file didn’t exist, the “fixture list” (which uses images as “thumbnails”) would try to load images repeatedly. I added a similar cache of “missing” images to the list renderer to fix that.

I also added several features and feature improvements:

  • In the worker-management GUI, it is now possible to set orders for all units of the same “kind” at once, by clicking that “kind” in the tree, entering the orders into the text-field, and clicking “Apply.” If all the units have the same orders, they will be displayed, but if any differ, the field will be empty.
  • I extended the herding-results calculator I mentioned last month to account for chickens.
  • I made it possible to call the trapping-model app from the query app (which is chiefly used for hunting and gathering nowadays).
  • In the exploration GUI, the list of the selected player’s units always described every unit in terms that included the player’s name, making it unnecessarily verbose. It now omits that name.
  • In addition to finally working properly, the fixture-filtering menu (labeled “Display…”) now no longer has the empty entry at the top, has “All” and “None” entries (to select and deselect all kinds of fixtures, respectively) and also has a hotkey associated with it (so the user can open it with “Alt-D”).
  • In the map viewer, I changed the display ordering, so that arbitrary-text notes show up even on tiles that have forests. (They had previously only shown up, essentially, if there was nothing else there.)
  • In the subset-calculating programs, I changed the logic so that a player’s map is still a subset of the main map if the main map has a village owing allegiance to a player and the player’s map thinks the village is independent. I also improved the subset display, so that every item is preceded by its full context.
  • I added arbitrary-text notes to the report generator.
  • In the stat-generating program, I added a way to make the program read workers’ names from file and generate stats for all of them, instead of asking “Enter stats manually?” for every one.
  • In the exploration GUI, I added the ability to have an explorer accept villages’ fealty, as is possible in the command-line program.
  • Lastly, as I mentioned last week, I added a new program to generate a spreadsheet representing the contents of a mine or mineral vein.

In addition, I changed several APIs, most notably the Subsettable interface, to call for and use anything implementing “Appendable” rather than requiring a PrintWriter or OutputStream. (I made this change after rereading this old post, since I remembered being frustrated at my APIs calling for PrintStreams when I had a Writer, or the other way around.)

Roadmap

The list of “planned” features (which has debatable correspondence with the Pivotal Tracker backlog, remains largely unchanged from previous months.

The first item is to make the apps behave like native apps (following human-interface guidelines, etc.) on the major platforms, starting with Mac OS X. I’ve made something of a start on this, but getting any farther will be tricky.

Second, with it possible for players to make changes to a known-world map using the “helper apps” (rather than just a text editor) and send it back, changesets need to become a priority.

Third, I want to “finish,” test, and switch to (once I’ve demonstrated it won’t lose data) the new map API; this may make developing changesets easier, and it’s possible it’ll bring performance improvements, but we’ll have to see. I started writing tests for the new API this month, but I disabled them because they require XML I/O to be in place.

Fourth, I want to write programs to automate the more tedious parts of running a turn, such as agriculture, herding, food gathering, and hunting—the latter three are much better now, but how much meat any given animal produces, for example, still has to be looked up by hand.

That ties into the fifth item on the list, “resource management,” eventually including modeling resource production and resource accounting.

Sixth, I hope to add larger images (“portraits”) for units and some other kinds of fixtures.

Seventh, as I mentioned last week, I want the mine-model-generation program to produce something suitable for stone deposits as well.

And eighth, I want to make some way of recording fixture ID numbers as used in player maps without actually adding fixtures (or the file-size that fixtures take up).

Among other planned features.

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