Print

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

[Iä! RIAKTOR!]

Tweak makeown is useful for making haulers. But they are not citizens. How make unit a citizen of fortress, with changeable labors?

[Fleeting Frames]

Try the script in this thread perhaps?

[Warmist]

on somewhat related note: do we know enough to add a petition? maybe that would sidestep all this hackery and just make df do the work?

[lethosor]

on somewhat related note: do we know enough to add a petition? maybe that would sidestep all this hackery and just make df do the work?

Looks like agreement is the relevant struct, and there are some unknown fields in it and in agreement_party, so it may or may not be possible to create working petitions.

[Chai]

Using rejuvenate successfully changes dwarves to 20 in fortress mode; however, retiring the fort and checking the dwarves in Legends Mode will state they were born in their original birth date. Reclaiming the fort will show they are all, however, still 20 as I left them.
Rejuvenate on Adventurer Mode will appear to work on a never-before-retired character, giving the message that <name> is 20 and will live at least a hundred years, but retiring them will show they were born at some other completely different time, and attempting to use rejuvenate on a previously retired character, who thus already has an age set in legends, will just crash the game.
Why? I realize this function wasn't intended for Adventurer Mode, I am curious though.

Does the supposed birth date actually matter? If I remove the birth date change and make rejuvenate only use unit.old_year = current_year + 100, would that work fine? It'd take a lot more time investment for me to check this part myself.

I understand rejuvenate isn't meant to be used in Adventurer, but does anyone know how it might be used that way? Taking the function and only slightly changing it lets you put in any number into the argument so you can pick the age of the target, I tested this with 20, 34, 15, and 9, and stuff changed just fine, retaining it. If something along these lines could be used to customize your adventurer's age, that'd be nice. Maybe it'd have to be something done on the setup screen, much like adv-max-skills, though in this case to avoid crashes and make it stick in legends mode (I would hope).
Any input would be appreciated, I don't know how anything works.

[lethosor]

Using rejuvenate successfully changes dwarves to 20 in fortress mode; however, retiring the fort and checking the dwarves in Legends Mode will state they were born in their original birth date. Reclaiming the fort will show they are all, however, still 20 as I left them.

