Print

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

[PatrikLundell]

Hello all.
I've made a script, which will locate historical figures, and I want to hear whatever there is any interest in having it added to DFHack.
[snip]

Well if nobody's commenting on this I'd at least like to mention that I'd like a copy of that script if you have it available somewhere

Sulter provided it here: http://www.bay12forums.com/smf/index.php?topic=175307.0

[darkhog]

Could you add an option of "just save" to ESC menu that would save the game, but then return to the fort/adventure (i.e. saving without quitting)?

[Bumber]

Could you add an option of "just save" to ESC menu that would save the game, but then return to the fort/adventure (i.e. saving without quitting)?

The default dfhack.init lets you quicksave with Alt+Ctrl+S.

[PatrikLundell]

Could you add an option of "just save" to ESC menu that would save the game, but then return to the fort/adventure (i.e. saving without quitting)?

The default dfhack.init lets you quicksave with Alt+Ctrl+S.

And you can type "quicksave" into the DFHack console as well.

Something completely different: I've failed to find where DF stores info about what growths each plant sports (leaves, fruit, etc.). The plant_raw contains info of what it CAN have (and when), but shrubs without usable structure parts can have their growths picked while leaving the structure part behind (e.g. bitter melon vines left behind when gathering the leaves and the melons), and fruit pickers climb ladders to pick fruit from different parts of trees, so the info obviously resides somewhere. The logical place (at least according to my logic) would be a reference in the plant structure (the one in the vector that's used to hold info of every plant on the map), but it has no specific info on shrubs, and only generic info for trees (branches, twigs, roots). Can someone point me in the right direction, or hasn't that info been mapped yet?

[therahedwig]

It should be mapped, I distinctly recall making graphics for stonesense that rely on SS knowing where the growths are in DF, but I can't tell you where that would be...

[Roses]

Could you add an option of "just save" to ESC menu that would save the game, but then return to the fort/adventure (i.e. saving without quitting)?

The default dfhack.init lets you quicksave with Alt+Ctrl+S.

And you can type "quicksave" into the DFHack console as well.

Something completely different: I've failed to find where DF stores info about what growths each plant sports (leaves, fruit, etc.). The plant_raw contains info of what it CAN have (and when), but shrubs without usable structure parts can have their growths picked while leaving the structure part behind (e.g. bitter melon vines left behind when gathering the leaves and the melons), and fruit pickers climb ladders to pick fruit from different parts of trees, so the info obviously resides somewhere. The logical place (at least according to my logic) would be a reference in the plant structure (the one in the vector that's used to hold info of every plant on the map), but it has no specific info on shrubs, and only generic info for trees (branches, twigs, roots). Can someone point me in the right direction, or hasn't that info been mapped yet?

IIRC there is the df.global.world.plants.all table (which I believe is what you are referencing in your post) and then there are further details in the map block and columns. I'm not sure if the information you want is there, but it could be

[PatrikLundell]

Thanks to therahedwig and Roses for the answers.

Regarding growths: Unless I'm blind (which cannot be ruled out) it's not in df.global.world.plants.all (which is what I referred to), and I've failed to find anything useful in the map blocks or columns. The closest thing is a list of references to plants present in the block, but that's just the same type as in the vector (and, I assume, are the same objects as those in the vector). There's also a vector of items on those tiles, but growths don't become items until they've been collected (I counted the number of bitter lemons in the item list [10] with a script, and that matched the number on the stocks screen, but that's far less than the 50-60 plants designated for gathering).

