v50 Steam/Premium information for editors
- v50 information can now be added to pages in the main namespace. v0.47 information can still be found in the DF2014 namespace. See here for more details on the new versioning policy.
- Use this page to report any issues related to the migration.
This notice may be cached—the current version can be found here.
Editing Utility:DFHack/Programming
Jump to navigation
Jump to search
Warning: You are not logged in.
Your IP address will be recorded in this page's edit history.
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
− | |||
− | == | + | v1.1 (see change log at the end) |
+ | |||
+ | == Introduction == | ||
− | |||
− | It is possible for developers to write plugins for DFHack, in order to extend the capabilities of DFHack (and therefore DF's gameplay). The plugins come mainly in two flavours: | + | DFHack is a Dwarf Fortress (DF) memory access library and a set of basic |
− | * C++ plugins: libraries written in C++ that need to be compiled. They can use DFHack's low level functions very closely | + | tools that use it (see the readme at https://github.com/peterix/dfhack/blob/master/Readme.rst ). |
− | * Lua and Ruby scripts: | + | |
+ | It is possible for developers to write plugins for DFHack, in | ||
+ | order to extend the capabilities of DFHack (and therefore DF's gameplay). | ||
+ | The plugins come mainly in two flavours: | ||
+ | * C++ plugins: libraries written in C++, that need to be compiled. They can use DFHack's | ||
+ | low level functions very closely. | ||
+ | * Lua and Ruby scripts: placed in the right folder, they are loaded at | ||
+ | DFHack's startup (outside of this document's scope. see more at | ||
+ | https://github.com/peterix/dfhack/blob/master/Lua%20API.rst ) | ||
+ | |||
+ | This document explains how to get started at writing C++ plugins with | ||
+ | VisualC++ 2010, step by step. It is intended for people who are totally | ||
+ | new to DFHack. | ||
+ | |||
− | |||
== Getting Dwarf Fortress == | == Getting Dwarf Fortress == | ||
− | You'll need a test environment to run your script. Hence the need of getting DF. I'd recommend getting the latest " | + | You'll need a test environment to run your script. Hence the need of getting |
− | * Download the latest " | + | DF. I'd recommend getting the latest "Starter Pack", which includes not only |
− | + | Dwarf Fortress but also DFHack and other nice things, ready-to-use: | |
+ | |||
+ | * Download the latest "Starer Pack". | ||
+ | You can run DF once and observe the DFHack console. Type ``die`` in that window | ||
+ | to observe that the command line works (``die`` is a command to force-close DF). | ||
+ | |||
== Getting DFHack == | == Getting DFHack == | ||
You must download the sources, and build them. | You must download the sources, and build them. | ||
− | |||
− | == Make yourself | + | * Follow exactly the steps described in DFHack's readme : |
− | + | https://github.com/peterix/dfhack/blob/master/Compile.rst | |
− | As explained in the compiling guidelines (above), there are several scripts available, that will do different things | + | |
− | * Open | + | == Make yourself comfortable == |
− | * Right-click on the Solution, and select "Properties" | + | |
− | * Go to "configuration properties" | + | As explained in the compiling guidelines (above), there are several scripts |
− | * In the full list of projects, uncheck | + | available, that will do different things. Some will just build, some will |
+ | also install the results to your DF's DFHack folder. | ||
+ | To save some time, here is to run the latter script in your VisualC++ every | ||
+ | time you press ``F7`` (Generate solution): | ||
+ | |||
+ | * Open ``dfhack.sln`` in VisualC++ | ||
+ | * Right-click on the Solution, and select "Properties" | ||
+ | * Go to "configuration properties"-->"Configuration" | ||
+ | * In the full list of projects, uncheck ``ALL_BUILD``, and instead check ``INSTALL`` | ||
+ | |||
+ | This way, it will force-build "INSTALL" every time. Which runs the install script. | ||
+ | |||
+ | == Create your own plugin == | ||
− | + | What are the requirements for a plugin? | |
− | + | * Its set of C++ source files (there can be just one if you want!) | |
− | * | + | * The libraries (``.lib``) it will use |
− | * The libraries ( | + | * The protobufs it will use (if any!) |
− | * The protobufs it will use (if any!) | + | |
− | + | Protobufs are some sort of serialization standard developed by Google. This is | |
+ | outside of the scope of this document. Only a handful of plugins use that | ||
+ | technology. The ``rename`` and ``isoworldremote`` plugins do. | ||
− | The libraries are all the 3rd-party libraries you want to use in your project. The good news is that most libraries normally used in C++ have a high probability to be already used by some other plugin | + | The libraries are all the 3rd-party libraries you want to use in your project. |
+ | The good news is that most libraries normally used in C++ have a high probability | ||
+ | to be already used by some other plugin. | ||
− | + | For example: | |
− | * | + | * ``workflow`` links to ``Lua``. |
− | * | + | * ``dfstream`` links to ``dfhack-tinythread``. |
− | + | * ``SDL`` is available in any case. | |
− | * | ||
− | Now you need to run DFHack's | + | The first step is to add your plugin to the list of plugins : |
− | * Observe all the batch files in | + | * Open ``dfhack/plugins/CMakeLists.txt`` |
− | * Run your favourite one. For example | + | * Locate the section listing all the plugins : they start with ``DFHACK_PLUGIN`` |
− | + | * Add a line with your own plugin: ``DFHACK_PLUGIN(myplugin myplugin.cpp)`` , and save the file. | |
+ | * Create a blank file called ``myplugin.cpp`` in ``dfhack/plugins`` , alongside all the other plugins. | ||
+ | |||
+ | Now you need to run DFHack's scripts, to make them generate all the | ||
+ | relevant project files for you: | ||
+ | * Close Visual Studio | ||
+ | * Observe all the batch files in ``dfhack/build`` starting with "generate" | ||
+ | * Run your favourite one. For example you can choose ``generate-MSVC-minimal.bat`` | ||
+ | |||
+ | Now if you re-open ``dfhack.sln`` (in ``dfhack/build/VC2010/``) , you'll | ||
+ | notice that your project "myplugin" is in the list. But it's not | ||
+ | ready to compile yet since the source file is empty. | ||
== Mandatory C++ instructions == | == Mandatory C++ instructions == | ||
− | Open any simple plugin (e.g. | + | Open any simple plugin (e.g. ``catsplosion.cpp`` ) and observe its structure. |
− | + | You'll notice all the includes for using standard data structures (lists, | |
+ | vectors, etc.) :: | ||
− | < | + | #include <iostream> |
− | #include | + | #include <cstdlib> |
− | #include | + | #include <assert.h> |
− | #include | + | #include <climits> |
− | #include | + | #include <stdlib.h> // for rand() |
+ | #include <algorithm> // for std::transform | ||
+ | #include <vector> | ||
+ | #include <list> | ||
+ | #include <iterator> | ||
+ | using namespace std; | ||
− | + | More interestingly, you'll notice all the includes allowing you to use DFHack: | |
− | + | #include "DFHack.h" | |
+ | #include "Core.h" | ||
+ | #include "Console.h" | ||
+ | #include "Export.h" | ||
+ | #include "PluginManager.h" | ||
+ | #include "DataDefs.h" | ||
− | + | using namespace DFHack; | |
− | |||
− | + | Let's imagine your plugin will be a command called from DFHack's console. Well | |
− | + | then, that command will call an actual function. It is that function that you | |
+ | declare here:: | ||
− | + | command_result catsplosion (color_ostream &out, std::vector <std::string> & parameters); | |
− | + | For now, the function only gets declared, we'll define it later in the source | |
− | + | code. You'll need to do the same, by replacing ``catsplosion`` with ``myplugin`` | |
− | + | Now, tell DFHack's global plugin engine to be aware of our plugin (so that it | |
− | + | can load it, etc.): | |
− | |||
− | |||
− | + | DFHACK_PLUGIN("catsplosion"); | |
− | + | From now on, every time you see "catsplosion", replace it with "myplugin". | |
− | + | Each plugin has two central functions: | |
+ | * ``plugin_init``. This is run when the plugin gets loaded, whether or not its command | ||
+ | gets run from the command line. | ||
+ | * ``plugin_shutdown``. This is run when the plugin gets unloaded (i.e. when DFHack shuts | ||
+ | down). | ||
+ | |||
+ | You'll notice that catsplosion's ``plugin_shutdown`` is empty (it just returns | ||
+ | the standardized "OK" return code : ``CR_OK``). That's because the plugin is | ||
+ | simple and doesn't need to delete objects, or close connections, or do any kind | ||
+ | of post-processing. | ||
+ | |||
+ | However, catsplosion's ``plugin_init`` contains an important instruction, that | ||
+ | will tell DFHack to be aware of a new custom command-line instruction:: | ||
+ | |||
+ | // Fill the command list with your commands. | ||
+ | commands.push_back(PluginCommand( | ||
+ | "catsplosion", "Make cats just /multiply/.", | ||
+ | catsplosion, false, | ||
+ | " Makes cats abnormally abundant, if you provide some base population ;)\n" | ||
+ | )); | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Details: | Details: | ||
+ | * ``"catsplosion"`` will be the string to which the command line must respond ,when | ||
+ | entered. | ||
+ | * ``catsplosion`` is the function that must be called when the command is typed | ||
+ | in to the command line. | ||
+ | * ``"Make cats just multiply"`` and ``"Make cats abnormally ..."`` are the | ||
+ | "manual" that will be displayed in the help or when the command is called | ||
+ | with the wrong parameters (see below how to test that). | ||
− | + | Finally, you'll find the actual function definition:: | |
− | |||
− | |||
− | + | command_result catsplosion (color_ostream &out, std::vector <std::string> & parameters) | |
+ | { | ||
+ | ... | ||
+ | } | ||
+ | return CR_OK; | ||
+ | |||
+ | |||
+ | == Simplest possible plugin: Hello world! == | ||
− | + | Here is how to just have a message displayed in the DFHack console when someone enters | |
+ | your command:: | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+ | command_result myplugin (color_ostream &out, std::vector <std::string> & parameters) | ||
+ | { | ||
+ | out.print("Hello Monsieur Ouxx!\n"); | ||
+ | } | ||
+ | return CR_OK; | ||
− | + | Please note that you have other outputs available:: | |
− | + | out.printerr("Oh my gosh, this is an error.\n"); | |
− | + | You can now test your plugin: Press F7, then run DF and enter "myplugin" in the DFHack console. | |
− | + | You should see the message "Hello Monsieur Ouxx!". | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | You can now test your plugin : Press F7, then run DF and enter "myplugin" in the DFHack console. You should see the message "Hello Monsieur Ouxx!". | ||
== Parameters checking == | == Parameters checking == | ||
− | You might want to test that your command was called with the relevant parameters. Here is an example of how to do it: | + | You might want to test that your command was called with the relevant parameters. |
+ | Here is an example of how to do it: | ||
− | + | command_result myplugin (color_ostream &out, std::vector <std::string> & parameters) | |
− | { | + | { |
− | + | bool param1_ok, param2_ok; | |
− | + | for(size_t i = 0; i < parameters.size();i++) | |
− | + | { | |
− | + | if(parameters[i] == "param1") | |
− | + | param1_ok = true; | |
− | + | else if(parameters[i] == "param2") | |
− | + | param2_ok = true; | |
− | + | else | |
− | + | return CR_WRONG_USAGE; | |
− | + | } | |
− | + | if(!param1_ok && !param2_ok) | |
− | + | return CR_WRONG_USAGE; | |
+ | |||
+ | return CR_OK; | ||
+ | } | ||
− | + | As explained before, if ``CR_WRONG_USAGE`` is returned, then the verbose help | |
− | + | text defined in ``commands.push_back`` will be displayed. | |
− | As explained before, if | ||
Another interesting approach to that (as seen in plugin "buildingplan"): | Another interesting approach to that (as seen in plugin "buildingplan"): | ||
− | + | if (!parameters.empty()) | |
− | { | + | { |
− | + | if (parameters.size() == 1 && toLower(parameters[0])[0] == 'v') | |
− | + | { | |
− | + | out << "Building Plan" << endl << "Version: " << PLUGIN_VERSION << endl; | |
− | + | } | |
− | + | else if (parameters.size() == 2 && toLower(parameters[0]) == "debug") | |
− | + | { | |
− | + | show_debugging = (toLower(parameters[1]) == "on"); | |
− | + | out << "Debugging " << ((show_debugging) ? "enabled" : "disabled") << endl; | |
− | + | } | |
− | } | + | } |
+ | |||
+ | == Suspend the core! == | ||
− | + | This might be the '''MOST IMPORTANT''' section in this document. | |
+ | Never ever forget to suspend the game's core execution before you manipulate | ||
+ | anything in its internal data. It is done by running the following instruction:: | ||
− | + | CoreSuspender suspend; | |
− | + | You will observe that most plugins actually start with that instruction. | |
+ | Fortunately, our "Hello world" plugin doesn't manipulate any internal data, | ||
+ | so we didn't need that. But that's about to change. | ||
− | + | ||
+ | == Create your own view screen == | ||
− | + | Many plugins consist in adding menus to DF in order to extend capabilities | |
+ | (or, at least, sort out DF's mess ;) ). | ||
− | |||
− | + | A good example of that is plugin ``buildingplan``. It displays a menu with | |
+ | lists of materials, and allows to filter the materials. Lists and filters. | ||
+ | That's what DF is all about! ;) | ||
− | + | http://imageshack.us/a/img28/4686/materials.png | |
− | You make them fit into a " | + | You make them fit into a "view screen", that is: an additional screen |
+ | that will fit into DF. This section is about creating a NEW viewscreen, not | ||
+ | replacing one already existing in DF. | ||
− | Have a look at class | + | Have a look at class ``ViewscreenChooseMaterial`` : it extends DFHack-provided |
+ | class ``dfhack_viewscreen``: | ||
− | + | class ViewscreenChooseMaterial : public dfhack_viewscreen | |
− | { | + | { |
− | ... | + | ... |
− | |||
− | + | It needs to implement the two following functions:: | |
− | |||
− | |||
− | |||
− | void render() | + | void feed(set<df::interface_key> *input) |
− | { | + | { |
− | + | ... | |
− | + | } | |
− | + | ||
− | } | + | void render() |
− | + | { | |
+ | ... | ||
+ | dfhack_viewscreen::render(); | ||
+ | ... | ||
+ | } | ||
− | + | Notice how ``render`` calls the overridden function of its parent class. | |
− | See also: "Replacing an existing view screen" | + | You will find more examples in plugin ``manipulator``. Have a look at class ``viewscreen_unitlaborsst`` |
+ | |||
+ | See also: "Replacing an existing view screen" | ||
+ | |||
== Manipulate the display == | == Manipulate the display == | ||
− | Once your | + | Once your view screen is up and running, with its very own ``render`` |
+ | function, you may do whatever you please with the display:: | ||
− | + | Screen::clear(); //delete the screen | |
− | Screen::drawBorder(" Building Material "); | + | Screen::drawBorder(" Building Material "); //create a new DF-stryle screen, with a title and a border |
+ | |||
+ | masks_column.display(selected_column == 0); //display our column (read this tutorial further) | ||
+ | |||
+ | int32_t y = gps->dimy - 3; //do some calculation on the window size, to position stuff | ||
+ | OutputHotkeyString(2, y, "Toggle", "Enter"); //define some hotkey | ||
+ | x += 3; | ||
+ | OutputHotkeyString(x, y, "Save", "Shift-Enter"); | ||
− | |||
− | |||
− | |||
− | |||
− | |||
== List columns == | == List columns == | ||
− | |||
− | < | + | In class ``ViewscreenChooseMaterial`` 's private members, you'll see this:: |
+ | |||
+ | ListColumn<df::dfhack_material_category> masks_column; | ||
+ | |||
+ | ``ListColumn`` is a template provided by DFHack. Just feed it with anything you like. | ||
− | |||
== Manipulating DF's data == | == Manipulating DF's data == | ||
− | Start with observing | + | Start with observing class ``ItemFilter``. You'll notice that DF exposes |
+ | pretty much every possible type of object/item from the game. And what DF | ||
+ | doesn't, DFHack does. You'll immediately notice these:: | ||
+ | df::dfhack_material_category | ||
+ | DFHack::MaterialInfo | ||
+ | df::enums::item_quality | ||
+ | etc. | ||
+ | |||
+ | Have a look at ``vector<string> getMaterialFilterAsVector()``. It shows | ||
+ | you how to get the description from a material, as a string:: | ||
+ | |||
+ | |||
+ | transform_(materials, descriptions, material_to_string_fn); | ||
− | + | if (descriptions.size() == 0) | |
− | + | bitfield_to_string(&descriptions, mat_mask); | |
− | + | ||
− | |||
− | + | == Managing speed == | |
+ | |||
+ | Some plugins need to run regular processing, but at a certain rate, | ||
+ | in order not to block DF. Here is how ``buildingplan`` handles game | ||
+ | ticks (important: this is only provided as an out-of-context code | ||
+ | snippet, with no further explanations):: | ||
+ | |||
+ | |||
+ | #define DAY_TICKS 1200 | ||
+ | DFhackCExport command_result plugin_onupdate(color_ostream &out) | ||
+ | { | ||
+ | static decltype(world->frame_counter) last_frame_count = 0; | ||
+ | if ((world->frame_counter - last_frame_count) >= DAY_TICKS/2) | ||
+ | { | ||
+ | last_frame_count = world->frame_counter; | ||
+ | planner.doCycle(); | ||
+ | } | ||
− | + | return CR_OK; | |
− | + | } | |
+ | |||
+ | == Replacing an existing view screen == | ||
+ | |||
+ | Maybe you don't want to add an additional view screen, but instead add | ||
+ | features to one that already exists in DF. | ||
+ | In that case, creating a child to ``dfhack_viewscreen``` (as seen in | ||
+ | section "Create your own view screen") and overriding ``render`` and | ||
+ | ``feed`` is not enough. You need to "interpose" those two functions | ||
+ | in the global DF system. | ||
− | + | That's the case of class ``buildingplan_hook`` in plugin ``buildingplan``. | |
− | + | You will notice that, unlike ``ViewscreenChooseMaterial``, it extends class | |
+ | ``df::viewscreen_dwarfmodest`` instead of ``dfhack_viewscreen``:: | ||
− | + | struct buildingplan_hook : public df::viewscreen_dwarfmodest | |
− | + | { | |
− | + | ||
− | + | ||
− | + | The following instructions are then required to glue everything together:: | |
+ | |||
+ | DEFINE_VMETHOD_INTERPOSE(void, feed, (set<df::interface_key> *input)) | ||
{ | { | ||
− | + | ... | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | DEFINE_VMETHOD_INTERPOSE(void, render, ()) | |
− | + | { | |
+ | ... | ||
+ | } | ||
− | + | Once you've defined how the two functions will insert into DF, you can put them to action:: | |
− | + | IMPLEMENT_VMETHOD_INTERPOSE(buildingplan_hook, feed); | |
+ | IMPLEMENT_VMETHOD_INTERPOSE(buildingplan_hook, render); | ||
− | |||
− | |||
− | |||
− | + | Note: That would need more explanations. | |
− | |||
− | |||
− | |||
− | + | See also: "Create your own view screen" | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== CHANGE LOG == | == CHANGE LOG == | ||
− | * v1.0 Redaction | + | * v1.0 Redaction |
− | * v1.1 | + | * v1.1 |
− | + | - moved "return CR_OK;" in one of the code snippets | |
− | + | - corrected a mistake about the need of using "DEFINE_VMETHOD_INTERPOSE" |