Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 173 174 [175] 176 177 ... 244

Author Topic: DFHack 50.14-r1.1  (Read 888962 times)

A_Curious_Cat

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2610 on: October 11, 2020, 11:47:47 am »

I forgot to update master so it was still on r2. Fixed. For reference, you can see when the branch was last updated at https://github.com/dfhack/dfhack/tree/master - previously, it said "0.47.04-r2" and "August 8".

I think I'll try again, then...

Also:

I am extremely angry.  The first time I posted the post above this one, the forum software ate half my post.  Then when I went to edit the post, it wouldn't let me save the changes.  So, then I copied the changes, went out of the thread and came back in, clicked modify, deleted everything and pasted only to have it paste in something else instead of what I had just copied.  At that point I just gave up and made this (second) post.  >:(

Edit:

Currently got all 8 cores compiling...

Also, should I be concerned about this warning ccmake gave me:
Code: [Select]
CMake Warning at depends/jsoncpp-sub/src/lib_json/CMakeLists.txt:36 (MESSAGE):
   Locale functionality is not supported



 CMake Warning (dev) at depends/libzip/CMakeLists.txt:186 (find_package):
   Policy CMP0074 is not set: find_package uses <PackageName>_ROOT variables.
   Run "cmake --help-policy CMP0074" for policy details.  Use the cmake_policy
   command to set the policy and suppress this warning.

   CMake variable ZLIB_ROOT is set to:

     /usr/lib/i386-linux-gnu

   For compatibility, CMake is ignoring the variable.
 This warning is for project developers.  Use -Wno-dev to suppress it.
?
« Last Edit: October 11, 2020, 12:10:11 pm by A_Curious_Cat »
Logged
Really hoping somebody puts this in their signature.

A_Curious_Cat

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2611 on: October 11, 2020, 12:17:26 pm »

Here's the entire output of "ninja -j8 install":

Code: [Select]
[121/578] Building C object depends/libzip/lib/CMakeFiles/zip.dir/zip_add_dir.c.o
FAILED: depends/libzip/lib/CMakeFiles/zip.dir/zip_add_dir.c.o
ccache /usr/bin/cc -DHAVE_CUCHAR -DLINUX_BUILD -DLUA_BUILD_AS_DLL -DPROTOBUF_USE_DLLS -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_CXX11_ABI=0 -D_LINUX -I../depends/protobuf -I../depends/lua/include -I../depends/md5 -I../depends/tinyxml -I../depends/tthread -I../depends/clsocket/src -I../depends/xlsxio/include -I../depends/libzip/lib -Idepends/libzip -fvisibility=hidden -mtune=generic -m32 -march=i686 -O3 -DNDEBUG -fPIC -MD -MT depends/libzip/lib/CMakeFiles/zip.dir/zip_add_dir.c.o -MF depends/libzip/lib/CMakeFiles/zip.dir/zip_add_dir.c.o.d -o depends/libzip/lib/CMakeFiles/zip.dir/zip_add_dir.c.o   -c ../depends/libzip/lib/zip_add_dir.c
In file included from depends/libzip/config.h:4,
                 from ../depends/libzip/lib/zipint.h:37,
                 from ../depends/libzip/lib/zip_add_dir.c:36:
depends/libzip/zipconf.h:28:10: warning: type defaults to ‘int’ in declaration of ‘zip_int16_t’ [-Wimplicit-int]
 typedef  zip_int16_t;
          ^~~~~~~~~~~
depends/libzip/zipconf.h:29:10: warning: type defaults to ‘int’ in declaration of ‘zip_uint16_t’ [-Wimplicit-int]
 typedef  zip_uint16_t;
          ^~~~~~~~~~~~
In file included from ../depends/libzip/lib/zipint.h:38,
                 from ../depends/libzip/lib/zip_add_dir.c:36:
../depends/libzip/lib/compat.h:146:2: error: #error unsupported size of off_t
 #error unsupported size of off_t
  ^~~~~
