Print

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

[Andux]

A vein changer would definitely be doable; I've already been working on a basic vein viewer for the next release of dfmarmot.

As for changing layer stone: As I understand it, the type of layer stone (or soil) you get is determined by the tile's biome and geolayer_index designations. I think biome might be an index into the block's biome_indices array; if so, one could create tiles of any arbitrary layer stone by inserting new data into an unused biome_indices slot. That may be horribly wrong, though; I'm still trying to make sense of this.

[peterix]

Well. I decided to experiment a bit... get crazy

Here are the problems currently plaguing DFHack:

• It can't allocate and free memory or manipulate things like strings and vectors properly.
• There is a significant performance bottleneck caused by us having to read sparse bits of information using the OS-provided debugging APIs - this means a fairly high constant cost for each call, no matter how much data is read. Writing data on linux is about two orders of magnitude slower than it should be (OS forces us to write in 4-byte chunks for no good reason).
• DFHack is ultimately unsafe because of no proper locking and synchronization with DF.
• The current memory description (memory.xml) is untyped and just lists arbitrarily grouped numerical values.
• DFHack is mostly hand-written code, while it's more of an interface.

So, what's the solution?

• I will move all of DFHack *into* DF itself - this should solve 1., because the data access will be direct (and unprotected, putting greater emphassis on testing).
• By moving into DF, the memory access cost for things also loaded into DF approaches zero. External API will be done with some cross-platform COM-like scheme. This should make creating language bindings easier too. I'm looking at CORBA.
• Memory.xml format will be redone - this time to actually describe the memory layout of objects, instead of just listing some offset values. Having the layout, a lot of DFHack can be generated instead of written. This includes tests!
• The distribution method will have to change significantly. To make things easy for users, I'll have to package DFHack along with DF. This will let me trim out the support for all the historic crud with each version. I doubt anyone will miss it.
• This all means the support for wine DF is going away. This could bite me in the a**.
• DFHack will have to use the same compiler as DF. You won't be able to build it with Mingw32 on windows anymore.

A crazy experiment.... just throwing stuff at a wall and seeing what sticks, Cave Johnson style... without the exploding lemons though. I'll have to figure things out as I go, because there's a lot of problems to solve not listed here.

I expect the new DF version to break quite a bit of stuff. I also expect it to be hilariously buggy. That should give me some time for working on core DFHack. And yes. I'm done with all the uni finals... so I actually have some time for all this. It will be fun

Expect explosions.

The source on github is only up to 0.5.14. 
Any timeline on when the 0.5.15 source will be up?
dfstatus looks interesting I would like to check it out, but no source...

It's there. I just forgot to make a named version. Take current git HEAD.

A vein changer would definitely be doable; I've already been working on a basic vein viewer for the next release of dfmarmot.

As for changing layer stone: As I understand it, the type of layer stone (or soil) you get is determined by the tile's biome and geolayer_index designations. I think biome might be an index into the block's biome_indices array; if so, one could create tiles of any arbitrary layer stone by inserting new data into an unused biome_indices slot. That may be horribly wrong, though; I'm still trying to make sense of this.

Don't, you don't have to. Reading DFHack sources is better. Look at the Maps module. It's a horribly convoluted scheme, but in the end, it's just this: tile biome is index into an array of numbers stored in the block. Those in turn determine the positional offset at which the real source of biome is, relative to the current region (where region = 16x16 embark squares). This offset can be from -1 to +1 in both X and Y coordinates. Geolayer index is then the index of the geological layer. So, all you can do is change the geology of a whole biome, or change the layer and biome of a tile to one present near the current region. There is no way around this... and the ASM code looked horrible because Toady uses signed integers where he shouldn't.

Oh, and a vein changer would be trivial. I can make one today.

[Rumrusher]

I'm not saying people are being unreasonable to request things, I'm focusing on how to get those requests without overburdening programmers.

My focus was on getting more talent into the pool from others.

weird thing is about changing the type of stone was done in Dtil way back, Some thing about swapping a stone with another was lost during that time when 31. series came in.
Andux who works on tweak pops in some time to help, PM him or ask him directly in this thread on if he going to work on a Vein Changer utility?

