Damage Inc. & Prime Target Reversing

[Bobwithkeycard]

hey natranr, asylum's project is "just" about reverse engineering Damage Inc. like he mentioned earlier in this thread. Actually just below your last post. Integrating Damage Inc into Aleph One is a whole different continent, so better start learning C++, then you can do it yourself...eventually

[Asylum]

I have very bad news. Over the course of this project I've had many crashes, and they seem to have taken its toll on the IDA database for this project. It's not something that can be repaired, and no matter how many backups i make they will all be as damaged as the current one. IDA is crashing more and more frequently and sometimes work is not being saved. I'm abandoning my goal of creating a totally recompilable version of the Windows game because it will take too long to reverse the code new to the Windows port. Instead I'll focus on making the code new to Damage as clean as possible, then modifying the original M2 source release to integrate the changes. Hopper tells me that if I get the source into that format, it's possible he could port it to Aleph One. It'll be faster that way. Aleph One has all of the networking and rendering code already.

[Asylum]

For people who want to look at the current progress but don't feel like pirating IDA Pro and Hexrays...
https://www.dropbox.com/s/mgqb8pwk2qvnis5/damage.h
Those are the type/structure/union definitions.
https://www.dropbox.com/s/z61rqwjvh5n06d5/damage.c
This is the decompiler output for the whole program. Don't trust any of it. Hexrays is normally really good at decompiling Windows programs but the compiler used for Damage was a piece of shit. It has a tendency to generate full 32-bit memory accesses for 16-bit variables/structures. Instead of reading the field of a structure, it reads the field of the 16 bit field before it as a 32 bit field. This loads the 16 bit field before it into the lower 16 bits of the register, and places the REAL field into the upper 16 bits of the register. THEN it performs the x86 "sar" instruction, or shift arithmetic right. This causes EVERY 16-bit variable to appear to be a 32 bit one to the decompiler, and the use of sar causes it to interpret the result as a signed 32 bit integer.

Sometimes the decompiler generates decent code though. I read through the assembly and compare it to the C and normally I just have to change the sections where pointers to 16 bit variables are used. Hexrays is an amazing tool.

And here's the assembly if you're hardcore:
https://www.dropbox.com/s/7eexo86r344r9zb/damage.asm

[Asylum]

I was wrong about swinging_door_data. There is a separate sliding_door_data structure. I've also found a structure named swinging_door_definition, and another named textured_object_definition. I've managed to name the majority of the swinging_door_data fields.

I was wrong about swinging doors being objects. They are actually made up of seven individual objects. One represents the bottom of the door, another represents the top, another represents the center, and then there are four textured objects. The objects representing the top, center and bottom have no associated shapes collection. The four others represent only the shapes. The game manipulates the four to create the illusion of the swinging door.

So far I have no idea how sliding doors work, but they're probably not as complicated.

[Bobwithkeycard]

quite fascinating. Based on the one map editor for Damage Inc I always assumed it was just an object as well, but it seems this either just concerned the placement on the map or it was a workaround since damage Inc's map editor was just an alteration of a M2 map editor's source code.
There were lua scripters who tried to integrate swinging doors into aleph one by exchanging static scenery objects with rotating 3D objects. Of course there was always the problem of collision detection in these efforts.
I'm curous as what you'll be able to tell about sliding doors.

[Asylum]

quite fascinating. Based on the one map editor for Damage Inc I always assumed it was just an object as well, but it seems this either just concerned the placement on the map or it was a workaround since damage Inc's map editor was just an alteration of a M2 map editor's source code.
There were lua scripters who tried to integrate swinging doors into aleph one by exchanging static scenery objects with rotating 3D objects. Of course there was always the problem of collision detection in these efforts.
I'm curous as what you'll be able to tell about sliding doors.

