Print

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

[PatrikLundell]

Yes, it's has to be some probability distribution, but knowing that isn't sufficient to implement it: I'd need to know what it is, or something that's close enough.
However, I've implemented a "load on all" function to a layer as well as a clear one (to empty the stuff loaded), and prepared for, but not yet implemented,  Geo Diversity Single Biome and Geo Diversity All Biomes that would add everything to every layer for the current geo biome and the whole world respectively. I don't plan on testing what happens when embarking on them, though.

Adding new stuff to existing worlds is always messy, and I don't think it's recommended. If you added it properly adding the new things to existing biomes and then embarking there ought to allow you to get them (still only a probability), but adding them to a biome where there's an existing fortress will most certainly have no effect for a running fortress because the population (sort of) available to the fortress is set up at embark, drawn from a 7*7 world tile area centered on the embark world tile, and that's not updated by your hacking of the regions. I've tried to hack that structure to get new plants in, and have failed miserably (I've managed to get grasses, but who cares about them, and I think I've managed to replace one plant with another, but that's about it). I don't know if retired/abandoned fortresses store their 7*7 population data or if it's generated from scratch on resume/reclaim. (The 7*7 data is what region-pops draws its reports from, by the way).

Unless a fortress is 16*16 tiles it cannot take up a whole biome, and even then it's rather unlikely parts of it aren't in mid level tiles of neighboring world tiles.

[CaptainArchmage]

Probability distributions for mineral diversity were tested a long time ago, found this on the wiki:



It doesn't cover the probability weightings of the individual minerals though.

Update: Just did a "reveal" on the map I edited the biomes of. It seems like there is a reasonable occurrence of minerals in them and they are quite diverse. A lot of iron ore too.

It seems like for layer stone, the large clusters are placed first, and then the veins are placed, and then the small clusters are placed. So one replaces the other and there's a kind of hierarchy. The main clashes will be with small clusters especially with small clusters that should appear within specific other minerals. I haven't checked with veins or clusters that seem to have their own inclusions yet though.

[PatrikLundell]

The table is only a very rough start for an algorithm for determining minerals, and might not be useful at all on its own. The table gives you an indication of what you can expect from a world with a given mineral scarcity, but not that much help in actually bringing such a world about:
- The overall mineral abundance is not really that interesting from an algorithm point of view, as we need to get at it at the more detailed level of layers, where the layer material probably plays a crucial role. Given this material has this set of possible veins/clusters, how many vein/cluster materials should I select, how should that number of materials be distributed (sometimes yielding 3 and sometimes 7 different materials, for instance). Are the only factors scarcity and the number of possible materials, or does each individual material have properties that affect the outcome (and, if so, which properties and how)?
- Does DF use a common algorithm to select large/small clusters and veins, or does each category have its own algorithm, and, if so, are they independent or dependent on each other, and, if so, in what order (large cluster-vein-small cluster-inclusion)?
- How are inclusions determined? Do they use the same algorithm as clusters/veins based on the outcome of the previous step? I.e. given that I've gotten yellow diamond as a small cluster in the previous step, would I just apply the same algorithm to determine whether clear diamond should be present (I believe clear diamond is found only as inclusions in yellow diamond)?
- How are the abundance values determined? Would a low number of different materials selected result in higher abundance values than when the number of materials is higher? How does abundance depend on mineral scarcity?
- How are multiple selections of the same material handled? Are they just ignored with an RNG re-roll, or do they aggregate into a higher abundance value, and, if so, using which algorithm? Simple summing with a cut off at 100?
- I make the assumptions that the number of layers and layer thickness are not factors in the algorithms we're interested in. Is this a correct assumption (DF will generate more types of minerals and more of minerals in thicker layers, but that's not within the scope of the geo biome itself, but its application. Similarly, the amount of minerals generated depends on the thickness of the world from the magma sea upwards, which is decoupled from the geo biome [DF cuts off the parts that would appear below the magma sea, and stretches the lowest level to reach the sea if too shallow when generating an embark])?

For the application of generating a geo biome, I don't care how DF performs the following generation step of turning a geo biome into an actual embark. This does not mean I won't have a general DF mechanics interest in how it's done, though.

Edit:
Updated to 0.32 2017-12-27:
- Added the following Geo Manipulation commands:
  - Full mineral layer, i.e. add every mineral legal to a layer
  - Clear mineral layer, i.e. remove everything in a layer (to easily clear the above)
  - Geo Diversity Single to assign the full set of minerals to every level of the current Geo Biome
  - Geo Diversity All, to assign everything legal to every layer of every Geo Biome in the world.

