Print

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

[Nopenope]

As far as I can tell, it has never been in DFHack/dfhack (at least, not in 0.34.11-r1, 0.34.11-r3, 0.34.11-r5, 0.40.08-r1, or 0.40.11-r1).
Edit: Falconne's plugins are in this thread, although they were last updated for 0.34.11-r5 - only some of them are included in the official DFHack repo (and I'm not sure if the ones in Falconne's thread contain unmerged changes).

Oh. Is there any reason as to why some plugins were included and not the other ones (namely hotkeys and automelt)? Because they build and run fine on .40.11 for me, I could provide binaries for various OSes if people are interested.

[salithus]

As far as I can tell, it has never been in DFHack/dfhack (at least, not in 0.34.11-r1, 0.34.11-r3, 0.34.11-r5, 0.40.08-r1, or 0.40.11-r1).
Edit: Falconne's plugins are in this thread, although they were last updated for 0.34.11-r5 - only some of them are included in the official DFHack repo (and I'm not sure if the ones in Falconne's thread contain unmerged changes).

Oh. Is there any reason as to why some plugins were included and not the other ones (namely hotkeys and automelt)? Because they build and run fine on .40.11 for me, I could provide binaries for various OSes if people are interested.

I think just because no one is aware they work, officially or otherwise.

Here's the falconne weighing in that I mentioned above:

Sorry about the lack of updates, I've been busy on some other projects. Will try to get on it soon. I was hoping to wait till the DF updates slowed down.

Here's....you?....asking where to get the source for hotkey (and not getting an answer that I saw):

Unless I'm missing something this plugin is absent in the latest repo for .40.x. Is the source available so we can at least build it ourselves? I find this hotkey plugin very useful and very much miss it in the latest version.

[lethosor]

As far as I can tell, it has never been in DFHack/dfhack (at least, not in 0.34.11-r1, 0.34.11-r3, 0.34.11-r5, 0.40.08-r1, or 0.40.11-r1).
Edit: Falconne's plugins are in this thread, although they were last updated for 0.34.11-r5 - only some of them are included in the official DFHack repo (and I'm not sure if the ones in Falconne's thread contain unmerged changes).

Oh. Is there any reason as to why some plugins were included and not the other ones (namely hotkeys and automelt)? Because they build and run fine on .40.11 for me, I could provide binaries for various OSes if people are interested.

I think just because no one is aware they work, officially or otherwise.

That, and the fact that nobody has merged them into the official DFHack repo yet - feel free to submit a pull request.

[salithus]

And by "feel free" he means "dear god hurry up and do one" because I'd really like to see those plugins too... :ohdear:

[Nopenope]

Here's....you?....asking where to get the source for hotkey (and not getting an answer that I saw):

I looked further and the source was actually buried in falconne's repos. So since no one knew what happened to the missing plugins I just built them myself.

And by "feel free" he means "dear god hurry up and do one" because I'd really like to see those plugins too... :ohdear:

Huh I don't have a github account but here are binaries:

Single link: http://a.pomf.se/qtdkef.tar.gz

Windows (hotkeys, automelt, dfterm3): http://a.pomf.se/yswsac.rar
GNU/Linux (hotkeys, automelt, dfterm3): http://a.pomf.se/nvyefw.tar.gz
OS X (hotkeys, automelt): http://a.pomf.se/belxgw.zip

[breadman]

I've opened a pull request for the hotkeys plugin, but automelt could benefit from an update to handle the new stockpile menu behavior of 0.40; I'll probably get to that tomorrow.

Meanwhile, I've also uploaded an older Linux build of DFHack 0.40.11-r1.  I included Stonesense this time, but haven't convinced it to actually work yet.  Unless someone lets me know that it works for them, I'll probably omit it in future builds, given that it's about two thirds of the package by size.

[Nopenope]

