Print

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

[danaris]

This is interesting; the way he releases a new version in a matter of hours after each dfhack release and focuses on dfhack-fixable bugs first makes me wonder if he doesn't want people to get used too much to dfhack magic.

I'm pretty sure the main reason Toady's fixed so many of the dfhack-fixable bugs in this cycle is because Quietust and ag have done a yeoman's job of figuring out exactly what those bugs are, where they are located, and what would be necessary to fix them, and provided that information in the bug notes.

[Warmist]

This is interesting; the way he releases a new version in a matter of hours after each dfhack release and focuses on dfhack-fixable bugs first makes me wonder if he doesn't want people to get used too much to dfhack magic.

I'm pretty sure the main reason Toady's fixed so many of the dfhack-fixable bugs in this cycle is because Quietust and ag have done a yeoman's job of figuring out exactly what those bugs are, where they are located, and what would be necessary to fix them, and provided that information in the bug notes.

Actually it's even more impresive than that. Some bug had code snippets (e.g. "i think you did for(int x=0;x<t;t++)... where you meant for(int x=0;x<t;x++)) with approximate location where to find it.

[PeridexisErrant]

Some bugs had code snippets (e.g. "i think you did for(int x=0;x<t;t++)... where you meant for(int x=0;x<t;x++)) with approximate location where to find it.

[indyofcomo]

I have recently downloaded the LNP for 40.12 and it of course comes with DFHack. Previously I started using DFHack on my last few 34.11 games and I don't use it for much. I like digx, cleanowned, fix/dead-units(?), and a few of the UI things (filters and cursor sticking).

Anyways, I started a new game with this latest version, and there is a new thing going on. I am getting some kind of intermediate display while I'm queueing work from workshops. This has happened in my kitchen, still, masonry, and carpentry workshops. If I recall correctly, it says something about the workshop not being assigned to a dwarf, and has an arrow on it pointing to the item I'm trying to build.

Again, it's not in front of me right now, so XXdescriptionXX and xaccuracyx, sorry. But if anyone could point me in the direction of a mod/fix/UI piece this might be, I'd appreciate it.

[Quietust]

Plus as I understand it, there's a noticeable performance hit from running it as a Lua script instead of a compiled plugin, because it's compiled each time it's run + the abstraction to the memory addresses.

I don't know if it's "noticeable", and I don't know whether performance is paramount when dealing with a script that will only be punctually used (such as a gui or various hack magic). There's only that much stuff that runs continuously along the game (like emigration, rendermax or twbt).

I actually did a test about 2 years ago to see how much slower it would be to implement reveal as a script instead of a plugin. The script version took almost an entire minute to run, compared to the plugin which was pretty much instantaneous. It's made even worse by the fact that the script wasn't doing the extra work of saving unreveal information or avoiding revealing HFS - adding that would have made it even slower.

Most of the "fix" scripts also take a noticeable amount of time to run, and rewriting them as plugins would probably drop their execution times down to a few hundred milliseconds.

[Nopenope]

I have recently downloaded the LNP for 40.12 and it of course comes with DFHack. Previously I started using DFHack on my last few 34.11 games and I don't use it for much. I like digx, cleanowned, fix/dead-units(?), and a few of the UI things (filters and cursor sticking).

Anyways, I started a new game with this latest version, and there is a new thing going on. I am getting some kind of intermediate display while I'm queueing work from workshops. This has happened in my kitchen, still, masonry, and carpentry workshops. If I recall correctly, it says something about the workshop not being assigned to a dwarf, and has an arrow on it pointing to the item I'm trying to build.

Again, it's not in front of me right now, so XXdescriptionXX and xaccuracyx, sorry. But if anyone could point me in the direction of a mod/fix/UI piece this might be, I'd appreciate it.

DFHack has this issue when you alt-tab out of the game, it still thinks you pressed alt and alt-r brings out a room gui. You probably set a workshop order to [r]epeat and it brought out this menu. Simply press alt again to resolve it.

Or something like that.

[indyofcomo]

DFHack has this issue when you alt-tab out of the game, it still thinks you pressed alt and alt-r brings out a room gui. You probably set a workshop order to [r]epeat and it brought out this menu. Simply press alt again to resolve it.

Yes, I am having this problem. I found it through google-fu on why I couldn't access my (m)ilitary screen.

Is this seen as a DFHack bug that's being looked at? (Is there a link where I could have answered that question myself?)

[expwnent]

Regarding 0.40.12-r1 'forum-dwarves' script included with the release version, in vanilla df 0.40.12:

Spoiler (click to show/hide)

[DFHack]# forum-dwarves
<viewscreen_textviewerst: 0x1afaf588>
child                    = nil
parent                   = <viewscreen_itemst: 0x154c8378>
breakdown_level          = 0
option_key_pressed       = 0
title                    =   (cave spider silk trousers)
title_colors             =
src_text                 = <vector<string*>: 0x1afaf5d0>
outvar_type              =
outvar_name              =
meeting_context          = <meeting_context: 0x1afaf618>
help_filename            = text_viewer
page_filename            =
formatted_text           = <vector<viewscreen_textviewerst.T_formatted_text*>: 0x1afaf660>
hyperlinks               = <vector<char*>: 0x1afaf670>
logged_error             = 0
scroll_pos               = 0
cursor_line              = 0
pause_depth              = 0
<viewscreen_textviewerst.T_formatted_text: 0x1b762ec8>
text                     = <char: 0x116ccd28>
format                   = <char: 0x116ccdb0>
flags                    = <viewscreen_textviewerst.T_formatted_text.T_flags: 0x1b762ed0>
pause_depth              = 0
return_val               = -1
indent                   = 0
<char: 0x116ccd28>
value                    = 84
...Documents\df\df_40_12_win\hack\scripts/forum-dwarves.lua:73: bad argument #1 to 'find' (string ex
pected, got userdata)
stack traceback:
        [C]: in function 'find'
        ...Documents\df\df_40_12_win\hack\scripts/forum-dwarves.lua:73: in function 'format_for_foru
