Print

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

[PatrikLundell]

I'm not into mouse interfaces (I'm very worried about the current UI work, still fearing the keyboard controls will be cut due to a lack of time), so you're unlikely to see that from me. However, I'm using Tweakmap (http://www.bay12forums.com/smf/index.php?topic=161188.msg7228166#msg7228166) to create my PSV worlds. That's essentially a different take on DF's world painter, but without the insane mouse interface and with the ability to select biomes in addition to the parameters that make up the biomes.

An upload in a couple of hours probably means I'll look at it tomorrow morning my time, so assuming things work out according to plan there should be a new version available when you get back from work tomorrow.

[Immortal-D]

I was referring to the keyboard box select, don't use mouse either.  Tweakmap looks like the kind of thing that is insanely useful once I take the time to learn it.  Damn, you are like the god of map editing, lol.  Anyways, here is the save with modded raws.  Any tropical broadleaf forest will generate the error.  Click Me!

[PatrikLundell]

Thanks for the save and the image showing there the issue becomes visible. This made it easy to first reproduce the error to make sure I'm looking at the correct location, apply the correction, and then see that the failure doesn't occur.
The contents at the targets of the links on the first page has been updated with the corrected version.
Also, thanks for reporting the problem in the first place: I can't fix bugs I don't know about...

[Immortal-D]

No, thank you.  I can't stress enough how insanely useful this is.  Combined with region manipulator, I can make the perfect waterfall / volcano combination any time I want.  I'll definitely be playing with Tweakmap later (I'm moving tomorrow).

[Rekov]

These are my notes from testing the manipulation of 'reanimating' weather via biome manipulator:

Reanimation should be thought of as two separate phenomena, which always occur together by default. These are:

1) Undead creatures spawn into the map.
2) Dead creatures in the reanimating biome reanimate as undead.

Biome manipulator is currently capable of turning off reanimating weather. That is to say, if you set the weather from 'reanimating' to 'none', both effects 1) and 2) are turned off.

Biome manipulator is more limited, however, in its ability to turn on reanimating weather. If you take a region with non-reanimating weather, and set it to 'reanimating', only effect 2) will turn on. Currently biome manipulator doesn't activate effect 1).

I don't know if this is something that can be fixed, or if the nature of Dwarf Fortress makes it impossible.


Alignment does not appear to affect reanimating at all, though by default it only occurs in evil biomes. If you take a reanimating biome and change the alignment, both 1) and 2) still occur. If you set the weather of a non-evil biome to reanimating, only 2) turns on, just as is observed above.

The percentage of dead plants also has no effect on reanimation.

[PatrikLundell]

Unless DF structure mapping has uncovered more knowledge since I looked at it there is currently no known way to change 1) independently.

When DF spawns a group entering the map that group is drawn from the set of creatures present in the region and belonging to that biome (a region may contain multiple biomes), and it's probably drawn from the data structure that contains everything within a 7*7 tile region centered on the embark world tile. I would guess that DF determines whether to send a live or an undead group based on the reanimation flag combined with evilness, and I speculate that it might also take the death percentage into calculation (the value that determines how much of the flora is dead, which is set to 100% for all regions which death has seeped into, and a random 0-100% in evil regions starting out as such). The death percentage only takes effect if the world tile the biome on the embark belongs to is evil.
As a further guess, groups entering are probably based on the evilness of the world tile the biome they enter on belongs to, and half of them should be the world tile bordering the embark world tile, with the other half being the embark world tile itself. It can be noted that the air biome buggily is the biome of the world tile to the NW of the embark world tile, explaining why completely evil free embarks can get plagued by flying undead.

[Immortal-D]

I've gone back to cooking and have a new one for you.  I changed a land tile into an ocean tile using 'map - adopt biome', then changed the evilness and savagery of that new ocean tile.  When I try to change the weather of that same tile, I get this error.  Changing the weather of any original-land tile within the embark works fine.

Spoiler (click to show/hide)