I tried to take a quick look at Stonesense (searching for "growth"), and it looks to me that growths are added based on whether the plant_raw data shows that the time is right for the growths, rather than whether the growths are actually there (I guess users of Stonesense could confirm whether a tree stripped of fruit looks different from a neighbor that hasn't been designated for fruit gathering). The Stonesense code also uses the data that specifies where growths should appear (trunk, branch, etc.), from the plant_raws, coupled with the generic tree info in the plant vector object that specifies where branches, etc. of each tree are located, so if there's a branch there and the tree species has a growth that grows on branches and the time is right growth tile processing is performed.

[lethosor]

It has been far too long, but we finally have a new release up for 0.44.12!
https://github.com/DFHack/dfhack/releases/tag/0.44.12-r3

Thanks to everyone who helped out with this, including the 12 (!) new contributors.

Looking at Toady's recent posts about a new DF release coming soon, this will probably be the last release for 0.44.12, and the last stable release for a while.

[Roses]

It has been far too long, but we finally have a new release up for 0.44.12!
https://github.com/DFHack/dfhack/releases/tag/0.44.12-r3

Thanks to everyone who helped out with this, including the 12 (!) new contributors.

Looking at Toady's recent posts about a new DF release coming soon, this will probably be the last release for 0.44.12, and the last stable release for a while.

Oooh boy... questions time!

1. I am digging the assign-X scripts, I have something very similar in my set of scripts, but I would obviously prefer to use the ones in the default package. My only question is speed. Is there much (if any) overhead in calling one of the assign-X scripts using the dfhack.script_environment() system?

2. Could we get some information on the new Persistence module and how it works? I switched from using the persistent tables to a global table that gets saved to a JSON file whenever the game saves and loads from the JSON file whenever the game loads (I was doing a lot with them and it was faster to go through global tables than the old persistent tables). It seems like the new system is using JSON files, but I am just wondering how it all works.

3. I'll probably have a bunch of questions about the persistence stuff, are there any scripts currently included in the package that use the new system (or is it the same syntax as the old one, with ._children and such)?

[lethosor]

1. I am digging the assign-X scripts, I have something very similar in my set of scripts, but I would obviously prefer to use the ones in the default package. My only question is speed. Is there much (if any) overhead in calling one of the assign-X scripts using the dfhack.script_environment() system?

Nope, it's actually the same system that running Lua scripts uses under the hood. I'd recommend reqscript() instead because it does some extra safety checks (and it's shorter) but either should work. As long as you only import the script once (i.e. not every time you call a function), it shouldn't be noticeable.

2. Could we get some information on the new Persistence module and how it works? I switched from using the persistent tables to a global table that gets saved to a JSON file whenever the game saves and loads from the JSON file whenever the game loads (I was doing a lot with them and it was faster to go through global tables than the old persistent tables). It seems like the new system is using JSON files, but I am just wondering how it all works.

3. I'll probably have a bunch of questions about the persistence stuff, are there any scripts currently included in the package that use the new system (or is it the same syntax as the old one, with ._children and such)?

From Lua it shouldn't be any different. It'll be stored differently under the hood, though. C++ plugins have access to a bit of extra stuff, but I expect persist-table and whatever else is available to Lua to continue to work normally. The functions in the World module are now just wrappers around the Persistence module.

[9joseph9]

I've got trouble trying to use the set-orientation command. If anybody could help, I'd be real grateful.
 Here's the error log
Invoking: set-orientation view
C:\Users\Me\Downloads\df_44_12_win\hack\lua\utils.lua:610: error parsing arg 1: view
stack traceback:
   [C]: in function 'error'
   C:\Users\Me\Downloads\df_44_12_win\hack\lua\utils.lua:610: in function 'utils.processArgs'
   ...\Downloads\df_44_12_win/hack/scripts/set-orientation.lua:189: in global 'main'
   ...\Downloads\df_44_12_win/hack/scripts/set-orientation.lua:265: in local 'script_code'
   C:\Users\Me\Downloads\df_44_12_win\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
   (...tail calls...)

[Atkana]

I've got trouble trying to use the set-orientation command. If anybody could help, I'd be real grateful.
 Here's the error log
Invoking: set-orientation view
C:\Users\Me\Downloads\df_44_12_win\hack\lua\utils.lua:610: error parsing arg 1: view
stack traceback:
   [C]: in function 'error'
   C:\Users\Me\Downloads\df_44_12_win\hack\lua\utils.lua:610: in function 'utils.processArgs'
   ...\Downloads\df_44_12_win/hack/scripts/set-orientation.lua:189: in global 'main'
   ...\Downloads\df_44_12_win/hack/scripts/set-orientation.lua:265: in local 'script_code'
   C:\Users\Me\Downloads\df_44_12_win\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
   (...tail calls...)

Make sure to begin the arguments with a -, so in this example set-orientation -view. I don't think I mentioned the necessity for doing that in any of the scripts I added, and this is one where I neglected to include an example usage so that's understandable. It's kinda the standard formatting for dfhack script arguments, but I don't know how many scripts actually use it over their own methods :b

[9joseph9]

I've got trouble trying to use the set-orientation command. If anybody could help, I'd be real grateful.
 Here's the error log
Invoking: set-orientation view
C:\Users\Me\Downloads\df_44_12_win\hack\lua\utils.lua:610: error parsing arg 1: view
stack traceback:
   [C]: in function 'error'
   C:\Users\Me\Downloads\df_44_12_win\hack\lua\utils.lua:610: in function 'utils.processArgs'
   ...\Downloads\df_44_12_win/hack/scripts/set-orientation.lua:189: in global 'main'
   ...\Downloads\df_44_12_win/hack/scripts/set-orientation.lua:265: in local 'script_code'
   C:\Users\Me\Downloads\df_44_12_win\hack\lua\dfhack.lua:680: in function 'dfhack.run_script_with_env'
   (...tail calls...)

Make sure to begin the arguments with a -, so in this example set-orientation -view. I don't think I mentioned the necessity for doing that in any of the scripts I added, and this is one where I neglected to include an example usage so that's understandable. It's kinda the standard formatting for dfhack script arguments, but I don't know how many scripts actually use it over their own methods :b

It worked! Thanks a ton, man. I'm not verse in DFHack so alot of common sense stuff escapes me. If you have anything you'd like to have drawn, I'd be more than happy to make you one as my thanks.

[PeridexisErrant]

The stockpile files I've created since my last post are industry based rather than workshop based, ...

LNP authors would probably also be willing to include them if you reached out (most of those threads are in the DF General Discussion forum).

Can confirm, I'd be happy to ship these 

[Roses]

Couple questions;

1. Does the defclass() support overloading operators? I know with "normal" metatables you can put functions for things like __add, __eq, etc... Just making sure that I can still do that.

2. I'm trying to decide how to organize my scripts and functions collection and am wondering what some of my options might be. Currently I am adding expanding on some of the current df-structures objects by using classes. As an example, I have a UNIT class which adds functions like UNIT:makeProjectile(vx,vy,vz) which turns the unit into a projectile. Now for the question, my current thoughts for organization are 1) Putting the defclass and all the functions associated with that class in their own file, or 2) put the defclass for each of the different classes in a single file with descriptions of each class, and then put the functions for the class in a seperate file, 3) group classes and functions into categories and create files for each category. Is there a "best" way to handle this in terms of performance (I'm guessing #3)? If they are all roughly equal I was thinking of using #2 because it would be the easiest to read and create help files for. Is there another way that I'm not thinking of?

3. I noticed in some of the scripts in the repository there is the line

Code: [Select]

if not dfhack_flags.module then
    main(...)
endJust wanted to make sure I understand this, if a script gets called from the command line or with run_script/run_command it will call main, if it gets access with reqscript() it will not call main, correct?