m'
        ...Documents\df\df_40_12_win\hack\scripts/forum-dwarves.lua:116: in main chunk
        (...tail calls...)

That's just from trying to use it to output the details of any object (in this case, cave spider silk trousers).
I don't know how to fix the problem, or I would.   

Seems like the stockflow is bugged.  Had a hard lockup when my recordkeeper went to update his records.  Crash does not occur if I insure there are no stockpiles with stockflow settings.  Nothing is printed to stdout or stderr.

I have recently downloaded the LNP for 40.12 and it of course comes with DFHack. Previously I started using DFHack on my last few 34.11 games and I don't use it for much. I like digx, cleanowned, fix/dead-units(?), and a few of the UI things (filters and cursor sticking).

Anyways, I started a new game with this latest version, and there is a new thing going on. I am getting some kind of intermediate display while I'm queueing work from workshops. This has happened in my kitchen, still, masonry, and carpentry workshops. If I recall correctly, it says something about the workshop not being assigned to a dwarf, and has an arrow on it pointing to the item I'm trying to build.

Again, it's not in front of me right now, so XXdescriptionXX and xaccuracyx, sorry. But if anyone could point me in the direction of a mod/fix/UI piece this might be, I'd appreciate it.

If you could make bug reports here that would be useful for keeping track of bugs. I have my personal todo list but I generally stay away from plugins other people wrote when I don't know how they work.

There have been multiple issues with forum-dwarves before and I updated that one so I'll fix that when I get to it but I don't know about the others.

[Dirst]

despite being the same original source (master branch of DFHack), previous DLLs would not work (aside from the version string issue), due to those changes?

Most of them will because they don't use changed structures.

Sanity check - if I understand what you said:

Let's say there are 30 structures total and that 2 of them changed. Most of the DLLs could work, because those 2 structures aren't ones "typically" used?

So phase 1 would be: if 0 of the structures changed, we're ok to use all the same plugins from before. Versioning would need to be based off identifying a specific changeset used from the symbols project.

Phase 2 would be figuring out a registration system, or some other method to see what specific structures are used, and identify the specific changeset AND structure used, which would require stricter handling on the plugin side, but looser coupling on the DFHack side.

Does that make sense?

The project could go to a 30-component version numbering scheme, but that seems stupid.  Maybe some meta-structure that holds version numbers for the DF structures, and use that to register dependencies.

Depending on what CMake can do, maybe sourcecode macros can be used to specify allowed version numbers for specific plug-ins.

A much more ambitious path is to include a plugin wrapper for experimental builds.  It would check the version string and throw up an obvious console warning in the event of a mis-match. 

********************************************************************
WARNING!
The plugin twbt.dll was compiled for DFHack version 0.40.12.r1
You are running DFHack version 0.40.13.i-cant-live-without-digv
********************************************************************
How do you want to proceed?
1. Do not load the plug-in (as if the DLL did not exist)
2. Load the plug-in this time
3. Load the plug-in and remember this decision (affects onLoad.init)

