Print

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

[DerMeister]

I need plugin for embark directly on underworld spire.

[Pvt. Pirate]

I need plugin for embark directly on underworld spire.

just edit d_init to show stuff not on "FINDER" but on "ALWAYS"
then, if it is present, you'll see stuff on embark map

[lethosor]

It's not impossible to put together a DFHack release for an old build of DF. We've considered that before, but only for major versions (e.g. 0.34.11) and have never actually done it. It'd be a bit annoying to test, since saves aren't forward-compatible.

after the "mousequery edge" bug on 44.12 is resolved, i tried it out, loved the way it is now, but the game is still too prone to crashing.
so, could you make a version with the new features, but for 0.44.09-r1 ?

From this, it sounds like both versions are unstable for you, so I'm not seeing a clear reason to make a build for 0.44.09. Let me know if I'm misunderstanding. I also haven't seen a clear consensus on 0.44.09 being more stable than 0.44.12 (and why .09 and not .11?), but maybe I missed something.

For comparison: the weapon trap crash of 0.43.05 was something widespread enough that we would have considered supporting 0.43.04 too. However, that was infeasible due to the 64-bit changes in 0.43.05.
I feel like there was some longstanding bug in 0.34.11 too, but DFHack for 0.34.11 also supported 0.34.10 anyway since they were binary-compatible.

I need plugin for embark directly on underworld spire.

Not totally sure what the issue is here, but two options:
- If you can't see the spires, see Pvt Pirate's suggestion.
- If you can see the spires but can't embark on them, try "embark-tools enable anywhere".

[PatrikLundell]

While it's not impossible to make DFHack versions based on older DF versions, it's bound to be a fair bit of work, and thus would require a fairly significant incentive to do.