Well, I'm at lost. whether it's freshly compiled libraries straight from the Allegro site or debian repos, the plugin simply won't load. What's weird is that "load stonesense" doesn't trigger an error or even debug information.

[PeridexisErrant]

I've just fixed exportlegends.lua, which can export the detailed maps, and optionally the legends files and xml too.  It would be awesome if it could be extended to export all the site maps too, now that they're so much more interesting.  If it was easy to export them, I can imagine uses popping up - improvements to legends viewers, visualisers for towns and cities, all kinds of cool stuff.  I'd love to do this, but my attempts never got anywhere - can anyone help?

The other thing which would be cool is if a script could force DF to export .png images (call optipng on each image as it was exported and delete the .bmp).  The space savings are massive; I routinely get 95-99.9 percent savings.  If dfhack can detect image export, worst case is an inelegant wrapper for local shell/cmd commands.  Thoughts?

[Saiko Kila]

I have question regarding binpatch on Windows. I had an idea to use dfhack binpatch instead of manually patching every DF executable, so it remains unchanged (I archive whole directories together with saves of interesting worlds, so I can return to it in a year or two) plus I would know exactly what was changed. Currently I patch only a string regarding pressure plates, to correctly show the trigger weight (which is lowered one order of magnitude in vanilla DF).

However, I cannot actually achieve patching. I try to use following line in dfhack.init:
binpatch apply pressureplate_04011.dif

I also tried explicitly targeting the executable,  but there's no difference:
binpatch apply "Dwarf Fortress.exe" pressureplate_04011.dif

It says patch applied, but I see no change.

pressureplate_04011.dif itself looks like this:

Code: [Select]

009B6D10: 4B 30
009B6D11: 00 4B

Isn't that supposed to work?

[Roses]

5. does not persist. Need to run each load (also just had an idea to extend this to run some code and check some prerequisites). No need for permissions (iirc)
6. removes native reactions. To be used for disabling hardcoded workshops or replacing (with 5.) their reactions
7. no. it needs a bit more tweaking after creation. I'm a bit rusty on this front... and still haven't finished "THE IMPLEMENTATION THAT WILL BE USED FOR EVERYTHING" of this (i.e. more stable, more features, other plugins could use it, etc...)
8. yes (i think) there is tame level, also there is civ id and a few flags (hopefully somebody has more info)

2. it's possible (have been doing that) but never with any intention of real use.
3. i'm pretty sure they don't have any effect on game

1 might be possible, but you'd have to be careful to catch worldgen fast enough and use a CoreSuspend object in C++.

Thanks for all the responses, two more slightly specific questions

9. If I have two scripts that enable the same eventful event type (e.g. events.enableEvent(events.eventType.UNIT_DEATH,100)) will both get run, or will one be overwritten/ignored?
10. Is there any way to make tile temperature changes more permanent? It seems like every time I change the tiles temperature (both temperature1 and temperature2) it just reverts back to the surrounding, even if I set temperature update to false.

EDIT: Heres another one just for expwnent;
11. The old LUA_HOOK system allowed us access to the items used in a reaction, have you given any thought to trying the same functionality in the new reaction-trigger system?

[0x517A5D]

However, I cannot actually achieve patching. I try to use following line in dfhack.init:
binpatch apply pressureplate_04011.dif

I also tried explicitly targeting the executable,  but there's no difference:
binpatch apply "Dwarf Fortress.exe" pressureplate_04011.dif

It says patch applied, but I see no change.

pressureplate_04011.dif itself looks like this:

Code: [Select]

009B6D10: 4B 30
009B6D11: 00 4B

Isn't that supposed to work?

It works for me.  I did this:

• Extracted df_40_11_win_s.zip to a new test directory,
• Extracted dfhack-0.40.11-r1-Windows.7z there,
• Created a subdirectory named hack\patches\v0.40.11 SDL ,
• In that subdirectory, created a file named pressureplate_04011.dif ,
• Pasted your patch content into that file,
• And started DF to the main menu.
• At the DFHack commandline,
  
• binpatch check pressureplate_04011
• Note that I did not append the .dif extension.
• binpatch apply pressureplate_04011
• binpatch remove pressureplate_04011
• DFHack did not complain about any of that, which surprised me a bit.
• Then I created a pocket world and started a new embark, crafted a few mechanisms,
• And began to construct a creature-triggered pressure plate.  I noted the min weight of 5K.
• I backed out of all the menus, and again did:
• binpatch apply pressureplate_04011
• And constructed a pressure plate.  I noted the min weight of 50K.

I concluded that the patch does change the weight strings.

I suggest checking your patch file.  Are you using the right command?  Is the file in the right place?  Do you have multiple copies scattered around, with different contents?  Do you have a file named pressureplate_04011.dif.dif ?  (Note the doubled extension.)

[Seagoon]

Im rather new to DF hack, how would i go about applying the armory fixes? Also ensuring they are applied automatically every time i load the game?

[lethosor]

fix-armory hasn't been updated to 0.40.xx yet, as far as I can tell - its line in CMakeLists.txt is currently commented out, so it's not included in any 0.40.xx builds of DFHack.

[Seagoon]

fix-armory hasn't been updated to 0.40.xx yet, as far as I can tell - its line in CMakeLists.txt is currently commented out, so it's not included in any 0.40.xx builds of DFHack.

Ah ok, thanks

[Saiko Kila]

However, I cannot actually achieve patching. I try to use following line in dfhack.init:
binpatch apply pressureplate_04011.dif

I also tried explicitly targeting the executable,  but there's no difference:
binpatch apply "Dwarf Fortress.exe" pressureplate_04011.dif

It says patch applied, but I see no change.

pressureplate_04011.dif itself looks like this:

Code: [Select]

009B6D10: 4B 30
009B6D11: 00 4B

Isn't that supposed to work?

It works for me.  I did this:

• Extracted df_40_11_win_s.zip to a new test directory,
• Extracted dfhack-0.40.11-r1-Windows.7z there,
• Created a subdirectory named hack\patches\v0.40.11 SDL ,
• In that subdirectory, created a file named pressureplate_04011.dif ,
• Pasted your patch content into that file,
• And started DF to the main menu.
• At the DFHack commandline,
  
• binpatch check pressureplate_04011
• Note that I did not append the .dif extension.
• binpatch apply pressureplate_04011
• binpatch remove pressureplate_04011
• DFHack did not complain about any of that, which surprised me a bit.
• Then I created a pocket world and started a new embark, crafted a few mechanisms,
• And began to construct a creature-triggered pressure plate.  I noted the min weight of 5K.
• I backed out of all the menus, and again did:
• binpatch apply pressureplate_04011
• And constructed a pressure plate.  I noted the min weight of 50K.

I concluded that the patch does change the weight strings.

I suggest checking your patch file.  Are you using the right command?  Is the file in the right place?  Do you have multiple copies scattered around, with different contents?  Do you have a file named pressureplate_04011.dif.dif ?  (Note the doubled extension.)

Thank you for answers and suggestion. I have no idea why it doesn't work for me, I even tried the steps you describe, starting with downloading df_40_11_win_s.zip. Could you please tell what "check" function of binpatch returns after successfully applying the patch?

When I apply the patch, like this

Code: [Select]

binpatch apply pressureplate_04011the prompt says that the patch was applied (if it doesn't find the file it clearly states in red that it can't find the patch). But when I check for changes like this

Code: [Select]

binpatch check pressureplate_04011it always says that the patch is removed, which means that no changes were actually made.

What worries me is if I deliberately put a wrong value in the patch file, like changing expected original value of 4B to 4A for example, then applying the patch also says that it was applied. Which means the function returned success even though it shouldn't/couldn't, instead it that example it should write something like "conflict at address" I think.