In any case, there are absolutely no guarantees about the behavior of a plug-in not designed specifically for that version.  It turns out that .12 stuff would run fine under .11, but some .13 stuff would cause magma to ooze out of your USB ports.  If someone is mucking around the sourcecode to make this compile, they should be aware of the risks.

[Warmist]

Plus as I understand it, there's a noticeable performance hit from running it as a Lua script instead of a compiled plugin, because it's compiled each time it's run + the abstraction to the memory addresses.

I don't know if it's "noticeable", and I don't know whether performance is paramount when dealing with a script that will only be punctually used (such as a gui or various hack magic). There's only that much stuff that runs continuously along the game (like emigration, rendermax or twbt).

I actually did a test about 2 years ago to see how much slower it would be to implement reveal as a script instead of a plugin. The script version took almost an entire minute to run, compared to the plugin which was pretty much instantaneous. It's made even worse by the fact that the script wasn't doing the extra work of saving unreveal information or avoiding revealing HFS - adding that would have made it even slower.

Most of the "fix" scripts also take a noticeable amount of time to run, and rewriting them as plugins would probably drop their execution times down to a few hundred milliseconds.

As a counter argument I would provide an example of rendermax lighting mod. First implementation was in lua  yes verrrrryyyy slow, but I had something almost nice in matter of minutes. The c++ engine ( though to be fair a lot more complex) took way longer and with help from other people.
So in the end: quick iterations- lua/ruby. Best performance - c++

[fricy]

@Dirst: Twbt is a bad example, as it doesn't (only?) depend on symbols.xml, but uses hard-coded memory adresses. So that's one that needs to be recompiled for every df version.

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

[Max™]

A much more ambitious path is to include a plugin wrapper for experimental builds.  It would check the version string and throw up an obvious console warning in the event of a mis-match. 

********************************************************************
WARNING!
The plugin twbt.dll was compiled for DFHack version 0.40.12.r1
You are running DFHack version 0.40.13.i-cant-live-without-digv
********************************************************************
How do you want to proceed?
1. Do not load the plug-in (as if the DLL did not exist)
2. Load the plug-in this time
3. Load the plug-in and remember this decision (affects onLoad.init)

In any case, there are absolutely no guarantees about the behavior of a plug-in not designed specifically for that version.  It turns out that .12 stuff would run fine under .11, but some .13 stuff would cause magma to ooze out of your USB ports.  If someone is mucking around the sourcecode to make this compile, they should be aware of the risks.

*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.

[salithus]

A much more ambitious path is to include a plugin wrapper for experimental builds.  It would check the version string and throw up an obvious console warning in the event of a mis-match. 

********************************************************************
WARNING!
The plugin twbt.dll was compiled for DFHack version 0.40.12.r1
You are running DFHack version 0.40.13.i-cant-live-without-digv
********************************************************************
How do you want to proceed?
1. Do not load the plug-in (as if the DLL did not exist)
2. Load the plug-in this time
3. Load the plug-in and remember this decision (affects onLoad.init)

In any case, there are absolutely no guarantees about the behavior of a plug-in not designed specifically for that version.  It turns out that .12 stuff would run fine under .11, but some .13 stuff would cause magma to ooze out of your USB ports.  If someone is mucking around the sourcecode to make this compile, they should be aware of the risks.

*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.

That and the goal isn't to make plugins work with unofficial builds, but:

1) find a way to let a stable release of DFHack be updated to the latest DF version without needing to wait on the DFHack team to put together a new release
2) find a way to let plugins identify what they are compatible with structure-wise so that they don't have to be recompiled with each DFHack release

[Quietust]

@Dirst: Twbt is a bad example, as it doesn't (only?) depend on symbols.xml, but uses hard-coded memory adresses. So that's one that needs to be recompiled for every df version.

Indeed - if you tried editing the version string on TWBT to run it in a newer version than whatever it was compiled for, it would either refuse to run or crash the game entirely, neither of which are in any way useful. It also appears to contain a bunch of hardcoded binary patches, all of which were likely designed solely for version 0.34.11 and are thus nonfunctional in the current version anyways.

Needless to say, that plugin will never be accepted into the DFHack codebase in that state.

[breadman]

Seems like the stockflow is bugged.  Had a hard lockup when my recordkeeper went to update his records.  Crash does not occur if I insure there are no stockpiles with stockflow settings.  Nothing is printed to stdout or stderr.

That's probably my fault, unless you're using an unofficial DFHack release, or there's another structure change that we haven't noticed yet.  I'll fix it once I can reproduce the issue.  Which platform (OS, DF version, and DFHack version) are you using?  Could you upload an affected save for me?