Print

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

[devek]

And it won't crash when the memory is freed by DF's allocator? I had enough problems with that to write off any such easy hacks as rubbish

DF's allocator physically can't free the memory so it won't crash my program. Why DF doesn't crash trying to free it, I honestly don't know yet. I do other fun hacks too like store data in the first byte of a vector/string. I noticed Toady was doing it for the custom reactions structure and it worked so lol. Good thing too, or I wouldn't be able to find the memory I had previously allocated when my program was restarted and would have to start over and allocate more.

[snooptodd]

31.12, linux, git pull about 3hrs ago
Is this what happens when the memory layouts are incorrect? Or is something else wrong?

Code: [Select]

~/src/dfhack/output$ ./dfvdig
pread failed: can't read 0x18 bytes at address 0xb1836198
errno: 16
terminate called after throwing an instance of 'DFHack::Error::MemoryAccessDenied'
  what():  SHM ACCESS DENIED
Aborted

Normally, yes. But I know that the 31.12 linux version should be OK. I tested the tool just now and it works.

Could be something unexpected happening. Can you pack your DF folder and put it online? Just make a copy of it and delete all saves except for the one where you got this error. Those things can be quite big. I'll look at it when I have some time.

it might be something wrong on my end. As a test I stuck the df and dfhack/output folders on a usb drive and tried them on another computer running ubuntu lucid and it worked fine.

here is the df folder.

[peterix]

it might be something wrong on my end. As a test I stuck the df and dfhack/output folders on a usb drive and tried them on another computer running ubuntu lucid and it worked fine.

here is the df folder.

Well, looks like it works all right over here. What's the system on the first computer? I've had a lot of problems with older kernels (anything older than 2.6.32 was bad I think)... Also, having something like this enabled could break things.

[keda]

Yes, it's there, just not for vectors yet and it requires hooking a few SDL functions to get code in. No code caves, no assembly and no messing with virtual memory involved   You just need to make sure you're using the same C and STL libraries as DF for the fake SDL.
A bit of example code:

Code: [Select]

std::string * to_set = (std::string *) offset;
to_set->assign("string assigned by dfhack...");
This is the code that goes into the fake SDL: http://github.com/peterix/dfhack/tree/master/library/shm/
The client uses the SHM versions of the Process class to talk to it.

I just had a look at the code and couldn't make head or tail out of it. Are you going to do this for vectors too any time soon? I'd hope so and appreciate it, since that is way over my head.

[Shukaro]

Sorry if this is a bit of a derailing, but the 4.0.5 download is missing the dfposition and dfoffsets tools. Sorry if this has already been said before.

[s20dan]

Sorry if this is a bit of a derailing, but the 4.0.5 download is missing the dfposition and dfoffsets tools. Sorry if this has already been said before.

 You can just use the tools that come with the older versions.
http://github.com/downloads/peterix/dfhack/dfhack-bin-0.4.0.2.zip
That one has them.

[Shukaro]

Yeah, but they won't work with 31.12, even dfoffsets.

Edit: Just swapped out the memory.xml, and it worked, so it's all good now.

Edit: Hmm, the mouse xy tile coordinates would be very helpful as well.

[peterix]

Yeah, but they won't work with 31.12, even dfoffsets.

Edit: Just swapped out the memory.xml, and it worked, so it's all good now.

Edit: Hmm, the mouse xy tile coordinates would be very helpful as well.

Wow. There are mouse coords available? I'll have to add that

[Shukaro]

Yeah, DF stores the X/Y position of the tile the mouse is over. And, it's relative to the screen, not the world.

[snooptodd]

it might be something wrong on my end. As a test I stuck the df and dfhack/output folders on a usb drive and tried them on another computer running ubuntu lucid and it worked fine.

here is the df folder.

Well, looks like it works all right over here. What's the system on the first computer? I've had a lot of problems with older kernels (anything older than 2.6.32 was bad I think)... Also, having something like this enabled could break things.

both computers are current with 32bit Ubuntu lucid. That got me thinking, the one that works is running the pae enabled kernel.
I installed the pae kernel and it appears to work. More testing is required

