Print

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

[Alex.]

Download it here

So I thought I'd give DFHack a go and I must say that after a couple of hours of digging through source code it made a lot of sense, which is fairly unusual for me. After looking at the itemdump tool I figured I could probably make it change things into bauxite and so I present to you the fruits of my labour, DFBauxite. No longer must we be slaves to the magma, viva la revolution!

== Instructions ==

1. Backup your Fortress
2. Open Dwarf Fortress
3. Run dfbauxite.exe
4. Press any key to continue
5. Build intricate goblin-murdering magma defences

[darius]

Welcome to the darkside

[Shima]

What version does this work for?  And does it work on ALL mechanisms (IE, ones already built), or only ones laying around?  Does it affect ones that are still to be made?

[Alex.]

Fairly sure it'll only work in 0.28.181.40d. It only works on pre-existing mechanisms, all it does it scan all items and when it finds a mechanism it changes the material to bauxite. It does seem to work on mechanisms already being used in constructions though.

[peterix]

Correction: from reading the code, it looks like it currently only works with 0.28.181.40d16.
Also, there are a few problems with hard-coded values. Don't use this with mods that change DF's stone material raws. Avoid worlds generated with older DF versions, even if the raws were the same. You will most probably get something else instead of bauxite.

I'll poke around
I should have something very soon. At least something that doesn't have the hardcoded values problem.
Eliminated the crasher bugs.

Revised code, should be much safer:

Spoiler (click to show/hide)

Code: [Select]

/*
DFBauxite - Converts all your mechanisms to bauxite (for use in magma).
Author: Alex Legg

Based on code from and uses DFHack - www.sourceforge.net/projects/dfhack
*/

#include "DFCommonInternal.h"
#include <sstream>
using namespace std;

int main ()
{
    DFHack::Process *proc;
    DFHack::memory_info *meminfo;
    DFHack::DfVector *items_vector;
    DFHack::t_item_df40d item_40d;
    DFHack::t_matglossPair item_40d_material;
    vector<DFHack::t_matgloss> stoneMat;
    uint32_t item_material_offset;
    uint32_t temp;
    int32_t type;
    int items;
    int found = 0, converted = 0;

    DFHack::API DF ("Memory.xml");
    if(!DF.Attach())
    {
        cerr << "DF not found" << endl;
        return 1;
    }

    DF.Suspend();
   
    /*
     * Find out which material is bauxite
     */
    DF.ReadStoneMatgloss(stoneMat);
    int bauxiteIndex = -1;
    for (int i = 0; i < stoneMat.size();i++)
    {
        if(strcmp(stoneMat[i].id, "BAUXITE") == 0)
        {
            bauxiteIndex = i;
            break;
        }
    }
    if(bauxiteIndex == -1)
    {
        cout << "Cannot locate bauxite in the DF raws, exiting" << endl;
        #ifndef LINUX_BUILD
            cin.ignore();
        #endif
        DF.Detach();
        return EXIT_FAILURE;
    }
   
    //FIXME: very counter-intuitive, fix the API. This returns a mapping from the internal ID to the object name
    //       internal IDs can be obtained by using resolveClassId
    //FIXME: Proper error reporting/exceptions support is sorely needed
    /*
     * Get the object name/ID mapping
     */
    vector <string> buildingtypes;
    uint32_t numBuildings = DF.InitReadBuildings(buildingtypes);
   
    proc = DF.getProcess();
    meminfo = proc->getDescriptor();
   
    //FIXME: work on the 'supported features' system required
    /*
     * Check availability of required addresses and offsets (doing custom stuff here)
     */
    items = meminfo->getAddress("items");
    item_material_offset = meminfo->getOffset("item_materials");
    if( !items || ! item_material_offset)
    {
        cout << "Items not supported for this DF version, exiting" << endl;
        #ifndef LINUX_BUILD
            cin.ignore();
        #endif
        DF.Detach();
        return EXIT_FAILURE;
    }
   
    items_vector = new DFHack::DfVector (proc->getDataModel()->readVector (items, 4));
    for(uint32_t i = 0; i < items_vector->getSize(); i++)
    {
        // get pointer to object
        temp = * (uint32_t *) items_vector->at (i);
        // read object
        proc->read (temp, sizeof (DFHack::t_item_df40d), (uint8_t *) &item_40d);

        // resolve object type
        type = -1;
       
        // skip things we can't identify
        if(!meminfo->resolveClassId (temp, type))
            continue;
       
        if(buildingtypes[type] == "item_trapparts")
        {
            proc->read (temp + item_material_offset, sizeof (DFHack::t_matglossPair), (uint8_t *) &item_40d_material);

            cout << dec << "Mechanism at x:" << item_40d.x << " y:" << item_40d.y << " z:" << item_40d.z << " ID:" << item_40d.ID << endl;
           
            if (item_40d_material.index != bauxiteIndex)
            {
                item_40d_material.index = bauxiteIndex;
                proc->write (temp + item_material_offset, sizeof (DFHack::t_matglossPair), (uint8_t *) &item_40d_material);
                converted++;
            }

            found++;
        }
    }


    if (found == 0)
    {
        cout << "No mechanisms to convert" << endl;
    } else {
        cout << found << " mechanisms found" << endl;
        cout << converted << " mechanisms converted" << endl;
    }

    DF.Resume();
    DF.Detach();

    delete items_vector;

#ifndef LINUX_BUILD
    cout << "Done. Press any key to continue" << endl;
    cin.ignore();
#endif
    return 0;
}

Spoiler (click to show/hide)

This is very valuable. Seeing how is the library being used is a great way to find weak spots. I already found and verified *three* major problems in my code. Nothing that would impact the user directly, but some mismatches in method naming, bad or missing error reporting and similar problems.

Anyway, I should finally do something about item support in dfhack. Belal made some progress there, but apparently you had to use a few work-arounds (lack of write support in the main API being the main problem).

Oh, and the DF.Suspend(); call should go before any of the read/write functions. You would get crashes on Linux and when using the accelerated interface.

[Alex.]

Thanks! I forgot all about the hard coded values. And thanks for the error checking stuff as well.

I was wondering why there was no WriteItems function, so I decided to try and edit the memory directly just to see if it worked. Which is, as you said, counter-intuitive. I would have tried to write something for the API but I would almost definitely have created more bugs...

I've uploaded peterix's changes to DFFD for anyone who wants to actually use this.

[peterix]

The part that's really counter-intuitive is using InitReadBuildings to get the object id/name mapping. And the fact the method can't return an error if it triggers one.

Oh well.