General Improvement Mod - A New Unofficial Patch for DK2

[Hapuga]

On the patch:

I invested about 3 hours into playing the game. I played a couple of maps with heroes, and noticed one thing - while I really enjoy the upped damage of DE and E units, they do way too much damage. 4 level 5 elves easily wipe out a 5-7 unit team (say, 3 mistresses, 2 black knights and 2 trolls) and + n amount of elves raise the damage output almost by a power of n (due to grenade mostly). I lost 2 dark angels, 4 black knights, 2 mistresses, a bunch of warlocks, trolls and goblins to 7(!!!) level 5-7 elves. Elves are now a walking nuclear launcher. Also, due to colossal damage, there is no real advantage in leveling them. a level 1 E will have only about 30% less chance of winning against a level 10 E. 3 level 1 E will put down level 10 E with 1 well-aimed shot. I suggest decreasing E damage by 2/5 for all attacks.

On game:

I spent some time disassembling the .exe and I found the starting point of the program (WinMain). I will try to move through the calls procedurally, to understand what function calls are made. Maybe it will eventually lead to something interesting.

UPD:

while the normal portals work as hero portals, the heroes lack the "climb out" action, as well as animation, Due to that, most heroes have to be picked up manually from the portal when they appear.

regarding the Ai - ai is terrible at managing gold. It acts slightly better if there is a gem seam close-by. It acts pretty well if the gem seam is in the middle of the 5x5 treasury. I would strongly recommend adding a gem seam to all AI player maps for every player.

Several things that (if we ever get that far) should be fixed:
- AI gold management should be rewritten. Digging, storing and casting.
- Room placement and expansion.
- Room repair. AI does not know how to fix "broken" rooms. It simply creates a new room of the same size.
- AI expansion rate. Now AI can win only if you let it win intentionally.
- AI aggressiveness.

Minor AI tweaks that would be useful:
- let the creatures fight to 0-20% life before picking them out from combat pit (now picks them at about 70%).
- garbage creature dumping.

On a side note, I would recommend reducing training room per hit price reduction from 20 to 5.

[Hapuga]

Also the price of combat pit should go up to at least 1000-1100. I'd even say 1750. That will prevent the 6x6 cp rush as it is now. At least, on more "balanced" maps, with less gold.

I started using IDA instead of AMD disassembly and it is much, much more intuitive. It even understands some of the calls to the c++ stl library (like stl::string). It also gives a graph(!!!) of all loops, conditionals and return points for each function, which also helps a lot. All we have to do is find the addresses of the calls to the specific AI functions, reinterpret the parameters that are sent and return types. After that we may create a .dll and inject it's functionality into the places where specific calls are made in EXE. Easier said than done of course, but worth a try definitely.

[Hapuga]

Looks like heap corruption. You are either overriding memory that you should not or you are passing wrong array offset/pointer. if you tell me what you're doing I might be able to give you a better clue on how to fix it.

[Hapuga]

from that chunk - this is what I understand:

a stack segment local.3 was copied into the ESI register.
a data segment was moved into EAX retister (4 bytes after ESI, siggests that it is data in array)
XOR the EDI register with itself, compare result to EAX.
jump to address 0058F5D5 if they are equal
move data segment of EAX + 14 bytes to the ECX register
copy the value of ECX to the position of ESI+4
copy the value of EDI to EAX+14
copy the value of EDI to EAX+4
copy the value at address 78E610 to CL

Basically, it is like this.

dword a = local.3;
dword b = local.3+4
if(EAX == EDI)
do something at address 0058F5D5 (a function call maybe?)
else
assign bunch of stuff.

Bunch of pointer arithmetic. Instead of nooping those, try adding different offsets, and see what happens. For example, +4 suggests that it's a float, or an integer. Try adding +8 + 12 etc. +14 on the other hand is weird, because logically if the type is 4 bytes, you would either have +12 or +16.

Or for example, those 2 lines
0058F596 |> \8B7424 24 MOV ESI,DWORD PTR SS:[LOCAL.3]
0058F59A |> 8B46 04 MOV EAX,DWORD PTR DS:[ESI+4] ;Causes access violation crash

if setting EAX causes a crash, it means that the ofset is off. Try assigning just ESI, see what happens. I assume that DS:[ESI+4] is some sort of a class variable. try other variables - local.1, local.2 etc. interesting results may be achieved.

Size of DWORD is 4 bytes. so you should move by multiples of 4. I'm pretty positive that +14 is incorrect. But I'm not an asm expert myself.

If you could post some code that has more info about LOCAL pointer, and some code about the jump to that address that I mentioned, we may be able to figure something out.

[Hapuga]

the problem with buffer overflow is that the code you are looking at may not be the issue. It may be something else that corrupted the stack, and when this (potentially harmless) code tries to assign something, everything goes down.

[Hapuga]

In worst case - yes, it will be pretty difficult. Even having C++/C code in front of you may be hard to debug when shit randomly crashes. But lets try.

This is what you are looking for:
any jump operations (jne, je, etc) that usually lead to function calls or assignments
any loops (if there are several almost identical chunks of code, its probably a loop).
any pushing/popping (usually represent passing parameters to functions).

try to get an idea of how the code circulates, and where it returns. Even without understanding the code, you will see some sort of a pattern, the calls that are made every frame. That will help alot. Look at the addresses.

If you can ( I dont know what program you use) put a breakpoint before the crashing operation, and look at the stack. Try to follow the operations back and trace what was called where.

[Metal Gear Rex]

I've started an attempt to debug the game executable. So far I think I've managed to correct a few crash bugs, but now instead of the game crashing the graphics just go to hell:

Attachment 1225

If anyone has any ideas of how to fix this graphics corruption or wants to help then that would be great.

UPDATE EDIT:

Corrupted torture chamber:

Attachment 1226

It's a bit amusing really...

That's hilariously glitchy. I want to play that patch, it looks like it'd be a good laugh for a bit just exploring everything. I can't even tell who is in the TC.

[Metal Gear Rex]

Well I might let you but I'm not sure how stable that executable is. I think it just scrambles all the game textures but I'm not sure.

Well, the whole point is to just screw around with things. I don't really care that much for it so there's not much reason for you to bother with the effort.

The world's most efficient training room:

Attachment 1228

Even more so because it promotes Black Knights!

Attachment 1229

"Dwarf"

ID Tag. Gotta properly label your property.

[Hapuga]

Exiting to main menu deinitializes the level, so yes, it goes back to normal. Does it return to normal when there are less creatures on screen? Because if it does, it is 100% buffer overflow. If we only could find the buffer and increase its size.

[Hapuga]

Access violation when reading [E7940012] means that you are trying to read memory outside of the array. With data that you provided it is safe to assume that 0058F59A + 8 is the last element in the array.
Other crashes mean that you are sending bad pointers to the object. if + 0 works, +4 crashes and +8 works again, probably the object is 8 bytes long. Now, that is either a double on 32 bit microsoft architecture, or a custom struct that has several elements. It is hard to determine for me what those elements are, they may be 2 floats, or 2 ints, or 8 bools, or (if padding is done wrong) something else. In other words - I cant tell what those 8 bytes represent. we have to go deeper. Also, ask Mefistofelis what he thinks about it. There is not enough information to conclude anything from the code that you provided.

EDIT:

Taking into account the changes that appear on screen (funny graphics), I think that those elements are actually pointers to the textures. Assuming a 4 byte pointer and a 8 byte struct, I would take a guess and say that it is a struct that holds two pointers to diffuse and specular textures of the mesh. The addresses that you move them along may be some kind of containers (95% - arrays or vectors) that store the texture information.