thanks for the help.

[Quietust]

The naked_itemflags struct in library/include/dfhack/DFTypes.h appears to have some flags in the wrong positions - it claims to be the same as what's in 40d, yet in_inventory is the 3rd bit instead of the 4th bit (Rick's table skips 0x4 entirely).

Also, I'm fairly certain that Rick's assessment of 0x100000 being "item shows wear" is incorrect (item wear is actually an integer value stored elsewhere, 1 for "x", 2 for "X", 3 for "XX") - nearly all of these flags match exactly what I've personally reverse-engineered from version 0.23.130.23a (for some retro-tools I wrote), and in that version said flag indicated that the object was owned by a dwarf and thus shouldn't be touched by anyone else (except when clearing away debris for constructing a building). A quick check against 0.31.12 confirms that this is still the case - while clearing the flag won't clear the "Owned by:" in the item description (that's stored in a vector within the item object, the same vector that keeps track of where the item is physically located), clearing the flag does allow the item to be picked up by other dwarves and stored in a stockpile or taken to a garbage dump zone (which would have been ideal back in 40d for removing clothing from the floors of cluttered barracks) or possibly even to be claimed by another dwarf.

Similarly, the "narrow" flag (0x4000) doesn't actually mean "narrow" - it means "produced offsite" (i.e. shows up with parentheses around the name), while 0x8000 was (and probably still is) used for items being sold by a caravan (never completely figured out that flag).

Another side note - the dfhack sources come with batch files to generate project files for MSVC 2002 and 2003, but it won't actually compile with them because they don't have "intrin.h".

[peterix]

The naked_itemflags struct in library/include/dfhack/DFTypes.h appears to have some flags in the wrong positions - it claims to be the same as what's in 40d, yet in_inventory is the 3rd bit instead of the 4th bit (Rick's table skips 0x4 entirely).

Also, I'm fairly certain that Rick's assessment of 0x100000 being "item shows wear" is incorrect (item wear is actually an integer value stored elsewhere, 1 for "x", 2 for "X", 3 for "XX") - nearly all of these flags match exactly what I've personally reverse-engineered from version 0.23.130.23a (for some retro-tools I wrote), and in that version said flag indicated that the object was owned by a dwarf and thus shouldn't be touched by anyone else (except when clearing away debris for constructing a building). A quick check against 0.31.12 confirms that this is still the case - while clearing the flag won't clear the "Owned by:" in the item description (that's stored in a vector within the item object, the same vector that keeps track of where the item is physically located), clearing the flag does allow the item to be picked up by other dwarves and stored in a stockpile or taken to a garbage dump zone (which would have been ideal back in 40d for removing clothing from the floors of cluttered barracks) or possibly even to be claimed by another dwarf.

Similarly, the "narrow" flag (0x4000) doesn't actually mean "narrow" - it means "produced offsite" (i.e. shows up with parentheses around the name), while 0x8000 was (and probably still is) used for items being sold by a caravan (never completely figured out that flag).

Yes, item support is still pretty much broken. There's something in place, but it's currently Windows only and reads *code*. From the flags, only a few were ever used. Mostly for things like setting dwarven pants on fire and vaporizing stone

* peterix adds a task into the bugtracker

Another side note - the dfhack sources come with batch files to generate project files for MSVC 2002 and 2003, but it won't actually compile with them because they don't have "intrin.h".

Then it's probably a very bad idea to use those versions. I'll remove the scripts.

[mLegion]

I noticed dfprobe can get the outside/inside light/dark aboveground/subterranean would it be possible to modify that so we can set tiles back to being dark subterranean?

[peterix]

I noticed dfprobe can get the outside/inside light/dark aboveground/subterranean would it be possible to modify that so we can set tiles back to being dark subterranean?

I want to make a good editor kind of application with a graphical user interface first. Something that shows the map very much like DF does, but also lets you make changes. Of course, changing a few flags is very simple and could be tacked onto the dfliquids tool for example.

I'll think about it.

[mLegion]

My mistake, didn't realize dfliquids already does that