Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 107 108 [109] 110 111 ... 361

Author Topic: DFHack 0.43.03-r1  (Read 849528 times)

Shonai_Dweller

  • Bay Watcher
    • View Profile
Re: DFHack 0.40.19-r1
« Reply #1620 on: December 07, 2014, 04:39:51 pm »

Are you sure this is caused by DFHack? I know it's noticeable with DFHack keybindings, but could you see if it occurs with vanilla DF?

I've played for quite a bit in 4.19 without DFHack and built quite a few statues. It's not yet tried to build an Alt-s Slab by mistake yet.
Also using Alt-s to build slabs doesn't ever seem to make the Alt key 'stick'. I'm also Alt-tabbing a lot to Dwarf Therapist with no obvious problems. Installing DFHack causes problems (solved by tapping Alt once) almost immediately.

I guess that's not very helpful, apart from to say Alt seems to 'stick' at random without ever actually having to press it and hasn't yet occurred in several hours of 4.19 vanilla play. Does anyone have a definite way to make it happen yet?
Logged

vjek

  • Bay Watcher
  • If it didn't work, change the world so it does.
    • View Profile
Re: DFHack 0.40.19-r1
« Reply #1621 on: December 07, 2014, 06:34:16 pm »

Is elevate-physical gone in the new version?
I'm going to be testing all my scripts with the current (40.19) df/dfhack this week, and updating the wiki page to reflect any changes.  They might work perfectly at the moment, they might burn down your house, not sure yet. :)

Putnam

  • Bay Watcher
  • DAT WIZARD
    • View Profile
Re: DFHack 0.40.19-r1
« Reply #1622 on: December 07, 2014, 07:36:26 pm »

Code: [Select]
-- lets babies be adopted by couples with no infants.

local function getSpouseOrLover(unit)
    local lover_unit=df.unit.find(unit.relations.lover_id) or df.unit.find(unit.relations.spouse_id)
    if lover_unit then
        return lover_unit.hist_figure_id
    else
        local hist_fig=df.historical_figure.find(unit.hist_figure_id)
        for k,v in ipairs(hist_fig.histfig_links) do
            if df.histfig_hf_link_spousest:is_instance(v) or df.histfig_hf_link_loverst:is_instance(v) then
                return v.target_hf
            end
        end
    end
    return false
end

local function getNumberOfChildren(unit)
    local children=0
    for k,v in ipairs(df.historical_figure.find(unit.hist_figure_id).histfig_links) do
        if df.histfig_hf_link_childst:is_instance(v) then children=children+1 end
    end
    return children
end

local function figureIsAlive(hist_figure)
    return hist_figure.died_year==-1
end

local function unitIsChild(unit)
    return df.global.cur_year-unit.relations.birth_year<12
end

local function unitIsOrphan(unit)
    if unitIsChild(unit) then
        local fatherIsAlive,motherIsAlive=false,false
        for k,v in ipairs(df.historical_figure.find(unit.hist_figure_id).histfig_links) do
            if df.histfig_hf_link_motherst:is_instance(v) then
                if figureIsAlive(df.historical_figure.find(v.hist_figure_id)) then motherIsAlive=true end
            elseif df.histfig_hf_link_fatherst:is_instance(v) then
                if figureIsAlive(df.historical_figure.find(v.hist_figure_id)) then fatherIsAlive=true end           
            end
        end
        return (fatherIsAlive or motherIsAlive)
    end
    return false
end

local function adopt(baby,couple)
    local mother,father=false,false
    if df.historical_figure.find(couple.unit).sex==0 then
        mother=couple.unit
        father=couple.lover --yeah, the "father" will be female if the unit's lover is female, but the game will correctly display both as "mother"
    else
        father=couple.unit
        mother=couple.lover --similar to the above, the "mother" will be male if the unit's lover is male, but they'll both be "father" pretty elegantly.
    end
    local mother_fig=df.historical_figure.find(mother)
    local father_fig=df.historical_figure.find(father)
    local baby_hist_fig=df.historical_figure.find(baby.hist_figure_id)
    for k,v in ipairs(baby_hist_fig.histfig_links) do
        if df.histfig_hf_link_motherst:is_instance(v) then
            v.target_hf=mother --yeah, adoption will remove any relation other than genetics between biological parents and children.
        elseif df.histfig_hf_link_fatherst:is_instance(v) then
            v.target_hf=father
        end
    end
    mother_fig.histfig_links:insert('#',{new=df.histfig_hf_link_childst,target_hf=baby.hist_figure_id,link_strength=100})
    father_fig.histfig_links:insert('#',{new=df.histfig_hf_link_childst,target_hf=baby.hist_figure_id,link_strength=100})
    baby.relations.mother_id=mother_fig.unit_id
    baby.relations.father_id=father_fig.unit_id
    local message = dfhack.TranslateName(mother_fig.name) .. ' and ' .. dfhack.TranslateName(father_fig.name) .. ' have adopted ' .. dfhack.TranslateName(dfhack.units.getVisibleName(baby)) .. '.'
    dfhack.gui.showAnnouncement(message)
    dfhack.gui.writeToGamelog(message) --too lazy to use makeAnnouncement right now