I was amazed when it started coming together. I even started up the game to check, and I realized I could actually see between the different textured_objects. I was wondering whether the same could have been done in lua. I also checked the maps in Obed and found the object that represents the swinging doors. Just to clarify, in the map file they are represented by one object, but after loading the map the game reads the locations for the swinging doors and unpacks them into the seven individual objects. It's a bit of a hack.

I'm a bit mystified by sliding doors at the moment. The sliding_door_data structure is actually larger than the swinging_door_data structure. Also, I am missing the name of one of the functions associated with sliding doors, because it was indirectly referenced. As in, the address of the function is used, not a direct call to the function. very weird for a static ingame object.

Also, some super good news. The issue I was talking about before with bitwise shift >> 16 and shorts and whatnot can be fixed. I've written a script that will find every instance of that sequence of instructions and change it to offset the memory location by 2 and replace the bitwise shifts with the NOP instruction. This is going to clean things up a lot. Also the changed instructions will accomplish exactly the same thing. It'll just allow the decompiler to actually function.

Scripts not done atm but it detected the sequence 2367 times.

[Alric]

Damage was one of my favourite games when I was a child. I haven't played since, but I remember the squad management being the ultimate form of AI in computer games... I won't play it again since I don't want to spoil those good memories.

Also it contained a wolf howl sample that I have heard *everywhere* since. It's featured at the beginning of Kavinsky & Lovefoxxx's "Nightcall" from the Drive OST. I suppose it's one of those samples.

I downloaded this game for PC about two years ago and gave it a (second) play through. Its just as good as I remembered, if not more so now that I'm old enough to understand fire-team level tactics. Sure, its a flawed game in a few ways but if you like to think tactically its fantastic. Just keep in mind the time it was made and that this was the first FPS (as far as I know) to have a controllable fire-team and you'll enjoy it for what it is. I think it's a shame Damage came out as late as it did. By 1997 if your FPS didn't have full 3D polygon graphics no one would give a crap about it.

An Aleph One port would be nothing short of amazing, I always wanted to be able to mod Damage Incorporated past maps.

[Asylum]

I've resumed working on this. Updates will also resume.

My current priority is to finish up the swinging door related functions and document the remaining fields.

[Bobwithkeycard]

ten four. don't let the door hit you on the way in

[Asylum]

No work has been done on this project in a few months. I sort of lost motivation for some time. I think I will begin experimenting with my own fork of A1 with some of DI's features, just to test.

Not DI related, but lately I've been having fun playing with the lua console in A1. I plan on trying to add functionality for modifying the physics model from lua (I've been able to do this in real time with a memory editor to change attributes of projectiles and swap weapon projectiles. Might not work for everything though.)

[Zott]

Glad to hear it is still alive. I was curious about the progress.

[Bobwithkeycard]

