Print

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

[Rose]

here's what it involves:

First, do a search for all the numbers in the DF memory.

then, wait for some critters to spawn, say.. 5 groundhogs.

then, you find which number is reduced by 5.

then wait for more groundhogs to appear.

keep going and you might just find out which number is being used for the number of available groundhogs. now you have to find out what refers to that number.

[NecroRebel]

here's what it involves:

First, do a search for all the numbers in the DF memory.

then, wait for some critters to spawn, say.. 5 groundhogs.

then, you find which number is reduced by 5.

then wait for more groundhogs to appear.

keep going and you might just find out which number is being used for the number of available groundhogs. now you have to find out what refers to that number.

...I'm hoping there's a way to generalize once you've got the memory positions for a few species instead of having to figure out each creature's memory position individually. Having to do each species one by one would be terrible 

Anyway, I'll leave it up to someone who actually knows what they're doing to decide if this is possible and worth the effort. Thanks for the information.

[Root Infinity]

Would it be possibly to do a "reset" function? It would iterate through the entire map (obviously slow) recalculating tempature, passibility, and (possibly) aboveground status.

[Greiger]

About the number of animals on the map thing, wouldn't it be possible to find that information in an uncompressed save?  Or is that stuff too complex to even begin finding useful stuff? (Other than FB and titan raws of course)

[Root Infinity]

About the number of animals on the map thing, wouldn't it be possible to find that information in an uncompressed save?  Or is that stuff too complex to even begin finding useful stuff? (Other than FB and titan raws of course)

Hmm... Does anyone have any information about the saves (Assuming uncompressed for now...)? It would be interesting to go through them with a hex editor and a file comparer (Copy save. Change nothing, leaving game paused. Save. Anything changed? What about if you just change the view? What changed? Et cetera...) but I really don't want to duplicate any work already done (if any).

[Andux]

Hmm... Does anyone have any information about the saves (Assuming uncompressed for now...)?

I've mainly looked at WORLD.DAT files (worlds with no active adventurer/fort), but yeah.

[daego]

I dropped the new tick offset from https://github.com/peterix/dfhack/commit/b29871cb8c3d428925f001a379441c2ba21cd840 to the master branch locally. I can confirm the offset changes (just by dumping out

Code: [Select]

d>tick_offset) but via my tools or dfposition, I don't see "Tick" ever changing from 0. I know it's not from the return 0 fall-through case.

Am I just really bad at this? I don't necessarily see other changes on the dfapi branch that would impact the offset...

[Root Infinity]

Hmm... Does anyone have any information about the saves (Assuming uncompressed for now...)?

I've mainly looked at WORLD.DAT files (worlds with no active adventurer/fort), but yeah.

Nice job so far!

You seem to have taken an entirely different approach than I would have. Interesting...

[peterix]

Right. I have a very basic plugin system in place now working on both Windows and Linux. It's a start I guess.

And here's a current binary build for Linux. Just extract to a linux 31.25 directory and run 'dfhack' from a terminal. The terminal will be transformed into a DFHack console.
https://github.com/downloads/peterix/dfhack/dfhack-kittens.tar.gz

To have full support for plugin development, I'll have to add a few things to the build system... I want to have a binary SDK people can just download and build things on top of.

Stay tuned

EDIT: prospector plugin. Just drop it in. http://dethware.org/prospector.plug.so

Am I just really bad at this? I don't necessarily see other changes on the dfapi branch that would impact the offset...

Well, no idea. The offset is only for Windows... and I haven't really bothered to test it to be honest. It mainly affects dwarf beard color in stonesense...

[daego]

I'm using Windows; no biggie. I had a status-like plugin using it that graphed and tracked the status of resources over time: http://i.imgur.com/8Tsys.png -- I swapped the graphs for random data for now but the figures are correct as far as I can tell.

[peterix]

I'm using Windows; no biggie. I had a status-like plugin using it that graphed and tracked the status of resources over time: http://i.imgur.com/8Tsys.png -- I swapped the graphs for random data for now but the figures are correct as far as I can tell.

Looks pretty cool. Hmm. Maybe some offset hunting is in order

[Artanis00]

To have full support for plugin development, I'll have to add a few things to the build system... I want to have a binary SDK people can just download and build things on top of.

Personally, I'd like to see support for plugins that are distributed by source instead of compiled binaries. Python, for example; and instead of an SDK, dfhack stuff would be in a package supplied by the plugin system.

I'm not really keen on people distributing binaries. Seems like it would be too easy to slip something nasty in.

[Rose]

To have full support for plugin development, I'll have to add a few things to the build system... I want to have a binary SDK people can just download and build things on top of.

Personally, I'd like to see support for plugins that are distributed by source instead of compiled binaries. Python, for example; and instead of an SDK, dfhack stuff would be in a package supplied by the plugin system.

I'm not really keen on people distributing binaries. Seems like it would be too easy to slip something nasty in.

I am not writing stonesense in python.

Hell.

No.

[peterix]

To have full support for plugin development, I'll have to add a few things to the build system... I want to have a binary SDK people can just download and build things on top of.

Personally, I'd like to see support for plugins that are distributed by source instead of compiled binaries. Python, for example; and instead of an SDK, dfhack stuff would be in a package supplied by the plugin system.

I'm not really keen on people distributing binaries. Seems like it would be too easy to slip something nasty in.

Well, rejoice! Before, I was getting in sideways and telling people to disable their rabid antivirus programs and poorly designed OS protections. Now I'll be distributing binaries that don't have to 'break in', so to speak. This is a massive improvement. And it's damn fast in comparison with other alternatives.

I can see how this could be used by some nasty person to do bad things, sure... but they could do it before and they'll be able to do it no matter how I change DFHack. The key thing is to *NOT* download binaries from someone you don't trust. I give you source code of everything I release. Read it. Compile it. You don't need the binaries, those are just for convenience.

[Rumrusher]

I want to know because it's not really clear to me, does new DFhack can attach to other DF programs if its in one DF folder or do I need to copy and paste the same DFhack to the others to get it to work?