Actually, that's a good point. I had forgotten that Andux was dealing with Tweak. I don't think he's updated it for 31.XX though. I could be wrong. Although, if I remember correctly, the tile changing utility was difficult to use, because a.)you had to individually edit each and every tile by going into a submenu and typing in the four digit/character reference for each type of material, b.) you could only do it one square at a time, c.) it sometimes screwed up pathing, d.) you couldn't create individual ore stone tiles (Sidenote: I love DFLiquid's new range function for magma/water/obsidian casting).

That said, it would be wonderful if Andux would be so kind as to look into this.

Great comment.

He updated it to 31.xx, I only got it to work for 31.21 on a Xp pc before the whole thing stop responding on my Win 7 pc. I used it mainly for quick adventure mode fixes and was the key to what is now a staple for non scatter items.
Warning - while you were typing a new reply has been posted. You may wish to review your post.

I will move all of DFHack *into* DF itself - this should solve 1., because the data access will be direct (and unprotected, putting greater emphassis on testing).

Does this mean we have to place a Dfhack folder inside all DF folders or you need to do this once on one and DFhack can be access through any other copies of the same version of Dwarf fortress?

[Greiger]

That's....that's even possible?  I didn't know you could merge a program into another program without being able to change the source of the second program, am I just horribly misinformed?  Or do you have Toady assisting with it or something?

Anyway that sounds pretty awesome.  Hope that's easier than it all sounds peterix, we'd hate to lose you to a failed mood.    *assigns war dogs just in case*

[narhiril]

I'd just like to say dfcleanowned is the best thing I've ever used.  Ever.  At least, until the next release

[Artanis00]

[W]e'd hate to lose you to a failed mood.    *assigns war dogs just in case*

That's a hilarious mental image.

Peterix cancels DFHack: too insane
Peterix begins throwing a tantrum!
www.bay12forums.com cancels request: interrupted by Peterix
Peterix drives a truck through www.bay12forums.com's security holes, breaking Apache and corrupting the database! The severed config file sails off in an arc!

_{note: I have no knowledge of www.bay12forums.com security holes, nor whether or not one could drive a truck through the alleged security holes.}

[Greiger]

Even should he just go melancholy the whole forum might tantrum spiral,  I mean for the short time he was banned chained in the jail during 'that which shall not be named' there was a pretty strong effect.

[profit]

That's....that's even possible?  I didn't know you could merge a program into another program without being able to change the source of the second program, am I just horribly misinformed?  Or do you have Toady assisting with it or something?

Anyway that sounds pretty awesome.  Hope that's easier than it all sounds peterix, we'd hate to lose you to a failed mood.    *assigns war dogs just in case*

It is possible, just not as Petrix thinks. 

You have to lay out the two exe's assembly code, change the ones references so they do not conflict with the other. Then add jmp instructions inside the code after the first one initializes to hit up the next one..   

I have honestly never seen this done on such a scale before.

hackers use loaders grafted onto protected exe's sometimes to change some bytes at runtime in order to defeat copy protections and to create trainers... however this is really a whole other ball of wax and will require excellent assembly skills on Petrix's part (not that he does not already have decent ones as shown with his memory editing and reading)

I suppose if he stole the source to dwarf fortress somehow or maybe dissembled the exe (it has been done) he might be able to recompile with his changes. 

Either way, it is a lot of work as far as I know.

[Justiceface]

I'd really like to get this working in Linux.  I'm running Lucid and apparently my edition of libncursesw5 isn't enough to make DFHack happy.  Is there a version that runs on Lucid?

[peterix]

That's....that's even possible?  I didn't know you could merge a program into another program without being able to change the source of the second program, am I just horribly misinformed?  Or do you have Toady assisting with it or something?

Anyway that sounds pretty awesome.  Hope that's easier than it all sounds peterix, we'd hate to lose you to a failed mood.    *assigns war dogs just in case*

It is possible, just not as Petrix thinks. 

You have to lay out the two exe's assembly code, change the ones references so they do not conflict with the other. Then add jmp instructions inside the code after the first one initializes to hit up the next one..   

I have honestly never seen this done on such a scale before.

hackers use loaders grafted onto protected exe's sometimes to change some bytes at runtime in order to defeat copy protections and to create trainers... however this is really a whole other ball of wax and will require excellent assembly skills on Petrix's part (not that he does not already have decent ones as shown with his memory editing and reading)

I suppose if he stole the source to dwarf fortress somehow or maybe dissembled the exe (it has been done) he might be able to recompile with his changes. 

Either way, it is a lot of work as far as I know.

Sorry, but I'm not trying to change what DF does, just add more stuff to it. I can do this with no silly assembly, the source, or any of that crud All I really need is a bunch of C calls to hook. Ideally one that's called when DF starts, one when it shuts down (just to be nice and clean up after myself), and one when it's done with a simulation frame. I have that, so all that I need is a plain old C++ compiler. The OS-provided dynamic linker will do all the hard work. Library wrappers FTW.

I'd really like to get this working in Linux.  I'm running Lucid and apparently my edition of libncursesw5 isn't enough to make DFHack happy.  Is there a version that runs on Lucid?

You need that only for dfstatus and dfveinlook AFAIK. Rest should work. Just grab the 10.10 package.

[Justiceface]

I'd really like to get this working in Linux.  I'm running Lucid and apparently my edition of libncursesw5 isn't enough to make DFHack happy.  Is there a version that runs on Lucid?

You need that only for dfstatus and dfveinlook AFAIK. Rest should work. Just grab the 10.10 package.

It won't even install.  I opened the .deb in GDebi and get this:

Error: Dependency is not satisfiable: libncursesw5 (>=5.7+20100313)

I have the latest version of ncurses available to me on Lucid.  I tried to force a different version to install, but Synaptic doesn't allow that either (option greyed out).

[peterix]

I have the latest version of ncurses available to me on Lucid.  I tried to force a different version to install, but Synaptic doesn't allow that either (option greyed out).

OK. Guess I don't know which ubuntu is lucid. Anyway, you can build your own package
Here's how:
Start with fresh dfhack sources.

Code: [Select]

mkdir -p build/ubuntu && cd build/ubuntu
ccmake ../..This will show some 'stuff'. Hit 'c' for configure, then set up all the pieces to look like this:

Code: [Select]

BUILD_DFHACK_C_BINDINGS         *ON                                           
 BUILD_DFHACK_DEVEL              *ON                                           
 BUILD_DFHACK_DOXYGEN            *OFF                                         
 BUILD_DFHACK_EXAMPLES           *OFF                                         
 BUILD_DFHACK_LIBRARY            *ON                                           
 BUILD_DFHACK_PLAYGROUND         *OFF                                         
 BUILD_DFHACK_PYTHON_BINDINGS    *OFF                                         
 BUILD_DFHACK_SUPPORTED          *ON                                           
 CMAKE_BUILD_TYPE                *Release                                     
 CMAKE_INSTALL_PREFIX            */usr                                         
 DFHACK_INSTALL                  *ubuntu-10.10                                 
 MEMXML_DATA_PATH                */usr/share/dfhack                           
 X11_LIBRARY                     */usr/lib/libX11.so                         Hit 'c' and 'g' for generate, then run:

Code: [Select]

fakeroot make package
You'll end up with a deb package for your ubuntu version. You might have to install ccmake/cmake, fakeroot and a whole pile of different -dev packages tho. See the COMPILE file for details on that.

[arclance]

The source on github is only up to 0.5.14. 
Any timeline on when the 0.5.15 source will be up?
dfstatus looks interesting I would like to check it out, but no source...

It's there. I just forgot to make a named version. Take current git HEAD.

How would I do that?  I have had no luck trying to figure it out.

[peterix]

The source on github is only up to 0.5.14. 
Any timeline on when the 0.5.15 source will be up?
dfstatus looks interesting I would like to check it out, but no source...

It's there. I just forgot to make a named version. Take current git HEAD.

How would I do that?  I have had no luck trying to figure it out.

https://github.com/peterix/dfhack -> downloads -> download zip/tar.gz1 ... it's right there.

[arclance]

https://github.com/peterix/dfhack -> downloads -> download zip/tar.gz1 ... it's right there.

I tried that before and got this.

Spoiler (click to show/hide)

When I compile I get the 0.5.14 executables.  The new ones like dfstatus are not built.