Print

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

[Fleeting Frames]

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]

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

[lethosor]

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.

[Roses]

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.

[Warmist]

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]

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)

[DerMeister]

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.

[Silverwing235]

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. 

[DerMeister]

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

[lethosor]

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.

[Fleeting Frames]

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]

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.

[DerMeister]

I need plugin that will make sapients milkable and sapientr corpses usable if play as civ with eat sapient other etics.

[Fleeting Frames]

A quick search brings up Unbutcherable sentient workaround for the latter.

[DerMeister]

A quick search brings up Unbutcherable sentient workaround for the latter.

Thank you. Whats about milking sentients?