Print

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

[whitecold]

I just got an interesting result with 3d veins. I reshuffled the map, which contains an aquifer and a waterfall, as a result the cliffs where the aquifer came out began to leak; somehow the outermost-layer-doesn't-leak has gotten lost somewhere.

[lethosor]

Sometimes there can be changes that break compatibility, there was such between 0.34.11r3 and r5 not so long ago.
However of course I'd prefer not to recompile twbt for each minor dfhack update.
So in general version check is good but probably it should include only major changes.

That said, all other plugins are included in dfhack source tree and built together with it, so it's a problem for twbt only, so I don't expect anything to change here.

Yeah I don't expect it will change either, but I'm still right that my way is better

Actually, I wonder how big of a change it would to just change DFHack's version to be separate from DF itself. That way you could do regular major/minor/revision versioning for DFHack (I'd call it 6.whatever at this point and consider 0.34.11r5 5.0) and then the DF version check would go against the contents of symbols.xml.

I will have to update twbt for each df version anyway (but not dfhack release).

Things like the Hotkeys plugin, though, wouldn't - source I used for that was from before DF 0.40 so there's really no reason the dll from before shouldn't work, other than the version check that fails.

Using the same source doesn't guarantee compatibility - if a structure used by a plugin changes at all, that plugin will have to be recompiled, even if it doesn't need to be updated. For example, here is a diff of the viewscreen_loadgamest.h changes between 0.34.11 and 0.40.12. Note the addition of the "unk_v40_1a" and "unk_v40_1b" fields - any plugin compiled before these fields were introduced will almost certainly crash when attempting to access other fields (e.g. "saves").

Edit: In addition to structure changes, DFHack changes can break compatibility - for example, this change broke compatibility with all plugins that interpose vmethods.

[Roses]

So if one is checked every 100 and another every 1000, the one that gets checked every 1000 will never be checked? Or will it instead be checked every 100?

It will check for events every 100 ticks. When that happens, all listeners will be notified, regardless of how often or rarely they requested EventManager to check for events.

As for the rest, I don't know.

Thanks for all the help (and Putnam too!), I will be doing some tests regarding many of the values found in the entities tables to see what is able to be changed and what effects it has on game play. I know that the force script no longer works for sieges in the new DF version, but can it still generate caravans? That would greatly help my testing abilities.

[TheDorf]

I've got a few ideas for plugins that I would love to see. I would love to eventually get into script coding, but I don't think I'll have the time before my winter break.

Anyway, I was just thinking I would go ahead and ask if it would be possible to give a material template (in this case blood) the effect of satisfying bloodthirst? If there are already any plugins that could be used for this, it'd be awesome, and if not, I guess I'll have something to do this winter.

While I'm at it, I might as well ask if there are any plugins that can give artifacts itemsyndromes (or something similar) when they are created? IIRC itemsyndromes could only be assigned to materials, but I read that a while ago, so it could have changed.

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

[salithus]

Sometimes there can be changes that break compatibility, there was such between 0.34.11r3 and r5 not so long ago.
However of course I'd prefer not to recompile twbt for each minor dfhack update.
So in general version check is good but probably it should include only major changes.

That said, all other plugins are included in dfhack source tree and built together with it, so it's a problem for twbt only, so I don't expect anything to change here.

Yeah I don't expect it will change either, but I'm still right that my way is better

Actually, I wonder how big of a change it would to just change DFHack's version to be separate from DF itself. That way you could do regular major/minor/revision versioning for DFHack (I'd call it 6.whatever at this point and consider 0.34.11r5 5.0) and then the DF version check would go against the contents of symbols.xml.

I will have to update twbt for each df version anyway (but not dfhack release).

Things like the Hotkeys plugin, though, wouldn't - source I used for that was from before DF 0.40 so there's really no reason the dll from before shouldn't work, other than the version check that fails.

Using the same source doesn't guarantee compatibility - if a structure used by a plugin changes at all, that plugin will have to be recompiled, even if it doesn't need to be updated. For example, here is a diff of the viewscreen_loadgamest.h changes between 0.34.11 and 0.40.12. Note the addition of the "unk_v40_1a" and "unk_v40_1b" fields - any plugin compiled before these fields were introduced will almost certainly crash when attempting to access other fields (e.g. "saves").

Edit: In addition to structure changes, DFHack changes can break compatibility - for example, this change broke compatibility with all plugins that interpose vmethods.

I'm not sure what you're saying by this. I see the first type of change as just bad design and the whole reason we're having this discussion in the first place - yes I know it would take a lot of work to fix and there are ~reasons~ it evolved the way it did, but it doesn't change the fact that it's bad practice when designing an API. Additive changes shouldn't break compatibility and plugins that don't use changed functionality shouldn't need to recompile just to get a new version number.