Edit2:
Updated to 0.33 2018-01-11:
- Fixed bug in evil weather reanimation detection causing reanimation to be reported when it isn't.
- Added ability to change percentage of vegetation to be dead in biomes. DF itself only has a non zero value for reanimating biomes, but it can be applied to any biome.

The evil weather correction above has led to the discovery that you CAN set reanimation on non evil regions, and you can probably set it on an active fortress (not tested, but as weather effects are applied reanimation is probably applied as well). The reason previous attempts failed was that the region interactions used actually didn't reanimate...

Edit3:
Updated to 0.34 2018-01-15:
- Updated to be able to handle the naming of the dead_percentage field (as well as the old unk_1e4 name).

[xaldin]

Been tinkering with running this and manipulating the areas I'm going to embark in. Quite handy in some ways and in others hard to figure out. For example sometimes when I adjust the rivers they really do expand as expected, others they don't. The formula doesn't seem to be always accurate (flow/40000*46) I've had it off as much as 4 tiles in either direction at times.

The area that really fascinates me though is the geo level manipulation. More than a few embarks I go 'that'd be awesome if only it had (more) N'. This tool actually presents the possibility that could be adjusted.

I wonder if it can be stretched to point of making almost custom embarks for a more scenario based gameplay within the bigger active world. Meaning I get the embark of my dreams but rest of the world is dynamic.

[PatrikLundell]

The flow calculation is what I concluded after experimenting with it a lot. However, the result is the stable state width: to ensure you get that you need to have the same (or close enough) flow both up river and down river for one tile, or you're going to have effects from gradual widening and narrowing.

