Print

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

[bloop_bleep]

I wouldn't see why... I mean, if this isn't in some extremely hot loop, overhead from checking table size or setting up the iteration through an empty table is pretty insignificant.

[lethosor]

Exactly - I would be more concerned about optimizing the loop body, since that's presumably run more often.

[vjek]

Regarding stonesense.. Is the expectation that it's currently supposed to be working, in -r1?  Or is that a future revision goal?
I've tried a default/brand-new install of both 0.47.04 + dfhack 0.47.04-r1, and attempting to launch stonesense crashes df and dfhack.
There's a few exceptions/errors thrown, but if they're all known, I won't bother pursuing it..

last lines of stonesense.log (with [VERBOSE_LOGGING:YES]):
Reading xml stonesense\items\greiger items\Grei_items.xml...
New image: stonesense\items\greiger items\Grei_items.png

last lines of stderr.log:
Reading xml stonesense\buildings\Shop.xml...
stonesense\buildings\Shop.xml: <building

possibly relevant errors in stderr.log:(?)
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: cHRM chunk does not match sRGB
(many of each)

[Rumrusher]

wonder if it's possible to trigger an event in world gen to generate a new creature?

Since there are moments where a deity could make a new species and necromancers and demons can legit get bored enough to make a new species there should be something that tells the game to generate a new being from scratch.

[Roses]

Exactly - I would be more concerned about optimizing the loop body, since that's presumably run more often.

More just wanted to make sure that the x = y or z syntax wasn't stupidly expensive (it's not in the other languages I code in, so I didn't have a good handle on it). That being said, I should have just run a little test case (which I just did) with a million calls there was no appreciably difference in run times (when the SubTable was present the second was slightly faster, when the SubTable was not present the first was slightly faster, but within a few percent of eachother each time I ran)

[Rose]

Regarding stonesense.. Is the expectation that it's currently supposed to be working, in -r1?  Or is that a future revision goal?
I've tried a default/brand-new install of both 0.47.04 + dfhack 0.47.04-r1, and attempting to launch stonesense crashes df and dfhack.
There's a few exceptions/errors thrown, but if they're all known, I won't bother pursuing it..

last lines of stonesense.log (with [VERBOSE_LOGGING:YES]):
Reading xml stonesense\items\greiger items\Grei_items.xml...
New image: stonesense\items\greiger items\Grei_items.png

last lines of stderr.log:
Reading xml stonesense\buildings\Shop.xml...
stonesense\buildings\Shop.xml: <building

possibly relevant errors in stderr.log:(?)
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: cHRM chunk does not match sRGB
(many of each)

There's fixes made in stonesense that aren't in R1 currently.

[Bumber]

How do I get info about a tiletype in lua? The code below just gives me numbers:

Code: [Select]

tt = dfhack.maps.getTileBlock(x,y,z).tiletype[x%16][y%16]
tt_info = df.tiletype.attrs[tt]

print(tt)
print(tt_info.shape..','..tt_info.material..','..tt_info.special)
How do I use them as the enums that show up in "df-structures/df.tile-types.xml", etc.? There's matinfo for materials, but I'm not sure how to use that. (tile-material.lua seems to have some additional stuff on materials.)

Also, what's the difference between "dfhack.maps.getTileBlock(x,y,z)" and "dfhack.maps.ensureTileBlock(x,y,z)"?

[PatrikLundell]

@Bumber:

Code: [Select]

dfhack.println (df.tiletype [dfhack.maps.getTileBlock(x,y,z).tiletype[x%16][y%16]]) should print the tile type enum value. You're essentially going one step too far to try to get attributes for the enum value.

Matinfo is a pain in general, where you have to feed the mat_type and mat_index (with or without underscore depending on location in the structures) into the appropriate conversion operations (I always have to look them up in the DFHack Lua documentation) in the materials section). In the other direction you can feed strings in to get the corresponding tuple, but getting the strings right isn't trivial either (often I end up somehow getting hold of the tuple, e.g. from a stockpiled plant, and feed it into the operation that will give me the string (buried in a structure, I think), to then use the string for tuple generation in scripts (to protect against number shuffling due to changes to raws)).

[Bumber]

Code: [Select]

dfhack.println (df.tiletype [dfhack.maps.getTileBlock(x,y,z).tiletype[x%16][y%16]]) should print the tile type enum value. You're essentially going one step too far to try to get attributes for the enum value.

Thanks. I actually need the attributes, which works using "df.tiletype_shape[tt_info.shape]", etc.

[lethosor]