...Dwarf Fortress 0.47.05/hack/scripts/biomemanipulator.lua:6962: bad argument #1 to 'len' (string expected, got nil)
stack traceback:
        [C]: in function 'string.len'
        ...Dwarf Fortress 0.47.05/hack/scripts/biomemanipulator.lua:6962: in function <...Dwarf Fortress 0.47.05/hack/scripts/biomemanipulator.lua:6910>
        [C]: in field 'on_select'
        ...Fortress\Dwarf Fortress 0.47.05\hack\lua\gui\widgets.lua:568: in method 'moveCursor'
        ...Fortress\Dwarf Fortress 0.47.05\hack\lua\gui\widgets.lua:499: in method 'setSelected'
        ...Dwarf Fortress 0.47.05/hack/scripts/biomemanipulator.lua:8600: in function <...Dwarf Fortress 0.47.05/hack/scripts/biomemanipulator.lua:8446>
        [C]: in ?

[PatrikLundell]

Looking at the script around line 6962 I come to the conclusion that the problem probably isn't related to the biome change, but rather to the weather, and thus that you'd get the error without the prior manipulation.

The problem seems to be that the weather defines some kind of syndrome effect that somehow doesn't match the expectations of the script, which may be caused by incorrect assumptions in the script (most likely) or some effect that DFHack hasn't mapped (less likely).
In either case, I'd need to reproduce the error with your save with a description of which tile you're trying to modify. I'm not sure if I need to know what you wanted to change the weather into as I'm not sure where this error occurs in the process, even though it looks like it would be when listing the options (i.e. before the selection).

[Immortal-D]

You are correct.  I tried weather change at the natural ocean border and got the same problem.  I am using ZM5 'Lands Of Duality' which includes new good / evil weather.  They all loaded in the manipulator, but most likely one is the culprit.  Save and location; https://www.dropbox.com/s/71lhsxxfthe4jsr/region6.7z?dl=0

[PatrikLundell]

Is that the correct same? I'm unable to match up any features of the world with those of the JPG file.

[Immortal-D]

Sorry, that picture was very zoomed in.  I think this will be better; https://www.dropbox.com/s/ruxu72val2fyt7v/Capture2.JPG?dl=0

[PatrikLundell]

The problem is caused by a value unmapped by DFHack. The mapping goes up to a value of 35, but the value encountered is 41 (in the type creature_interaction_effect_type), and there are values up to 47.

The problematic world has modded interaction raws for weather ("BP_HEALING_SAP" in this case), and these interactions use values that aren't mapped by DFHack, so I would advice you or ZM5 (who I assume is the author of the mod files, given their suffices) to update the DFHack structures to assign names to those values (I've also written an Issue for df-structures mentioning unmapped values).

Nevertheless I've modified the Biome Manipulator to handle these unknown values. The output isn't pretty, of course, but it no longer fails.

[Immortal-D]

The problem is caused by a value unmapped by DFHack. The mapping goes up to a value of 35, but the value encountered is 41 (in the type creature_interaction_effect_type), and there are values up to 47.

The problematic world has modded interaction raws for weather ("BP_HEALING_SAP" in this case), and these interactions use values that aren't mapped by DFHack, so I would advice you or ZM5 (who I assume is the author of the mod files, given their suffices) to update the DFHack structures to assign names to those values (I've also written an Issue for df-structures mentioning unmapped values).

Nevertheless I've modified the Biome Manipulator to handle these unknown values. The output isn't pretty, of course, but it no longer fails.

Fascinating.  I did not notice that particular weather was not displaying values before.  Your fix works perfectly, it now shows 'unknown values', and ingame the weather itself still works as expected.  Thank you sir!  I can not emphasize enough just how cool this plugin is, and how much fun I'm having combining world tiles into a perfect embark.

[A_Curious_Cat]

Would it be possible for biome-manipulator to change the layer stone of a stone layer while keeping the inclusions (veins, clusters, etc.) from before?

[PatrikLundell]

Would it be possible for biome-manipulator to change the layer stone of a stone layer while keeping the inclusions (veins, clusters, etc.) from before?

I haven't refreshed my knowledge, so I may be wrong, but I think the answer is:
- Thematically: No
- Technically: Probably no.
The reason is that it currently respects the specifications of what "stuff" each layer material may contain, so you're only allowed to select the materials permitted by the raw definitions, and layer materials each have their own set of "stuff" that can be in them.
I think the layer "stuff" definitions reference the indices in the raw definitions, in which case you'd have to change the raws first to provide something to reference.

I stress again that I haven't checked the technical details, so it might reference materials directly rather than indices.