You can probably customize your embark in a "naturally" generated world, but it's quite a bit of work to adjust everything. If you're going to use the same setup for multiple embarks you probably want a PSV world to generate the basics. Producing a "create defined embark here using template X" tool would be quite a lot of work, not the least of which would be to define the syntax/vocabulary for it while still allowing for some things to be random. I'd say such a potential tool would be a stand alone thing rather than part of this (already large) script. Obviously, whoever would embark on such a quest could copy/paste parts from this script as starting points for features.
Also note that mid level tile features are generated by DF as the come into focus, and any manipulation to those are lost when going out of focus (when the same world tile comes into focus again DF again generates it the same as the first time. The Region Manipulator script deals with that level, but an embark builder would presumably want elements from that as well.

Something I haven't dealt with is manipulation of embark depth and cavern depth. The data is mapped by DFHack, so I expect it should be possible to change them, but I've never tried.

[xaldin]

Thanks for the information about the flow calculation. It makes a lot of sense now. Still doesn't match up perfectly all time but that's ok, it is close enough for functionality.

I don't tinker with perfect world utility typically since I cannot really manage it very effectively. Shortcoming on my part that as a tool it has never really clicked with me for usability. I still find it easier to get the DF world gen to manage the general world I want easier. I don't typically have problem getting the basics I want, I'm using yours to 'tweak' it in sense of weather, river, and somewhat geo level editing for more N material. Some of it I've figured out some I haven't.  If I could ever figure out how to combine tools to get the perfect embark it'd be awesome but for now I get 'close' and try to work with it with your script primarily.

[PatrikLundell]

I don't use the vanilla PSV map editing functionality, as I find the mouse only interface absolutely horrible. I know some people use spreadsheets, while I use Tweakmap (named as such as it started out as a tool to tweak a normal world exported as PSV data with Exportmap [not to be confused with Ragundo's plugin of the same name that's sitting in acceptance limbo]). If I've understood Perfect World correctly you start from a map image (taken from somewhere or made yourself, which, to me, sounds like far too much work as an input work around), and that doesn't fit me at all. If it's possible to start from PSV data I haven't found out how.

[Jazz Cat]

Are there plans to integrate RegionManipulator into this? I'd love to be able to add in the elevation tools at a region-tile level. I'd use them both separately but the changes don't carry over between them.

[PatrikLundell]

No. They can't really be integrated for technical reasons:

Region Manipulator manipulates the region in focus, but DF discards the region when the focus is shifted to a different region. When focus is returned, the region is re-generated from the seeds (which means the manipulations you made won't appear, as they're not a product of those seeds), using the current (possibly changed) world data.

Changes made with Biome Manipulator, however, persist until the save is saved (by embarking, as I don't know of a way to save DF in the pre embark state) or exited, which means changes made pre embark will be used as a basis for changes made by Region Manipulator. To be sure things work properly, you should change focus from your intended embark region (if it was there) somewhere else and back again to make sure DF generates the region based on the manipulated state. Thereafter it's time to refine the embark with Region Manipulator (and it's still easy to hit the wrong key, change the focus, and have to redo that part of the work...).

It can also be noted that changing the focus in Biome Manipulator also changes DF's focus.

I hope this explains the underlying DF constraints we have to work with. If not, feel free to ask for clarifications.

[Jazz Cat]

Okay, I gotcha. I was aware of the limitations of the Region Manipulator in that it only holds the changes until you shift the focus (I think I read that in your Geo Manipulator thread); I'd assumed that the same issue happened with Biome Manipulator, and that opening Region Manipulator after making changes with Biome Manipulator would discard the Biome changes. I think I got confused because that is how it works if you do it the other way around, using Region Manipulator first and then Biome Manipulator, which is what I tried. I'm glad there's a solution.

As a side note, do you know how DF handles the elevation changes to a region? If is use Biome Manipulator to put a vein of hematite in layers 0 through -4, and then use Region Manipulator to change a tile from elevation 164 to 159, does that hematite vein get lost, or...? I think I'm trying to figure out how the relative, top-down elevations in the geomanipulation compare with the absolute elevations in the Region Manipulator.

Thanks!

[PatrikLundell]

No. DF erodes soil levels based on elevation, but not stone ones. Apart from that, the Geo Biome starts at the surface, so if you raise the terrain a part of the bottom end of the Geo Biome would be raised above the SMR, and thus appear (and DF streches the lowest layer of the Geo Biome to reach the SMR if it's too shallow). If you lower the elevation (as in what you want to achieve) the bottom end of the Geo Biome would be pushed down and disappear when it meets the SMR.
The Geo Manipulator is based on local conditions, while the Biome Manipulator is based on world ones, and the Geo Biome is a property connected to a region, where different parts of the region can have different elevations.

However, apart from soil erosion, the Geo Biome is "anchored" in the surface with the whole stack of layers moving up and down as you pull and push in the surface (it should be possible to move the SMR [and the basement] up and down as well, but I haven't tried such manipulations, and they'd have to be done to different data structures).

[gchristopher]

This really is impressive work. I'd done a lot of poking at the structures, but never aspired to putting it all together in a tool like this. Way to go!!

[Rekov]

Are volcanoes considered biomes? Would it be possible in theory to make a utility which could add volcanoes to a desired embark site?

[PatrikLundell]

Are volcanoes considered biomes? Would it be possible in theory to make a utility which could add volcanoes to a desired embark site?

No, volcanoes are features of the same type as rivers, candy spires, and underground passages. None of those are biomes in themselves (although rivers have creatures attached to them), but rather reside inside of "real" biomes (as do murky pools, but those are not features of the same kind as volcanoes). In fact, it should be possible for DF to split a volcano tile among several surrounding biomes (at a level that's RNG controlled, and not possible to influence other than by changing the seeds, and we have no way of predicting what seed values would result in what).
I believe it would be possible to add a volcano to a mid level tile, though, but my current thinking is that it's something that would fit better with the Region Manipulator, as it operates on that scale.

[Gooblin]

Hi, I've been having an issue whenever I try to use morph in the Geo Manipulation mode of biome-manipulator. Nothing happens when either trying to type the name of a layer or selecting a layer through the list of available options, I get this error message in the dfhack console when trying to type anything:

Code: [Select]

...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\widgets.lua:792: bad argument #1 to 'match' (string expected, got nil)
stack traceback:
        [C]: in function 'string.match'
        ...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\widgets.lua:792: in method 'setFilter'
        ...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\widgets.lua:813: in function <...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\widgets.lua:812>
        [C]: in field 'on_change'
        ...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\widgets.lua:166: in method 'onInput'
        ...top\Dorf\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui.lua:484: in method 'inputToSubviews'
        ...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\widgets.lua:722: in method 'onInput'
        ...top\Dorf\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui.lua:484: in method 'inputToSubviews'
        ...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\dialogs.lua:224: in function <...\DF-TES~1\Dwarf Fortress .44.12\hack\lua\gui\dialogs.lua:217>
        [C]: in ?
I get this problem with a clean install of dwarf fortress 44.12 and the latest release of dfhack with nothing added but the biome-manipulator script itself. So I assume it should be completely reproducible.