Demo-code Released

[Eddy-B]

It took me quite some time today, but i've managed to back-engineer the code of the outpost 2 demo's. In doing so, i've also learned how to use UnitBlock and UnitRecord.

The purpose: so we can all learn how to use the code. I've tested both source files, they compile and run just like the original demo "missions". I've inserted as many comments i thought necessary. I hope this will get the new coders going.

For now, there's only the 2, but i'll work out the 3rd one tomorrow:  Demo's source code (wiki)

Good luck!

[Leviathan]

nice work

[Eddy-B]

Third source file has been added, and i cleaned it up a little bit, added some links etc.. : Demo's source code (wiki)
 

[BlackBox]

Looks good. I was planning on looking into the UnitBlock myself, so we could use it, but it seems that won't be necessary (as you took the time yourself

I believe each UnitBlock class has a CreateUnits method as well, so it might be possible to create unit blocks that way as well.

Anyway ... good work!

[Eddy-B]

The use of UnitRecords is almost identical to what we use now (BaseData.h), except that the UnitRecord/UnitBlock structures are created by Dynamix, and the other op2helper format by OPU.

A UnitRecord is defined much in the same way as you'd be accustomed to when using op2helper:

Code: [Select]

UnitRecord record_name_here[]=
{
  { unitType, X, Y, 0, orientation, weaponCargo, unknown, cargo, amount },

  // a line of zeroes ends the list
  { mapNone, 0, 0, 0, 0, mapNone, 0, 0, 0 }
};

The unknown above seems to be 16 (0x10) in all 3 demo's. I tried changing it to a different value, but it just gets reset 15 (0x0F) after the UnitRecord was used in the UnitBlock constructor. So i think it more of a return value from UnitBlock then it is an input param.

For orientation, i've included a new enum (see below) that behaves differently then the Direction enum you use with TethysGame::CreateUnit.

Code: [Select]

enum Orientation
{
  orE  =0x00,
  orSE=0x20,
  orS  =0x40,
  orSW=0x60,
  orW  =0x80,
  orNW=0xA0,
  orN  =0xC0,
  orNE=0xE0
};

The UnitRecord itself does not have to be EXPORTed, but if you plan to use it with TethysGame::CreateUnitBlock you MUST EXPORT the UnitBlock, so Outpost2.exe can find it; the same way you'd export trigger-functions, using my EXPORT directive (or the SCRIPT_API as defined in the SDK headers). Of course you could also just use the declspec directly, but be sure to include extern "C" so the compiler will not decorate the exported name with its type information as it normally does will all exported identifiers.

Code: [Select]

EXPORT UnitBlock block_name_here(record_name_here);
TethysGame::CreateUnitBlock(Player[xx], "block_name_here", 0);

I do not yet know what the third param does. Just leave it 0 for now.

The above instruction creates the units immediatly. If you want them to a group, this is not necessary; just use AddUnits:

Code: [Select]

FightGroup grp=CreateFightGroup(Player[xx]);
grp.AddUnits(block_name_here);

[HaXtOr]

Looks good. I was planning on looking into the UnitBlock myself, so we could use it, but it seems that won't be necessary (as you took the time yourself

The UnitBlock was one of the first things that I looked at when i first started codeing levels...? you even helped me? I guess we forgot to report our findings lol

[Mcshay]

I'm curious, how do you do you get code from a mission dll?

[Sirbomber]

Yes, it would be very useful if we could look at the campaigns.

[Axalon]

I would guess you have to use a disassembler, but you'd need to be proficient in x86 assembly to be able to do anything with it.

[Sirbomber]

Eddy-B told me that'd be nearly impossible to do this to any "real" missions. (Campaign, colony game, etc.)

[Eddy-B]

I managed to decompile the 3 demo missions, because they are small. I spent roughly 2 hours on each dll to extract the source lines. As you can see they're not too big.
Extracting was done using OllyDebug - looking at the raw assembler code, and deducting the c++ lines one at a time.

As i told you, this could be done because they are fairly simple and straight-forward, no complex trigger structures. As for my Renegades, you can judge by DLL size (NONE of the original dlls surpass any Renegades' dll size) it takes a lot more than just 2 hours to decompile those. On top of that, i use dozens of global variables, events and the IUnit stuff.. added to the local variables (that c++ stores on the stack) it would suffice to say: you won't be able to decompile them, unless you are a hardened hacker !  (I, myself would not even be able to decompile my own dlls).
The Dynamix dlls are somewhat less elaborate then mine, but still a task for a very advanced hacker.
 

[BlackBox]

It's possible, but yes you have to know what you're doing.

I'd recommend first learning x86 disassembler. That in itself isn't enough though, you need to know how common C++ compilers store data and represent certain language constructs at the low level.

One book I'd recommend would be "Hacker Disassembling Uncovered" by Kris Kaspersky. It tells a lot about how various compilers do different things at the low level. (though it does assume you know x86 assembly as well as plenty of C++)