Print

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

[Roses]

Questions about changing values;

I know if I use DFHack to change a value in the raws it will be overwritten on the next load of the game, but what about changing values in fields like df.global.world.entities.all[0].resources.ethic? Does anyone know if changing these values has an effect on the game, and if that effect is persistent through saving and loading?

[Quietust]

Questions about changing values;

I know if I use DFHack to change a value in the raws it will be overwritten on the next load of the game, but what about changing values in fields like df.global.world.entities.all[0].resources.ethic? Does anyone know if changing these values has an effect on the game, and if that effect is persistent through saving and loading?

The only reason raws do not persist is because they are not saved in world.[dat|sav] but are instead loaded from external files - if you modify an entity's properties in memory and save/load, the changes will absolutely persist through a save/load cycle (unless the properties you are modifying aren't saved to disk).

Now, whether or not changing those values will affect gameplay is a completely different story - in your example, most ethics are used only during worldgen and have no effect during Fortress mode.

[IndigoFenix]

Hmmm...
How do I remove a single item from a building or container, and place it on a specific tile as if it was dropped there?  dfhack.items.moveToGround returns false, deleting the general ref doesn't do anything, deleting the entry in buildings.contained_items destroys the item itself and calling the vmethod deconstructItems (which isn't what I want anyway, because it removes all items) followed by moveToGround crashes the game.  I find it hard to believe that this is such a complex task.

EDIT: I figured out a method that works, although it is completely ridiculous.  I set the item's position to the desired location, then turn the item into a projectile with no speed, and finally remove the entry in buildings.contained items.  It...works.  I can't honestly believe that this is the best way of doing it though.

[lordkrike]

I am having irritating issues with building DFHack, and I can't figure out what I'm doing wrong.  I was hoping I could get some assistance.

When I attempt to build the latest version with cmake or ccmake, I get the following error message:

Code: [Select]

CMake Error at depends/protobuf/CMakeLists.txt:60 (MESSAGE):
   Could not find a working hash map implementation.  Please install GCC >=
   4.4, and all necessary 32-bit C++ development libraries.

Which, if the other posts here are correct, suggest that I don't have the correct 32-bit libraries installed.

I'm running 64-bit Debian Testing.  I have multiarch support enabled.  I have practically every GCC and G++ library I can get from the repository without conflicts to include:

Spoiler (click to show/hide)

gcc
gcc-multilib
gcc-4.4
gcc-4.4-base
gcc-4.4-multilib
gcc-4.6
gcc-4.6-base
gcc-4.6-multilib
gcc-4.7
gcc-4.7-base
gcc-4.7-multilib
lib32gcc-4.7-dev
libgcc-4.7-dev
libx32gcc-4.7-dev
gcc-4.8
gcc-4.8-base
gcc-4.8-multilib
lib32gcc-4.8-dev
libgcc-4.8-dev
libx32gcc-4.8-dev
gcc-4.8-base:i386
lib32gcc
libgcc
lib32gcc1
libgcc1
libgcc1:i386
libx32gcc1

I also have protobuf-compiler and protobuf-c-compiler, and mingw.  mingw has both 32-bit and 64-bit libraries available, and I'm not sure about protobuf, but there is a separate :i386 library, I just can't have both installed simultaneously.

So I'm at a loss.  I have no idea what package I could be missing to fix this.  Does anyone have any ideas?

Below is my CMakeError.log:

Spoiler (click to show/hide)

Determining if the pthread_create exist failed with the following output:
Change Dir: /home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp

Run Build Command:/usr/bin/make "cmTryCompileExec1932352873/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec1932352873.dir/build.make CMakeFiles/cmTryCompileExec1932352873.dir/build
make[1]: Entering directory `/home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report /home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec1932352873.dir/CheckSymbolExists.c.o
/usr/bin/cc   -fvisibility=hidden -m32 -march=i686 -mtune=generic    -o CMakeFiles/cmTryCompileExec1932352873.dir/CheckSymbolExists.c.o   -c /home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c
Linking C executable cmTryCompileExec1932352873
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec1932352873.dir/link.txt --verbose=1
/usr/bin/cc   -fvisibility=hidden -m32 -march=i686 -mtune=generic     CMakeFiles/cmTryCompileExec1932352873.dir/CheckSymbolExists.c.o  -o cmTryCompileExec1932352873 -rdynamic
CMakeFiles/cmTryCompileExec1932352873.dir/CheckSymbolExists.c.o: In function `main':
CheckSymbolExists.c:(.text+0xa): undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status
make[1]: *** [cmTryCompileExec1932352873] Error 1
make[1]: Leaving directory `/home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp'
make: *** [cmTryCompileExec1932352873/fast] Error 2

File /home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include <pthread.h>

int main(int argc, char** argv)
{
  (void)argv;
#ifndef pthread_create
  return ((int*)(&pthread_create))[argc];
#else
  (void)argc;
  return 0;
#endif
}

Determining if the function pthread_create exists in the pthreads failed with the following output:
Change Dir: /home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp

Run Build Command:/usr/bin/make "cmTryCompileExec3908671546/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec3908671546.dir/build.make CMakeFiles/cmTryCompileExec3908671546.dir/build
make[1]: Entering directory `/home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report /home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec3908671546.dir/CheckFunctionExists.c.o
/usr/bin/cc   -fvisibility=hidden -m32 -march=i686 -mtune=generic -DCHECK_FUNCTION_EXISTS=pthread_create   -o CMakeFiles/cmTryCompileExec3908671546.dir/CheckFunctionExists.c.o   -c /usr/share/cmake-2.8/Modules/CheckFunctionExists.c
Linking C executable cmTryCompileExec3908671546
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec3908671546.dir/link.txt --verbose=1
/usr/bin/cc   -fvisibility=hidden -m32 -march=i686 -mtune=generic -DCHECK_FUNCTION_EXISTS=pthread_create    CMakeFiles/cmTryCompileExec3908671546.dir/CheckFunctionExists.c.o  -o cmTryCompileExec3908671546 -rdynamic -lpthreads
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
make[1]: Leaving directory `/home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp'
make[1]: *** [cmTryCompileExec3908671546] Error 1
make: *** [cmTryCompileExec3908671546/fast] Error 2

There's something about lpthreads in there, but I don't know jack about cmake and so I'm not sure what's going on.

[Roses]

Hmmm...
How do I remove a single item from a building or container, and place it on a specific tile as if it was dropped there?  dfhack.items.moveToGround returns false, deleting the general ref doesn't do anything, deleting the entry in buildings.contained_items destroys the item itself and calling the vmethod deconstructItems (which isn't what I want anyway, because it removes all items) followed by moveToGround crashes the game.  I find it hard to believe that this is such a complex task.

EDIT: I figured out a method that works, although it is completely ridiculous.  I set the item's position to the desired location, then turn the item into a projectile with no speed, and finally remove the entry in buildings.contained items.  It...works.  I can't honestly believe that this is the best way of doing it though.

I think just setting the position of the item and setting items.flags.on_ground=true (also removing the entry in the building) should work (at least I remember doing something similar for moving things created in a workshop up several z levels, I will see if I can find my old code).

[Sutremaine]

How do I take a look at a dwarf's infection level? I've been looking at the structures here and it would seem that unit.body.infection_level would be the right thing to use. However, if I try that, I get an error:

Cannot read field unit T_body.infection_level: not found

unit.body.blood_count works fine, and blood_count is immediately above infection_level.

[PeridexisErrant]

I got a message on Reddit from Ciphertext008 - it's about dfhack r3,but I thought I'd pass it on.

http://i.imgur.com/5zXj7Rn.png I have been updating my LNP from r44 to r48 this change might need to go upstream. Line 156 dwarfortress34.11/hack/lua/gui/script.lua is missing a ')'

[ulspa]

I am having irritating issues with building DFHack, and I can't figure out what I'm doing wrong.  I was hoping I could get some assistance.

When I attempt to build the latest version with cmake or ccmake, I get the following error message:

Code: [Select]

CMake Error at depends/protobuf/CMakeLists.txt:60 (MESSAGE):
   Could not find a working hash map implementation.  Please install GCC >=
   4.4, and all necessary 32-bit C++ development libraries.

Which, if the other posts here are correct, suggest that I don't have the correct 32-bit libraries installed.

I'm running 64-bit Debian Testing.  I have multiarch support enabled.  I have practically every GCC and G++ library I can get from the repository without conflicts to include:

Spoiler (click to show/hide)

gcc
gcc-multilib
gcc-4.4
gcc-4.4-base
gcc-4.4-multilib
gcc-4.6
gcc-4.6-base
gcc-4.6-multilib
gcc-4.7
gcc-4.7-base
gcc-4.7-multilib
lib32gcc-4.7-dev
libgcc-4.7-dev
libx32gcc-4.7-dev
gcc-4.8
gcc-4.8-base
gcc-4.8-multilib
lib32gcc-4.8-dev
libgcc-4.8-dev
libx32gcc-4.8-dev
gcc-4.8-base:i386
lib32gcc
libgcc
lib32gcc1
libgcc1
libgcc1:i386
libx32gcc1

I also have protobuf-compiler and protobuf-c-compiler, and mingw.  mingw has both 32-bit and 64-bit libraries available, and I'm not sure about protobuf, but there is a separate :i386 library, I just can't have both installed simultaneously.

So I'm at a loss.  I have no idea what package I could be missing to fix this.  Does anyone have any ideas?

Below is my CMakeError.log:

Spoiler (click to show/hide)

Determining if the pthread_create exist failed with the following output:
Change Dir: /home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp

Run Build Command:/usr/bin/make "cmTryCompileExec1932352873/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec1932352873.dir/build.make CMakeFiles/cmTryCompileExec1932352873.dir/build
make[1]: Entering directory `/home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report /home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec1932352873.dir/CheckSymbolExists.c.o
/usr/bin/cc   -fvisibility=hidden -m32 -march=i686 -mtune=generic    -o CMakeFiles/cmTryCompileExec1932352873.dir/CheckSymbolExists.c.o   -c /home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c
Linking C executable cmTryCompileExec1932352873
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec1932352873.dir/link.txt --verbose=1
/usr/bin/cc   -fvisibility=hidden -m32 -march=i686 -mtune=generic     CMakeFiles/cmTryCompileExec1932352873.dir/CheckSymbolExists.c.o  -o cmTryCompileExec1932352873 -rdynamic
CMakeFiles/cmTryCompileExec1932352873.dir/CheckSymbolExists.c.o: In function `main':
CheckSymbolExists.c:(.text+0xa): undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status
make[1]: *** [cmTryCompileExec1932352873] Error 1
make[1]: Leaving directory `/home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp'
make: *** [cmTryCompileExec1932352873/fast] Error 2

