In this period, a user reported a few bugs and feature requests in the main viewer app, which I fixed and implemented.
- Zooming in from the keyboard didn’t work. It turns out that they key-code I had used for the “plus” key would only have worked on non-US keyboards, so I fixed it to work with that (just in case a user with a non-US keyboard wanted to use the app), the “plus” key on the numeric keypad, or the “plus” key that’s “shift-equals.”
- The search feature was case-sensitive, but didn’t mention this anywhere. I added a case-insensitive search option.
- And on a “busy” map with lots of “fixtures,” it was hard to see where there were rivers. So now, as requested, any rivers on a tile are drawn under whatever the “top” fixture is.
The other notable changes (besides the usual fixes for warnings and the like):
- I changed the report generator to put worker stats on one line per worker, instead of one line per stat.
- Also in the report generator, I changed the format to list the player’s fortresses and units separately from other players’.
- I added a distance-between-points to the “query” command-line app, as a simple convenience.
- I added more standard hotkeys for “find” and “find next” (control-F or command-F and control-G or command-G, respectively) in the viewer app, and made those the hotkeys shown in the menu. The vi-like “forward-slash” and ‘n’ still work.
- And I added a command-line app to update a player’s map to include local knowledge from any villages (or other towns) that give allegiance to that player. This includes the basic terrain and everything that an explorer would be guaranteed to notice in the immediate surroundings (up to two tiles away) of such villages or towns, plus some things that an explorer might notice (except never caches, such as buried treasure), weighted to include more closer to the village or town than farther away.
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 earlier, 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.