[122/578] Building C object depends/libzip/lib/CMakeFiles/zip.dir/zip_add_entry.c.o
FAILED: depends/libzip/lib/CMakeFiles/zip.dir/zip_add_entry.c.o
ccache /usr/bin/cc -DHAVE_CUCHAR -DLINUX_BUILD -DLUA_BUILD_AS_DLL -DPROTOBUF_USE_DLLS -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_CXX11_ABI=0 -D_LINUX -I../depends/protobuf -I../depends/lua/include -I../depends/md5 -I../depends/tinyxml -I../depends/tthread -I../depends/clsocket/src -I../depends/xlsxio/include -I../depends/libzip/lib -Idepends/libzip -fvisibility=hidden -mtune=generic -m32 -march=i686 -O3 -DNDEBUG -fPIC -MD -MT depends/libzip/lib/CMakeFiles/zip.dir/zip_add_entry.c.o -MF depends/libzip/lib/CMakeFiles/zip.dir/zip_add_entry.c.o.d -o depends/libzip/lib/CMakeFiles/zip.dir/zip_add_entry.c.o   -c ../depends/libzip/lib/zip_add_entry.c
In file included from depends/libzip/config.h:4,
                 from ../depends/libzip/lib/zipint.h:37,
                 from ../depends/libzip/lib/zip_add_entry.c:37:
depends/libzip/zipconf.h:28:10: warning: type defaults to ‘int’ in declaration of ‘zip_int16_t’ [-Wimplicit-int]
 typedef  zip_int16_t;
          ^~~~~~~~~~~
depends/libzip/zipconf.h:29:10: warning: type defaults to ‘int’ in declaration of ‘zip_uint16_t’ [-Wimplicit-int]
 typedef  zip_uint16_t;
          ^~~~~~~~~~~~
In file included from ../depends/libzip/lib/zipint.h:38,
                 from ../depends/libzip/lib/zip_add_entry.c:37:
../depends/libzip/lib/compat.h:146:2: error: #error unsupported size of off_t
 #error unsupported size of off_t
  ^~~~~
[123/578] Building C object depends/libzip/lib/CMakeFiles/zip.dir/zip_add.c.o
FAILED: depends/libzip/lib/CMakeFiles/zip.dir/zip_add.c.o
ccache /usr/bin/cc -DHAVE_CUCHAR -DLINUX_BUILD -DLUA_BUILD_AS_DLL -DPROTOBUF_USE_DLLS -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_CXX11_ABI=0 -D_LINUX -I../depends/protobuf -I../depends/lua/include -I../depends/md5 -I../depends/tinyxml -I../depends/tthread -I../depends/clsocket/src -I../depends/xlsxio/include -I../depends/libzip/lib -Idepends/libzip -fvisibility=hidden -mtune=generic -m32 -march=i686 -O3 -DNDEBUG -fPIC -MD -MT depends/libzip/lib/CMakeFiles/zip.dir/zip_add.c.o -MF depends/libzip/lib/CMakeFiles/zip.dir/zip_add.c.o.d -o depends/libzip/lib/CMakeFiles/zip.dir/zip_add.c.o   -c ../depends/libzip/lib/zip_add.c
In file included from depends/libzip/config.h:4,
                 from ../depends/libzip/lib/zipint.h:37,
                 from ../depends/libzip/lib/zip_add.c:36:
depends/libzip/zipconf.h:28:10: warning: type defaults to ‘int’ in declaration of ‘zip_int16_t’ [-Wimplicit-int]
 typedef  zip_int16_t;
          ^~~~~~~~~~~
depends/libzip/zipconf.h:29:10: warning: type defaults to ‘int’ in declaration of ‘zip_uint16_t’ [-Wimplicit-int]
 typedef  zip_uint16_t;
          ^~~~~~~~~~~~
In file included from ../depends/libzip/lib/zipint.h:38,
                 from ../depends/libzip/lib/zip_add.c:36:
../depends/libzip/lib/compat.h:146:2: error: #error unsupported size of off_t
 #error unsupported size of off_t
  ^~~~~
[126/578] Building C object depends/libzip/lib/CMakeFiles/zip.dir/zip_algorithm_deflate.c.o
FAILED: depends/libzip/lib/CMakeFiles/zip.dir/zip_algorithm_deflate.c.o
ccache /usr/bin/cc -DHAVE_CUCHAR -DLINUX_BUILD -DLUA_BUILD_AS_DLL -DPROTOBUF_USE_DLLS -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_CXX11_ABI=0 -D_LINUX -I../depends/protobuf -I../depends/lua/include -I../depends/md5 -I../depends/tinyxml -I../depends/tthread -I../depends/clsocket/src -I../depends/xlsxio/include -I../depends/libzip/lib -Idepends/libzip -fvisibility=hidden -mtune=generic -m32 -march=i686 -O3 -DNDEBUG -fPIC -MD -MT depends/libzip/lib/CMakeFiles/zip.dir/zip_algorithm_deflate.c.o -MF depends/libzip/lib/CMakeFiles/zip.dir/zip_algorithm_deflate.c.o.d -o depends/libzip/lib/CMakeFiles/zip.dir/zip_algorithm_deflate.c.o   -c ../depends/libzip/lib/zip_algorithm_deflate.c
In file included from depends/libzip/config.h:4,
                 from ../depends/libzip/lib/zipint.h:37,
                 from ../depends/libzip/lib/zip_algorithm_deflate.c:34:
depends/libzip/zipconf.h:28:10: warning: type defaults to ‘int’ in declaration of ‘zip_int16_t’ [-Wimplicit-int]
 typedef  zip_int16_t;
          ^~~~~~~~~~~
depends/libzip/zipconf.h:29:10: warning: type defaults to ‘int’ in declaration of ‘zip_uint16_t’ [-Wimplicit-int]
 typedef  zip_uint16_t;
          ^~~~~~~~~~~~
In file included from ../depends/libzip/lib/zipint.h:38,
                 from ../depends/libzip/lib/zip_algorithm_deflate.c:34:
../depends/libzip/lib/compat.h:146:2: error: #error unsupported size of off_t
 #error unsupported size of off_t
  ^~~~~
[127/578] Building C object depends/libzip/lib/CMakeFiles/zip.dir/zip_buffer.c.o
FAILED: depends/libzip/lib/CMakeFiles/zip.dir/zip_buffer.c.o
ccache /usr/bin/cc -DHAVE_CUCHAR -DLINUX_BUILD -DLUA_BUILD_AS_DLL -DPROTOBUF_USE_DLLS -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_CXX11_ABI=0 -D_LINUX -I../depends/protobuf -I../depends/lua/include -I../depends/md5 -I../depends/tinyxml -I../depends/tthread -I../depends/clsocket/src -I../depends/xlsxio/include -I../depends/libzip/lib -Idepends/libzip -fvisibility=hidden -mtune=generic -m32 -march=i686 -O3 -DNDEBUG -fPIC -MD -MT depends/libzip/lib/CMakeFiles/zip.dir/zip_buffer.c.o -MF depends/libzip/lib/CMakeFiles/zip.dir/zip_buffer.c.o.d -o depends/libzip/lib/CMakeFiles/zip.dir/zip_buffer.c.o   -c ../depends/libzip/lib/zip_buffer.c
In file included from depends/libzip/config.h:4,
                 from ../depends/libzip/lib/zipint.h:37,
                 from ../depends/libzip/lib/zip_buffer.c:37:
depends/libzip/zipconf.h:28:10: warning: type defaults to ‘int’ in declaration of ‘zip_int16_t’ [-Wimplicit-int]
 typedef  zip_int16_t;
          ^~~~~~~~~~~
depends/libzip/zipconf.h:29:10: warning: type defaults to ‘int’ in declaration of ‘zip_uint16_t’ [-Wimplicit-int]
 typedef  zip_uint16_t;
          ^~~~~~~~~~~~
In file included from ../depends/libzip/lib/zipint.h:38,
                 from ../depends/libzip/lib/zip_buffer.c:37:
../depends/libzip/lib/compat.h:146:2: error: #error unsupported size of off_t
 #error unsupported size of off_t
  ^~~~~
../depends/libzip/lib/zip_buffer.c: In function ‘_zip_buffer_get_64’:
../depends/libzip/lib/zip_buffer.c:111:35: warning: left shift count >= width of type [-Wshift-count-overflow]
     return ((zip_uint64_t)data[7] << 56) + ((zip_uint64_t)data[6] << 48) + ((zip_uint64_t)data[5] << 40) + ((zip_uint64_t)data[4] << 32) + ((zip_uint64_t)data[3] << 24) + ((zip_uint64_t)data[2] << 16) + ((zip_uint64_t)data[1] << 8) + (zip_uint64_t)data[0];
                                   ^~
