Closed GoogleCodeExporter closed 9 years ago
A small clarification about #2, if I try to change Urist McGemCutter to a
custom profession I made, he remains in the jewelers profession. Of the several
ways to go about setting custom professions none of them get my dwarves
organized.
Original comment by pfifo.f...@gmail.com
on 7 Apr 2011 at 2:00
`emerge bug-buddy` installed libgnomesegvhandler.so
Im currently trying to patch this, but im a C programmer, and rarely play with
C++. And don't even get me started on windows programs... ugh
Original comment by pfifo.f...@gmail.com
on 9 Apr 2011 at 11:32
OK I have given up, this is being caused because memory address in 64 bit
are... well 64 bits!! I dont think anything less than an entire rewrite of the
program will fix this. Luckily for us we can cross-compile a working 32bit
version.
Original comment by pfifo.f...@gmail.com
on 9 Apr 2011 at 11:56
I just wanted to give an update of what I have found so far, 64bit anything
isnt a problem. the First issue is that the data stored in the memory for Urist
McCatButcher is not his actual nickname/profession, rather it is a pointer to a
char array, By default everyones nick/prof points to some default area of
memory, so when I tried simply changing its value , everry dwarf on the map
instantly had the nickname 'test' and were all in the 'test' profession.
Upon giving a single dwarf a custom profession in game, I could then change his
to anything I wanted with dwarf therapist. However, I cannot find the place
where the string length is stored. so I set his custom profession in game to
'foobar' and then in DT I changed it to 'deadbeef', but what ended up happening
is that in game his profession showed as 'deadbe' cause the string length was
set to 6.
Im currently writing some code to try and interrupt the game, and call whatever
function the game uses to set custom strings. however this is an amazingly
daunting task as Im no assembly programmer and have never used gdb todo such a
task.
Original comment by pfifo.f...@gmail.com
on 11 Apr 2011 at 6:58
Yeah those are actually std::string pointers you're seeing. Since they are
generally heap variables, you're going to have a hard time completely
replicating a std::string if you just treat it like a char**.
On windows this is a bit easier, as MSVC pre-allocates 16 bytes per
std::string. So on windows you're always sure to have at least 15 bytes to work
with (plus a terminator)
g++ doesn't do this though. This is a long-known issue. You may want to look
into how dfhack does it (using a shared memory segment via injection in the SDL
lib, to allocate new heap memory *as DF itself*)
Original comment by treyst...@gmail.com
on 11 Apr 2011 at 7:12
My patches for nicknames over here obviously fix this too:
http://code.google.com/p/dwarftherapist/issues/detail?id=175
Direct code injection is somewhat nasty, but I feel it's in a way less
complicated than full-blown LD_PRELOAD injection.
Original comment by ANGavri...@gmail.com
on 27 Apr 2011 at 4:11
Rolling this into issue 175.
Original comment by ehler...@gmail.com
on 6 Mar 2012 at 2:58
Original issue reported on code.google.com by
pfifo.f...@gmail.com
on 7 Apr 2011 at 1:57Attachments: