Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Fleeting Frames]

"width width" - typo there?

I'm surprised to see river manipulation so soon.

[PatrikLundell]

Yes, I've fixed it above. It should have said viewport width.

I kept thinking about rivers, and eventually ended up with a map/color indication scheme that I thought might work. After that it was mainly a matter of work (although I did get a reality check regarding feature shell features: they're unloaded when the shell goes out of focus [or something like that], rather than remaining loaded once loaded initially, as I thought I'd seen earlier, and may have claimed on the forum).
As with regions, rivers are given random unique names (rivers are called "The River of Y"). My attempts to find some mapped/exposed logic for selection of feature names hasn't been successful (although Quietust provided a mapping of words to some categories, allows for some variation in the "X" part of region names). MaxTM provided a script that almost worked in fortress mode for renaming things using the method you mentioned as its core. However, it doesn't seem to be trivial to replace the vocabulary since I don't have suitable ones, so I won't bother with renaming for the time being.

Just don't try to reroute every river on the map: my 33*129 test target world has over 1000 rivers and most world tiles have a river in them. To make it worse, there is no way to save "work in progress", so everything will have to be done in a single session (you can exit the script and reenter it, but DF itself will have to be in the same state). The exception to that is if you're working during pre embark (as opposed to during world gen), in which case you can do "save embarks", save, abandon/retire, and then continue.

Edit:
Updated to 0.22, 2017-11-18.
Added missing character causing selection of another river while one is selected to erroneously flag the sink as being in error.
It can also be noted that DF doesn't seem to like new rivers: I created one in pre embark mode, but it failed to show up on the region map, despite the known required structures looking correct. Rerouted pre existing rivers have displayed correctly when tested both during world gen and pre embark.

Edit 2: Creating a new river, embarking elsewhere, abandoning, and then re-entering pre embark shows the new river on the region map, so it seems to be a matter of DF not reacting to this hacking until the data is read anew. However, that still means you can't add a new river for your imminent embark, and that your large scale river creation projects won't show up in DF until the game is saved and reloaded (and I assume the same issue exists for creating new rivers during world gen).

[Fleeting Frames]

Aw. For lot of purposes, region manipulator's added rivers are fine enough to fix this, but for worldgen purposes of, say, directing human settlements need to reroute.

[PatrikLundell]

