Mod Maintenance
So I’ve just released my first mod, yay! The theory was rather simple, but the execution took far longer than I would have liked. Every programmer, naturally, is familiar with hunting for a missing semicolon for 6 hours, but it’s so much worse when you don’t even realize that you’re looking for a missing semicolon. Oh well, it’s out there now, and as of this writing, Steam is showing 120 subscribers, so I personally consider that a resounding success.
But what now? I’ve got lots of features that I want to add, but at this point, the deployment alone will take me a solid half an hour – package into smod, upload to dropbox, upload to github, update the Steam upload, update the Discourse post about the mod, update the Steam description, update Github readme (once I actually write that)… and I have to do this every time there’s an update or a bugfix. Sure am wondering if there can’t be a method to automate all this updating, but right now, I’m too excited about making more mods to write such a tool. Blah. Any other modders have any advice on this?
Miner Overview
I’ve included a Github link for my mod, so that anyone who wants to use it as a reference for their own miner class, or a different profession. The very basic idea was a modification of Radiant’s dig_adjacent_action.lua. Normally, when Hearthlings dig, they execute a single “work” animation (the strike of a pickaxe), then as soon as they do, they pick up a single block. I re-wrote this to require a certain number of work animations to start with, but after those are completed, the Hearthling can now pick up a number of blocks without striking them. It doesn’t look 100% as good as regular mining does, yet (especially when the miner decides to mine vertically, rather than horizontally), but it definitely achieves the goal I was aiming for – having a faster mining profession. This, the very core of the mod, was, incidentally, by far the easiest part of writing it. However, simply by modifying an existing lua file, a) we don’t actually have a mod yet, b) everybody and their cat can now do fast mining, rather than just the miner.
MoAI, MoProblems
The far more difficult part, then, was packaging the fast mining action into a profession, and then integrating that profession into the game properly. We need to make a distinction between the mining that all other hearthlings do, and the mining that the miner does, so I made a separate set of actions for fast mining. I copy-pasted stonehearth/actions/mining folder and made my modifications to it. When you want some specific class of Hearthlings to be able to execute a set of actions, you create an AI Pack for it, and tell your class that it’s allowed to use that AI pack. So I did that, and injected the pack into my miner. But now, the issue is that when I create a Mining Zone, only regular Hearthlings go to mine it! For some reason, my miner didn’t “know” that you’re supposed to go to a mining zone and mine it.
That took me a bit of investigation to figure out. There exists a file called town.lua, which essentially describes the functioning of your in-game community. This includes creating so-called “task groups”, which are, as the name suggests, groups of tasks that are unified by purpose. The game appears to do this in order to be able to orchestrate large numbers of hearthlings quickly towards a specific task. Mining for the sake of mining is one such task group, another one is mining out a foundation for a building, another one yet is for creating a building. This way, if the game has multiple definitions for, say, “mine”, it can have the freedom to say: “all hearthlings who can mine, go to that place and mine those blocks. I don’t care how you do it, but those blocks have got to go.”
The way you specify that a task does the same thing as another task is just like that – through the does attribute of a task. This was the mistake that cost me hours to fix. I thought that by giving everything a name that would be unique to my mod would decrease the likelihood of mod conflicts in the future. In so doing, I totally failed to realize that names are part of how Stonehearth identifies the various entities and events that take place within it. So instead of saying that my miners are able to do miner_prof:mine_fast, which Stonehearth has no clue what it is, I had to say that they are indeed capable of stonehearth:mine action definition. From that point on, I differentiate into my action (dig_fast_action.lua and dig_fast_adjacent_action.lua). Now Stonehearth knows that Miners are also capable of executing the “mining” task group, and it asks them to do so when a mining task is available. When the Miners actually receive the request, they go and use their own mining ability, rather than the standard Stonehearth one that most Hearthlings have; this is not something the game has to ask them to do specifically, it’s simply the only action they can perform that fulfills the stonehearth:mine request.
Additional documentation
Official Stonehearth modding guide
In-depth look at AI