Bay 12 Games Forum

Personally I wouldn't mind if they'd scan drawings and posted them in a thread, something similar to the Threetoe stories. That would, of course, rely on them being interested in occasionally drawing something.

Toady has mentioned a desire to overhaul farming in the past, and I assume that's still on the table. However, I don't think it's ever been in the realm of scheduled changes (i.e. it's in the realm of stuff they'd want to do at some time in the future).

No. Toady has responded to questions colored in other kinds of green in the past. As far as I can tell, coloring serves two purposes:

1. Make it easy for Toady to find the questions among all the chaff that is other discussions and answers to questions. Going through a month's worth of posts and find where to start combing to prepare an answer would be even more of a chore if there were no highlights to navigate between.
2. Make the colored text legible. I for one find the darker green harder to read than the lime green one, and I would guess that's the reason the latter one is selected for the convention. Squinting your way through what's already a tedious task would make it worse.

The thread specifically for a tool can't really be necroed unless the tool is well and truly dead. The ideal case for no activity would be a tool that worked so well there was no reason for any discussions at all...

All my interaction with DF apart from a limited site presence remains on hold until keyboard support has been restored, as I don't find a mouse only (or even mostly) game playable and thus don't have any interest in working on tools for it.
Thus, my current intention is to return to DF when keyboard support has been restored, but there's probably a limit to how many years I can wait before losing interest completely (it's been 1½ years since the announcement of the removal of keyboard support and the subsequent announcement of the reversal of that decision).

However, the UI changes will make an update a rather extensive task, and I have no idea how much work it would be replace the current overlay with a new one, or even if there would be suitable tiles available for it.
It can also be noted that the logic for biome determination is no longer correct, as DF changed some time before the Premium release (the ocean type boundaries have shifted a fair bit, while other differences are lesser). The DFHack plugin that performs this logic has not been updated (it would probably require a new disassembly effort to do so). If I remember correctly this script uses the Lua version of that code (written before the DFHack plugin exported the logic from the disassembly), but an update should probably hook into the DFHack plugin to improve future proofing.

It can also be noted that other things probably have changed, so research and usage of new/changed data structures would probably be required.

The most important keyboard support restoration would be the restoration of the Help key binding, as all my scripts have help screens using this key, and without this they won't work at all (The Librarian was updated on request, but I just disabled the help functionality entirely to get around that issue).

The Region Manipulator faces the same type of challenges as this script does.

I have no issues with someone else taking whatever logic they find useful in my scripts and roll their own, although I would prefer if they didn't use the same names for their scripts, as that would cause confusion.

The mining yield is a balancing issue rather than a map issue, and has been addressed once, as mentioned by Eric Blank.

The map rewrite may well change the vein/cluster/... logic, in particular to generate a 3D connection (so several levels build up a body or ore, rather than the current logic where each Z level is generated independently of the other levels within the same layer. Such a change would probably result in in more tiles of ore for the kinds that are selected, but fewer kinds would likely be generated (basically larger but fewer bodies of ore, potentially resulting in about the same number of ore tiles in total)). This might potentially result in a balancing change.

The reason embark-assistant is written in code rather than as a script is performance. My prototype was written in Lua, but as I expected from the start, the performance was completely unacceptable. It's was slow enough when compiled (although the majority of the time in the compiled code was spent loading DF data structures done by DF itself: I don't know how the current, changed, data loading logic of DF will affect this).

I will investigate if I'm able to do so only when DF becomes playable, i.e. keyboard support is returned. That doesn't stop mouse tolerant people to take up the task earlier, as this is part of DFHack.

I can mention two things here:
- The biome determination logic was changed prior to the Premium release, so some biome determinations were incorrect. The underlying logic could use an update, although it's no longer part of this plugin itself. The differences were not huge, but present.
- I've noticed that mousing around pre embark causes mid level tiles to get loaded, so once you can order the cursor to move with keyboard input again you should be able to load all of this info into memory before performing any processing, thus removing issues with having to cache information and processing the data in two passes. It can be noted that the information is loaded unordered, but that can be handled e.g. with an intermediate coordinate translation matrix.

@MalroktheIII:
I'm guessing, of course, but:
- Some spheres probably won't have any terrain effects as such. Instead, things like Revenge would firstly manifest through worshiper doctrine, and possibly secondly as a skew in the propensity for creatures within the sphere's influence to select that course of action, although that could be tricky to implement.
- In the combination case, the above could apply, i.e. worshipers in particular would seek fame in its many forms and engage in rumor mongering (which might assist in the fame creation process in this particular combination). Non worshipers within the influence ought to be skewed towards fame seeking and might have a higher probability of sharing rumors (or a lower trust threshold for it).
- Intersecting spheres would probably overlap as the default, and clash when conflicting. Thus, you might be blessed with luck while cursed with a shortened life span, or many crops might die due to a blight, but the ones that don't might be bountiful due to a blessing of bounty. When spheres clash the end result would likely be an average of their respective power in the area, possibly with a random factor. Obviously, implementing all variants (or, rather, a system that generates effect combinations) will probably be tricky, not fully thought out yet, and probably run into snags that will force things to change.