File /home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include <pthread.h>

int main(int argc, char** argv)
{
  (void)argv;
#ifndef pthread_create
  return ((int*)(&pthread_create))[argc];
#else
  (void)argc;
  return 0;
#endif
}

Determining if the function pthread_create exists in the pthreads failed with the following output:
Change Dir: /home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp

Run Build Command:/usr/bin/make "cmTryCompileExec3908671546/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec3908671546.dir/build.make CMakeFiles/cmTryCompileExec3908671546.dir/build
make[1]: Entering directory `/home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report /home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec3908671546.dir/CheckFunctionExists.c.o
/usr/bin/cc   -fvisibility=hidden -m32 -march=i686 -mtune=generic -DCHECK_FUNCTION_EXISTS=pthread_create   -o CMakeFiles/cmTryCompileExec3908671546.dir/CheckFunctionExists.c.o   -c /usr/share/cmake-2.8/Modules/CheckFunctionExists.c
Linking C executable cmTryCompileExec3908671546
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec3908671546.dir/link.txt --verbose=1
/usr/bin/cc   -fvisibility=hidden -m32 -march=i686 -mtune=generic -DCHECK_FUNCTION_EXISTS=pthread_create    CMakeFiles/cmTryCompileExec3908671546.dir/CheckFunctionExists.c.o  -o cmTryCompileExec3908671546 -rdynamic -lpthreads
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
make[1]: Leaving directory `/home/adam/Games/df_linux/dfhack/build/CMakeFiles/CMakeTmp'
make[1]: *** [cmTryCompileExec3908671546] Error 1
make: *** [cmTryCompileExec3908671546/fast] Error 2