end

local function findBabiesWithNoParents()
    local couples_histfig={}
    local orphans={}
    for k,unit in ipairs(df.global.world.units.active) do
        if dfhack.units.isCitizen(unit) then
            local spouseOrLover=getSpouseOrLover(unit)
            if spouseOrLover then
                couples_histfig[unit.hist_figure_id]=couples_histfig[unit.hist_figure_id] or {children=getNumberOfChildren(unit),lover=spouseOrLover,unit=unit.hist_figure_id}
                couples_histfig[spouseOrLover]=true --this weird sequence of crap makes it so that 1. I can easily cull redundant units and 2. I can still sort the table
            elseif unitIsOrphan(unit) then
                table.insert(orphans,unit)
            end
        end
    end
    local couples={}
    for k in pairs(couples_histfig) do
        if couples[k]==true then couples[k]=nil end --not doing this will make an error show up when sorting the couples table due to true.children being nonsense
    end
    for k,v in pairs(couples_histfig) do
        table.insert(couples,v) --makes the keys of the couples table be 1,2,3 etc. instead of being all over the place as histfigs
    end
    table.sort(couples,function(a,b) return a.children<b.children end)
    if #orphans>1 then
        for k,orphan in ipairs(orphans) do
            adopt(orphan,math.ceil(couples[k]/2))
        end
    end
end

require('repeat-util').scheduleUnlessAlreadyScheduled('Orphan Adoption Service',1,'days',findBabiesWithNoParents)

Adoption! It takes childless parents and gives them parents from couples.

Max™

  • Bay Watcher
  • [CULL:SQUARE]
    • View Profile
Re: DFHack 0.40.19-r1
« Reply #1623 on: December 08, 2014, 12:25:56 am »

Now that is a hell of a thing, good job!

Still can't figure out why stonesense wants libpng12, or why I can only find 64 bit versions of it when stonesense apparently wants a 32 bit version...
Logged

Rose

  • Bay Watcher
  • Spoopy time!
    • View Profile
Re: DFHack 0.40.19-r1
« Reply #1624 on: December 08, 2014, 12:47:15 am »

That would be due to whoever compiled it using that version.

You can probably symlink whatever version you have, as long as it's also 32bit
Logged

Max™

  • Bay Watcher
  • [CULL:SQUARE]
    • View Profile
Re: DFHack 0.40.19-r1
« Reply #1625 on: December 08, 2014, 12:55:52 am »

Yeah, that part is probably my bad, as I'm sure I'm forgetting an obvious way to install the 32 bit version, but every time I grab the i686 version or whichever trying to get it to work I keep ending up with the 64 bit one.

Edit: Ah hah, I was using the wrong terms trying to find it, I THINK this will end up working once it finishes: https://aur.archlinux.org/packages/lib32-libpng12/

KHAN!

So close...
Code: [Select]
libjpeg.so.62: cannot open shared object file: No such file or directory
Now to track that down.

YES, YES, IT'S BEAUTIFUL!
Spoiler (click to show/hide)
BWAHAHAHAHAHA!
« Last Edit: December 08, 2014, 01:37:45 am by Max™ »
Logged

Max™

  • Bay Watcher
  • [CULL:SQUARE]
    • View Profile
Re: DFHack 0.40.19-r1
« Reply #1626 on: December 08, 2014, 02:08:10 am »

To clear up the insanity there, I installed lib32-libpng12, libjpeg6, lib32-libjpeg6, and then placed a copy of the 32 bit versions right into the libs folder and it works like a charm.
Logged

Nopenope

  • Bay Watcher
    • View Profile
Re: DFHack 0.40.19-r1
« Reply #1627 on: December 08, 2014, 02:07:10 pm »

Adoption! It takes childless parents and gives them parents from couples.
Putnam, this is extremely cool, but could you be a sweetheart and make a gist out of it or upload it on wimbli or do a pull request or do anything that will prevent this cool script from getting buried in the massive thread? We've already had these issues in the .34.11r5 thread. This way you'd have an easier time maintaining it, too.
Logged