../depends/libzip/lib/zip_buffer.c:111:67: warning: left shift count >= width of type [-Wshift-count-overflow]
     return ((zip_uint64_t)data[7] << 56) + ((zip_uint64_t)data[6] << 48) + ((zip_uint64_t)data[5] << 40) + ((zip_uint64_t)data[4] << 32) + ((zip_uint64_t)data[3] << 24) + ((zip_uint64_t)data[2] << 16) + ((zip_uint64_t)data[1] << 8) + (zip_uint64_t)data[0];
                                                                   ^~
../depends/libzip/lib/zip_buffer.c:111:99: warning: left shift count >= width of type [-Wshift-count-overflow]
     return ((zip_uint64_t)data[7] << 56) + ((zip_uint64_t)data[6] << 48) + ((zip_uint64_t)data[5] << 40) + ((zip_uint64_t)data[4] << 32) + ((zip_uint64_t)data[3] << 24) + ((zip_uint64_t)data[2] << 16) + ((zip_uint64_t)data[1] << 8) + (zip_uint64_t)data[0];
                                                                                                   ^~
../depends/libzip/lib/zip_buffer.c:111:131: warning: left shift count >= width of type [-Wshift-count-overflow]
     return ((zip_uint64_t)data[7] << 56) + ((zip_uint64_t)data[6] << 48) + ((zip_uint64_t)data[5] << 40) + ((zip_uint64_t)data[4] << 32) + ((zip_uint64_t)data[3] << 24) + ((zip_uint64_t)data[2] << 16) + ((zip_uint64_t)data[1] << 8) + (zip_uint64_t)data[0];
                                                                                                                                   ^~
../depends/libzip/lib/zip_buffer.c: In function ‘_zip_buffer_put_64’:
../depends/libzip/lib/zip_buffer.c:273:32: warning: right shift count >= width of type [-Wshift-count-overflow]
     data[4] = (zip_uint8_t)((i >> 32) & 0xff);
                                ^~
../depends/libzip/lib/zip_buffer.c:274:32: warning: right shift count >= width of type [-Wshift-count-overflow]
     data[5] = (zip_uint8_t)((i >> 40) & 0xff);
                                ^~
../depends/libzip/lib/zip_buffer.c:275:32: warning: right shift count >= width of type [-Wshift-count-overflow]
     data[6] = (zip_uint8_t)((i >> 48) & 0xff);
                                ^~
../depends/libzip/lib/zip_buffer.c:276:32: warning: right shift count >= width of type [-Wshift-count-overflow]
     data[7] = (zip_uint8_t)((i >> 56) & 0xff);
                                ^~
[128/578] Building C object depends/libzip/lib/CMakeFiles/zip.dir/zip_close.c.o
FAILED: depends/libzip/lib/CMakeFiles/zip.dir/zip_close.c.o
ccache /usr/bin/cc -DHAVE_CUCHAR -DLINUX_BUILD -DLUA_BUILD_AS_DLL -DPROTOBUF_USE_DLLS -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_CXX11_ABI=0 -D_LINUX -I../depends/protobuf -I../depends/lua/include -I../depends/md5 -I../depends/tinyxml -I../depends/tthread -I../depends/clsocket/src -I../depends/xlsxio/include -I../depends/libzip/lib -Idepends/libzip -fvisibility=hidden -mtune=generic -m32 -march=i686 -O3 -DNDEBUG -fPIC -MD -MT depends/libzip/lib/CMakeFiles/zip.dir/zip_close.c.o -MF depends/libzip/lib/CMakeFiles/zip.dir/zip_close.c.o.d -o depends/libzip/lib/CMakeFiles/zip.dir/zip_close.c.o   -c ../depends/libzip/lib/zip_close.c
In file included from depends/libzip/config.h:4,
                 from ../depends/libzip/lib/zipint.h:37,
                 from ../depends/libzip/lib/zip_close.c:35:
depends/libzip/zipconf.h:28:10: warning: type defaults to ‘int’ in declaration of ‘zip_int16_t’ [-Wimplicit-int]
 typedef  zip_int16_t;
          ^~~~~~~~~~~
depends/libzip/zipconf.h:29:10: warning: type defaults to ‘int’ in declaration of ‘zip_uint16_t’ [-Wimplicit-int]
 typedef  zip_uint16_t;
          ^~~~~~~~~~~~
In file included from ../depends/libzip/lib/zipint.h:38,
                 from ../depends/libzip/lib/zip_close.c:35:
../depends/libzip/lib/compat.h:146:2: error: #error unsupported size of off_t
 #error unsupported size of off_t
  ^~~~~