hey asylum, in case you are interested: a while back (actually it's been four years now) I put together a mml file just so see to what extent A1 was able to load up Damage Inc. files. I got a couple of levels working, albeit with all the non A1-feautures missing. I lost interest in it once I learned that Damage Inc was using 128 or 512 texture slots in the shapes file instead of Marathon Infinity's 32 and the futility of the effort dawned on me.
Since there was no way of exporting damage Inc's physics for me, I just put in the standard physics for pistol, shotgung, ma-75B and gave the monsters the Trooper's behaviour without able to fire grenades.
It might be of some limited use as a start. Here's a screenshot:

Link to picture

Drop me a line if you want the files

[Asylum]

hey asylum, in case you are interested: a while back (actually it's been four years now) I put together a mml file just so see to what extent A1 was able to load up Damage Inc. files. I got a couple of levels working, albeit with all the non A1-feautures missing. I lost interest in it once I learned that Damage Inc was using 128 or 512 texture slots in the shapes file instead of Marathon Infinity's 32 and the futility of the effort dawned on me.
Since there was no way of exporting damage Inc's physics for me, I just put in the standard physics for pistol, shotgung, ma-75B and gave the monsters the Trooper's behaviour without able to fire grenades.
It might be of some limited use as a start. Here's a screenshot:

Link to picture

Drop me a line if you want the files

Might actually be a better idea than making Aleph One load Damages shapes file. I'm trying to familiarize myself with Aleph One's codebase. I added some new features to it. It used to be all monster attributes like enemies, allies, gravity, speed, intelligence were shared across monster types. You couldn't have, say, two troopers with different speeds. The modifications I made changed that so that the original monster definition was just used to instantiate a separate definition for each monster on the map. I've tested it and it works.

I haven't added lua functions for setting and getting each field of the monster definition yet but changing their collections, gravity, speed, and terminal velocity are all implemented right now. I just did this today so some stuff is not working right now. The individual monster definitions are not saved with save games and I haven't even looked into films yet. Haven't tested with M1 or any scenarios other than Infinity. Hopefully I can get someone to build it on OSX and some people can test it thoroughly.

If I get it working well I'll probably move onto other stuff like projectile instances.

Don't expect it to make its way into A1.

[Bobwithkeycard]

Might actually be a better idea than making Aleph One load Damages shapes file.

Acutally my aim was not to change the original Damage Inc shapes file and have A1 load it up with a help of a custom mml file so A1 would know where to find the basic stuff like collections for wall textures, player torso 'n legs, enemies and everything without A1 quitting to the desktop.
Maybe I've misunderstood your reply, so I apologize for writing things twice (I blame my English): the whole problem is that the damage Inc file uses alot more collections than A1's 32. So since any A1 custom physics and mml file can only point to collections below or equal 32 a Total Conversion of Damage Inc to A1 only gets you so far as perhaps Damage Inc's level 4 until items, enemies and other stuff will appear that is found in damage Inc shapes file only beyond collection 32.
Shape Fusion, the 3rd party shapes editor is still able to load it up, though. From the end user's perspective it seems that they didn't change the M2-shapes format very much apart from maximizing the size of allowed connections (A1: 32, Damage Inc maybe 512, Prime Target 1024).
I only offered the files to you because it's sort of grunt work to tell A1 in a mml file where to find correct door 'n switch sounds, wall texture collections and all sorts of other stuff. Doesn't sound like much, but it's still quite a list of things at the end of the day. Hours not very well spent

I'm trying to familiarize myself with Aleph One's codebase. I added some new features to it. It used to be all monster attributes like enemies, allies, gravity, speed, intelligence were shared across monster types. You couldn't have, say, two troopers with different speeds. The modifications I made changed that so that the original monster definition was just used to instantiate a separate definition for each monster on the map. I've tested it and it works.

sounds interesting, completely individual monsters. Now we could have trooper races, may the most intelligent win

[irons]

Acutally my aim was not to change the original Damage Inc shapes file

just to cheat using lua

[Bobwithkeycard]

never gets old, mate

[Asylum]

Might actually be a better idea than making Aleph One load Damages shapes file.

Acutally my aim was not to change the original Damage Inc shapes file and have A1 load it up with a help of a custom mml file so A1 would know where to find the basic stuff like collections for wall textures, player torso 'n legs, enemies and everything without A1 quitting to the desktop.
Maybe I've misunderstood your reply, so I apologize for writing things twice (I blame my English): the whole problem is that the damage Inc file uses alot more collections than A1's 32. So since any A1 custom physics and mml file can only point to collections below or equal 32 a Total Conversion of Damage Inc to A1 only gets you so far as perhaps Damage Inc's level 4 until items, enemies and other stuff will appear that is found in damage Inc shapes file only beyond collection 32.
Shape Fusion, the 3rd party shapes editor is still able to load it up, though. From the end user's perspective it seems that they didn't change the M2-shapes format very much apart from maximizing the size of allowed connections (A1: 32, Damage Inc maybe 512, Prime Target 1024).
I only offered the files to you because it's sort of grunt work to tell A1 in a mml file where to find correct door 'n switch sounds, wall texture collections and all sorts of other stuff. Doesn't sound like much, but it's still quite a list of things at the end of the day. Hours not very well spent

I'm trying to familiarize myself with Aleph One's codebase. I added some new features to it. It used to be all monster attributes like enemies, allies, gravity, speed, intelligence were shared across monster types. You couldn't have, say, two troopers with different speeds. The modifications I made changed that so that the original monster definition was just used to instantiate a separate definition for each monster on the map. I've tested it and it works.

sounds interesting, completely individual monsters. Now we could have trooper races, may the most intelligent win

Oh sorry. I wrote my reply a couple of hours after reading your post. That's way cooler than what I thought it was. I'd love it if you could send it to me.

Anyway, I've started deviating far from my original goal of just reverse engineering Damage. I'm pretty much working on my own fork of Aleph One now. I don't plan on supporting old films or old savegames in it. Netplay will still be supported. I'm just trying to rewrite the old original C to be cleaner and use OOP and struct/class methods for everything. Once I'm done with this rewrite it'll be so much easier to incorporate new features.

[Crater Creator]

Sounds ambitious, and reminds me a bit of Aleph Modular.

[Asylum]

Much newer version of the hexrays decompiler was leaked. Started using it and I'm pretty impressed with the results. Huge improvement over the version I was originally using.

I'm going to move the Damage code from AN1 over to a fresh pull of A1. AN1's monsters.cpp is a bit fucky unfortunately, and I'm having trouble finding where exactly I messed up there.

[€mancipated]

OH ASYLUM MASTER OF SCIENCE RETURN TO ME.

[Bobwithkeycard]

I too summon thee, leader of the urinal cake society. Lead us to the holy door (preferably swinging )

[Asylum]

The stars recently aligned when a tool called Ghidra was released, which features a decompiler that also targets PowerPC. I've loaded the Mac binary of Damage Inc, which includes debug information, into it and the output looks very clean and doesn't suffer from any of the issues that plagued my earlier attempt. Really all that has to be done is annotating the decompiled code with proper variable names and determining the differences in structures from the original source release.

I'm not saying I'm doing this again, because now I'm an old man with a wife, eleven kids, a full time job and a mistress, but it looks much more doable than it was before. That doesn't mean I have to be the one to do it in the event I disappear again. I also have no idea whether any interest still exists for porting this to A1 or if any of you are still alive (I know Steve passed away a few months ago, god rest his soul.)

[Bobwithkeycard]

yay, Asylum. The trick is to let the kids + the mistress work for you.

Sorry to hear about the death of a community member, though. Guess we're all starting to get grey in some way or another and not even A1 can stop this.

Since I'm not on a first name basis with most around here..what was his handle?

[Lion O Cyborg]

When this is ready and ported, will Damage's movement controls (and their keybinds) be included for use in any branch of Aleph One, even if as a plugin? While we currently have a decent LUA for one of the two functions in question, having both could be useful in making more complex maps e.g. realistically sized air vents for an escape sequence in an M2 Rebellion mission map.

I've recently gotten an abandonware Windows version of Damage and an older A1 build of Excalibur as I wanted to try them out at some point, but having full A1 versions with better resolutions and XLBA style HUDs would be awesome.

[TBCR]

The stars recently aligned when a tool called Ghidra was released, which features a decompiler that also targets PowerPC. I've loaded the Mac binary of Damage Inc, which includes debug information, into it and the output looks very clean and doesn't suffer from any of the issues that plagued my earlier attempt. Really all that has to be done is annotating the decompiled code with proper variable names and determining the differences in structures from the original source release.

To steer slightly off topic in regards, what particular settings did you use for importing in Ghidra? I've had a bit of issues getting PowerPC Mac applications imported successfully unless I do Raw Binary. Even then, the decompiler craps out on Jump Tables.