Print

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

[Droggarth]

Lethosor... *draws his own most precious Drolth sword from the collection that has many slain monster and creature names engraved into its memory-* Thank you so much! *-and gives that Drolth sword as a gift to Lethsor*

[Droggarth]

(delete: accidental double post upon editing the original post)

[Hesperid]

If we got an actual release of Dfhack for v 0.43.05, then that must mean the new Dwarf Fortress release is only days away.

[Amostubal]

okay I found this in a script in MW repository that is causing a slight issue.

df.global.gps.screen.value

in this:

Code: [Select]

  -- Reset count if a new fort or reclaim, i.e. onload.init runs prior to load of embark screen.
  if df.global.gps.screen.value == 0 then

and apparently this does not spot an embark screen. I'm not even sure what it is spotting.  But the reality is I want it moved to the onMapload.init anyway, so the question is at onMapload.init.  Is there a way to detect If a map is new?   Basically I want this counter to reset every time a new embark has occurred on the map, not every time the map is loaded.  And for it to occur when onMapload.init is loaded.

any ideas on a direction to head in?

[lethosor]

okay I found this in a script in MW repository that is causing a slight issue.

df.global.gps.screen.value

in this:

Code: [Select]

  -- Reset count if a new fort or reclaim, i.e. onload.init runs prior to load of embark screen.
  if df.global.gps.screen.value == 0 then

and apparently this does not spot an embark screen. I'm not even sure what it is spotting.  But the reality is I want it moved to the onMapload.init anyway, so the question is at onMapload.init.  Is there a way to detect If a map is new?   Basically I want this counter to reset every time a new embark has occurred on the map, not every time the map is loaded.  And for it to occur when onMapload.init is loaded.

any ideas on a direction to head in?

Yeah, that has nothing at all to do with the embark screen. That detects whether the tile in the upper left corner of the screen is blank, has a black background color, has a black foreground color, or doesn't have a bold/bright foreground color (it's exactly one of those four; I'm not sure which). I definitely would not rely on that. It looks to me like someone just found something that seemed to correspond to the embark screen sometimes and decided to use it.

This is one way to check for the embark screen:

Code: [Select]

