Topic: DFHack 50.14-r1.1 (Read 889034 times)

Roses · « **Reply #2040 on:** January 31, 2020, 12:01:52 pm »

Quote from: PatrikLundell on January 31, 2020, 11:56:25 am

The method I've used to detect if a field is present (to determine if the DF version is the current one or an older one) is to iterate over the fields with "pairs". If it's present I'll eventually get a match.

Code: [Select]
-- Backwards compatibility detection -- local river_type_updated = false if true then -- To get the temporary variable's context expire local river = df.world_river:new() for i, k in pairs (river) do if i == "flow" then river_type_updated = true break end end river:delete () end

That is my current method as well, was just wondering if there was a more efficient way, but if not thats ok, the lists usually aren't too long.

PatrikLundell · « **Reply #2041 on:** January 31, 2020, 04:47:47 pm »

It ought to be possible to use the operations that catch thrown exceptions, whatever they're called (I'm not sure I've ever used them, but I think you can find them in the Lua API document). However, iteration is good enough for my cases, and I do it only once for each mutable field.

lethosor · « **Reply #2042 on:** January 31, 2020, 06:00:33 pm »

Lua calls them errors (and they're not DFHack-specific, although DFHack adds some extra information to them). pcall (and its variants) will let you catch errors, although the API is a bit messy compared to some languages. Iterating over keys is probably fine, and you could use a per-type cache of field names if performance becomes an issue.

Fleeting Frames · « **Reply #2043 on:** January 31, 2020, 06:34:49 pm »

@Roses: iirc last time lethosor mentioned pcall is less efficient than normal call but more efficient than iterating pairs each time.

While a table of possible values would be even better, memoization would ensure only using pairs once:

Code: [Select]

function getFlag(dfvalue, key)
    -- Utility function for safely requesting info from df data
    if not dfvalue or not key then return nil end --pairs crash prevention
    flagtypetable = flagtypetable or {} --memoization so it doesn't iterate through the dfvalue if we've already checked that type of value for given flag
    if flagtypetable[dfvalue._type] and flagtypetable[dfvalue._type][key] then return dfvalue[key] end
    if flagtypetable[dfvalue._type] and flagtypetable[dfvalue._type][key]==false then return nil end
    if not flagtypetable[dfvalue._type] then flagtypetable[dfvalue._type] = {} end
    for akey, avalue in pairs(dfvalue) do
        if akey == key then
            flagtypetable[dfvalue._type][key] = true
            return dfvalue[akey]
        end
    end
    flagtypetable[dfvalue._type][key] = false
end

HungThir · « **Reply #2044 on:** January 31, 2020, 07:39:15 pm »

what key binding do people mostly use for toggling gui/gm-editor? it doesn't seem to have a default?

PatrikLundell · « **Reply #2045 on:** February 01, 2020, 04:42:46 am »

Quote from: HungThir on January 31, 2020, 07:39:15 pm

what key binding do people mostly use for toggling gui/gm-editor? it doesn't seem to have a default?

Typing "gui/gm-editor" into the console window. Most of the time I need a parameter to open the structure I want to look at anyway.

Roses · « **Reply #2046 on:** February 06, 2020, 10:18:45 am »

Question about the upcoming release since I don't remember how it worked for DF 44, new field structures won't necessarily have names that go with them right? I mean, we don't have names associated with structures from Toady, we have to figure it out, correct?

PatrikLundell · « **Reply #2047 on:** February 06, 2020, 12:13:28 pm »

Yes, fields located but not identified are typically named unk_offset, where "offset" is the offset in hex from the start of the structure (there are a lot of those that never have been identified reaching back a very long time).
As far as I understand, Toady provides some offset of some major structures, but the rest is for the community to figure out.

Abadrausar · « **Reply #2048 on:** February 06, 2020, 04:21:35 pm »

Possible bug in dfhack r3 in digfort exporting a multilevel nanofort

Code: [Select]

blueprint 47 47 30 nfort
digfort nfort-dig.csv

Faults to

Spoiler (click to show/hide)

however the csv file seems well formed (however Quickfort takes it without problem)

Spoiler (click to show/hide)

So maybe the sentinel over the y axis or dimension is incorrect

Code: [Select]

blueprint 48 48 30 nfort
digfort nfort-dig.csv

faults instead to

Spoiler (click to show/hide)

Looking at the ruby code it seems there are three problems (in my very misinformed opinion):
1-) it counts each occurrence of the semantic empty lines (in relation to designations)

Code: (nfort-dig.csv) [Select]

#dig
 , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,#

from the csv into the variable max_y when clearly it should not. (see point 3 final part)
2-) The line

Code: [Select]

if x < 0 or y < 0 or x+max_x >= map.x_count or y+max_y >= map.y_countshould be instead

Code: [Select]

