Print

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

[Dirst]

*peep*
Just an end user on this project, though I am aware of the difficulties which can arise from doing stuff like that, but those sort of "just making sure you're informed before you bone everything up anyways" alerts are too often overlooked, and mostly appreciated by people who already know what they're getting into, sadly.

The compile-time macros would allow bleeding-edge DFHacks to be tested with not-yet-updated plug-ins.  And yes TWBT would most likely crash the game and possibly take the region folder with it.  That console prompt is not intended as an end-user feature in an official release, just a way for people to figure out what needs to be updated and what doesn't.

Whatever the mechanism is, it needs to allow updates in the plug-ins as well.

Consider when 12r1 came out, and a plug-in has been compatible since 08r2 (excluding the version string).  The sourcecode could say that that specific named plug-in -- compiled for anything from 08r2 to 12r1 -- can run.  That way, the plug-in author can issue an update without requiring DFHack to be updated to run it.

Edit: grammar

[lethosor]

@Warmist: speaking of rendermax: any plans to update to 40.x?

Rendermax doesn't work with 0.40.xx because (if I understand correctly), the script that automatically locates <vtable-address> entries in symbols.xml doesn't check for 'renderer', which rendermax requires. Warmist has made changes that make rendermax compile with 0.40.xx, but I've been unable to test them without the required offsets.

[Warmist]

@Warmist: speaking of rendermax: any plans to update to 40.x?

Rendermax doesn't work with 0.40.xx because (if I understand correctly), the script that automatically locates <vtable-address> entries in symbols.xml doesn't check for 'renderer', which rendermax requires. Warmist has made changes that make rendermax compile with 0.40.xx, but I've been unable to test them without the required offsets.

Actually it "should" locate it automatically (in windows) but for some reason does not. Though it's probably one of the easiest things to do (finding vtables that is) i am a very lazy (read: busy) person. Also everybody is sad because new version has low fps, so rendermax (which takes away yet more fps) are not on top of people list of things they like

[fricy]

Also everybody is sad because new version has low fps, so rendermax (which takes away yet more fps) are not on top of people list of things they like

But it's soooooo preeeety! 

[Nopenope]

Actually it "should" locate it automatically (in windows) but for some reason does not. Though it's probably one of the easiest things to do (finding vtables that is) i am a very lazy (read: busy) person. Also everybody is sad because new version has low fps, so rendermax (which takes away yet more fps) are not on top of people list of things they like

Actually rendermax is what got me into that whole dfhack business, along with falconne's plugins. It's really nifty. Plus I think the few people who are aware that dfhack is a thing also know how to use rendermax options.

By the way, if anyone ever got stonesense to work on Linux, I'd be more than grateful if they posted instructions about how they made it work (or their configuration if it worked out of the box).

[lethosor]

Is there anything Stonesense-related in stderr.log?

[Nopenope]

Well there does seem to be something as opposed to past versions, this is interesting:

Code: [Select]

stonesense.plug.so: undefined symbol: al_color_rgb_to_hsv
Can't load plugin stonesense.plug.so

[lethosor]

https://github.com/DFHack/dfhack/issues/282
I'll try to rebuild my Linux build (GCC 4.5.4) with Eswald's change when I get a chance.

[Nopenope]

Thanks, that solved it.

On a second note, I notice I have to fiddle with cmakelists more often than not; I'm not sure whether I have a weird configuration or if it's just a lack of devs that use Linux as their main OS (and thus lack of testing). If it's the latter, I could post the changes I made to make various things build (and occasionally run).

[lethosor]

There are certainly devs that use Linux (and OS X, where the build process is nearly the same). What changes are you referring to? I haven't had to make changes to CMakeLists.txt for things to build/run on either. (It's probably due to your configuration, but any fixes are welcome, provided they don't interfere with other platforms.)

[Nopenope]

Let's see, lately when building Isoworld I usually run into various issues, most of which have been solved by maijin:

The compilation was successful, the linking process failed. You need to modify dfhack/plugins/isoworld/CMakeLists.txt file and add agui to linker. Here is my patch:

Code: [Select]

--- plugins/isoworld/CMakeLists.txt 2014-09-11 19:32:10.998717669 +0200
+++ plugins/isoworld/CMakeLists.txt 2014-08-28 01:18:09.000000000 +0200
@@ -91,6 +92,11 @@
  allegro_image
  allegro_ttf
  ${PROJECT_LIBS}
+ /home/majiin/repos/Agui/build/libagui_allegro5.a
+ /home/majiin/repos/Agui/build/libagui.a
+ )
+ include_directories (
+ /home/majiin/repos/Agui/include
  )
  ENDIF()
  ENDIF()