@DerMeister: It's a bit hard to understand what you want, so I'm guessing wildly:
It's not possible for a spire to reach the surface as far as I've seen (it was a long time ago, according to what I've heard), nor is it possible to embark underground. The Embark Assistant does not hack anything, but presents info about the world as it is. It is possible to hack various things using DFHack, though:
- Spires can be changed to reach any cavern level, as well as to stay the magma sea.
- Spires can be moved within their 2*2 mid level tile grids so they appear on a different mid level tile.
- The surface can be hacked to be lowered so much that one or more caverns are exposed, which can enable embarking at the cavern. This can also lead to cave-ins as cavern floors hacked to not exist result in material falling as soon as you embark.
These things can be done using the Region Manipulator script http://www.bay12forums.com/smf/index.php?topic=164136.msg7454345#msg7454345.
It may be possible to add new spires, but I haven't tried to do that, so such an attempt would have to be performed "manually".

[Pvt. Pirate]

It's not impossible to put together a DFHack release for an old build of DF. We've considered that before, but only for major versions (e.g. 0.34.11) and have never actually done it. It'd be a bit annoying to test, since saves aren't forward-compatible.

after the "mousequery edge" bug on 44.12 is resolved, i tried it out, loved the way it is now, but the game is still too prone to crashing.
so, could you make a version with the new features, but for 0.44.09-r1 ?

From this, it sounds like both versions are unstable for you, so I'm not seeing a clear reason to make a build for 0.44.09. Let me know if I'm misunderstanding. I also haven't seen a clear consensus on 0.44.09 being more stable than 0.44.12 (and why .09 and not .11?), but maybe I missed something.

For comparison: the weapon trap crash of 0.43.05 was something widespread enough that we would have considered supporting 0.43.04 too. However, that was infeasible due to the 64-bit changes in 0.43.05.
I feel like there was some longstanding bug in 0.34.11 too, but DFHack for 0.34.11 also supported 0.34.10 anyway since they were binary-compatible.

well, the 44.09-r1 is stable for me and the mousequery bug was fixable by using a different fork of dfhack or twbt (i don't remember right now). i can't find the necessary files online anywhere, which is why i repacked that fixed/patched version as a backup for myself.
the (now fixed) mousequery bug in 44.12 kept me from playing it at all, so i never came into any crashes, because i never played long enough.
i absolutely understand your considerations which versions to support, especially since it can be quite the work involved.

EDIT: i just found out, that even when only one embark square is marked, when i move the 3x3 embark so the flashing one is in the center, all biomes show the requirements as being met.
i always searched for ages to find a 3x3 flashing square. was i dumb before or is this not how it works?

[PatrikLundell]

Have you read the help screens? Unless I've made a grave mistake, it should state that a match for the embark rectangle is indicated by the single tile up in the top left corner or the rectangle, with the other tiles in the rectangle indicating the rectangles with those tiles as their corners.
The reason for this is that there is a need to indicate a match for any kind of rectangle, with a clear indication of where the matching rectangle is. You'd also note that with a 3*3 rectangle the two lowest  rows and the two rightmost columns never show any matches (because that would indicate a match in non existent mid level tiles outside the area).

Note that there are search conditions that require multiple embark tiles with different conditions in different tiles, such as e.g. partial aquifers, so a "matching tiles" logic doesn't work.

[clinodev]

Have you read the help screens? Unless I've made a grave mistake, it should state that a match for the embark rectangle is indicated by the single tile up in the top left corner or the rectangle, with the other tiles in the rectangle indicating the rectangles with those tiles as their corners.

Well, heck. Today I learned.

That's going to make finding great embark sites even easier!

[Pvt. Pirate]

Have you read the help screens? Unless I've made a grave mistake, it should state that a match for the embark rectangle is indicated by the single tile up in the top left corner or the rectangle, with the other tiles in the rectangle indicating the rectangles with those tiles as their corners.
The reason for this is that there is a need to indicate a match for any kind of rectangle, with a clear indication of where the matching rectangle is. You'd also note that with a 3*3 rectangle the two lowest  rows and the two rightmost columns never show any matches (because that would indicate a match in non existent mid level tiles outside the area).

Note that there are search conditions that require multiple embark tiles with different conditions in different tiles, such as e.g. partial aquifers, so a "matching tiles" logic doesn't work.

so i'd have ti place the 3x3 with its top-left tile on the flashing tile?
i mean i search for 3x3 embarks and there are sometimes 1x1 tiles flashing. maybe we just use different terminology...

[PatrikLundell]

yeS. as I believe I said, the tile in the top left corner indicates the match/no match for the embark rectangle of the selected size with its top left corner on that tilE.

[Pvt. Pirate]

oh, then i actually was bad at reading...

[PatrikLundell]

vjek encountered a crash bug when the advanced world gen parameters specified that no metals should be generated procedurally. The issue can be worked around by specifying at least one metal.

A pull request with a correction has been made, but there probably won't be any more DFHack releases before the Villains changes have been released.

[clinodev]

Interesting. I wonder what other factors are involved?

I ask because my regular AWG parameter set specifies "[GENERATE_DIVINE_MATERIALS:0]", and in the process of finding a world I liked for a tutorial I recently generated literally (in the old fashioned sense of "I'm not exaggerating for effect,") dozens of worlds over the course of three nights and ran embark-assistant on them, with no crashes that I recall.

[PatrikLundell]

Thanks for the follow up, clinodev.

Since your experience didn't seem to make sense given what the code looks (or looked) like, I ran a script that printed the names of all generated materials in my last fortress. It turns out that beside DIVINE_X, there's also EVIL_RAIN_X, so apparently you'd have to disable both evil weather and divine materials to be affected by the bug (I'm not sure if evil mist would appear as well: that world has those set to 0).

I think setting divine materials to 1 is better than setting the number of evil weathers to one though, if you really don't want either.

[clinodev]

Ah, nice.

Yes, I've always controlled my evil weather exposure through site selection, but annoying procgen materials clutter my menus and caravans no matter how far I embark away from their sources.

[Fleeting Frames]

after the "mousequery edge" bug on 44.12 is resolved, i tried it out, loved the way it is now, but the game is still too prone to crashing.
so, could you make a version with the new features, but for 0.44.09-r1 ?

Two notes:

One, you can port 44.09 saves to 44.12. So you can copy your region folder to 44.12, and look for embark there, then quit and start the embark in 44.09. Iirc geography was also the same between the two, so generating from same parameters+seed might work as well for this.


Second, what you ask, if you're still interested, is not quite the same as doing latest dfhack release for an old build of DF, and the ways it differs is that it is a lot easier.
I'm guessing you would need to 1) compile dfhack for your OS according to dfhack build instructions, expect instead of pulling the most recent dfhack from git pulling the latest 44.09 version; 2) replace the embark-assistant plugin code with the latest one; 3) compare the plugin codes and unreplace any anonymous/unknown fields that got named with their 44.09 versions.

(I once did something like that for TWBT here, though that was likely far more involved due both 32-64 bit jump and Next being substantial jump.)