In file included from depends/libzip/config.h:4,
                 from ../depends/libzip/lib/zipint.h:37,
                 from ../depends/libzip/lib/zip_close.c:35:
../depends/libzip/lib/zip_close.c: In function ‘zip_close’:
depends/libzip/zipconf.h:49:25: warning: conversion from ‘long long unsigned int’ to ‘zip_uint64_t’ {aka ‘long unsigned int’} changes value from ‘18446744073709551615’ to ‘4294967295’ [-Woverflow]
 #define ZIP_UINT64_MAX  0xffffffffffffffffULL
                         ^~~~~~~~~~~~~~~~~~~~~
../depends/libzip/lib/zip_close.c:91:24: note: in expansion of macro ‘ZIP_UINT64_MAX’
     unchanged_offset = ZIP_UINT64_MAX;
                        ^~~~~~~~~~~~~~
depends/libzip/zipconf.h:49:25: warning: conversion from ‘long long unsigned int’ to ‘zip_uint64_t’ {aka ‘long unsigned int’} changes value from ‘18446744073709551615’ to ‘4294967295’ [-Woverflow]
 #define ZIP_UINT64_MAX  0xffffffffffffffffULL
                         ^~~~~~~~~~~~~~~~~~~~~
../depends/libzip/lib/zip_close.c:122:32: note: in expansion of macro ‘ZIP_UINT64_MAX’
      zip_uint64_t last_index = ZIP_UINT64_MAX;
                                ^~~~~~~~~~~~~~
ninja: build stopped: subcommand failed.
Logged
Really hoping somebody puts this in their signature.

A_Curious_Cat

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2612 on: October 11, 2020, 12:33:40 pm »

just looked up "off_t".  Found something saying it should be defined in bits/types.h.  Looked in there and it does appear that it isn't defined.
Logged
Really hoping somebody puts this in their signature.

lethosor

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2613 on: October 11, 2020, 01:32:02 pm »

If you're using something Debian-based, I would expect the binaries from https://github.com/dfhack/dfhack/releases/0.47.04-r3 to work. Probably the 32-bit ones if you have a 32-bit userspace. https://docs.dfhack.org/en/latest/docs/Installing.html explains the difference between the various builds a bit more.

It looks like bits/types.h is from the "libc6-dev" package on Debian. Do you have that package installed? If so, what version?

Edit: off_t might also be defined in sys/types.h.
« Last Edit: October 11, 2020, 01:41:31 pm by lethosor »
Logged
DFHack - Dwarf Manipulator (Lua) - DF Wiki talk

There was a typo in the siegers' campfire code. When the fires went out, so did the game.

A_Curious_Cat

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2614 on: October 11, 2020, 01:43:14 pm »

If you're using something Debian-based, I would expect the binaries from https://github.com/dfhack/dfhack/releases/0.47.04-r3 to work. Probably the 32-bit ones if you have a 32-bit userspace. https://docs.dfhack.org/en/latest/docs/Installing.html explains the difference between the various builds a bit more.

It looks like bits/types.h is from the "libc6-dev" package on Debian. Do you have that package installed? If so, what version?

looks like I've got libc6-dev 2.29-2.  It says the latest stable version is 2.31-4, but when I try and upgrade it does that thing again where it wants to uninstall half the packages on my system.

Edit:

Ok.  It looks like the binary is working.  So far...
« Last Edit: October 11, 2020, 01:49:19 pm by A_Curious_Cat »
Logged
Really hoping somebody puts this in their signature.

A_Curious_Cat

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2615 on: October 11, 2020, 02:49:01 pm »

Some more details about the issue you're encountering would be helpful - we can't fix it without more information.

I've been generating multiple worlds almost every day for what seems like the past 2 months, and when I run embark-assistant on them it almost always tells me that the are 0 matching world tiles.  Before I learned to run the find function twice, it was finding only 1-3 embarks in only one of the world that I genned in a week (and those almost always had some problem that made them unusable).  Since I started running find twice, it hasn't found anything.

Are you sure that a matching site exists?

No, come to think of it, I'm not.
Logged
Really hoping somebody puts this in their signature.

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2616 on: October 11, 2020, 04:29:03 pm »

Some more details about the issue you're encountering would be helpful - we can't fix it without more information.

