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

In the month since my last report on the development of the suite of assistive programs for players and Judges of Strategic Primer, there’s been little progress, but I’ve added one user-requested feature, so I may as well make a new release.

You can download the new (snapshot) release, 0.4.3211, as usual, from BitBucket, and if you want to see the development history in detail you can browse the Mercurial repository online.

Changes

The one major change in this release is that in the worker-management app, there is now a panel showing the details of the currently-selected unit member, if any. Nearly all of the information this panel displays was available through the tree on the left of the interface (the worker stats through tooltips), and all of it was available through the report that can be generated from the map, but a player requested a panel to make the information more visible. The one part of the panel user interface that isn’t obvious is that Skill levels are shown in a tooltip if you hover your mouse over a Job in the list at the bottom.

The subset-checking app (which most players won’t have a reason to use) also got some improvements in this release, including ignoring false positives caused by the differences between the new map API and the underlying (XML) representation (the first forest loaded is “the” forest for a tile, instead of the XML having a forest set as a separate property, for example), treating units outside a fortress properly (by doing deep subset comparison, instead of treating a not-quite-equal unit as an extra unit), and adding a warning when the “main” map has a nonempty unit named “unassigned” and the corresponding unit in a player’s map is empty.

Other changes were primarily warning fixes. Most interesting, probably, was one where I found that the hash-code calculations in a few fixture classes weren’t doing what I expected, because in Java addition is a higher-priority operation than bit-shifting, instead of the other way round as I had thought.

I also made some progress on the bug that causes some apps to not quit when the last window closes; I suspect I might have finally fixed it, and I no longer routinely run into it, but I’m not sure I’ve completely fixed it.

Roadmap

The top items in the Pivotal Tracker backlog are currently some performance issues, a couple of fairly-urgent bugs that I mentioned in December and still haven’t fixed.

The performance issues are that I currently use several APIs that best practice recommends not using for loading and drawing images and limiting the drawing area, and there are places where the GUI calls time-consuming operations that could be but aren’t yet done in parallel to the GUI-update thread.

One other bug that I haven’t added there, that may still be present despite my attempts to fix it, is that some apps don’t quit (shut down the Java process) when the last window closes.

My current top-features list is mostly the same as the last couple of months:

  • 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”.
  • Apps that allow the user to create units or other fixtures should allow him or her to either specify an ID number or pre-seed the cache of used ID numbers, to avoid (for example) giving a new unit an ID number that is used by a fixture that player doesn’t know about.
  • In the worker-management app, the user should be able to use the “report” tree to find an item in the map viewer.
  • As a user requested, when zooming in using the mouse scroll wheel, the zoom should center on the mouse cursor.
  • The worker stat generator should apply racial stat adjustments.
  • Make the apps behave (more) like native apps (following human-interface guidelines) on the major platforms, starting with Mac OS X. The Window menu is a good start, and finally works, 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.
  • Unit (and other) “portraits”—larger images for individual units, towns, and the like.
  • 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.

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