Print

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

[BlackRogue]

Is this the one? http://www.bay12forums.com/smf/index.php?topic=104015.0

That's the one!  Thx. 

Glad I could help.

[Beeskee]

For the spire thing, it doesn't have to be an "official" spire, just something that looks like one.

Since the main problems with the spire maps is the tall spires end up being technically infinite, and producing some seriously weird glitches where dwarfs won't mine them.

I was thinking it would mainly be for RP maps or things like that.

[Girlinhat]

In that case, you can open the raws, remove [LAVA] from Obsidian, and place it onto Adamantine.  Then use DFLiquids, and using the "obsidian" mode it will now paint adamantine instead.  When you're done, undo the changes and your artificial spire will remain.

Works for any material, really.  You can produce a slade tower if you want.

[Quietust]

In that case, you can open the raws, remove [LAVA] from Obsidian, and place it onto Adamantine.  Then use DFLiquids, and using the "obsidian" mode it will now paint adamantine instead.  When you're done, undo the changes and your artificial spire will remain.

No, it will not - it'll change back to obsidian once you save/load. As such, you could just as easily cast a bunch of obsidian, save, then move [LAVA] from Obsidian to Raw Adamantine.

[Girlinhat]

Hrm, really?  I could swear that it would stick...

[Andux]

Obsidian is handled using a special set of tile types, rather than a vein, so there's no specific material ID stored with the tiles (though I'd imagine there's a global "LAVA Stone Mat Index" variable that gets filled in whenever the raws are loaded). Any stones you mined out should stick, though.

[Quietust]

Obsidian is handled using a special set of tile types, rather than a vein, so there's no specific material ID stored with the tiles (though I'd imagine there's a global "LAVA Stone Mat Index" variable that gets filled in whenever the raws are loaded).

Interestingly, it's not a global, but part of the geology data - if you have more than one [LAVA] stone, you'll get a different one in each biome.

[walberg]

I don't see that a 0.34.06 compatible release has been officially announced yet, so probably everything since 0.34.05-r1 is still considered unstable, but I wanted to report an apparent bug anyway...

On all commits since edf77c (Link protobuf to dfhack core as a shared library.), the Linux build seems to no longer work. It compiles fine, but running it simply gives "Memory fault" and dies. I did a Debug build, and the core file generated indicates the memory fault is here:

Core was generated by `/usr/local/games/dwarf-fortress/dfbin/libs/Dwarf_Fortress'.
Program terminated with signal 11, Segmentation fault.
[New process 25918]
#0  0xf74d0644 in global constructors keyed to DataStaticsFields.cpp ()
   from /usr/local/games/dwarf-fortress/dfbin/hack/libdfhack.so

Not so sure that helps a lot, but it gives someplace to start. This is on a 64-bit Debian 5.0.8 system with GCC 4.5.0, but is repeatable on Debian 6.0.4 (64-bit also with same version of compiler). I could try a different compiler version as well, but it'll take a while to cook one up...

[Rinin_Rus]

http://zalil.ru/32962130
http://www.filehosting.org/file/details/325079/dfhack-0.34.06-r1f-Windows-pre-alpha.zip

Ok, since I can't wait anymore for release i've just download and compile partially complete version of DFHack. "Reveal" and "prospect" seems works, it's enough for me to start. Other features could work, or not. I did nothing except downloading and compiling.

If you can't wait like me - you could try it.

And thanks again to all people working at this awesome project

PS windows only

[DirtyChineseCigarettes]

Thnx, I wasnt sure what would happen first, dfhack getting updated or df getting updated.

[narhiril]

Obsidian is handled using a special set of tile types, rather than a vein, so there's no specific material ID stored with the tiles (though I'd imagine there's a global "LAVA Stone Mat Index" variable that gets filled in whenever the raws are loaded).

Interestingly, it's not a global, but part of the geology data - if you have more than one [LAVA] stone, you'll get a different one in each biome.

I must find a way to abuse this.

[kingofthescots]

Thanks Rinin, those two tools are the ones I use the most anyways.

[slink]

Yes, thanks Rinin.  Drybuckets seems to work.  18 buckets recovered, wheee!   

[Electrode]

I don't see that a 0.34.06 compatible release has been officially announced yet, so probably everything since 0.34.05-r1 is still considered unstable, but I wanted to report an apparent bug anyway...

On all commits since edf77c (Link protobuf to dfhack core as a shared library.), the Linux build seems to no longer work. It compiles fine, but running it simply gives "Memory fault" and dies. I did a Debug build, and the core file generated indicates the memory fault is here:

(snip)

Not so sure that helps a lot, but it gives someplace to start. This is on a 64-bit Debian 5.0.8 system with GCC 4.5.0, but is repeatable on Debian 6.0.4 (64-bit also with same version of compiler). I could try a different compiler version as well, but it'll take a while to cook one up...

Latest code (d2d16271f0) is working fine for me, built with GCC 4.5.3 on 64-bit Gentoo. Remember that you need to compile dfhack as a 32-bit app. Try:

Code: [Select]

cd dfhack/build
setarch i386 cmake .. -DCMAKE_BUILD_TYPE:string=Release -DCMAKE_INSTALL_PREFIX=~/df_linux
setarch i386 make install


[the_game_hunt]

It seems that something horrible happened, that means no dfhacks, which is horrible.

Playing without dfhacks is really anoying (clean, prospect,fastdwarf,etc)