I've been generating multiple worlds almost every day for what seems like the past 2 months, and when I run embark-assistant on them it almost always tells me that the are 0 matching world tiles.  Before I learned to run the find function twice, it was finding only 1-3 embarks in only one of the world that I genned in a week (and those almost always had some problem that made them unusable).  Since I started running find twice, it hasn't found anything.

Are you sure that a matching site exists?

No, come to think of it, I'm not.
Identifying and fixing a match bug would probably require a case where the search profile is known and a save where a matching location has been located manually (and info of where that location is).

However, a full description of the profile might give some indication about whether it's likely to be a bug or a case of the profile being too specific for worlds to be likely to have any matching sites (in which case relaxing the criteria might give you sites that are acceptable, but not perfect).  If the world generated are highly tweaked that info would be needed as well, although I won't be much good in predicting how meshes this way or that would affect things.
Logged

A_Curious_Cat

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2617 on: October 11, 2020, 06:42:51 pm »

Some more details about the issue you're encountering would be helpful - we can't fix it without more information.

I've been generating multiple worlds almost every day for what seems like the past 2 months, and when I run embark-assistant on them it almost always tells me that the are 0 matching world tiles.  Before I learned to run the find function twice, it was finding only 1-3 embarks in only one of the world that I genned in a week (and those almost always had some problem that made them unusable).  Since I started running find twice, it hasn't found anything.

Are you sure that a matching site exists?

No, come to think of it, I'm not.
Identifying and fixing a match bug would probably require a case where the search profile is known and a save where a matching location has been located manually (and info of where that location is).

However, a full description of the profile might give some indication about whether it's likely to be a bug or a case of the profile being too specific for worlds to be likely to have any matching sites (in which case relaxing the criteria might give you sites that are acceptable, but not perfect).  If the world generated are highly tweaked that info would be needed as well, although I won't be much good in predicting how meshes this way or that would affect things.

Here's the world creation parameters:



Here's the search parameters:



Any help would be appreciated.  Note that I'm specifically trying to stay away from goblins as I'm still learning the ropes and haven't figured out the military yet (I also haven't figured out how to use the manager for food and booze either).

Thanks in advance.
Logged
Really hoping somebody puts this in their signature.

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2618 on: October 12, 2020, 03:10:59 am »

Thanks.
It's a large non evil embark (so the evil weather parameters are redundant, but won't cause any harm either), no aquifer, min height waterfall (where brook has been excluded as the source), non freezing (which would probably always be the case for moist broadleaf anyway).
However, demanding fire clay, iron, gypsum, kaolinite and bit-coal is very demanding even without the other restrictions, despite the world gen mineral occurrence is set to Everywhere in a Large world.

For starters, is there any specific reason you demand bit-coal, rather than just any coal (further up in the list)? That would about double the chance for a match.

A short history reduces the impact of the demand for no necros in range, while staying away from gobbos typically excludes most of the world.

My conclusion from looking at it is that the chances of finding any locations matching those requirements in any given world would be rather low, and I'd either ease up on the requirements, or find a site that's near what's wanted, and then hack the site to match the requirements, e.g. using the Biome Manipulator to "correct" the biome, evilness, and/or geo biome.
Logged

A_Curious_Cat

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2619 on: October 12, 2020, 09:24:55 am »

Thanks.
It's a large non evil embark (so the evil weather parameters are redundant, but won't cause any harm either),

I'm still learning show I can't handle evil embarks and weather.

no aquifer,

I don't know how to handle aquifers yet.  The last time I tried doing the double slit method, the dwarves wouldn't pump long enough to do anything because they kept spending all their time hanging out by the river.

min height waterfall (where brook has been excluded as the source),

I need the waterfall to be at least 2-z high in order to get "donations".  I need at least a stream for the same reason.

non freezing (which would probably always be the case for moist broadleaf anyway).

I'm still learning so I don't want to have to worry about ice.

Thanks.
However, demanding fire clay,

I'd like to be able to make at least one type of ceramic that doesn't need to be glazed (I'd prefer not to waste all my wood making ash glaze and then not have enough for everything else).

iron,

I'd like to eventually create a military and steel armor and weapons are necessary to defeat the goblins (I'd also like to be able to deal with things like the problem I had in my last fort where a human maceman kept finding his way back from the caverns where I repeatedly gui/teleported him to after he started sneaking around and scaring my dwarves while looking for an artifact that had already been given to somebody else and taken off the map).

