Print

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

[Putnam]

It shows you them (in your example, by e.g. df.emotion_type.attrs['Joy'].divider) but you can't edit them for any effect.

It wouldn't be that obnoxiously complicated to shadow the mood system the way you're describing tbh. I already have an on-emotion event and persistent data is trivial.

[expwnent]

Is it accurate to call DFHack a modding API that comes with a few built-in mods?

I'd say the scripts in the modtools folder are. DFHack in general is also a tool for end users for making the game easier, harder, or more convenient.

I'm guessing the answer is "no," but does DFHack expose any hardcoded variables, like the happiness bonuses for different positive emotions?  I imagine most of them are elided by the compiler, but I know I've, in the past, used vectors full of constants in my own games.

I'm curious about making dwarven moods more difficult to handle.  I've always considered it too easy to make dwarves happy by giving them large rooms.  What I actually think should happen is that dwarves should become inured to specific luxuries after a while, but that would require new mechanics on Tarn's part (or a really obnoxiously complicated plugin that shadows the entire mood system).  But, just making them less ecstatic about having a nice dining room would be a start.

It doesn't work anymore but I wrote a plugin several versions ago to intensify negative thoughts by duplicating them. You'd have to do it differently for the new emotion system but it shouldn't be too hard. I think plugins/misery.cpp is still in the github repository if you want to take a look.

[kane_t]

Hmm, interesting.  It would be pretty easily, actually, to just store, in persist data, all the "amazing seat" thoughts the game wants each dwarf to have and only keep the best one, so there's no doubling-up of happiness bonuses.  It'd also make the thoughts screen a heck of a lot more readable.  I'll give that a shot and see if it has a good effect.  Cheers.

I could also, I suppose, manually calculate the values of owned rooms using my own algorithm and then modify the AdmireOwnBuilding thoughts as they appear.  Figuring out which tiles are part of a room looks like it'll be a pain, though, since the game doesn't actually store a list of the tiles that're part of a room.  Looks like the laziest way to roll my own flood-fill would be to just call buildings->containsTile() for each tile to find the adjacent tiles (starting with the centre).  Does that function work for non-rectangular rooms?

[Rose]

The game does store which tiles are part of a room, though.

[kane_t]

The game does store which tiles are part of a room, though.

Where?  As far as I can see, it only stores a rectangular building area (x and y coords, and a width and height).  Because rooms can be non-rectangular, that's presumably the bounding box that contains all of the tiles, but some tiles in the bounding box won't be part of the room.

EDIT: I did some looking around, and containsTile() does work for non-rectangular rooms, so I don't even need to flood-fill, I can just check every tile in the bounding box.  But, you might be right that it's storing all the tiles somewhere, because changing the internal/external status of doors doesn't change the size of the room, which it would if the game was redoing the flood-fill every time it needed the room size.  But that information doesn't seem to be stored anywhere in the building information, and I didn't see anything under df.global.world that looked like it would have it, either.

Not terribly important, since the brute force approach will work just fine, but I'm curious where it's storing that room information.

[Warmist]

There is building_extents (IIRC) they hold if cell of building WxH box is part of the building

[kane_t]

Nope.  It may be a bug in the current version of DFHack, but currently building_extents is the x, y, width, and height of the bounding box, and a single pointer to a uint8 that's just: "0 - not room; 1 in stockpile; 2 wall; 3 inner; 4 distance boundary" according to df-structures.

Maybe the pointer is supposed to be to an array of something like struct { uint8 extent_type; union { /* the different types of extent */ }; }; but that's gotten lost?

EDIT: Aha!  Sorry, I keep forgetting that the source of DFHack is just on Github.  Just looked at the code, and figured out what the problem is: the pointer is a pointer to a bare array, but both the Lua API and gui/gm-editor are only set up to access vectors.  So, from a plugin, I can just do a lookup into that array, I just won't be able to rely on bounds-checking to catch bugs.

[Warmist]

Nope.  It may be a bug in the current version of DFHack, but currently building_extents is the x, y, width, and height of the bounding box, and a single pointer to a uint8 that's just: "0 - not room; 1 in stockpile; 2 wall; 3 inner; 4 distance boundary" according to df-structures.

Maybe the pointer is supposed to be to an array of something like struct { uint8 extent_type; union { /* the different types of extent */ }; }; but that's gotten lost?

EDIT: Aha!  Sorry, I keep forgetting that the source of DFHack is just on Github.  Just looked at the code, and figured out what the problem is: the pointer is a pointer to a bare array, but both the Lua API and gui/gm-editor are only set up to access vectors.  So, from a plugin, I can just do a lookup into that array, I just won't be able to rely on bounds-checking to catch bugs.

RTM Dynamic size arrays can not be nicely shown in gm-editor or lua. You need to index into them manually. Thus use ptr[x+y*w] or similar. In gm-editor there is "displace" or "offset" shortcut for that. For normal usage there is lua helpers (e.g. "dfhack.buildings.containsTile(building, x, y[, room])").
The same problem in C or C++ really. C type arrays when passed as an argument are turned into pointer thus loosing the size information.

[kane_t]

Well, to be fair, it's not really a "problem" in C/C++ because pointers are arrays and arrays are pointers.  That's why you can say 5[array] instead of array[5], if you want to be weird about it.  The subscript operator is just a bit of convenient syntactic sugar.  (And, for size information, you should also really never use sizeof() on an array.  It's the closest to undefined behaviour you can get without actually being undefined behaviour.  Personally, I don't think it should even be allowed, but there are legacy reasons for keeping it around, and frankly most compiler vendors would probably keep it as undefined behaviour even if the standard was changed.)

