Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 194 195 [196] 197 198 ... 373

Author Topic: DFHack 0.34.11 r3  (Read 1457282 times)

Naryar

  • Bay Watcher
  • [SPHERE:VERMIN][LIKES_FIGHTING]
    • View Profile
Re: DFHack 0.34.11 r2
« Reply #2925 on: February 03, 2013, 09:44:09 am »

I heard there was a tool that permitted creature respawn, because my current fort is out of cavern creatures and i'm pretty damn sure I didn't hunted them all to extinction, considering how like only 2 GCS ever spawned on my map, and the population number is far higher.

Mikesullivan

  • Bay Watcher
    • View Profile
Re: DFHack 0.34.11 r2
« Reply #2926 on: February 03, 2013, 12:20:06 pm »

ANy ideas why im allways getting the error message "could not move xxx", it usually happens to stones and i dont understand why.
Logged

Telgin

  • Bay Watcher
  • Professional Programmer
    • View Profile
Re: DFHack 0.34.11 r2
« Reply #2927 on: February 03, 2013, 01:02:27 pm »

There is nothing proper in linear loops :P. Use df.historical_figure.find(id) and df.unit.find(id). Also, if run from hack/script/ and not via legacy dfusion, core is always already suspended.

That find method is certainly simpler than what I was doing.  As I mentioned before, my experience with Lua is completely confined to those scripts, which also represent the entire breadth of my DFHack knowledge.  It's good to know that the core is always suspended for Lua scripts, that would also explain why this didn't crash DF like I expected it to before I added the suspend call.

Looking at the "marry" and "divorce" scripts, you're missing one important thing: historical events; the 'marry' script should add a pair of history_event_add_hf_hf_linkst entries so Legends will report them having been married, and the 'divorce' script should similarly add a pair of history_event_remove_hf_hf_linkst entries (which, if I recall correctly, will actually show up as "X divorced Y" in Legends mode).

I saw something about those in df-structures, but since I pretty much never read Legends mode and really only cared if it worked in Fort mode it was good enough for me.  Still, it pays to do it right I suppose.  There are a few more tweaks that could be added to the scripts (such as upgrading lovers to marriages instead of just letting a dwarf have both...), so when I get to fixing that I'll see about adding the Legends mode data.
Logged
Through pain, I find wisdom.

Putnam

  • Bay Watcher
  • DAT WIZARD
    • View Profile
Re: DFHack 0.34.11 r2
« Reply #2928 on: February 03, 2013, 01:04:58 pm »

So, uh, can anyone have a looksie at this here script I wrote and see if there's anything odd? I'm not going to be that confident in this business until I write ~5 or 6 of them...

Code: [Select]
[c-- Gives power level of selected unit. Type "popup" for popup announcement.

local selectedUnit = dfhack.gui.getSelectedUnit(silent)

local arg = ...

function isWinded(unit)
if unit.counters.winded > 0 then return true end
return false
end
function isStunned(unit)
if unit.counters.stunned > 0 then return true end
return false
end
function isUnconscious(unit)
if unit.counters.unconscious > 0 then return true end
return false
end
function isParalyzed(unit)
if unit.counters2.paralysis > 0 then return true end
return false
end
function getExhaustion(unit)
local exhaustion = 1
if unit.counters2.exhaustion~=0 then
exhaustion = 1000/unit.counters2.exhaustion
if exhaustion>1 then exhaustion = 1 end
else unit.counters2.exhaustion=1
return exhaustion
end
return 1
end
function getBoost(unit)
return unit.counters.soldier_mood
end

--power levels should account for disabilities and such

--I have to declare the individual skill's numbers, including these here makes the program easier to read
local MELEE_COMBAT = 99
local WRESTLING = 102
local GRASP_STRIKE = 104
local STANCE_STRIKE = 105
local BITE = 103
local THROW = 55
local RANGED_COMBAT = 101

if df.isnull(selectedUnit) then
qerror('Need to select a unit.')
end

--blood_max appears to be the creature's body size divided by 10; the power level calculation relies on body size divided by 1000, so divided by 100 it is. blood_count refers to current blood amount, and it, when full, is equal to blood_max.
local strength = selectedUnit.body.physical_attrs.STRENGTH.value/3550
local agility = selectedUnit.body.physical_attrs.AGILITY.value/3550
local endurance = selectedUnit.body.physical_attrs.ENDURANCE.value/1000
local toughness = selectedUnit.body.physical_attrs.TOUGHNESS.value/2250
local spatialsense = selectedUnit.status.current_soul.mental_attrs.SPATIAL_SENSE.value/1500
local kinestheticsense = selectedUnit.status.current_soul.mental_attrs.KINESTHETIC_SENSE.value/1000
local willpower = selectedUnit.status.current_soul.mental_attrs.WILLPOWER.value/1000
local exhaustion = getExhaustion(selectedUnit)
local bodysize = selectedUnit.body.blood_count/100
local fighting = dfhack.units.getEffectiveSkill(selectedUnit, MELEE_COMBAT)*1000
local wrestling = dfhack.units.getEffectiveSkill(selectedUnit, WRESTLING)*1000
local grasp_strike = dfhack.units.getEffectiveSkill(selectedUnit, GRASP_STRIKE)*1000
local stance_strike = dfhack.units.getEffectiveSkill(selectedUnit, STANCE_STRIKE)*1000
local biting = dfhack.units.getEffectiveSkill(selectedUnit, BITE)*1000
local ki = dfhack.units.getEffectiveSkill(selectedUnit, THROW)*1000 + dfhack.units.getEffectiveSkill(selectedUnit, RANGED_COMBAT)*1000
local powerlevel = bodysize*bodysize*strength*agility*endurance*toughness*spatialsense*kinestheticsense*willpower*exhaustion+fighting+wrestling+grasp_strike+stance_strike+biting+ki
if getBoost(selectedUnit)==0 then powerlevel=powerlevel*1.5 end
if getBoost(selectedUnit)==1 then powerlevel=powerlevel*2 end
if getBoost(selectedUnit)==2 then powerlevel=powerlevel*1.3 end
if isWinded(selectedUnit) then powerlevel=powerlevel/1.2 end
if isStunned(selectedUnit) then powerlevel=powerlevel/1.5 end
if isParalyzed(selectedUnit) then powerlevel=powerlevel/5 end
if isUnconscious(selectedUnit) then powerlevel=powerlevel/10 end

if arg == "popup" or arg == "Popup" then
dfhack.gui.showPopupAnnouncement("The scouter says " .. math.floor(powerlevel) .. "!",11)
else dfhack.gui.showAnnouncement("The scouter says " .. math.floor(powerlevel) .. "!",11)
end

Lord_Phoenix

  • Bay Watcher
    • View Profile
Re: DFHack 0.34.11 r2
« Reply #2929 on: February 03, 2013, 01:06:01 pm »

ANy ideas why im allways getting the error message "could not move xxx", it usually happens to stones and i dont understand why.

With autodump?  Helps to say what you're doing.

With autodump, if the item is forbidden or already has a task generated for it (like someone coming to move it to a stockpile, or someone coming to grab it for some job), then it will stay there and give that error.  In the case of it being a task, then the item will forbid itself and the task will fail, and then you have to reclaim the thing.
Logged

WillowLuman

  • Bay Watcher
  • They/Them Life is weird
    • View Profile
Re: DFHack 0.34.11 r2
« Reply #2930 on: February 03, 2013, 01:24:29 pm »

Oh, no, it's not.  That's the historical figure id of whoever you told it to marry.  That's specific to each world and whoever it is for.  In this case, that just means that one of the two you were trying to marry had a historical figure id of 6965, but the number of historical figures currently in DF's memory is less than 6965.  That could be either because DF doesn't load them all in adventure mode, or because they lose the 1-to-1 relationship of index associated to historical figure id I was relying on.  That worked in my world, but worlds that have actually had gameplay happen in them may invalidate that.
Actually, the id's I tried to use were 2465 and 2414, which was why I was perplexed at 6965. Maybe I mistyped the first one?

I'll test the updated script right now.

EDIT: seems to work in adventure mode so far, only glitch I've seen is the "Marrying and " doesn't show names (but it calls for nicknames right?)
« Last Edit: February 03, 2013, 01:30:26 pm by HugoLuman »
Logged
Dwarf Souls: Prepare to Mine
Keep Me Safe - A Girl and Her Computer (Illustrated Game)
Darkest Garden - Illustrated game. - What mysteries lie in the abandoned dark?

Mikesullivan

  • Bay Watcher
    • View Profile
Re: DFHack 0.34.11 r2
« Reply #2931 on: February 03, 2013, 01:27:16 pm »

Thank you, it looks like that was the problem (dwarfs was trying to use that rock and i cant autodump because they are going to get it already).

Logged

Telgin

  • Bay Watcher
  • Professional Programmer
    • View Profile
Re: DFHack 0.34.11 r2
« Reply #2932 on: February 03, 2013, 01:48:20 pm »

Oh, no, it's not.  That's the historical figure id of whoever you told it to marry.  That's specific to each world and whoever it is for.  In this case, that just means that one of the two you were trying to marry had a historical figure id of 6965, but the number of historical figures currently in DF's memory is less than 6965.  That could be either because DF doesn't load them all in adventure mode, or because they lose the 1-to-1 relationship of index associated to historical figure id I was relying on.  That worked in my world, but worlds that have actually had gameplay happen in them may invalidate that.
Actually, the id's I tried to use were 2465 and 2414, which was why I was perplexed at 6965. Maybe I mistyped the first one?

I'll test the updated script right now.

EDIT: seems to work in adventure mode so far, only glitch I've seen is the "Marrying and " doesn't show names (but it calls for nicknames right?)

That's correct.  It's just a diagnostic message though, and I didn't want to fool around with translating the compound names if DFHack doesn't do it for you.  The 6965 sounds like it's right.  What's happening is that you enter the unit ids 2465 and 2414, which are then associated with historical figures which use different ids.  So 6965 was the historical figure id of one of the two units you provided.

Quote
So, uh, can anyone have a looksie at this here script I wrote and see if there's anything odd? I'm not going to be that confident in this business until I write ~5 or 6 of them...

I don't see anything obviously amiss, but my Lua is very green.  The only thing that looks suspicious is the way you're treating the arg variable.  Is it not always an array?  You might want to use

Code: [Select]
local args = ...
if args[1] == "popup"

instead of

Code: [Select]
local arg = ...
if arg == "popup"

Does it work as is?  I may be completely mistaken in the way Lua treats this variable.
Logged
Through pain, I find wisdom.

Putnam

  • Bay Watcher
  • DAT WIZARD
    • View Profile
Re: DFHack 0.34.11 r2
« Reply #2933 on: February 03, 2013, 01:49:41 pm »

It works as-is. I figure that it doesn't need to be an array if I only have one argument.

Telgin

  • Bay Watcher
  • Professional Programmer
    • View Profile
Re: DFHack 0.34.11 r2
« Reply #2934 on: February 03, 2013, 02:46:13 pm »

Hmm, interesting.  I guess accessing the array in that manner silently accesses the first element?

Anyway, is there any way to use the Lua API to set up a repeating event?  Something like the workflow plugin?  It looks like the workflow plugin is registering a callback of some sort that is called every frame, but I didn't see anything like that in the Lua interface documentation.

If that's not possible, then I guess I'll have to write the "family planning" plugin I want as a C++ module.  I recall Quietust writing earlier in the thread VS2012 won't work because of the runtime.  Is that because DFHack's precompiled binary uses an older runtime, or because Dwarf Fortress does?  I'm guessing it's the latter, which would mean rebuilding all of DFHack in VS2012 won't fix the problem.  Guess I need to find a computer to install an older version of VS on.

Or I could just write a buggy plugin that leaks memory, I guess.
Logged
Through pain, I find wisdom.

Quietust

  • Bay Watcher
  • Does not suffer fools gladly
    • View Profile
    • QMT Productions
Re: DFHack 0.34.11 r2
« Reply #2935 on: February 03, 2013, 05:27:30 pm »

I recall Quietust writing earlier in the thread VS2012 won't work because of the runtime.  Is that because DFHack's precompiled binary uses an older runtime, or because Dwarf Fortress does?  I'm guessing it's the latter, which would mean rebuilding all of DFHack in VS2012 won't fix the problem.
Dwarf Fortress uses the MSVC 2010 runtime, therefore DFHack (and all of its plugins) must also use it.

It would be theoretically possible for DFHack to use a different runtime, but you'd need to jump through a bunch of extra hoops to get it to work. DFHack-23a and DFHack-40d did this, and I had to write special versions of malloc() and free() (as well as operator new/delete) which used DF's own heap handle instead of the one in the C runtime.

The problem is that that technique wouldn't work very well with 0.31 and later since the heap handle is located inside msvcr100.dll, meaning you'd have to find its load address without actually allocating any memory on the heap (which would require a whole bunch of special logic); it worked in 23a and 40d (with difficulty) because they linked against the static version of libc and were non-relocateable (so I could just hardcode the address of the heap handle).
Logged
P.S. If you don't get this note, let me know and I'll write you another.
It's amazing how dwarves can make a stack of bones completely waterproof and magmaproof.
It's amazing how they can make an entire floodgate out of the bones of 2 cats.

TigerHunter

  • Bay Watcher
    • View Profile
Re: DFHack 0.34.11 r2
« Reply #2936 on: February 03, 2013, 07:20:15 pm »

I am having difficulty getting DFHack to run on OSX.

I extracted the files into my DF folder. When I double-click on "dfhack", it opens terminal and dwarffort.exe but does not start the game.

Double-clicking "dfhack-run" opens another terminal window that displays "Segmentation fault", then logs out and declares the process completed.

The readme has not been updated to include the new OSX version, can anyone help me? I have no idea what I'm doing.
Logged

expwnent

  • Bay Watcher
    • View Profile
Re: DFHack 0.34.11 r2
« Reply #2937 on: February 04, 2013, 12:51:56 am »

Here's a little script I just cooked up to give proper spouse/parent last names to dwarves in the fort (only works if spouse/parent is actually at the fort), for those who like having family names.  Valid arguments are nothing or 0 for a patriarchal lineage (wives and children get father/husband last name), or 1 for a matriarchal lineage (husbands and children get mother/wife last name).  I just cobbled this together, so it's nothing perfect, might be builtin dfhack functions to do some stuff that I did, but I don't know cause there's very little documentation I could find on the properties and methods associated with each class, so I just had to go by key,value pairs to find properties and worked from there.  If anyone wants to do any improvements to it, that's fine by me.  Not even sure this would actually change their names in legends or what since there seems to be a separate historical id.

Oh, and does anyone know how to update the names when viewing unit status without giving them a nick and then removing it in game?

Does all of that and more: http://www.bay12forums.com/smf/index.php?topic=112381.0
Logged

WillowLuman

  • Bay Watcher
  • They/Them Life is weird
    • View Profile
Re: DFHack 0.34.11 r2
« Reply #2938 on: February 04, 2013, 01:09:36 am »

Alright Telgin, new script successfully results in marriages, but when the woman is impregnated using Dfusion, the child still does not belong to the father ("father is lost to history"). My guess is that the script needs to set the lover_id as well as spouse_id. Needs more testing, though.
Logged
Dwarf Souls: Prepare to Mine
Keep Me Safe - A Girl and Her Computer (Illustrated Game)
Darkest Garden - Illustrated game. - What mysteries lie in the abandoned dark?

Warmist

  • Bay Watcher
  • Master of unfinished jobs
    • View Profile
Re: DFHack 0.34.11 r2
« Reply #2939 on: February 04, 2013, 01:26:27 am »

Alright Telgin, new script successfully results in marriages, but when the woman is impregnated using Dfusion, the child still does not belong to the father ("father is lost to history"). My guess is that the script needs to set the lover_id as well as spouse_id. Needs more testing, though.
The dfusion impregnation might be at fault here.
Pages: 1 ... 194 195 [196] 197 198 ... 373