Of course you need to change /home/majiin/repos/Agui/build/ and /home/majiin/repos/Agui/include to the location where you have those files. Maybe there is a simpler way to do this but this worked for me.

Where libagui_allegro5.a and libagui.a are 32-bit .a files that are absent from the main repo and had to be compiled manually.

Also, MapSection.h seems to have a weird line:

Code: [Select]

--- plugins/isoworld/MapSection.h 2014-09-11 17:47:18.331186059 +0200
+++ plugins/isoworld/MapSection.h 2014-09-09 12:12:36.000000000 +0200
@@ -32,7 +32,7 @@
  void pointToSprite(float *inx, float *iny, int inz);
  void load_heights(ALLEGRO_BITMAP * heightmap);
  void load_water_level(ALLEGRO_BITMAP * watermap);
- void MapSection::load_colors(s_maplist * map_list);
+ void load_colors(s_maplist * map_list);
  void load_level(ALLEGRO_BITMAP * levelmap, int level);
  void load_biome_tiles(s_maplist * maplist);
  void load_structure_tiles(ALLEGRO_BITMAP * structuremap);
Will post more as I recall along.

[Hades]

It looks like the exterminate script may be broke for 0.40.12, assuming it's not something I am doing. Works fine on a clean install in 0.40.11 (Dwarf Fortress and DFHack only), but does nothing in a clean install of 0.40.12. Running the script gives nothing for output, and the same for any switches you try with it. Just FYI.

It's working for me. What platform are you using? Is Ruby available?

Windows 7 64. Have ruby installed. I tried running someone else's compilation of DFHack (0.40.12) for comparison and have the same issue.

Just to follow up my post. Works fine in the new release. Must have been something I did compiling it (be nice to know what but alas). And thanks for the new release! Appreciate all the work you all do!

Figured out my issue. Silly mistake but I thought I would post it in case anyone else ever runs into something similar (the joys of learning). Either make sure to add Ruby when compiling DFHack (if following previous posted instructions, don't uncheck "DL_RUBY" and copy over the files needed), or make sure to add the libruby.dll to DFHack install afterwards. Thanks lethosor for pointing me in the right direction, it just didn't click until compiling DFHack again.

[Rose]

Let's see, lately when building Isoworld I usually run into various issues, most of which have been solved by maijin:

The compilation was successful, the linking process failed. You need to modify dfhack/plugins/isoworld/CMakeLists.txt file and add agui to linker. Here is my patch:

Code: [Select]

--- plugins/isoworld/CMakeLists.txt 2014-09-11 19:32:10.998717669 +0200
+++ plugins/isoworld/CMakeLists.txt 2014-08-28 01:18:09.000000000 +0200
@@ -91,6 +92,11 @@
  allegro_image
  allegro_ttf
  ${PROJECT_LIBS}
+ /home/majiin/repos/Agui/build/libagui_allegro5.a
+ /home/majiin/repos/Agui/build/libagui.a
+ )
+ include_directories (
+ /home/majiin/repos/Agui/include
  )
  ENDIF()
  ENDIF()
Of course you need to change /home/majiin/repos/Agui/build/ and /home/majiin/repos/Agui/include to the location where you have those files. Maybe there is a simpler way to do this but this worked for me.

Where libagui_allegro5.a and libagui.a are 32-bit .a files that are absent from the main repo and had to be compiled manually.

Also, MapSection.h seems to have a weird line:

Code: [Select]

--- plugins/isoworld/MapSection.h 2014-09-11 17:47:18.331186059 +0200
+++ plugins/isoworld/MapSection.h 2014-09-09 12:12:36.000000000 +0200
@@ -32,7 +32,7 @@
  void pointToSprite(float *inx, float *iny, int inz);
  void load_heights(ALLEGRO_BITMAP * heightmap);
  void load_water_level(ALLEGRO_BITMAP * watermap);
- void MapSection::load_colors(s_maplist * map_list);
+ void load_colors(s_maplist * map_list);
  void load_level(ALLEGRO_BITMAP * levelmap, int level);
  void load_biome_tiles(s_maplist * maplist);
  void load_structure_tiles(ALLEGRO_BITMAP * structuremap);
Will post more as I recall along.

If you have to change something in isoworld to make it compile, a github fork is probably easier to find than some patches in a forum thread.

[Hetairos]

Is there a DFHack 0.34.11 r5-compatible script which makes injured but conscious dwarves take care of themselves?

There's fix/feeding-timers.

...but it doesn't seem to be included, I can't find it on this board, and I don't think it would've helped anyway. There is this, but for r3, and it doesn't appear to work in r5.

[expwnent]

https://github.com/DFHack/dfhack/blob/master/scripts/fix/feeding-timers.lua