Print

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

[Atomic Chicken]

I've got a couple of ideas which require modtools/add-syndrome to work, but have so far been prevented from accomplishing them due to the script not functioning as intended when it comes to removing syndromes. I've been meaning to report this problem since the previous version, but never got round to it. Nevertheless:

Say a unit has a syndrome which, for example, gives the unit the ability to perform an interaction. Attempting to remove the syndrome via "modtools/add-syndrome -target X -syndrome Y -eraseAll" will indeed remove the unit_syndrome from unit.syndromes.active . However, it will NOT remove the syndrome effects, such that the unit retains the ability to perform the interaction, etc.

Digging into the issue, I found that whenever a syndrome is added to a unit, a new unit_wound is created in unit.body.wounds (This, and the following information, may already be common knowledge to a number of you). This unit_wound is referenced in the unit_syndrome as "wound_id". The unit_wound is linked to the raw-defined syndrome via unit_wound.syndrome_id , and unit_wound.curse is what contains the syndrome effects to be applied to the unit. Erasing the unit_wound is what is actually required to remove most of the syndrome effects from a unit. Note that the unit_wound will be recreated if the unit_syndrome is not also erased. Erasing only the unit_syndrome (as is currently done by the eraseSyndrome function in syndrome-util ) will leave the unit_wound and its resultant effects untouched.

I've seemingly fixed the issue in my tests by adding the following to the eraseSyndrome function in syndrome-util:

Code: [Select]

local w1
local wN
local d

 if oldestFirst then
  w1 = 0
  wN = #unit.body.wounds-1
  d = 1
 else
w1 = #unit.body.wounds-1
wN = 0
d = -1
end
 
 local wounds = unit.body.wounds
 for w=w1,wN,d do
  if wounds[w].syndrome_id == syndromeId then
   wounds:erase(w)
   return true
    end
    end

[lethosor]

It was for most of the 40.x releases...

Do you mean in the Windows packages? Because the headers aren't in any of the OS X or Linux ones that I've downloaded, which include (heh) most of the releases since 0.34.11.

If they're really useful, I can try to package/upload them separately. I don't know if it would be possible/safe to compile anything with them, though, but I don't think they vary across platforms currently. The size really is a concern, though - the header files currently take up around 10 MB, while a clean DFHack release without them takes around 15-25 MB. There are also 1331 individual files with the latest df-structures, which tends to slow down extractors even if the files aren't that big.

Regarding documentation, I'm not sure how you could really generate something from just the information in the XML files, aside from boring stuff like "the 5th field in the viewscreen_titlest structure is a 32-bit integer named 'sel_submenu_line'". There are comments and ref-target attributes in a few places, sure, but including them would still result in pretty sparse documentation, and going into detail about what every field is would just clutter up the XML files. Maybe I'm misunderstanding your comments about documentation, though, so do feel free to make suggestions.