Good to know about that offset shortcut in gm-editor, though.  I've seen it in the help page, but there was nothing that indicated what that was supposed to do, and I haven't come across a bare array anywhere else in any of the data structures dfhack exposes, so I haven't had an opportunity to experiment with it.  Maybe adding a little note to the help page to clarify that it's for indexing bare arrays would be useful?

But, just out of curiosity, has it been determined that that particular variable is actually a bare array?  Is it possible that that's a vector and nobody's noticed yet?  I mean, everywhere else that I've seen, vectors are used, even in places where you could legitimately get away with even a statically-sized array, like the unit attributes and personality traits.

[Warmist]

Well, to be fair, it's not really a "problem" in C/C++ because pointers are arrays and arrays are pointers.  That's why you can say 5[array] instead of array[5], if you want to be weird about it.  The subscript operator is just a bit of convenient syntactic sugar.  (And, for size information, you should also really never use sizeof() on an array.  It's the closest to undefined behaviour you can get without actually being undefined behaviour.  Personally, I don't think it should even be allowed, but there are legacy reasons for keeping it around, and frankly most compiler vendors would probably keep it as undefined behaviour even if the standard was changed.)

Good to know about that offset shortcut in gm-editor, though.  I've seen it in the help page, but there was nothing that indicated what that was supposed to do, and I haven't come across a bare array anywhere else in any of the data structures dfhack exposes, so I haven't had an opportunity to experiment with it.  Maybe adding a little note to the help page to clarify that it's for indexing bare arrays would be useful?

But, just out of curiosity, has it been determined that that particular variable is actually a bare array?  Is it possible that that's a vector and nobody's noticed yet?  I mean, everywhere else that I've seen, vectors are used, even in places where you could legitimately get away with even a statically-sized array, like the unit attributes and personality traits.

Short answer: no this can't be vector.
Long answer:
We mostly have the layouts from disassembly (and by we i mean other smarter people). This naked array is stored as an simple pointer (thing void* because in assembly every pointer is void*). Only the accessing code is reading e.g. by byte and checking nearby word or byte to stop or not the iteration. The vector on the other hand is totally different. It has three pointers. Each read is usually prefixed by size check which is read two pointers and shift/div/etc to figure out the item count, then compare to imput and sometimes jmp to exception or just jump to ret 0 part.
Statically sized arrays are also different thing. It's just like having a struct with N fields (e.g. {int x,y,z} is same as {int p[3]} but not {int* p} or {int p[] (is this valid at all?)}) So it looks totally different and the resulting size of struct is way bigger.
Then there is a HUGE magical thing that is lua wrapper. At the start i tried writing one but then angavrilov wrote the whole thing. There are some limitations like - you can't interpose vmethods from lua as it requires compiled code to replace the original (or doing automatic wrapper for EACH VMETHOD FOR ALL CLASSES - would be slow like hell) or like lua does not have "please list out all vmethods of this object with arguments" because nobody did need this bad enough to implement. Or in this case size for T* arrays. Although there are very few of them, and you could write out special handling for each of them - it's simpler to understand what is happening and have small snipped that does the same.

[kane_t]

Haha, sorry, you don't need to go into that kind of CS 101 detail for me.  I've actually re-implemented the STL vector before because I was bored one day (of course, I expected it to take an afternoon, and it ended up taking me a week, as is typical; in my defence, I spent most of that time doing something goofy with one of the insert range functions to see if I could beat the MSVC implementation, which is the best one I've seen thus far)

What I was asking, specifically, is whether maybe somebody initially put this in df-structures as an unsigned __int8* because they didn't know what it was, and then only later did someone figure out it was the array of tile information and incorporate it into dfhack.buildings, but nobody got around to looking to see if there were size and capacity pointers behind it that got missed.  It's just weird that this one variable is the only bare array, it seemed more likely to me that it just slipped through the cracks.

Looking in df-structures, though, it looks like there's no room for it, unless the way you folks auto-generate the headers automatically detects padding and missing fields, and it's auto-detecting the size and capacity pointers at the front of the building_extents as 8 bytes of padding, which seems unlikely.

[lethosor]

It does deal with padding. It's just that building_extents is a raw array. There could well be non-virtual methods that Toady uses to deal with it that we have no idea about, but we can't make it into a vector when it's not.

(Also, small nitpick: gm-editor doesn't do things any differently from the Lua API - it literally just calls pairs() and displays the result in a UI.)

[kane_t]

Fair enough, thanks!

One last question.  I found a bug in my combine-plants and combine-drinks scripts a while back--and have wanted to improve them for a while, anyway, especially since it turns out some people actually use them--so I'm going to rewrite them as a plugin that's a lot more robust.  Before I get started, is there a release somewhere of the auto-generated headers for any recent version of DFHack that I can use?  Or am I going to have to install Perl and generate them myself from df-structures?

[lethosor]

You'll have to generate them anyway as part of the DFHack build process. There are a couple Windows releases for 0.42 that included them accidentally, if you want to look at examples - maybe alphas for versions around 0.42.04?

[Urlance Woolsbane]

In the 40.24 version of DFHack there was a plugin or script that allowed you to switch game-mode in game. Does anyone remember its name and whether or not it's available for 42.06?