Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 123 124 [125] 126 127 ... 129

Author Topic: DFHack 0.44.12-r2  (Read 206254 times)

lethosor

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r2
« Reply #1860 on: September 19, 2019, 04:04:27 pm »

Yes, see http://www.bay12forums.com/smf/index.php?topic=126076.msg8025916#msg8025916. I might have time to look at it, but it sounds like DFHack was bundled in that pack incorrectly, which is not something we can fix ourselves.
Logged
DFHack - Dwarf Manipulator (Lua) - DF Wiki talk

There was a typo in the siegers' campfire code. When the fires went out, so did the game.

Roses

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r2
« Reply #1861 on: September 24, 2019, 09:38:27 am »

Is anyone doing any work on the persist-table module (allowing numbers to be stored instead of just strings, changing how it works, etc...)? I am working on completely re-writing my stuff and it heavily uses the persistent stuff, just wanted to make sure any work I do isn't going to be invalidated or pointless based on someone elses work
Logged

Fleeting Frames

  • Bay Watcher
  • Spooky cart at distance
    • View Profile
Re: DFHack 0.44.12-r2
« Reply #1862 on: September 24, 2019, 10:18:03 am »

Not on that as such, no.

Though maybe worth consideration when doing this: When I looked sharing things with dwarfmonitor off df. (as dm doesn't have persistent storage module loaded), I found I could use positions listed in df.global.ui.main.fortress_entity.positions.own, which might provide roughly 16 strings, numbers and unknown number of booleans. i.e. I could have dwarfmonitor pull data from there, alter the data from lua console, and have the results reflected in dwarmonitor's display.

(I haven't actually written anything for that yet, leaving it off for when I do need it and only implementing "simpler" widgets for now.)

I recall putnam mentioned too intense usage of persist-table can drag the game down; if that's down to the size of historical unit vector this could perhaps help streamline it a little bit.

Roses

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r2
« Reply #1863 on: September 24, 2019, 10:44:05 am »

Not on that as such, no.

Though maybe worth consideration when doing this: When I looked sharing things with dwarfmonitor off df. (as dm doesn't have persistent storage module loaded), I found I could use positions listed in df.global.ui.main.fortress_entity.positions.own, which might provide roughly 16 strings, numbers and unknown number of booleans. i.e. I could have dwarfmonitor pull data from there, alter the data from lua console, and have the results reflected in dwarmonitor's display.

(I haven't actually written anything for that yet, leaving it off for when I do need it and only implementing "simpler" widgets for now.)

I recall putnam mentioned too intense usage of persist-table can drag the game down; if that's down to the size of historical unit vector this could perhaps help streamline it a little bit.

Yes, I know my previous attempts at using persistent table storage had a notable impact because I was constantly saving to and loading from it. I've since been experimenting with using global variables during game play and only using the persistent storage on game load/save. Also experimenting with using json files in a similar manner, but allowing for more complex data types. That way you aren't storing a lot of information in the historical unit vectore
Logged

lethosor

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r2
« Reply #1864 on: September 24, 2019, 05:29:54 pm »

Worth noting that https://github.com/DFHack/dfhack/pull/1402 was merged and will be in the next release - specifically, it changes the underlying persistent storage API from using histfigs to using global structures that get saved/loaded to/from JSON files as needed, much like you mentioned.
However, both the new and previous implementations should be relatively fast, since all changes are made in memory. Any slowness you're observing with persist-table is likely due to issues specific to persist-table (my understanding is that it has to do some weird and slow things to store tables across multiple histfigs) or due to you making a LOT of writes (which the new JSON-based implementation wouldn't address either). Granted, with the new API from that PR, persist-table could be made a lot faster, if I'm right about why it's slow right now, but migrating old data would take a decent amount of effort and I haven't really looked into it.
Logged
DFHack - Dwarf Manipulator (Lua) - DF Wiki talk

There was a typo in the siegers' campfire code. When the fires went out, so did the game.

Roses

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r2
« Reply #1865 on: September 27, 2019, 10:04:21 am »

Worth noting that https://github.com/DFHack/dfhack/pull/1402 was merged and will be in the next release - specifically, it changes the underlying persistent storage API from using histfigs to using global structures that get saved/loaded to/from JSON files as needed, much like you mentioned.
However, both the new and previous implementations should be relatively fast, since all changes are made in memory. Any slowness you're observing with persist-table is likely due to issues specific to persist-table (my understanding is that it has to do some weird and slow things to store tables across multiple histfigs) or due to you making a LOT of writes (which the new JSON-based implementation wouldn't address either). Granted, with the new API from that PR, persist-table could be made a lot faster, if I'm right about why it's slow right now, but migrating old data would take a decent amount of effort and I haven't really looked into it.

Interesting. For now I will stick with my json work around that just stores everything in global arrays and then writes it out every so often to the data/save/current directory. I'll check out the new API in the next release and see if I can tie it in to what I am doing.

A new question though, I have been using lua for a different project and have gotten more comfortable with some of the more advanced features that I have completely ignored for my dfhack work. My question is, is there a preferred method for dfhack scripts for class constructions (e.g. table-based vs closure-based)? I've noticed most scripts seem to use the table-based method but have been trying to decide which one to use. They each have their advantages/disadvantages, but if one is more preferred for this then I'll gladly just use that.
Logged

Warmist

  • Bay Watcher
  • Master of unfinished jobs
    • View Profile
Re: DFHack 0.44.12-r2
« Reply #1866 on: September 27, 2019, 12:07:42 pm »

Worth noting that https://github.com/DFHack/dfhack/pull/1402 was merged and will be in the next release - specifically, it changes the underlying persistent storage API from using histfigs to using global structures that get saved/loaded to/from JSON files as needed, much like you mentioned.
However, both the new and previous implementations should be relatively fast, since all changes are made in memory. Any slowness you're observing with persist-table is likely due to issues specific to persist-table (my understanding is that it has to do some weird and slow things to store tables across multiple histfigs) or due to you making a LOT of writes (which the new JSON-based implementation wouldn't address either). Granted, with the new API from that PR, persist-table could be made a lot faster, if I'm right about why it's slow right now, but migrating old data would take a decent amount of effort and I haven't really looked into it.

Interesting. For now I will stick with my json work around that just stores everything in global arrays and then writes it out every so often to the data/save/current directory. I'll check out the new API in the next release and see if I can tie it in to what I am doing.

A new question though, I have been using lua for a different project and have gotten more comfortable with some of the more advanced features that I have completely ignored for my dfhack work. My question is, is there a preferred method for dfhack scripts for class constructions (e.g. table-based vs closure-based)? I've noticed most scripts seem to use the table-based method but have been trying to decide which one to use. They each have their advantages/disadvantages, but if one is more preferred for this then I'll gladly just use that.
I'm not sure what you mean by closure based. There is only one class implementation in dfhack (i.e. defclass) and it uses table based single inheritance model.

Roses

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r2
« Reply #1867 on: September 28, 2019, 11:38:43 am »

I'm not sure what you mean by closure based. There is only one class implementation in dfhack (i.e. defclass) and it uses table based single inheritance model.

Closure based just uses a closed function to store the class so that you can generate both public and private variables and functions. It is generally slightly faster as everything is just an upvalue instead of needed to go through an __index search, but it is also more memory intensive as it creates a hash for each function for each instance of the class you create. Since dfhack has defclass which uses a single inheritance table based model I will just stick with that since I don't think the speed advantage of the closure approach is that big of an impact (the only reason I was thinking about using the closure approach is because I like it better asthetically)
Logged

DerMeister

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r2
« Reply #1868 on: September 30, 2019, 11:48:30 pm »

I request script or plugin that will make sapients (example, ogress) milkable. This script will temporary add syndrome of removing can_learn (and slow_learner, and intelligent) for milkable creature. After creature milking, syndrome will removed.
Logged

Silverwing235

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r2
« Reply #1869 on: October 01, 2019, 11:19:49 am »

Requesting/suggesting an adjustment to exportlegends commands: that they look in DF root for a folder called 'legends'. If not found, then they go through the ISO standard user dialogue of "legends does not exist. Would you like to create it (Y/N)?" 'cause I'm rather fed up with, say, exportlegends info dumping to root like it does, and mess-making as a result. 
« Last Edit: October 01, 2019, 02:22:05 pm by Silverwing235 »
Logged

DerMeister

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r2
« Reply #1870 on: October 01, 2019, 06:13:04 pm »

Also I request plugin thet make corpses of sapients unsapient if you play as civ with goblinish etics.
Logged

lethosor

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r2
« Reply #1871 on: October 01, 2019, 06:30:03 pm »

Requesting/suggesting an adjustment to exportlegends commands: that they look in DF root for a folder called 'legends'. If not found, then they go through the ISO standard user dialogue of "legends does not exist. Would you like to create it (Y/N)?" 'cause I'm rather fed up with, say, exportlegends info dumping to root like it does, and mess-making as a result.
Some of the files that get dumped into the main DF folder are put there by vanilla DF's legends exporter - it's not something that DFHack controls. Having exportlegends move those afterwards is probably doable, though, and has been suggested before.
Logged
DFHack - Dwarf Manipulator (Lua) - DF Wiki talk

There was a typo in the siegers' campfire code. When the fires went out, so did the game.

Fleeting Frames

  • Bay Watcher
  • Spooky cart at distance
    • View Profile
Re: DFHack 0.44.12-r2
« Reply #1872 on: October 02, 2019, 02:05:53 am »

So, while writing a script that, amongst other things, would allow to limit allowed workers on farmplots and stockpiles via job cooldowns looked at dfhack.job.setJobCooldown - specifically, the part where it will not decrement current cooldown or set it below zero. The initial commit five and half years ago didn't mention why, but does anybody here still know why the limit?

(The -1 setting seems particularly useful for "Never", as it would take over five hundred thousand years to overflow.)

PS: Also, the documentation should probably mention the timeout should is/should be in hundreds of ticks.

Silverwing235

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r2
« Reply #1873 on: October 02, 2019, 01:46:57 pm »

Some of the files that get dumped into the main DF folder are put there by vanilla DF's legends exporter - it's not something that DFHack controls. Having exportlegends move those afterwards is probably doable, though, and has been suggested before.

"Janitorial duties, however..." Yeah, consider my vote cast in favour of that notion, if you please.
Logged

DerMeister

  • Bay Watcher
    • View Profile
Re: DFHack 0.44.12-r2
« Reply #1874 on: October 02, 2019, 04:26:34 pm »

I need plugin that will make sapients milkable and sapientr corpses usable if play as civ with eat sapient other etics.
Logged
Pages: 1 ... 123 124 [125] 126 127 ... 129