There is a file called "Lua API.rst", by the way, which covers most of the DFHack-implemented Lua API (i.e. the parts that don't wrap DF structures).

[milo christiansen]

Clean, easy to read descriptions of the structures (something that looks like C, without the stuff that the compiler needs but the programmer doesn't), preferably with links connecting types to their definitions. Basically something much like what godoc generates (for example). Anything not exported to Lua can be left out.

[lethosor]

How's Doxygen? It might be possible to get that working with df-structures's headers.

[milo christiansen]

Depends on how much you have to mark the headers up, too much markup and it's not worth it. If it can be gotten to work, and produces nice, clear, output (that preferably can be linked into the existing DFHack docs), then it is probably worth the effort required.

Once upon a time I tried to make a document generator that read the XML, but that XML is nearly impossible to parse without a lowering pass (and Go had no XLST library at the time), so I gave up

[Warmist]

Once upon a time I tried to make a document generator that read the XML, but that XML is nearly impossible to parse without a lowering pass (and Go had no XLST library at the time), so I gave up

ugh reminds me of the time i did a setup for boost-like documentation. It's a nightmare that hangs by a thread that is built on arcane invocations of xmls and other insanities and there is no agreed upon format for that... We are still not using that part...

[jaked122]

How's Doxygen? It might be possible to get that working with df-structures's headers.

Doxygen is lovely, just requires a lot of good comments in its style to work as well as it might. That being said, it is a good place to get started.


Edit: For the love of god, don't roll your own. That's a mistake with crypto and code documentation.

[Insanegame27]

EDIT NOOBERMIND

[expwnent]

Spoiler (click to show/hide)

I've got a couple of ideas which require modtools/add-syndrome to work, but have so far been prevented from accomplishing them due to the script not functioning as intended when it comes to removing syndromes. I've been meaning to report this problem since the previous version, but never got round to it. Nevertheless:

Say a unit has a syndrome which, for example, gives the unit the ability to perform an interaction. Attempting to remove the syndrome via "modtools/add-syndrome -target X -syndrome Y -eraseAll" will indeed remove the unit_syndrome from unit.syndromes.active . However, it will NOT remove the syndrome effects, such that the unit retains the ability to perform the interaction, etc.

Digging into the issue, I found that whenever a syndrome is added to a unit, a new unit_wound is created in unit.body.wounds (This, and the following information, may already be common knowledge to a number of you). This unit_wound is referenced in the unit_syndrome as "wound_id". The unit_wound is linked to the raw-defined syndrome via unit_wound.syndrome_id , and unit_wound.curse is what contains the syndrome effects to be applied to the unit. Erasing the unit_wound is what is actually required to remove most of the syndrome effects from a unit. Note that the unit_wound will be recreated if the unit_syndrome is not also erased. Erasing only the unit_syndrome (as is currently done by the eraseSyndrome function in syndrome-util ) will leave the unit_wound and its resultant effects untouched.

I've seemingly fixed the issue in my tests by adding the following to the eraseSyndrome function in syndrome-util:

Code: [Select]

local w1
local wN
local d

 if oldestFirst then
  w1 = 0
  wN = #unit.body.wounds-1
  d = 1
 else
w1 = #unit.body.wounds-1
wN = 0
d = -1
end
 
 local wounds = unit.body.wounds
 for w=w1,wN,d do
  if wounds[w].syndrome_id == syndromeId then
   wounds:erase(w)
   return true
    end
    end

Noted for my todo list. This is a newly-observed problem, so thank you for noticing.

I've been 99% unavailable for the last several months and that will continue for another week. At that point depending on a real life undecided factor I'll either be a little more active or a lot more active. If there have been any problems with add-syndrome, scripts in modtools, event manager, or the create-unit script I've done my best to make a note of them but I may have missed a few.

[jobywalker]

Is there a reason why the automaterial plugin hasn't been applied to constructed tracks and track stops?

[lethosor]

Not that I know of. Feel free to make a report on GitHub, as people will probably lose track of it here.

[0x517A5D]

That bug is definitely confirmed for 42.04, I'll try to get a Mantis account to post it.

Thanks for the heads-up. Guess I'm sticking with 42.03 for now.

It's bad enough to impact gameplay and requires preference editing to handle.  Pass. 

This is not a new bug just added to 42.04.

The only change related to ownership in .04 was about trade goods in retired/unretired forts.

And I've personally seen this in .03, although I didn't really know what I was looking at.  (I thought it was directly related to tavern drinks, but I now believe that's only a common trigger.)

Your call, but IMO the prayer fix alone justifies upgrading.

[jaked122]

Yeah, you get some awfully unfulfilled dwarves if they can't pray. Sadly alcohol has one flaw, it can't fix piety.

[TheFlame52]

Yeah, it's in .03 too.

[lethosor]

Here's another alpha release: https://github.com/DFHack/dfhack/releases/tag/0.42.04-alpha2

This one has some new stuff in it, and some fixes since alpha1, although apparently there weren't any awful bugs. The Linux build is using a new cross-compiler now - one consequence of this is that you'll have to delete libs/libstdc++.so.6 if you weren't doing that before, since it's GCC 4.8 (and hopefully your system has GCC 4.8 or newer installed). However, rendermax seems to work perfectly on my Linux machine now - I don't know if this is due to the compiler change or not, since I hadn't tested it in a while, but others should investigate as well. Anyway, please report any issues that are reliably reproducible on Linux with this particular alpha2 build only (that don't occur with a native alpha2 build or alpha1), as well as general issues with alpha2 as usual.

Thanks to DersEvvak for providing a Windows build this time!