Bay 12 Games Forum

The main reason symbols.xml is still loaded at runtime is that the values in it cannot ever carry over to a new release and must be found one way or another anew. Keeping the file loaded at runtime allows adding more values to it without recompiling as we work on it.

However the bulk of the knowledge about DF is all the rest of xml files, and they are in effect compiled into both dfhack core and any plugins. If anything at all other than symbols.xml changes everything must be recompiled.

On the other hand if symbols.xml is truly the only thing that changed like with 0.40.12, then you can just get a new version of it and drop into the old dfhack, and it will work just fine.

The yellow area was marked by automated code running a quick check on structures in memory; it's yellow precisely because no human looked at that stuff.

Plus I have a question about item-occupancy.lua: What does it do, should I run it with repeat, or at all.

That script is an extremely slow process intended to diagnose and fix corruption from buggy scripts or plugins teleporting items around. It should only be used if you encounter problems like dwarves claiming there is an item in a tile when there is none. It's somewhat similar to programs like chkdisk that fix your filesystem.

Anyway, these classes are not in dfhack, so it's pointless to talk about what would be possible to do if they were there.

The reason dfhack does not really define renderer classes other than the base one, is that in the linux version they are located in a separate library, so their vtable pointers are hard to specify. Also, messing with renderers is also not something to be undertaken lightly because of the threading limitations; it is also not needed unless you are doing something well beyond the current capabilities, like warmist's lighting plugin. However, when you are going that far, you might as well subclass the base class and implement vmethods normally.

I had a discussion with lxnt, baughn and Toady, and later on another with Taffer, Baughn and Toady. Baughn would like to update the graphics significantly, but cant work without source access. Toady understands this, but wont give this access. (which is perfectly within his right to do)

I seem to have read Baughn saying somewhere that adding too much stuff to objects makes the game crash or something, which slows down the possible rate of change. I may have an idea why this happens, and a very easy workaround would be to add some "char padding[256]" to the end of all global objects that baughn wants to grow, so that once Toady recompiles, enough space is reserved.

Regarding the plugin, manually hacking into the vtables is a very bad approach when dfhack has an already available vtable interposing API, which doesn't require any weird inline assembly, and even allows different plugins to define hooks for the same methods without conflicting.

Another thing is that renderers don't have the right to access any game objects, because rendering is run in a different thread and is only synchronized for a buffer swap. Thus, the appropriate way to do such thing is to hook the render vmethod of viewscreen_dwarfmodest (using the interposing API is a must, because other plugins already hook it), and work with the tile arrays via the Pen API. In order to make the game load the necessary tile images, you can assign one of the tiles in your bitmap as a graphical icon for something silly and impossible like "cat miner ghost" via raws, and then use findGraphicsTile to look up the index.

If anything, "unit" would be the one who did the interaction and "unit_syndrome" would be the one who didn't.

If you look at the XML properly, you will note that unit_syndrome is a structure type, and it has nothing whatsoever to do with doing interactions. This method is involved in per-tick processing of syndromes already active on a unit.

Yeah, those are missing for whatever reason, but here's a simple function that should do the same thing (weighted for syndromes as well):

Oops, forgot to actually add those to the export list - will be fixed in the next release whenever that happens.

What is the purpose of the "Nemesis" entries anyways? What do they do that isn't redundant to the unit or historical figure data?

As far as we understand, they control how unit data is stored in unit-*.dat files in your save directory. They are also where the game stores permanently which units are your current or past adventurer, and who its companions are.