Putnam

  • Bay Watcher
  • DAT WIZARD
    • View Profile
Re: DFHack 0.40.19-r1
« Reply #1628 on: December 08, 2014, 03:37:51 pm »

breadman

  • Bay Watcher
    • View Profile
Re: DFHack 0.40.19-r1
« Reply #1629 on: December 08, 2014, 04:33:37 pm »

I'm not sure if this is possible, but I've seen a LOT of people get confused by the stuck-Alt-key issue and complain in the Starter Pack thread.

Are you sure this is caused by DFHack? I know it's noticeable with DFHack keybindings, but could you see if it occurs with vanilla DF?

I'm reasonably certain this problem is specific to DFHack keybindings on Windows.  While the Alt key is stuck, DFHack (a) incorrectly runs hotkeys defined with Alt, and (b) incorrectly fails to run hotkeys defined without Alt.  But only DFHack keybindings are affected; not native DF keys, and not keys checked by DFHack plugins.

I have been able to modify Core::DFH_SDL_EVENT to notice SDL window focus events on Linux, which would be a convenient place to clear the bad state if we can do so.  Unfortunately, ke->ksym.mod is set by SDL internally, so we would need to either maintain our own flag for the Alt key, or perhaps use SDL_PushEvent to pretend that the Alt key has been pressed and released.  Note that DF itself uses the former solution; see update_modstate in g_src/enabler_input.cpp, and its associated comment.

Unfortunately, while I sometimes play on Windows, I can't currently compile for that platform, which makes it hard to test potential solutions.
Logged
Quote from: Kevin Wayne, in r.g.r.n
Is a "diety" the being pictured by one of those extremely skinny aboriginal statues?

m-logik

  • Bay Watcher
    • View Profile
Re: DFHack 0.40.19-r1
« Reply #1630 on: December 08, 2014, 09:01:54 pm »

Is this the right place to report bugs with dfhack components?

I'm playing with 3dveins for the first time, and it seems to have worked properly. There are, however, several places where minerals "pierced" the ground under boulders, replacing them with a boulder of their material. This isn't much of a problem, except that there doesn't seem to be a tile defined for boulders of non-layer stones, resulting in a black square wherever this happens. I've got a save where all I've done is run 3dveins if it would be helpful.
Logged

Nopenope

  • Bay Watcher
    • View Profile
Re: DFHack 0.40.19-r1
« Reply #1631 on: December 09, 2014, 06:32:05 am »

Speaking of which, has Toady made a decision on whether he intends to make a forum specific to DFHack stuff? I have a feeling that this thread is going to end up like the .34.11 one, with everything buried in it.
Logged

Rose

  • Bay Watcher
  • Spoopy time!
    • View Profile
Re: DFHack 0.40.19-r1
« Reply #1632 on: December 09, 2014, 09:00:43 am »

You may notice that this is in the 'utilities and 3rd party applications' subforum
Logged

Nopenope

  • Bay Watcher
    • View Profile
Re: DFHack 0.40.19-r1
« Reply #1633 on: December 09, 2014, 09:23:16 am »

Uh, yes. What I meant is that there should be a subforum specifically dedicated to DFHack so all questions related to it aren't contained within one giant thread. There was a poll about it some time ago, and most people were favourable to the idea.
Logged

Rumrusher

  • Bay Watcher
  • current project : searching...
    • View Profile
Re: DFHack 0.40.19-r1
« Reply #1634 on: December 09, 2014, 02:02:01 pm »

Uh, yes. What I meant is that there should be a subforum specifically dedicated to DFHack so all questions related to it aren't contained within one giant thread. There was a poll about it some time ago, and most people were favourable to the idea.
Japa means that UA3PA forum is kinda the DFhack(and other utilities) subforum after it got separated from DFmodding. I don't think another subforum would be needed for a Post in a thread, that's like making a new planet for one person in a country. you're better off just making a [Dfhack question] thread and hope someone could answer it(we usually don't so it's bound to be empty).  Though you're best bet for questions to not get swallowed up is to hit us on IRC.
Though I really don't want to redirect folks to a different thread since if we answer your question in with a script then you have 2 threads to search through for scripts than just 1(well there's separate threads with scripts now so more than 1). then again I wonder if looking at a posters history in the thread would ease up 'new script' woes.
Logged
I thought I would I had never hear my daughter's escapades from some boy...
DAMN YOU RUMRUSHER!!!!!!!!
"body swapping and YOU!"
Adventure in baby making!Adv Homes
Pages: 1 ... 107 108 [109] 110 111 ... 361