Hm, a couple of discouraging world gen observations, only partially Biome Manipulator related: I modded goblins to start on glaciers exclusively (for blizzard men access and placement control). However:
- They never spawned on single tile glaciers, regardless of whether those were evil or neutral (nor at good ones, naturally), but 3 tiles in a row worked (I haven't tried dual tile ones).
- "Adjusting" evilness of regions from good to evil before megabeast placement (which follows directly after good/evil placement) did NOT work to get goblins to spawn there. Unfortunately, it seems DF caches the good/evil info somewhere for civ placement purposes. It should still be possible to apply the logic "backwards" by adjusting the future embark's evilness and flora/fauna, though.

Edit: 2 tile regions are enough for the goblins. Also, I've verified that Faunadiversity adding blizzard men to potential goblin glaciers did cause goblins to get blizzard men when those biomes did not have them before running the command (I had 7 potential start regions, and only two had blizzard men. 5 goblin civs were spawned and all of them had blizzard men [and all but one had ogres. The one missing out was the one that did not have an evil plain as their immediate neighboring tile, instead having to pass the other glacier tile to reach the plain]).

I also experimented with adding a beast tamer position to goblins, but that did not have any effect on any of the goblin civs [no giant bats or other interesting cavern creatures added, nor ice wolves {if they're even eligible}], so I probably did it wrong (not surprising, as I don't really know how it should be done).

[Fleeting Frames]

Mm. The Civilization Cookbook suggests you could have [EXCLUSIVE_START_BIOME:GLACIER] with [BIOME_SUPPORT:ANY_GRASSLAND] or vice-versa to have goblin dark fortress start on the boundary between the two and not spawn pits.

Did you test with a larger region? I recall my own troubles with trying to get dwarves to spawn on 1-tile mountains with 17x127 worlds, where 17x17 worlds had no problems. In the end I settled on larger mountain area.

[PatrikLundell]

Very useful link I wasn't aware of!

While your suggested tags should guide the placement properly, the expansion would not, as I want them to expand normally. The proper work around in my case is probably to make sure there's evil grassland beside both tiles.

Anyway, some good news: I believe I've found where DF "caches" a region's evilness. Region element unk_1e8 seems to have a value of 1 for evil regions, 0 for neutral, and 256 for good ones (and I wonder what 257 would do...). I've updated the script to change regions according to this when changing evilness/generating new regions, and I now get goblins to spawn in converted former good regions. Thus:
Updated to 0.23 2017-11-24:
- Updated region wide evilness changes and newly created regions to set an unidentified region evilness indicator to get world gen placement to take changes into account.

Edit:
Updated to 0.24 2017-11-25:
- Adapted to naming of river fields. DFHack has named previously unnamed fields. The script detects whether the new or the old names should be used to remain backwards compatible.

Edit 2: I've investigated if it's possible to do a biodiversity operation on rivers, and found the general answer to be "maybe" and applicability for this script to be no. I was able to use gui/gm-editor to add a couple to legal critters to a river tile (the data is stored down in the feature map), but leaving the context and returning (i.e. moving away on the world map and returning) had the original data restored. This indicates that while creation of river entries in the feature map is saved, the river population is generated anew as the feature array is retrieved from storage. Thus, the "maybe" case would be immediately prior to embark, a context more suitable for regionmanipulator (and I still don't know if it actually would have any effect, given that river critters seem to be present on embark, migrate, and nothing new returns to the river, not counting vermin critters).

[MachinaMandala]

Does this work in 44.02? And are you capable of changing the names of regions?

[PatrikLundell]

Provided you have a DFHack environment to run it in it works in a currently unreleased version. I did compile DFHack and ran a few scripts of mine in order to try to find DFHack issues, and this was one of them. I had to make a few updates to the script to make it compatible with the naming of a few previously unnamed elements, but apart from that it was surprisingly uneventful.
Since we're still a fair bit away from a DFHack release I haven't bothered to update the script here (although it is backwards compatible), as there are additional unnamed field naming in the pipe which may or may not be accepted before an experimental DFHack version becomes available.

The script currently does not provide any naming interfaces. Forumites have kindly provided info that ought to make it reasonably easy to (ab)use a native DF name setting interface, but one reason I haven't pursued it further is that I haven't found any way to generate an alternative vocabulary from some kind of native DF source, i.e. a description of what words and combinations DF uses for regions and rivers, but just using the one used to name adventurers, fortresses, or groups (it seems to be the same set) ought to be possible if there's a demand for it.

My compiler environment is currently FUBAR, so I likely won't be able to do any further 0.44.0X testing until it's resolved.

[Rekov]

In case this is of any help, this is the error message I got when attempting to use biome manipulator with the alpha version of DFHack:

Code: [Select]

...Dwarf Fortress 0.44.02/hack/scripts/biomemanipulator.lua:250: decompose fails to match 'r' in 0.44.02-alpha1
stack traceback:
        [C]: in function 'error'
        ...Dwarf Fortress 0.44.02/hack/scripts/biomemanipulator.lua:250: in global 'decomposeDFHackReleaseNumber'
        ...Dwarf Fortress 0.44.02/hack/scripts/biomemanipulator.lua:270: in global 'isDFHackOlderThan'
        ...Dwarf Fortress 0.44.02/hack/scripts/biomemanipulator.lua:3238: in global 'Make_Profile'
        ...Dwarf Fortress 0.44.02/hack/scripts/biomemanipulator.lua:4862: in local 'fun'
        ...sktop\DFSTUF~1\Dwarf Fortress 0.44.02\hack\lua\class.lua:98: in upvalue 'invoke_after_rec'
        ...sktop\DFSTUF~1\Dwarf Fortress 0.44.02\hack\lua\class.lua:127: in global 'BiomeManipulatorUi'
        ...Dwarf Fortress 0.44.02/hack/scripts/biomemanipulator.lua:9303: in global 'Show_Viewer'
        ...Dwarf Fortress 0.44.02/hack/scripts/biomemanipulator.lua:9310: in global 'biomemanipulator'
        ...Dwarf Fortress 0.44.02/hack/scripts/biomemanipulator.lua:9313: in local 'script_code'
        ...ktop\DFSTUF~1\Dwarf Fortress 0.44.02\hack\lua\dfhack.lua:562: in function 'dfhack.run_script_with_env'
        (...tail calls...)

[MachinaMandala]

Not that I've ever used DFHack, but I'm guessing it's because the release hasn't been added to some master list of releases this is compatible with.

[PatrikLundell]

Not that I've ever used DFHack, but I'm guessing it's because the release hasn't been added to some master list of releases this is compatible with.

No, it's because the logic written to extract components from release names didn't expect the "alpha" instead of "r" syntax. Even if that had been the case, however, it the previous version still wouldn't work because of field name changes.

Updated to 0.25 2017-12-08:
- Updated release comparison to handle DFHack alpha versions.
- Updated to handle naming of previously unnamed fields. The logic should be backwards compatible through version field presence dependent parsing.
- Fixed presentation of river Elevation (for whatever reason the line that should have allocated the value wasn't there.
- Various minor details tweaked/fixed.

[Rekov]

Have you posted the information on the help screen somewhere online? I have a really hard time reading the text in DF when many of the characters are replaced with tiles.

[PatrikLundell]

Not as such, but you can open the Lua script file as text. The the contents of the help screens are produced by a number of functions after each other somewhere towards the middle of the (rather large) file. The functions are called Helptext_XXX, so you can search for Helptext to find them.
I'm not too keen on maintaining the info in multiple places (copies have a tendency to get out of sync). I'll see if I can create a "print" option that would take the info and put it into a text file in the DF directory, though, but color might be an issue. It would be possible to output it to the DFHack console window, where I think it should be possible to keep the color (you'd probably have to enarge the console window to see the output properly).

Edit:
Due to the color issue I've skipped writing to file, but have added writing to the DFHack console window.

Updated to 0.26 2017-12-09:
- Added ability to print the currently viewed help screen to the DFHack console (command keys get mangled a bit).

[Rusty_knight]

If there's another lunatic who sticks to df 43.03 and happens to do so under windows, he can PM me for a biomemanipulator workaround.

[PatrikLundell]

The best I can offer is to move the cursor within DF itself, i.e.:
- Move the DF focus to the world tile you want (the embark rectangle doesn't matter in this case).
- Start Biome Manipulator.
- Do the manipulation you want in that tile.
- Exit Biome Manipulator.
- Move the cursor.
- Repeat ad nauseam.

Edit: It is possible to change the script so it will work during world gen using an alternative mechanism that is available only at that time.
For pre embark someone would have to inform me of a method available to 0.43.03 that moves the DF focus during pre embark without feeding DF simulated movement orders using the :feed_key () function that hasn't been introduced at that time.

Edit 2: I've done some archeology, and it does indeed seem that version 0.20 works on 0.43.03, as movement of the underlying world coordinates was introduced in 0.21. Version 0.20 should be available here https://www.dropbox.com/s/ouxyhluiri7uy5k/biomemanipulator.0.20.lua?dl=0.

Edit 3:
OK, I've changed the script to not move the DF focus on versions older than 0.43.05-r2 (I don't know where the cutoff is). I've blocked access to river manipulation for those versions as it relies on simulated input to work. I haven't tested anything else apart from movement, so don't be surprised if things blow up.

Updated to version 0.27 2017-12-10:
- Supported 0.43.03 by disabling DF focus movement and river manipulation in versions older than 0.43.05-r2. Mostly untested, but should not affect modern DF versions.

Edit 4:
Updated to version 0.28 2017-12-10:
- Supported new region generation for 0.43.03. Also fixed a bug which probably would cause it to fail for 0.44.02 (some strangely missing conditional code).