Print

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

[lethosor]

Lethosor:   "Maybe its just a small cache of those first 10 rels." - It *cannot* be longer than it is currently, ...

Ok, thats something. We all still seem to be in the situation that *no one here knows* where to find units friends, friendly terms, aquaintances... And whatever info is in figure.info.relationships.links is unkeyed.

Im just putting that info as I find it, here, for others to notice, or duckduckgo later.

Lethosor: a crash (except when saving the game) will not permanently affect your save.

I wouldnt have expected it to because I noticed task-killing a game is usually fine, but I have bugged dozens of game saves, with silly division by zero, infinite loops or null pointer crashes occuring while in manipulator (while not doing any saving). I dont know the mechanism but a hard crash while in manipulator, on linux, can kill a save, and the process I described can repair it (not necessary to actually export the levels, just scan through them - maybe even just open and close the feature).

figure.info.relationships.links might be it, although I'm seeing garbage for year_tick (0xaaaaaaaa, which means it's uninitialized in my setup), so that structure might be off a bit.

I can guarantee that you did not corrupt your save by doing anything in manipulator. If it crashes, any modifications you made to the save are gone. Back before there was a data/save/current folder (around 23a), crashes and killing DF could corrupt saves, because everything was written to the region folder, but that's no longer the case. If you saved files yourself, though (like custom profession files), those might be corrupted somehow. Anyway, you're probably just getting lucky with the map-export feature. I can't think of a way it would affect anything else, but bugs due to undefined behavior can be affected by doing unrelated things sometimes, if you get lucky.

Just to clarify, what exactly is wrong with these "bugged saves" you have? Do they crash at some point soon after loading, or do they exhibit some other bug(s)? Particularly if it's the former, I'd like to take a look at one of these saves.

[Putnam]

Can you write me a script that teleports you in adv mode to the cursor with "l"? It would make navigating laggy areas more bearable.

Write one for you, personally?

Absolutely not.

Already have one?

Probably.

Code: (flashstep.lua) [Select]

--Teleports unit to cursor
--[====[

flashstep
=========
A hotkey-friendly teleport that places you where your cursor is.

]====]
function flashstep(flash,step)
    local flash = df.global.world.units.active[0]
    local step
        if df.global.ui_advmode.menu == df.ui_advmode_menu.Look then
            step = df.global.cursor
        else
            qerror("No [l] cursor located! You kinda need it for this script.")
        end
    local unitoccupancy = dfhack.maps.getTileBlock(flash.pos).occupancy[flash.pos.x%16][flash.pos.y%16]
        flash.pos.x = step.x
        flash.pos.y = step.y
        flash.pos.z = step.z
            if flash.pos.x==step.x then
            local stepvisibility = dfhack.maps.getTileBlock(flash.pos).designation[flash.pos.x%16][flash.pos.y%16]
                stepvisibility.hidden=false
            end
    if not flash.flags1.on_ground then unitoccupancy.unit = false else unitoccupancy.unit_grounded = false end
end
flashstep(flash,step)


you could also use dfhack's teleport script both to get your adventurer's ID and to teleport your adventurer that way

[lethosor]

you could also use dfhack's teleport script both to get your adventurer's ID and to teleport your adventurer that way

I think the "more bearable" part implied that the teleport script was annoying to use (which is fair - gui/teleport is nicer, in my opinion, but only works in fortress mode).

[strainer]

Lethosor:

>Just to clarify, what exactly is wrong with these "bugged saves" you have?

I do find them strange, I can make them easily, just put a div by zero or something in manipulator, open it, df crashes, fix manipulator, next time I open the save it can crash seconds after loading, even while paused, or run for a few seconds unpaused before crashing, it wont save again. I would kick myself if it was a good game and then found through trial that 'export' proceedure can straighten it out somehow enough so it saves, and then runs again. I dont expect its very interesting, maybe just some out of sync temp file or something, but I can make one and zip it up this week if you're curious.

[Max™]

you could also use dfhack's teleport script both to get your adventurer's ID and to teleport your adventurer that way

I think the "more bearable" part implied that the teleport script was annoying to use (which is fair - gui/teleport is nicer, in my opinion, but only works in fortress mode).