My guess is that this is because the script is only changing unit.birth_year, and legends mode is checking the corresponding historical figure instead of the unit (since units don't really exist in legends mode). Maybe it should be changing the histfig age too.

Rejuvenate on Adventurer Mode will appear to work on a never-before-retired character, giving the message that <name> is 20 and will live at least a hundred years, but retiring them will show they were born at some other completely different time, and attempting to use rejuvenate on a previously retired character, who thus already has an age set in legends, will just crash the game.
Why? I realize this function wasn't intended for Adventurer Mode, I am curious though.

Ideally it wouldn't be able to cause a crash, so I'm also curious. What happens if you run the script with "-dry-run" in this case? (I'm wondering if it's crashing when actually setting the age or at some point before.)

Does the supposed birth date actually matter? If I remove the birth date change and make rejuvenate only use unit.old_year = current_year + 100, would that work fine? It'd take a lot more time investment for me to check this part myself.

From comments in df-structures, old_year isn't when the unit was born - it may be when they die, although it's unclear if this was ever confirmed.

[someone12345]

I am not very familiar with dfhack or lua, but how would I go about making remove-wear remove wear only from armor and weapons, and not from clothing?

Code: [Select]

local args = {...}
local count = 0

if args[1] == 'help' then
    print(help)
    return
elseif args[1] == 'all' or args[1] == '-all' then
    for _, item in ipairs(df.global.world.items.all) do
        if item.wear > 0 then --hint:df.item_actual
            item:setWear(0)
            count = count + 1
        end
    end
else
    for i, arg in ipairs(args) do
        local item_id = tonumber(arg)
        if item_id then
            local item = df.item.find(item_id)
            if item then
                item:setWear(0)
                count = count + 1
            else
                dfhack.printerr('remove-wear: could not find item: ' .. item_id)
            end
        else
            qerror('Invalid item ID: ' .. arg)
        end
    end
end

print('remove-wear: removed wear from '..count..' objects')



Would I add a section like so:

Code: [Select]

elseif args[1] == 'equipment' or args[1] == '-equipment' then
    for _, item in ipairs(df.global.world.items.all) do
        if item.wear > 0 then --hint:df.item_actual -- Here?????
            item:setWear(0)
            count = count + 1
        end
    end

I'm thinking you would add some condition with item.type == armor or item.type == weapon, but I do not know how to use lua or how dfhack's internal syntax works. How would I go about doing this?

[lethosor]

You have the right spot identified, I think. You'll want to check "item.type", I think - to find the right type, you could run gui/gm-editor with an item selected and inspect the type field. It's an enum, so you should get a list of valid values - make sure you use df.item_type.SOME_TYPE and not the raw number.

Unfortunately, looking at https://dwarffortresswiki.org/index.php/DF2014:Item_token, item types don't make a distinction between armor and other clothing. The item subtype might be what distinguishes between those, but I don't know as much about that off the top of my head.

[Atomic Chicken]

It'd be possible to check the subtype info of valid item types for a non-clothing armorlevel, but there's a very convenient vmethod that does all the work for us. The following one-liner should serve as a general weapon/armour check (including shields):

Code: [Select]

if item._type == df.item_weaponst or item:isArmorNotClothing() then


[Fleeting Frames]

Hm, what's a safe way to convert df::item to, say, df::item_threadst or df::item_constructed?

Atm I've managed to compile

Spoiler: this cant be right... (click to show/hide)

Code: [Select]

void *holdconvert = item;
if(item->getType() == df::item_type::THREAD){
item_threadst *threaditem = (item_threadst*)holdconvert;
dye_mat_type = threaditem->dye_mat_type;
dye_mat_index = threaditem->dye_mat_index;
}

And while it works, it seems wrong. (More obvious (to me) conversion methods throw compiling errors at me.)

[Clément]

dynamic_cast ? I'm not sure if that works in DFHack.

I see there is a virtual_cast in DataDefs.h, I guess that's better.

[lethosor]

Yeah, virtual_cast is definitely what you want here - it'll return null if the type you specify doesn't match the type of the object (similar to dynamic_cast). The important difference is that virtual_cast checks the type information of the types defined in DF, while dynamic_cast uses type information from the stubs defined in DFHack, which it considers completely unrelated types from the ones in DF.

It can be shortened like this:

Code: [Select]

if (auto threaditem = virtual_cast<item_threadst>(item)) {
  // do stuff with threaditem
}


[Fleeting Frames]

Yeah, that worked. Thanks!

[lethosor]

Heads up: the current dev build is likely to be one of the last before we release 0.47.04-r1 (the last couple things on the r1 to-do list probably don't need to be addressed urgently). I don't know exactly when this build will be ready because the one before it in the queue got stuck, but hopefully within the next 12 hours hour or so. (Update: BenLubar fixed the stuck build)
Anyway, we haven't gotten a lot of reports of urgent issues in 0.47.04-beta1 - hopefully that means there aren't any left to fix, but if you've been encountering any issues with the beta build(s), please let us know!

[Roses]

Heads up: the current dev build is likely to be one of the last before we release 0.47.04-r1 (the last couple things on the r1 to-do list probably don't need to be addressed urgently). I don't know exactly when this build will be ready because the one before it in the queue got stuck, but hopefully within the next 12 hours hour or so. (Update: BenLubar fixed the stuck build)
Anyway, we haven't gotten a lot of reports of urgent issues in 0.47.04-beta1 - hopefully that means there aren't any left to fix, but if you've been encountering any issues with the beta build(s), please let us know!

I ran all my scripts and tests, no issues detected with the beta build