There's something about lpthreads in there, but I don't know jack about cmake and so I'm not sure what's going on.

Your problem is, that your compiler can't find the file libpthreads. There is no problem with cmake.
You can check whether you have a file called libpthreads.so in /usr/lib/ or in /lib or anywhere else.
But most probably you don't have this file installed.
libpthreads is part of glibc. You can search for glibc or libpthreads in your package manager. Most probably you will find it there, otherwise you can ask somewhere in a debian related forum how to obtain this library. Hope this helps you to solve your problem.

[Putnam]

I got a message on Reddit from Ciphertext008 - it's about dfhack r3,but I thought I'd pass it on.

http://i.imgur.com/5zXj7Rn.png I have been updating my LNP from r44 to r48 this change might need to go upstream. Line 156 dwarfortress34.11/hack/lua/gui/script.lua is missing a ')'

Yeah, that was fixed in r4

[IndigoFenix]

How do I read the subtype of a given item if I don't know whether or not it has a subtype?  I've tried passing it to a variable and checking if the variable is nil but it seems that just trying to check for a subtype on an item with no subtype crashes the script.

[Rumrusher]

okay so finally figure out how to bypass the whole every one goes insane and attacks each other when switching to arena mode.
it's mostly due to every one in fort/adventure mode have their Combat_side_id set to 0 which is independent and a giant hostile mess for every one.
with this new script remodel from an old 'companion every civ' script you can swap to and from arena mode with not worrying about dwarves murdering each other though.
script here
 

[lordkrike]

Your problem is, that your compiler can't find the file libpthreads. There is no problem with cmake.
You can check whether you have a file called libpthreads.so in /usr/lib/ or in /lib or anywhere else.
But most probably you don't have this file installed.
libpthreads is part of glibc. You can search for glibc or libpthreads in your package manager. Most probably you will find it there, otherwise you can ask somewhere in a debian related forum how to obtain this library. Hope this helps you to solve your problem.

Alright, so one problem down.  I had to install libc6:i386 to get a 32-bit libpthreads.so.0.  It seems to be okay with finding pthreads now.

However, I still have the message that it can't find a working hash map.  The full output from cmake follows:

Spoiler (click to show/hide)

-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.8")
CMake Error at depends/protobuf/CMakeLists.txt:60 (MESSAGE):
  Could not find a working hash map implementation.  Please install GCC >=
  4.4, and all necessary 32-bit C++ development libraries.


-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE 
-- Configuring incomplete, errors occurred!

And actually, looking at the complete output from cmake (which ccmake doesn't print, oddly enough), it might be suggesting that it can't find a 32-bit version of zlib.  Except I have a 32-bit version of zlib installed (/lib/i386-linux-gnu/libz.so.1 from the zlib1g:i386 package).

Thoughts?

[Putnam]

How do I read the subtype of a given item if I don't know whether or not it has a subtype?  I've tried passing it to a variable and checking if the variable is nil but it seems that just trying to check for a subtype on an item with no subtype crashes the script.

item:getSubtype()

If that returns -1, it has no subtype.

[IndigoFenix]

How do I read the subtype of a given item if I don't know whether or not it has a subtype?  I've tried passing it to a variable and checking if the variable is nil but it seems that just trying to check for a subtype on an item with no subtype crashes the script.

item:getSubtype()

If that returns -1, it has no subtype.

Oh, that simple?  I'm pretty sure I tried that... or maybe I used some variation of it, like dfhack.item:getSubtype() or something.

[Putnam]

It's a method of the item itself, so I can see why you would have problem with that :p