Bay 12 Games Forum

Purpose: Generate a world map in DF, export it as parameters+PSV data, tweak the PSV data, and then regenerate a tweaked world resembling the original one. The functionality of tweakmap has grown to allow it to act as a replacement for World Painter, if desired.

https://www.dropbox.com/s/mlhcs3ik1wdnkgw/exportmap.lua?dl=0 version 0.1 2016-10-22
https://www.dropbox.com/s/60kmfv55ctnmebc/tweakmap.lua?dl=0 version 0.8 2017-11-23
Both can be found here:https://github.com/PatrikLundell/scripts/tree/own_scripts

exportmap.lua:
This script exports a world as parameters + PSV data to <DF directory>\data\init\exported_map.txt. The data isn't exported exactly as is, but rather adjusted to generate approximately the same world when DF's advanced world generation uses it (when the file contents has been pasted into world_gen.txt).
- Elevation is converted from the ranges used in the world to those used by the PSV set.
- Temperatures are attempted to be adjusted to compensate for elevation and latitude adjustments performed by DF. "Attempted" means the formulae used are not known, and so measured translation tables are used.
- Most of the world gen parameters are exported as they exist in DF, but some are changed to attempt to increase the chances that DF will actually generate the same thing world map tiles. Variances are modified, for instance, and if the pole was specified to one of the "chose one" alternatives it's locked to the one actually used.

tweakmap.lua:
This script reads the contents of the file exportmap.lua produced and presents it using DF as a display engine, without actually using any data within DF itself. The script displays world map tiles according to the biomes the PSV values would result in.
- You can change any if the PSV values for the currently selected tile to any value within the legal range.
- You can select the biome of the currently selected tile from a list of ones legal at that latitude. That will change PSV values to values that generate the selected biome. These parameters can be manually tuned after biome selection by the function above.
- Temperatures are WYSIWYG, i.e. the temperatures displayed differ from what was/will be in the PSV set and displays what they correspond to in a DF world.
- You can save the modified parameter + PSV set back to <DF directory>\data\init\exported_map.txt for manual copy into world_gen.txt.
- PSV parameter sets can be ignored, i.e. not saved. This is probably useful only to let DF randomize Volcanism.

Caveats, known deficiencies, rambling, etc:
- Temperature conversion is measured table based, rather than using the actual formulae DF used, since those are unknown to the author. Differences seem to be limited to 1 degree.
- World generation does not generate exactly the same elevations as the PSV set specifies, but they are generally close.
- Volcanism can spread out one tile from volcanoes, and volcanoes do not necessarily appear in the same location in a regenerated world.
- Biomes are determined using 6 parameters: Elevation, Temperature, Rainfall, Drainage, Vegetation, and Salinity. It can be noted that Vegetation and Salinity are not available as PSV parameters. Vegetation seems to always match Rainfall, so that's used as a proxy. Salinity, however, is problematic. Tweakmap uses a salinity value of 100 for wetlands as that allows for Mangrove Swamps, but the users should be aware that they may end up with freshwater marshers/swamps instead.
- The author has tried to set the parameters to get DF's world to match the PSV data as closely as possible, but the author is not confident the selections are the best ones possible, so there may very well be room for improvement.
- Tweakmap does not change the parameter part of the data read, but rather prints it out unchanged: all modifications are done by exportmap.
- Since Evilness is not available as PSV data, the data is displayed without consideration to any possible evilness values.

The author intends to modify this first post to reflect any changes in the scripts or associated knowledge without explicit change markings. Usually a new post at the end of the thread would indicate this post has changed, though.

Change log:
tweakmap 0.8 2017-11-23: Fixed bug in grid widget for maps wider than they are high.
  Changed ESCAPE behavior to escape out of help to the main display, rather than out of the tool completely.
  Blocked the editing and movement command keys from having any effect while the help is displayed (save and exit still work).
tweakmap 0.7 2017-08-05: Fixed screwed up addressing of 'r' and 'b' for frames essentially replacing them with 'w' and 'h'. Affected screen resizing handling, but had no effects on actual functionality.
tweakmap 0.6 2017-07-23:
- Fixed bug in determination of possible biomes on smaller maps for the "maybe" zone.
- Fixed incorrect key function descriptions referring to the wrong name of the save file.
tweakmap 0.5 2017-06-27:
- Replaced the crummy movement scheme of separate movement and panning with a single set of keys that pans automatically to keep the cursor as close to the center as possible (incidentally the same way DF does it...).
tweakmap 0.4 2017-06-22:
- Restored the functionality for the "map" to resize when the DF window size is changed.
tweakmap 0.3 2017-06-21:
- No functionality changes. Updated help text slightly.
- Replaced internal mechanism for map panning using a new widget.
tweakmap 0.2 2017-02-21:
- Tweaked maps are now saved back into exported_map.txt rather than to a separate file.
- Missing PSV values are replaced by defaults, allowing tweakmap to be used as a replacement for World Painter. In that case you would start with the world generation parameters only in the exported_map.txt file.
- It's possible to suppress the saving of one or more PSV parameters, allowing DF to generate those on its own.

A rotting meal was destroyed in the refuse stockpile, and the cook suffered a shock. Since clothing refuse destruction is legitimate, I would have expected the same to go for meals?

It's the second time I've been subjected to this. A fire spewing FB is "safely" kept out of a cavern by a wall with a wall on top of the single tile wide strip the FB is confined to with two raised stone drawbridges in the wall and Up staircases on top of the bridges. The FB then finds something to blast with fire, and fire somehow spreads into the cavern and eliminates my stocks of logs (that's only a temporary nuisance, though). Since dorfs don't really understand fire, the whole cavern will have to be placed off limits while the fire rages.

Any ideas of why fire jumps through walls and, potentially, how to block it?

z+0:

w..b......w
WWWBWWWBWWW
......hbh..

z+1:

wWWWWWWWWWw
...u...u...

where:
w = natural wall
. = floor (natural on Z+0, top of wall on Z+1)
b = lifted part of raising drawbridge (i.e. the one "disappearing")
W = constructed wall
B = "hinge" part of raising drawbridge (i.e. the one remaining visible when raised)
h = ramp down (and the rightmost bridge has a ramp under the lifted part)
u = constructed up stair

I'm trying to determine if bones from an undead dwarf can be used for crafting the same way as bones from e.g. an undead goblin (while bones from regular goblins and dwarves can not be used), and I happen to have a number of subjects at hand. The problem is that my embark is shallow, so the 25 levels I have between the bottom of the thick aquifer and the magma sea isn't enough for a splatterer setup (I've tried dropping onto lead and steel and both just leads to various injuries, and a menacing spike trap at the bottom just results in a dead, but undivided, undead. Slade is not available (unsurprisingly), nor is any of the heavy kinds of stone, unless the human caravan next year brings some. My civ is dead, so there's no dwarven caravan to order stuff from).
Thus, I'm looking for the trap type that leads to the largest number of bits, and my experience of traps other than cage ones is limited. Candy is not yet available.

As an alternative to investigating this myself, someone else might already know the 0.43.05 answer?

The suggestion is to write a pre processing program/script that takes the raw descriptions of the ordinary creatures and generates raw descriptions of giant and animal man versions from them.
The ordinary animal raw descriptions could be extended with overriding hints for the giant and animal men versions if needed. These hints would have no effect in DF itself, but would guide the pre processor in its generation.
The reason to produce raws for these derived creatures is to allow modders/players to change them, while vanilla DF would provide the results of generation only (DF itself would be oblivious to the generation and would use each creature raw for that creature, regardless of whether it was a base or derived version).
It would be a bonus if the pre processor would be provided so modders could do the same generation based on their modified creature sets.

Obviously, oddballs such as Plump Helmet Men, Gorlaks, and Gremlins would still have to be defined manually, since they're not derived from underlying creatures.

Implementing the suggestion would silence the bitching about the non existence of Giant Desert Scorpions, and might result in things like Mussel Men, Cave Spider Men , or Creepy Crawler Men (although a subterranean tag might be used to suppress generation of giant and animal people versions, if desired, with an override required to get/retain the GCS while suppressing the animal people version).

A very basic FotF level question is why this isn't done already, since it seems to be a natural fit for the DF philosophy. There might be some simple answer such as "it won't work because of..." or "haven't gotten to it yet" of course.

I'd like to kick the current lot of loiters out and replace them with some fresh blood, but I'd like to do that in a civilized manner, not by simply kill them (using direct or indirect means), i.e. I want them to leave my embark and do so alive.

I've set the visitors cap to 0, which throttles the fresh blood, but it has no effect on the current set of loiters. I tried to set the locations to citizens and long term residents only, but that just causes the buggers to stand around without any activity.

My oldest loiters seem to have been glued to the (dry) bar for over 4 years, so they're definitely due for a change of scenery.

Edit:
After waiting 3 months with all facilities blocked for visitors without anyone leaving I caved in and started operation GREEN PAINT.
A new area was dug out fairly far from the rest and was set up as the original tavern, open to all. At the same time, the area associated with the original tavern was reassociated with a new tavern open to residents only. The open tavern was gradually given 3 tavern keepers, but it took a season or so of praying to strengthen the dorfs for the task (the 3:rd one has never been seen in that tavern). In less than a season 4 over staying visitors have had their livers pickled and another 10 have left. Three of the pickled ones left tattered clothing behind as a clear sign of their over stay.

I suspect DF instrument allocation is bugged after having two fortresses where everyone insists on simulating about 3 instruments that are neither possible to create in the fortress, nor possible to buy from the elven or human caravans (my civ is dead, so I don't know if they could have been bought from the dwarven caravan, although it would be logical that the locally available instruments were the same as those of the mountainhome.
I don't have a problem with visiting bards wanting to use the instruments they are familiar with, but the locals in my second fortress simulate the same set as the visiting bards do (my first fortress didn't get any visitors).

What I'm getting at is that it seems DF generate a bunch of instruments and a bunch of music using instruments, and then distributes both randomly between civs, so the likelihood of your civ ending up knowing any music that use your instruments is rather low. (I did see a single case of the use of an instrument in a short lived intermediate fortress, though).

If my guess above is correct, a more appropriate approach would be to generate instrument sets (where the same instrument can appear in multiple sets) and then generate music appropriate for each set. Each civ would then get a starting package consisting of instruments and music appropriate for those instruments.
The acquisition of knowledge of how to make foreign instruments will have to wait for some unknown future time, though.