The second one I'm not sure what "interposing" means for this, but looking at the comment text of the change, "Track readable names of vmethod hooks for diagnostic messages.". If its' not making a mandatory functionality change, then the methods should have been overloaded, and possibly marked as deprecated, instead of changed. That would have given better stability for existing plugins, while making any future compiles aware of the new method for better debugging output.

All that's really happening by requiring a recompile with the same version # specified is you get a poor man's unit test - if it at least compiles against the code you've got some belief that the plugin might work. But with just enough knowledge to be dangerous, a plugin could be compiled against any set of DFHack code and the wrong version # specified and you get a DLL that DFHack thinks should load against its version but won't if there are breaking changes. Yes, it's better than no system. No, having a system doesn't mean there's no room for improvement.

[lethosor]

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?

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

[urmane]

Not sure this is the right place to ask this - is the 0.34.11-r5 source, with all the submodules, still available?  I'm trying to compile a MDF version for linux, and it's still using the old dfhack.

[Rose]

I'm not sure what you're saying by this. I see the first type of change as just bad design and the whole reason we're having this discussion in the first place - yes I know it would take a lot of work to fix and there are ~reasons~ it evolved the way it did, but it doesn't change the fact that it's bad practice when designing an API. Additive changes shouldn't break compatibility and plugins that don't use changed functionality shouldn't need to recompile just to get a new version number.

Sorry, but if there was an actual modding API for DF, this would be valid, but unfortunately, there isn't one. If something changes in the DF memory stuctures, there's no way for a plugin to necessarily know that.

[expwnent]

Not sure this is the right place to ask this - is the 0.34.11-r5 source, with all the submodules, still available?  I'm trying to compile a MDF version for linux, and it's still using the old dfhack.

https://github.com/DFHack/dfhack/tree/0.34.11-r5

Just do a git checkout 0.34.11-r5 and it should work hopefully. git submodule update also to use the old df-structures.

[Quietust]

I'm not sure what you're saying by this. I see the first type of change as just bad design and the whole reason we're having this discussion in the first place - yes I know it would take a lot of work to fix and there are ~reasons~ it evolved the way it did, but it doesn't change the fact that it's bad practice when designing an API. Additive changes shouldn't break compatibility and plugins that don't use changed functionality shouldn't need to recompile just to get a new version number.

Sorry, but if there was an actual modding API for DF, this would be valid, but unfortunately, there isn't one. If something changes in the DF memory stuctures, there's no way for a plugin to necessarily know that.

It helps to realize that there is effectively no abstraction between DFHack plugins and DF itself - memory addresses for globals are determined on program startup (based on data inside symbols.xml), but structure layouts are defined in C++ header files (which are generated by a Perl script prior to compiling DFHack itself) so that plugins are able to directly access DF's internals as if they were part of DF itself (which, for all intents and purposes, they are). Once a plugin is compiled, an access to "viewscreen_loadgamest.loading" simply becomes "BYTE PTR [ecx+10h]", so if a new int32 field named "unk_v40_1a" gets added, it will end up reading the wrong data.

If you want something you don't need to recompile between releases, you need to use scripts, since those are effectively recompiled every time you run them and will thus know where to get that new field since they can ask DFHack where it is, and while DFHack has the same issue described above, recompiling it for new versions of DF is acceptable and expected by most people. Of course, scripts are also slower, but that's the cost you pay for increased flexibility.

[urmane]

Not sure this is the right place to ask this - is the 0.34.11-r5 source, with all the submodules, still available?  I'm trying to compile a MDF version for linux, and it's still using the old dfhack.

https://github.com/DFHack/dfhack/tree/0.34.11-r5

Just do a git checkout 0.34.11-r5 and it should work hopefully. git submodule update also to use the old df-structures.

Thanks, expwnent.  I actually went back to r4, to get a working stonesense, and so far it's looking good.

[0x517A5D]

I've been experimenting with an automated way to figure out binary patch locations.  I have a Perl script that uses regexps to find the raw file locations for the weaponrack-unassign patch.  I have those locations for DF in 0.40.08, .11, and .12 for all of Windows, Linux (untested), and OSX (untested).

Would the raw binpatches for these versions be useful to anyone?  Only weaponrack-unassign at the moment.

(I'm not going to release the Perl script as-is; it's really nasty right now, it needs cleanup.)

I am considering porting to Lua or Ruby so that patches can be installed at runtime, similar to the binpatch console command.  I've got problems because Lua doesn't have a full Regexp engine, and the Ruby implementation doesn't have a way to feed the entire getMemRanges() list back to a script.  I'm considering my path at the moment.  Suggestions?

Also, it appears that the DF OSX image has two entire versions of DF in it, what's up with that?  Something about OS version, or maybe old 680x0/new x86 architectures?

[lethosor]

Are you referring to the "binpatch" external executable or the "binpatch" Lua script (included in DFHack)? It sounds like what you're describing is already covered by the latter.