df.viewscreen_choose_start_sitest:is_instance(dfhack.gui.getCurViewscreen())
I would be more inclined to use an onStateChange handler in your situation (see http://dfhack.readthedocs.io/en/stable/docs/Lua%20API.html). Maybe something like this:

Code: [Select]

was_embarking = false
dfhack.onStateChange.your_script_name = function(event)
    if event == SC_VIEWSCREEN_CHANGED then
        if df.viewscreen_choose_start_sitest:is_instance(dfhack.gui.getCurViewscreen()) then
            was_embarking = true
        end
    elseif event == SC_MAP_LOADED then
        if was_embarking then
            print('do stuff')
        end
        -- make sure this doesn't fire again the next time a map loads, unless the user embarks again
        was_embarking = false
    end
end


[Amostubal]

awesome lethosor... new unbroken territory of dfhack for me.  I'll try that and see what I can get it to do.


I've also found some other scripts I thought were from DFHack but apparently not?  Some of them I'm not even sure why they even exist or what they were there to fix.   I didn't notice these until I was switching to this version (previously I just copied back in all the scripts that were removed, then deleted/fixed as they produced errors, this time I grouped them into one folder separate from DFHack).  I've identified several of their sources... most were old scripts that apparently were just left in, even though their usage had stopped.

But a couple I find are rather useful, and one I thought was odd for not being a DFHack script, it needs some reformatting to fit the motif of DFHack, but its a fix for handedness of gloves produced by reactions... As far as I can tell its just checking every X ticks for unhanded gloves then just switching them left, right, left, right.  Its in ruby, so I'm not fully on board with the language, but I think I can read other rb scripts in DFHack, and update the format to fit. and post it to the github if your interested in a such a fix... I couldn't find a similar fix inside of DFHack, other than the one in create-item.

[Amostubal]

new information... apparently dfhack persistent created tables are deleted when a map site is abandoned, at least my test map was doing that... I just removed the line of code and the whole thing returned to normal operation all together, as the saved counter disappeared when I abandoned the fortress.  is that as intended?  I'm going with it at the moment, and stick to this fix, unless someone has some other

[lethosor]

But a couple I find are rather useful, and one I thought was odd for not being a DFHack script, it needs some reformatting to fit the motif of DFHack, but its a fix for handedness of gloves produced by reactions... As far as I can tell its just checking every X ticks for unhanded gloves then just switching them left, right, left, right.  Its in ruby, so I'm not fully on board with the language, but I think I can read other rb scripts in DFHack, and update the format to fit. and post it to the github if your interested in a such a fix... I couldn't find a similar fix inside of DFHack, other than the one in create-item.

Is that autofixhandedness? It sounds familiar, but I couldn't find it in any Git history, and I'm not entirely sure what it was used for. Maybe I just heard about it from MDF.

new information... apparently dfhack persistent created tables are deleted when a map site is abandoned, at least my test map was doing that... I just removed the line of code and the whole thing returned to normal operation all together, as the saved counter disappeared when I abandoned the fortress.  is that as intended?  I'm going with it at the moment, and stick to this fix, unless someone has some other

I don't think that's intentional. Had you saved before abandoning? Persistent tables are still saved as histfigs, I believe, and those shouldn't normally be deleted when you abandon a fortress, as long as the world stays around.

[Gorobay]

How can I determine site-specific position assignments, like captain of the guard? I can get entity-wide position assignments using historical_entity.positions.assignments, but I can’t find the site equivalent.

[lethosor]

How can I determine site-specific position assignments, like captain of the guard? I can get entity-wide position assignments using historical_entity.positions.assignments, but I can’t find the site equivalent.

This is what gui/extended-status uses to find managers. I couldn't find anything in my fort's world_site instance ("df.world_site.find(ui.site_id)"), but it has two entries in "df.world_site.find(ui.site_id).entity_links", with one's entity_id equal to ui.civ_id and the other's entity_id equal to ui.group_id, and the assignments for the latter (what gui/extended-status uses) change when I assign a manager.

I'm not sure if that's useful or not, since I couldn't figure out a way to detect a militia commander just now. I'm assuming captain of the guard wouldn't be much different.

[Gorobay]

That was indeed helpful. Given a site site, its assignments are df.historical_entity.find(site.cur_owner_id).positions.assignments, which is exactly what I was looking for.

[lethosor]

Cool. Player fortresses seem to have a cur_owner_id of -1, so I would have missed that. Out of curiosity, how are you finding militia commanders? Are you searching through assignments yourself? I couldn't find something in assignments_by_type that looked like it was changing when I assigned one.

[Gorobay]

I am not looking for militia commanders, or any other position in particular: I had some numbers which I was pretty sure corresponded to site positions, and in fact they are indexes into the site’s group’s positions.assignments. A pull request is forthcoming. I am not sure how to find the assignment for a given position, but probably I would iterate through that vector, checking each position_id in positions.own until I found the one that matched the position I wanted.

[Max™]

Hmmm, I just checked one of my active reclaimed forts, df.global.world.world_data.active_site.entity_links and looked at the bottom of the list, numbers list the site id and relevant entity, usually player created/claimed site groups are near or at the end, went to that entity and grabbed this shot:

Spoiler (click to show/hide)

Isn't that it?

Oh yeah! Is there a simple way to recenter a screen on a unit or whatnot that I'm just a moron and overlooked? I couldn't figure out dfhack.screen.zoom() syntax at all though I tried feeding it my unit position, cursor position, unit id, and a couple other things.

Hmmm, there's an update screen check too isn't there? Was annoying trying out a "teleport to the cursor" hotkeyable script because if you have the cursor out of view you have to move before it will refresh your screen fully. Even tried having it just straight up list that tile as revealed through the dfhack.maps.getTileBlock(blah).designations[xmath][ymath] stuff with no luck.

[Amostubal]

But a couple I find are rather useful, and one I thought was odd for not being a DFHack script, it needs some reformatting to fit the motif of DFHack, but its a fix for handedness of gloves produced by reactions... As far as I can tell its just checking every X ticks for unhanded gloves then just switching them left, right, left, right.  Its in ruby, so I'm not fully on board with the language, but I think I can read other rb scripts in DFHack, and update the format to fit. and post it to the github if your interested in a such a fix... I couldn't find a similar fix inside of DFHack, other than the one in create-item.

Is that autofixhandedness? It sounds familiar, but I couldn't find it in any Git history, and I'm not entirely sure what it was used for. Maybe I just heard about it from MDF.

Yes it was... I couldn't find it anywhere online... but its just a basic repeating script... It works, its set to 2000 ticks if I understand it correctly, and in fortress mode that's just about perfect timing, I couldn't tell you how "optimized" it is.  Here you go:

Code: [Select]

class AutoFixHandedness

def initialize
end

def process
return false unless @running

# the colection of GLOVES
gloves=df.world.items.other[:GLOVES]
hand=0 # which hand  0=right, 1=left
count=0
gloves.each do |glove|
# if glove is unhanded (right and left = false, fix it
unless glove.handedness[0] or glove.handedness[1]
#puts glove.id
glove.handedness[hand] = true
hand ^= 1 # switch hand for next glove
count += 1
end
end

puts "Found #{count} unhanded glove(s)." unless count == 0

end

def start
@onupdate = df.onupdate_register('autofixhandedness', 2000) { process }
@running = true
@item_next_id = 0
end

def stop
df.onupdate_unregister(@onupdate)
@running = false
end

def status
@running ? 'Running.' : 'Stopped.'
end

end

case $script_args[0]
when 'start'
    $AutoFixHandedness = AutoFixHandedness.new unless $AutoFixHandedness
    $AutoFixHandedness.start

when 'end', 'stop'
    $AutoFixHandedness.stop

else
    if $AutoFixHandedness
        puts $AutoFixHandedness.status
    else
        puts 'Not loaded.'
    end
end


new information... apparently dfhack persistent created tables are deleted when a map site is abandoned, at least my test map was doing that... I just removed the line of code and the whole thing returned to normal operation all together, as the saved counter disappeared when I abandoned the fortress.  is that as intended?  I'm going with it at the moment, and stick to this fix, unless someone has some other

I don't think that's intentional. Had you saved before abandoning? Persistent tables are still saved as histfigs, I believe, and those shouldn't normally be deleted when you abandon a fortress, as long as the world stays around.

yeah I had, and on abandon, it reset the counter when I claimed a new site on the same map.  I can try and do some more testing but It may be next week and I'll get back to you.  I've got a load of things I'm trying to accomplish between today and monday, so when I can, its back on my list.  I don't want to have to fix that set of scripts anymore...