Print

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

[A_Curious_Cat]

@A_Curious_Cat:
That's probably because you've got lots of peat on the top. DF cares only about levels below the ground for aquifers, not the number of layers of soil. You need to reduce the number of levels of peat to get the sand as level 2 below ground at the most (I don't know if your embark is at a sufficiently high elevation to subject the embark to soil erosion). If you've got no soil erosion, you should have 0-0 as peat, -1--1 as sand (or 0--1 as sand, if you don't care about the peat at the top).

Wait, are we talking about “layers” as in what’s under where it says “layers” or are we talking about individual z-levels as in what are listed below “top” and “bottom”?

Also, I embarked and I didn’t get an aquifer.  I also didn’t get the 7 z-level waterfall I was promised, nor did I get the black sand and peat layers.

[Fleeting Frames]

Waterfalls ought to be pretty obvious from just vanilla DF elevation indicators. I guess you embarked in wrong place?

[PatrikLundell]

When I said "Layers" I meant those vertical extents of materials called Layers in the UI (as that's what they're called in the DFHack representation of the DF structures) which can be several Z level thick, while "Levels" refers to Z Levels, i.e. the individual steps you traverse downwards with the "<" key, which also is the unit used for the Top and Bottom columns (again, the numbers are negative because that's what they are in the DF structures).

I can't comment about the waterfall beyond what Fleeting Frames already has without a save (and instructions on where to embark) to look at.

You won't get any effects from hacking the geo biome if you embark where a different geo biome is in effect or you have multiple (geo) biomes in the embark and happen to dig down in one that isn't the one you hacked.
The embark may well have the geo biome of a neighboring world tile rather than the "native" one, so you need to check which biome you're embarking on to find the right geo biome to hack. Geo biomes follow the same boundaries as biomes do, although there are cases where several biomes actually share the same geo biome. The same goes for when your embark covers several biomes, and it's often tricky to see the boundaries manually (you can go down one Z level to look at the material surrounding lakes, as the top level material is often different in different neighboring geo biomes).

[A_Curious_Cat]

Well, I’ve already embarked and I’m currently invested in this embark (it’s been just a little over a year and, thanks to two of the migrant waves, I’m now up to seven miners).

Btw, does anyone know if there’s a DFHack command to print the coordinates of the currently selected embark / move the cursor to an embark based on inputted coordinates?

Edit:

Also, is there anyway to record the changes made in biome manipulator for playback later?  I like to use DT to assign skills to my starting seven when “embarking carefully”, and I often find myself in a situation where no ones suitable for a role, and I have to abort and embark carefully again to re-roll the starting seven.  It would be nice if when doing so on an embark where I’d used biome manipulator if I didn’t have to change everything by hand again and again every time.

[PatrikLundell]

The only way I know of to move the cursor on the pre embark world map is to produce simulated input to DF, but I don't think there's any stand alone script for it (Embark Assistant uses that method to move the cursor when surveying and then returning the cursor to the original location, and the same logic is used in the candy corrector script (in Lua rather than C)). There are also DF variables containing the MLT coordinates of the embark rectangle, but, again, you'd have to make the script yourself.

I'm not aware of any way to record Biome Manipulator actions and replay them, although I believe there are third party tools that can capture and replay key presses.

[Rekov]

Possible bug specific to good/evil-aligned taiga tiles: Currently, biomemanipulator doesn't seem able to create new regions on these tiles.

Steps to Reproduce:

• Find a tile with the taiga biome and a good or evil alignment.
• From within the (m) World Map Edit menu, select (n) New Region.
• Observe that no new region is created. Strangely, the Size of the existing region is reduced by several tiles, but this doesn't show up until you move the cursor at least once.

The following error appeared in the console:


As far as I can tell, this bug only affects good evil-aligned taigas, but I haven't tested all possible biome/alignment combinations. Neutral taigas don't seem affected.

[PatrikLundell]

The cause of the problem was that a field has been identified and named, which affected all tree bearing savage, good, and evil biomes. The script has been updated (in what should be a backwards compatible manner), and the links on the first page should point to the updated version.

[Rekov]

Thanks for the quick bug fix, Patrik!

EDIT: Removed part from wrong thread.

[PatrikLundell]

I'm afraid I don't follow what you said here, as the context is implied rather than stated, and I fail to find what the "tool tip" reference refers to.

The Biome Manipulator works on the world tile level, and your table looks like it's for the MLT one, so I'm rather confused.

[Rekov]

I'm afraid I don't follow what you said here, as the context is implied rather than stated, and I fail to find what the "tool tip" reference refers to.

The Biome Manipulator works on the world tile level, and your table looks like it's for the MLT one, so I'm rather confused.

Oh dang, you're absolute right. I mean to post that in the region manipulator thread.

[Immortal-D]

Edit: The error seems to occur at a Tropical Forest of any type.

Hey folks.  I started cooking Worlds again, and this is the first time I have ever encountered an error with the plugin;

.Dwarf Fortress 0.47.05/hack/scripts/biomemanipulator.lua:3949: attempt to index a nil value (global 'vein_mat')
stack traceback:
        ...Dwarf Fortress 0.47.05/hack/scripts/biomemanipulator.lua:3949: in global 'Make_Geo_Layer'
        ...Dwarf Fortress 0.47.05/hack/scripts/biomemanipulator.lua:3956: in global 'Make_Layer'
        ...Dwarf Fortress 0.47.05/hack/scripts/biomemanipulator.lua:5674: in local 'fun'
        E:\Dwarf Fortress\Dwarf Fortress 0.47.05\hack\lua\class.lua:98: in upvalue 'invoke_after_rec'
        E:\Dwarf Fortress\Dwarf Fortress 0.47.05\hack\lua\class.lua:127: in global 'BiomeManipulatorUi'
        ...Dwarf Fortress 0.47.05/hack/scripts/biomemanipulator.lua:10230: in global 'Show_Viewer'
        ...Dwarf Fortress 0.47.05/hack/scripts/biomemanipulator.lua:10237: in global 'biomemanipulator'
        ...Dwarf Fortress 0.47.05/hack/scripts/biomemanipulator.lua:10240: in local 'script_code'
        ...warf Fortress\Dwarf Fortress 0.47.05\hack\lua\dfhack.lua:775: in function 'dfhack.run_script_with_env'
        (...tail calls...)

Do I have too many biomes on this world tile?  Any info is appreciated.

[PatrikLundell]

I'm looking at your traceback, and it complains about "vein_mat". It does indeed look like it's used incorrectly (i.e. that it's a bug).

However, then I try the script it doesn't trigger the error because it doesn't enter the loop where the error is, so I can't reproduce the error. I believe line 3950 should say "index = vein})", but I'd like to be able to reproduce the error so I can see if that actually does fix it.

There are two approaches I can see:
- You upload your save to DFFD and describe where your cursor is when the Biome Manipulator is started (so I can start it at the same location and reproduce the error).
- You change that line locally in your copy and report back. Note that you'd have to make sure you're testing this with the cursor in exactly the same place as the one(s) you get the error in, as the reason it hasn't been detected earlier is that most world tiles don't seem to fulfill the conditions.

As an aside, it seems to require the top layer (which should be soil in forests) should have veins, which doesn't happen in vanilla DF. I don't think it would happen in mountains either, as the top layer ought to be soil there as well, but eroded away so the top visible layer is rock.
This indicates there's something odd with your world, so if you haven't intentionally introduced veins into soil you ought to take a look at what changes there are (I'm not saying this doesn't mean there isn't a bug, only that special conditions that may not be intended are required for the bug to manifest itself).

[Immortal-D]

I believe the soil layer is the culprit.  I was looking at the differences between the error forest & an adjacent tundra, and discovered the forest has the single new ore added by sver combat reworked.  Specifically, it spreads out iron distribution to be less of an 'all or nothing' approach, which includes the occasional surface-level vein.  Incidentally, this only seems to generate at a single biome for each world, which I why I never caught it before.  In my first error world, it was only tropical broadleaf forest, all others were fine.  The next world saw the error only at coniferous forest.  So, can biome manipulator be told that surface-veins are ok to edit?

[PatrikLundell]

Yes, it's a bug in the script, not anything inherent in the design. I believe that the change I described will fix the issue, but I'd like it tested before I release it, so if you can provide me with your world or you can try out the change that would work as a test.

[Immortal-D]

I'm at work right now, can upload the world in a few hours.  And before I forget, THANK YOU!  This plugin is up there with Perfect World for worldgen chefs/junkies.  Been using it for ages.  Interface is a heck of a lot cleaner than Perfect World too.  Perhaps one day we'll have an actual painter where you can just pick a set of parameters and drag a box, just like mining.