Print

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

[peterix]

Just noticed that the MD5 hash it reports changes with every run.

Yes. This is something that definitely doesn't happen on my machines - real or virtual. And it's extremely weird. Do the previous releases have the same problem?

i wonder if df hack in its current state has any means for messing with the siege flag in the game?

It is quite hard to do that, because the 'siege' state is not controlled by a single flag AFAIK. A possible solution could be turning a random animal into an invader that belongs to the goblin civilization and letting it walk into a cage trap.

[sniken]

ok, just tried giving a badger same civ id in runesmith as the goblins and made it an active invader. killed it but no result. gonna try again but this time put up a lot of cage traps for them.

[uggi]

Yes. This is something that definitely doesn't happen on my machines - real or virtual. And it's extremely weird. Do the previous releases have the same problem?

Sorry, haven't tried them. I tried to compile DFHack myself, but it seems my GCC doesn't like nullptr.

[uggi]

Ah, just found out from github that there's been more than one revisions for 0.31.25 :p Tried them all. r1 gives no error, just exits. r4 to r7 all give the same undefined symbol error. But r2 and r3 works for me, yay!

[peterix]

Sorry, haven't tried them. I tried to compile DFHack myself, but it seems my GCC doesn't like nullptr.

Your GCC is too old ~_~

Ah, just found out from github that there's been more than one revisions for 0.31.25 :p Tried them all. r1 gives no error, just exits. r4 to r7 all give the same undefined symbol error. But r2 and r3 works for me, yay!

I think I actually compiled r2 and r3 under some ubuntu version. Anyway, I'll have to find a better md5 implementation than the one I'm using.

OK. Here's a possibility: the algorithm is sound (it works). Therefore, the failures come from reading the file itself - calls to fread fail for some reason. Hopefully, it's signals delivered to DF interrupting the fread() calls and not something worse.

... yay for unhandled errors I though would never show up. I'll try to get a fixed release out tomorrow.

[rampaging-poet]

Could I request a tool that automatically marks all tree saplings and uncollected webs as high movement cost?
Should prevent them from being trampled so much.

I can probably get that done tomorrow night.

Could it have a selection range for saplings and shrubs? like rectange painting? that way It doesn't have to be run everytime a new batch of them grow (because everywhere other then my tree farm is littered with no-no spots,making my dwarves treat the local area as a mine field). Also it wouldn't mess up my traffic zones so much (If this gets implimented)

I'll see if I can make an interactive version that allows selection.  I'll definitely add the ability to specify a range in tiles to all the traffic tools.

[Nice Save]

Could I request a tool that automatically marks all tree saplings and uncollected webs as high movement cost?
Should prevent them from being trampled so much.

I can probably get that done tomorrow night.

An option to make this work for surface water would be really useful, to stop murky pools and rivers from thawing out from under dwarves as they walk over them.

[Dienes]

Super thanks for making/upgrading/maintaining this. Things like cleanowned, prospector, and vdig make df a lot more pleasant to play.

[peterix]

I just released r7c with some fixes. Fastdwarf should now work as intended on Windows.

@uggi: can you try this version? I added a few error checks to the part where it reads the DF file.

[uggi]

@uggi: can you try this version? I added a few error checks to the part where it reads the DF file.

Still the same problem. And the hash still changes. Could it be related to the PID somehow? That's the only thing that changes, after all. You sure it's not checking the hash of the path as a string, not the file itself?

Loading hack/Memory.xml ... OK
Unable to retrieve version information.
File: /proc/self/exe
MD5: cb32492f84d29e4da6f9b219af999e19
working dir: /home/uggi/df_linux
Not a known DF version. DFHack will now deactivate.

[peterix]

Still the same problem. And the hash still changes. Could it be related to the PID somehow? That's the only thing that changes, after all. You sure it's not checking the hash of the path as a string, not the file itself?

Well. I'm puzzled. I have a fully update 32bit ubuntu 10.10 virtual machine right here and I have no such problem. The algorithm works (you'd get some garbage or crashes instead if it didn't). The file is read properly and at no point does it run into read errors (md5 sum it outputs would be replaced with an error message).

This leads me to believe that your system is just plain weird. Could be some security thing. Could be a rootkit. I have no idea.

I'll add an output for file length and a 1KB hexdump from the start of the file to make sure it's actually the DF binary and not something like /dev/urandom.

[uggi]

This leads me to believe that your system is just plain weird. Could be some security thing. Could be a rootkit. I have no idea.

Well, this is an old system, originally installed as 8.04LTS.

Anyway, I just finally managed to compile DFHack (7c from github) and it works!

Although I had to use a workaround for the missing nullptr and had to disable vdig plugin because of these errors:

plugins/vdig.cpp:176: error: expected primary-expression before ‘[’ token
plugins/vdig.cpp:176: error: expected primary-expression before ‘]’ token
plugins/vdig.cpp:176: error: expected primary-expression before ‘x’
plugins/vdig.cpp:176: error: expected primary-expression before ‘y’
plugins/vdig.cpp:176: error: expected primary-expression before ‘z’
plugins/vdig.cpp:176: error: expected unqualified-id before ‘bool’
plugins/vdig.cpp:176: error: unable to deduce ‘auto’ from ‘<expression error>’
plugins/vdig.cpp:176: error: expected ‘,’ or ‘;’ before ‘bool’
plugins/vdig.cpp:923: error: expected ‘}’ at end of input

[twalberg]

Something between 0.31.25-r5-32-gd451c6 and 0.31.25-r7c seems to have broken cleanowned. Running "cleanowned scattered" no longer seems to notice discarded clothing/etc - just foodstuffs. Haven't had a chance to dig further into it - when I have some time I can try to bisect. It's entirely possible that my particular fort is broken too, so it might be worth validating on a different fort as well. This is on Linux build, if it turns out to be a system-dependent issue - only local mods I've made are replacing 'nullptr' with 'NULL' until I get a chance to upgrade my compiler. Other than that, it builds cleanly except for the usual pile of warning messages in the stonesense submod.

Edit: quick run through git bisect shows this:

$ git bisect bad
1f0e91c3d0769c4fb3a0a77858feb12f67355622 is the first bad commit
commit 1f0e91c3d0769c4fb3a0a77858feb12f67355622
Author: Petr MrΓ‘zek <peterix@gmail.com>
Date:   Wed Oct 26 23:12:20 2011 +0200

    Add enum for item types.

:040000 040000 ae2ec87b4e835f9d75205d9277e5f4c5e58d45a8 6cd48202c2a363cc9ad65cc210469399fa0b7fde M      library
:040000 040000 0e04133f0bfdadfca835e9b542de71b969a74a98 7838d730d791deaedef7691b6593adce653f24f1 M      plugins



Not sure exactly what in there caused it to break, but the preceeding commit:
       b545de7f4308ae55d7d92f5eea091902ee26b15c Items refactor. readItem turned into copyItem, most Items methods now accept plain df_item
seems to work fine.

[peterix]

Just released an another revision - r7d.

Something between 0.31.25-r5-32-gd451c6 and 0.31.25-r7c seems to have broken cleanowned. Running "cleanowned scattered" no longer seems to notice discarded clothing/etc - just foodstuffs.

This should now be fixed regardless of OS.

Well, this is an old system, originally installed as 8.04LTS.

Anyway, I just finally managed to compile DFHack (7c from github) and it works!

Awesome! Try the r7d binary release if you can. I added even more output when stuff fails and I'd like to see it. It's such a weird problem you ran into

If it keeps failing, I'll try using the md5 implementation from libcrypto.

Although I had to use a workaround for the missing nullptr and had to disable vdig plugin because of these errors:

plugins/vdig.cpp:176: error: expected primary-expression before ‘[’ token
plugins/vdig.cpp:176: error: expected primary-expression before ‘]’ token
plugins/vdig.cpp:176: error: expected primary-expression before ‘x’
plugins/vdig.cpp:176: error: expected primary-expression before ‘y’
plugins/vdig.cpp:176: error: expected primary-expression before ‘z’
plugins/vdig.cpp:176: error: expected unqualified-id before ‘bool’
plugins/vdig.cpp:176: error: unable to deduce ‘auto’ from ‘<expression error>’
plugins/vdig.cpp:176: error: expected ‘,’ or ‘;’ before ‘bool’
plugins/vdig.cpp:923: error: expected ‘}’ at end of input

Yeah... I started using some C++11 features - auto, lambdas (abusing them in vdig, really), nullptr and a few others.

[Rumrusher]

this is my current 'folders' in my Onfunction plugin.lua
shared for those wanting to see how to cram 60 functions to auto run in DF with out the confusing process of finding out that it can only go through one(that and Addcallback doesn't work).
So far this is my Corrosion folder for my modifications to Corrosion. The actual functions will be posted separately for they tend to break the character count.

Code: [Select]

function Dfolder()
DeathMsg()
Ghost() --doesn't work
makeghost() --doesn't work
end
function Mfolder()
raceconvert() --in corrosion turns set of humans into infected skin rotten lepers and make them hostile
--ControlCiv3()
derot() -- keeps food fresh for ever
Zombieressurect()  -- this takes any one who dies and turns them into a zombie, this will stack with the Race convert and make zombie infected humans
--zombiearmy()  -- move to traits
trait()   -- this checks the race of the adventurer and run series of functions suited for that creature.
makeghost() -- doesn't work
end
function Bfolder()
Burn()  --burns all items if someone flips the switch, I haven't tested this yet and
end
function Hfolder()
DeathMsg() --default folder template
end


--onfunction.SetCallback("Die",Dfolder)
onfunction.SetCallback("Move",Mfolder)
onfunction.SetCallback("Flip",Bfolder)

Warning - while you were typing a new reply has been posted. You may wish to review your post.

so should I pick up r7d? or continue with r7