gypsum,

Gypsum is needed to set broken bones.

kaolinite and

See above under "fire clay" (although it is more of a nice to have and not a necessity).

bit-coal is very demanding even without the other restrictions, despite the world gen mineral occurrence is set to Everywhere in a Large world.

For starters, is there any specific reason you demand bit-coal, rather than just any coal (further up in the list)? That would about double the chance for a match.

I'm looking for bit-coal because it gives more coke (but I suppose I could do with any kind of coal.  I'd also prefer not to use up all my wood firing furnaces and kilns).

A short history reduces the impact of the demand for no necros in range,

How?

while staying away from gobbos typically excludes most of the world.

I haven't figured out the military yet (I'd prefer not getting curb stomped into oblivion before I can really get anything set up).

My conclusion from looking at it is that the chances of finding any locations matching those requirements in any given world would be rather low, and I'd either ease up on the requirements,

I'll try, but I'm not sure it'll work.  Some of the things listed above seem like necessities to me.

Also, it would be nice to be able to search for embarks that have at least one of either elves or humans instead of having to search for ones that have both.

or find a site that's near what's wanted, and then hack the site to match the requirements, e.g. using the Biome Manipulator to "correct" the biome, evilness, and/or geo biome.

Biome Manipulator?

I looked in the documentation for DFHack and the only thing I found was for something called Manipulator (which looks to be an attempt at making an in-game replacement for DT), but it didn't seem to have anything about "correct"ing any of the stuff you talked about above.

Also, what is a "geo biome"?
Logged
Really hoping somebody puts this in their signature.

lethosor

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2620 on: October 12, 2020, 10:16:41 am »

Biome Manipulator is one of PatrikLundell's scripts: http://www.bay12forums.com/smf/index.php?topic=164658.0
Logged
DFHack - Dwarf Manipulator (Lua) - DF Wiki talk

There was a typo in the siegers' campfire code. When the fires went out, so did the game.

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2621 on: October 12, 2020, 11:25:53 am »

The geo biome is the definition of what the mineral layers are at various locations. This definition also lists veins and inclusions (while I don't think those are guaranteed to show up if there are too many of them, as there is only so much room for those if you hack it).

The comments about the requirements weren't meant as complaints, just comments on what's there.

When it comes to aquifers, the light one is quite easy to deal with, although there's still room to screw up (I know, as I've done that).

I usually make my pots out of rock, rather than clay.

Gypsum isn't required. You can get by with splints and traction racks.

I think kaolinite is fairly rare, so requiring it reduces the chances of finding a match.

I don't use charcoal (or fossil coal) to fire my facilities, but go for magma powered ones. That means you'd only need coal for steel, and wood should be sufficient for that (fossil coal is convenient, though).

The DFHack Manipulator is indeed an alternative to DT, although the takes are slightly different, and thus cater to different tastes. I don't know which one came first, though.
Logged

daishi5

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2622 on: October 12, 2020, 01:27:04 pm »

I have been working on some embark issues, and I found this bug https://www.bay12games.com/dwarves/mantisbt/view.php?id=10267

I also helpfully found that you guys already wrote this script that seems to fix the bug https://github.com/PatrikLundell/scripts/blob/own_scripts/candy_corrector.lua

However, I cannot figure out how to run the script, so how do I run the candy corrector?
Logged

PatrikLundell

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2623 on: October 12, 2020, 01:38:47 pm »

Copy the script text (not the whole web page) into a "text" file in <DF>\hack\scripts called "candy_corrector.lua" (without the quotes). Then type "candy_corrector" (again without quotes) into the DFHack console window. Note that it will take the script quite some time to to run because it caused DF to perform quite time consuming data loading actions. The script should be run pre embark, i.e. at the screen showing the world, asking you where to embark. After the script has run you have to find your future location again as the data loading is prompted by moving the cursor over each world tile.
Logged

A_Curious_Cat

  • Bay Watcher
    • View Profile
Re: DFHack 0.47.04-r3
« Reply #2624 on: October 13, 2020, 06:33:03 am »

Btw, in embark-assistant it would be nice if there was a way after doing a search to search again using less restrictive search parameters without having to "abort game" and reload the world.  I tried using "cancel/clear find" but it didn't seem to do anything.
Logged
Really hoping somebody puts this in their signature.
Pages: 1 ... 173 174 [175] 176 177 ... 244