Regarding stonesense.. Is the expectation that it's currently supposed to be working, in -r1?  Or is that a future revision goal?
I've tried a default/brand-new install of both 0.47.04 + dfhack 0.47.04-r1, and attempting to launch stonesense crashes df and dfhack.

For reference, here is the issue. It's been around for a while, but Stonesense is large, complicated, and has few active devs (so thank you Rose for the fix!) so I didn't think it was worth holding off 0.47.04-r1 indefinitely for a fix. In retrospect, I probably should have made that more clear in the release notes. Our release notes are semi-generated now and really just focus on changes since the last release(s), not release-specific notes, but this is something we could improve.

At the same time, there is a weird and nasty bug on develop (well, hopefully just this one) that would definitely hold up an r2. Maybe we should start making smaller and more frequent "point" releases (like r1.1) with fixes like these, now that I think about it.

Exactly - I would be more concerned about optimizing the loop body, since that's presumably run more often.

More just wanted to make sure that the x = y or z syntax wasn't stupidly expensive (it's not in the other languages I code in, so I didn't have a good handle on it). That being said, I should have just run a little test case (which I just did) with a million calls there was no appreciably difference in run times (when the SubTable was present the second was slightly faster, when the SubTable was not present the first was slightly faster, but within a few percent of eachother each time I ran)

Lua does short-circuit and/or, for what it's worth, so it's about as inexpensive as it can get:

Code: [Select]

> 5 or f()
5
> nil or f()
stdin:1: attempt to call a nil value (global 'f')
stack traceback:
stdin:1: in main chunk
[C]: in ?


Also, what's the difference between "dfhack.maps.getTileBlock(x,y,z)" and "dfhack.maps.ensureTileBlock(x,y,z)"?

From docs:

dfhack.maps.ensureTileBlock(coords), or ensureTileBlock(x,y,z)

Like getTileBlock, but if the block is not allocated, try creating it.

I'd have to dig into the source here to give you a better answer: https://github.com/DFHack/dfhack/blob/f20446534bb7f39425e102bd70daec46e328004f/library/modules/Maps.cpp#L181-L223

Regarding enums, if you can navigate in gui/gm-editor to the structure containing the fields you're interested in, editing it will give you a popup containing a list of enum items as well as the enum type name.

[PatrikLundell]

I don't really see the point of point releases skipping parts of the development in normal cases (when not held up by weird bugs), as the normal case ought to be to release the current state of DFHack and DF structures. If there's extensive testing involved in releasing a new DFHack version that can largely be bypassed by a targeted point release of something deemed to be important there's a case for it, though.

[Bumber]

Regarding enums, if you can navigate in gui/gm-editor to the structure containing the fields you're interested in, editing it will give you a popup containing a list of enum items as well as the enum type name.

Can I do that with tiles? All I get is "No valid target found". I've just been using "printall" in lua to examine the fields, then doing another printall if there's another structure.

Now I've just got to figure out how to get the base material of a tile so I can determine if a construction is built in air. It shows up in probe.cpp as "mc.baseTiletypeAt(cursor)", where "mc" is a MapCache object. The "original_tile" field of a "df.global.world.constructions" entry just gives a soil layer, even in air. Edit: Never mind, it's working now. Not sure what I was doing wrong.

[ragundo]

Regarding enums, if you can navigate in gui/gm-editor to the structure containing the fields you're interested in, editing it will give you a popup containing a list of enum items as well as the enum type name.

Can I do that with tiles? All I get is "No valid target found". I've just been using "printall" in lua to examine the fields, then doing another printall if there's another structure.

Now I've just got to figure out how to get the base material of a tile so I can determine if a construction is built in air. It shows up in probe.cpp as "mc.baseTiletypeAt(cursor)", where "mc" is a MapCache object. The "original_tile" field of a "df.global.world.constructions" entry just gives a soil layer, even in air.

You can also use df::global::world.map.map_blocks vector and interate over each entry looking for the desired [x,y,z] coordinate in the map_pos field and getting the tiletypes values in the tiletype array

[lethosor]

Regarding enums, if you can navigate in gui/gm-editor to the structure containing the fields you're interested in, editing it will give you a popup containing a list of enum items as well as the enum type name.

Can I do that with tiles? All I get is "No valid target found". I've just been using "printall" in lua to examine the fields, then doing another printall if there's another structure.

You would have to pass in the expression you're looking at as an argument to gui/gm-editor ("gui/gm-editor world.something.tile"). It doesn't support selecting tiles in the GUI because there's no single "tile object" that it could display (some tile attributes are located in different structures).

[Bumber]

Thanks, everyone, for the help! Hopefully you'll be seeing the end result soon-ish.

@ragundo
Forgot about your tool. Dwarf Explorer would be a good way to do it in the future.