Yeah, in adventurer mode there is no reason to have a script which needs to be aimed but doesn't use the cursor. I can move myself around with gui/gm-editor easily enough too, or I can hit a keybind and poof over to where my cursor is currently.

[PatrikLundell]

I still don't understand what strainer is looking for, but it sounds like something along the lines of this:

Spoiler (click to show/hide)

Code: [Select]

:
:
function friend_lt (f1, f2)
  if #f1.anon_3 < #f2.anon_3 then
    return true
 
  elseif #f1.anon_3 > #f2.anon_3 then
    return false
  end
 
  if #f1.anon_3 == 2 then
    if f1.anon_5 < f2.anon_5 then
      return true
     
    elseif f1.anon_5 > f2.anon_5 then
      return false
    end
   
    return f1.anon_4 [0] < f2.anon_4 [0]
   
  elseif #f1.anon_3 == 1 then
    if f1.anon_5 < f2.anon_5 then
      return true
     
    elseif f1.anon_5 > f2.anon_5 then
      return false
    end
   
    return f1.anon_4 [0] < f2.anon_4 [0]
   
  elseif #f1.anon_3 == 0 then
    return f1.anon_5 < f2.anon_5
  end
 
  return false
end
 
------------------------------------------

:
:
    --  Personality with syndrome deviations, distractions, and stuff
     
    dfhack.color (COLOR_LIGHTGREY)
    if hf.info.relationships ~= nil then
      for k, relation in ipairs (hf.info.relationships.list) do
        --### Ought to filter out parents from this list, as they sometimes appear here.
        --### Ought to filter out any spouse as well.
        table.insert (friends, relation)
      end
     
      for k = 1, #friends - 1 do
        for l = k + 1, #friends do
          if friend_lt (friends [k], friends [l]) then
            temp = friends [k]
            friends [k] = friends [l]
            friends [l] = temp
          end
        end
      end     
     
      for k, relation in ipairs (friends) do
         if #relation.anon_3 == 3 then
          dfhack.print ("Spouse ")  --###  Is this the correct definition? They only appear here sometimes...
                                    --###  Would be logical if this was "Lover" instead.
        elseif #relation.anon_3 == 2 then
          dfhack.print ("Friend ")
         
        elseif #relation.anon_3 == 1 then
          if relation.anon_3 [0] == 3 then
            dfhack.print ("Bonded ")  --### Stray X (Training level)
          else
            dfhack.print ("Friendly Terms ")
          end
         
        else
          dfhack.print ("Passing Acquaintance ")
        end
       
        if #relation.anon_4 == 1 then
          temp = relation.anon_4 [0]
        else
          temp = 0
        end
       
        dfhack.println (get_hf_name (relation.histfig_id), relation.anon_1, #relation.anon_2, #relation.anon_3, temp, relation.anon_5)
      end
    end
  end
:
:


The snipped of a (unfinished) script gets reasonably close to what's shown on the relations screen, but doesn't get it correct all the time, and it also lists relations suppressed from that screen (but obviously present in df). I assume strainer is actually looking for something else, though.

[lethosor]

Yeah, no idea what's going on there. What files are you overwriting when you reinstall DFHack? It could be some sort of configuration thing. I'd expect that to be related to data/init/init.txt, though, which DFHack doesn't include.

[Rose]

If you right click in the dfhack window to select something during bootup, that can prevent the game from starting till you right click again.

[Isher]

When you build the source of DFHack, is that when the header files in  dfhack>library>include>df are created? Or do I get those from somewhere else?

[lethosor]

When you build the source of DFHack, is that when the header files in  dfhack>library>include>df are created?

Yes. Specifically, it's the "generate_headers" target, or the one that generates codegen.out.xml.

[Rose]

Note that this is why dfhack relies on perl.

[strainer]

"the header files in  dfhack/library/include/df are created ..."

Heh, I spent quite a while puzzled why I couldnt grep any header info, as I was writing and compiling on different machines.

PatrikLundell wrote:
"I still don't understand what strainer is looking for"

I was looking for where units deities are stored, which I found in figure.histfig_links. Im also interested in decoding all of the other unit relationships which is what I was refering to by "such info". Ive discussed the relationship info found in unit.relationship_ids and figure.histfig_links and figure.entity_links and the anon elements in figure.info.relationships.

Your code snippet is very intresting thanks, it looks like you have decoded some of anon figure.info.relationships. Ill try to use it (in the short term to make a rough count of units friends to complete a compact unit summary)

[PatrikLundell]

@strainer: Just be aware that the snippet is by no means the truth. It gets somewhat close to replicating what DF displays, but that's about it, but it might serve as a starting point. I think Fleeting Frames did a similar type of calculation using a different formula recently, but I haven't done any comparisons. I don't quite remember the context, but it might be regarding enhancements to Dwarf Manipulator info.

[strainer]

Great! Fleeting Frames has mostly decyphered the figure.info.relationships thing in relations-indicator.lua --lots of good comments too.

Thread: relations-indicator.lua

Thanks again Patrik.

... Im noticing that there is a manipulator.lua underway which my extension of manipulator.cpp ignores. Apologies for that Ive got too far into it before noticing to switch. Maybe they can compliment each other.

[lethosor]

I still don't understand what strainer is looking for, but it sounds like something along the lines of this:

Spoiler (click to show/hide)

Code: [Select]

:
:
function friend_lt (f1, f2)
  if #f1.anon_3 < #f2.anon_3 then
    return true
 
  elseif #f1.anon_3 > #f2.anon_3 then
    return false
  end
 
  if #f1.anon_3 == 2 then
    if f1.anon_5 < f2.anon_5 then
      return true
     
    elseif f1.anon_5 > f2.anon_5 then
      return false
    end
   
    return f1.anon_4 [0] < f2.anon_4 [0]
   
  elseif #f1.anon_3 == 1 then
    if f1.anon_5 < f2.anon_5 then
      return true
     
    elseif f1.anon_5 > f2.anon_5 then
      return false
    end
   
    return f1.anon_4 [0] < f2.anon_4 [0]
   
  elseif #f1.anon_3 == 0 then
    return f1.anon_5 < f2.anon_5
  end
 
  return false
end
 
------------------------------------------

:
:
    --  Personality with syndrome deviations, distractions, and stuff
     
    dfhack.color (COLOR_LIGHTGREY)
    if hf.info.relationships ~= nil then
      for k, relation in ipairs (hf.info.relationships.list) do
        --### Ought to filter out parents from this list, as they sometimes appear here.
        --### Ought to filter out any spouse as well.
        table.insert (friends, relation)
      end
     
      for k = 1, #friends - 1 do
        for l = k + 1, #friends do
          if friend_lt (friends [k], friends [l]) then
            temp = friends [k]
            friends [k] = friends [l]
            friends [l] = temp
          end
        end
      end     
     
      for k, relation in ipairs (friends) do
         if #relation.anon_3 == 3 then
          dfhack.print ("Spouse ")  --###  Is this the correct definition? They only appear here sometimes...
                                    --###  Would be logical if this was "Lover" instead.
        elseif #relation.anon_3 == 2 then
          dfhack.print ("Friend ")
         
        elseif #relation.anon_3 == 1 then
          if relation.anon_3 [0] == 3 then
            dfhack.print ("Bonded ")  --### Stray X (Training level)
          else
            dfhack.print ("Friendly Terms ")
          end
         
        else
          dfhack.print ("Passing Acquaintance ")
        end
       
        if #relation.anon_4 == 1 then
          temp = relation.anon_4 [0]
        else
          temp = 0
        end
       
        dfhack.println (get_hf_name (relation.histfig_id), relation.anon_1, #relation.anon_2, #relation.anon_3, temp, relation.anon_5)
      end
    end
  end
:
:


The snipped of a (unfinished) script gets reasonably close to what's shown on the relations screen, but doesn't get it correct all the time, and it also lists relations suppressed from that screen (but obviously present in df). I assume strainer is actually looking for something else, though.

Can you explain what the fields you used are? anon_3 appears to be some kind of weight, and anon_1 is some sort of ID, I think, but it's hard to tell at a glance. If you can make a PR at https://github.com/dfhack/df-structures, that would be even better. anon names are unreliable and generally shouldn't be used except for experimentation.