if x < 0 or y < 0 or x+max_x > map.x_count or y+max_y > map.y_countbecause we could only have an problem if the dimensions of the blueprint are bigger than those of the map, never if they are the same. Even when the blueprint dimensions are bigger than those of the map; maybe a better implementation than raising an exception before any work is done would be to stamp the part of the blueprint that effectively can be fit into the map and print a warning about the number of rows and/or lines not stamped to inform the user. More work done before trapping, more debug aware and in the worst case, the user can always delete the designations if they were not what he intended.
3-) The line

Code: [Select]

max_x = x if x > max_x and not t.empty?test correctly for semantic empty cells but

Code: [Select]

max_y = y if y > max_y does not take into account the semantic empty lines that we have identified that exist (example: #dig, ...), we must remember the fact that any border of the map (in X or Y) is by definition undesignable hence semantically empty in any case with respect to designations, that is, in any map the TOP and BOTTOM lines of the map are undesignable... Hope this helps to identify the issue.

I have tried to find a solution ~~but I dont know Ruby any more than to have a general idea of what is happening~~, so any kind soul with the required Ruby expertise to catch the problem will be most welcome

Code: (digfort.rb) [Select]

# designate an area based on a '.csv' plan
=begin

digfort
=======
A script to designate an area for digging according to a plan in csv format.

This script, inspired from quickfort, can designate an area for digging.
Your plan should be stored in a .csv file like this::

    # this is a comment
    d;d;u;d;d;skip this tile;d
    d;d;d;i

Available tile shapes are named after the 'dig' menu shortcuts:
``d`` for dig, ``u`` for upstairs, ``j`` downstairs, ``i`` updown,
``h`` channel, ``r`` upward ramp, ``x`` remove designation.
Unrecognized characters are ignored (eg the 'skip this tile' in the sample).

Empty lines and data after a ``#`` are ignored as comments.
To skip a row in your design, use a single ``;``.

One comment in the file may contain the phrase ``start(3,5)``. It is interpreted
as an offset for the pattern: instead of starting at the cursor, it will start
3 tiles left and 5 tiles up from the cursor.

additionally a comment can have a < for a rise in z level and a > for drop in z.

The script takes the plan filename, starting from the root df folder (where
``Dwarf Fortress.exe`` is found).

=end

fname = $script_args[0].to_s

if not $script_args[0] then
    puts "  Usage: digfort <plan filename>"
    throw :script_finished
end
if not fname[-4..-1] == ".csv" then
    puts "  The plan file must be in .csv format."
    throw :script_finished
end
if not File.file?(fname) then
    puts "  The specified file does not exist."
    throw :script_finished
end

planfile = File.read(fname)

if df.cursor.x == -30000
    puts "place the game cursor to the top-left corner of the design and retry"
    throw :script_finished
end

offset = [0, 0]
tiles = []
max_x = 0
max_y = 0
y = 0
planfile.each_line { |l|
    if l =~ /#.*start\s*\(\s*(-?\d+)\s*[,;]\s*(-?\d+)/
        raise "Error: multiple start() comments" if offset != [0, 0]
        offset = [$1.to_i, $2.to_i]
    end
    if l.chomp == '#<'
        l = '<'
        y = 0
    end

    if l.chomp == '#>'
        l = '>'
        y = 0
    end

    l = l.chomp.sub(/#.*/, '')
    next if l == ''
    x = 0
    tiles << l.split(/[;,]/).map { |t|
        t = t.strip
        x = x + 1
        max_x = x if x > max_x and not t.empty?
        (t[0] == '"') ? t[1..-2] : t
    }
    y = y + 1
    max_y = y if y > max_y
}

x = df.cursor.x - offset[0]
y = df.cursor.y - offset[1]
z = df.cursor.z
starty = y - 1

map = df.world.map

if x < 0 or y < 0 or x+max_x >= map.x_count or y+max_y >= map.y_count
    max_x = max_x + x + 1
    max_y = max_y + y + 1
    raise "Position would designate outside map limits. Selected limits are from (#{x+1}, #{y+1}) to (#{max_x},#{max_y})"
end

tiles.each { |line|
    next if line.empty? or line == ['']
    line.each { |tile|
        if tile.empty?
            x += 1
            next
        end
        t = df.map_tile_at(x, y, z)
        s = t.shape_basic
        case tile
        when 'd'; t.dig(:Default) if s == :Wall
        when 'u'; t.dig(:UpStair) if s == :Wall
        when 'j'; t.dig(:DownStair) if s == :Wall or s == :Floor
        when 'i'; t.dig(:UpDownStair) if s == :Wall
        when 'h'; t.dig(:Channel) if s == :Wall or s == :Floor
        when 'r'; t.dig(:Ramp) if s == :Wall
        when 'x'; t.dig(:No)
        when '<'; y=starty; z += 1
        when '>'; y=starty; z -= 1
        end
        x += 1
    }
    x = df.cursor.x - offset[0]
    y += 1
}

puts '  done'

PD: I have loved the new version with all those additional content especially the possibility of embarking in the caverns or even in the circus. Hope the team keeps all these good work

vixeyrose · « **Reply #2049 on:** February 07, 2020, 11:13:05 am »

not sure if this general question should go here or somewhere else.I figured I would try here because its based off information gathered with a script. I couldn't find an understandable answer. My question is, when I use "gui/unit-info-viewer" how do i interpret the size value? examples:

Puppy 'she appears to be about 1199:725 cubic decimeters in size

giant crab 'she appears to be about 545:988 cubic decimeters in size

and how does these numbers coincide with the size page on the wiki?

lethosor · « **Reply #2050 on:** February 08, 2020, 07:51:44 pm »

Quote from: vixeyrose on February 07, 2020, 11:13:05 am

not sure if this general question should go here or somewhere else.I figured I would try here because its based off information gathered with a script. I couldn't find an understandable answer. My question is, when I use "gui/unit-info-viewer" how do i interpret the size value? examples:

Puppy 'she appears to be about 1199:725 cubic decimeters in size

giant crab 'she appears to be about 545:988 cubic decimeters in size

and how does these numbers coincide with the size page on the wiki?

I looked at the code here - looks like the first number is related to strength and the second is related to agility. I'm not sure how this is related to size at all. Unfortunately, this dates back to the original version of the script added here, so it's difficult to say where this originated from. I personally think they're unrelated to size, though.

Quote from: Abadrausar on February 06, 2020, 04:21:35 pm

Possible bug in dfhack r3 in digfort exporting a multilevel nanofort

Curious, have you tried the version from 0.44.12-r2? digfort did change a bit between the two versions (to fix a similar issue) and I'm wondering if the fix broke your case.

Quote

2-) The line
Code: [Select]
if x < 0 or y < 0 or x+max_x >= map.x_count or y+max_y >= map.y_countshould be instead
Code: [Select]
if x < 0 or y < 0 or x+max_x > map.x_count or y+max_y > map.y_countbecause we could only have an problem if the dimensions of the blueprint are bigger than those of the map, never if they are the same.

I'm pretty sure the code as-is is correct - most things in DF, including the map, are 0-indexed, so while x_count is the number of things in the X dimension, the valid things range only from 0 to X-1.

Quote

3-) The line
Code: [Select]
max_x = x if x > max_x and not t.empty?test correctly for semantic empty cells but
Code: [Select]
max_y = y if y > max_y does not take into account the semantic empty lines that we have identified that exist (example: #dig, ...), we must remember the fact that any border of the map (in X or Y) is by definition undesignable hence semantically empty in any case with respect to designations, that is, in any map the TOP and BOTTOM lines of the map are undesignable... Hope this helps to identify the issue.

This does sound like it could be an issue to me. Does your fixed script work properly for you? (I wasn't sure if you meant your version didn't work at all, or if you weren't sure that it always worked.)

CyberianK · « **Reply #2051 on:** February 09, 2020, 06:19:09 am »

is there any way to revert remove-stress command?

So set stress to 0 again or so?

also revflood does not work with constructed walls right? did not work here for me:

edit: I used tiletypes painting and revflood after to hack the wall dont like different colors

feelotraveller · « **Reply #2052 on:** February 09, 2020, 02:34:36 pm »

Interesting, didn't know that. Can't comment about the intentions or logic of revflood.

A slightly labourious way to hide those tiles is to use the 'hidden' flag in tiletypes, from within tiletypes

Code: [Select]

paint hidden 1

Then run over each tile or brush area you want to hide. It can be combined with other commands if you want. paint hidden 0 should be the reverse (reveal) tile command from memory.

Flying Teasets · « **Reply #2053 on:** February 09, 2020, 04:53:20 pm »

Bumber · « **Reply #2054 on:** February 09, 2020, 08:26:37 pm »

I'm pretty sure revflood worked on constructions in past versions.

News:

Author Topic: DFHack 50.14-r1.1 (Read 889034 times)

Roses

Re: DFHack 0.44.12-r3

PatrikLundell

Re: DFHack 0.44.12-r3

lethosor

Re: DFHack 0.44.12-r3

Fleeting Frames

Re: DFHack 0.44.12-r3

HungThir

Re: DFHack 0.44.12-r3

PatrikLundell

Re: DFHack 0.44.12-r3

Roses

Re: DFHack 0.44.12-r3

PatrikLundell

Re: DFHack 0.44.12-r3

Abadrausar

Re: DFHack 0.44.12-r3

vixeyrose

Re: DFHack 0.44.12-r3

lethosor

Re: DFHack 0.44.12-r3

CyberianK

Re: DFHack 0.44.12-r3

feelotraveller

Re: DFHack 0.44.12-r3

Flying Teasets

Re: DFHack 0.44.12-r3

Bumber

Re: DFHack 0.44.12-r3