The DLL Project

[pd]

I'm not developing all day.
So I'm happy to answer it all, hehe.

Out of interest, how much of the RP2 'core' is done and how much work are you anticipating for DLLs?

The RP2 "core" (being YR++) is like the exe research, it cannot be "done". It would be done if I had the game's entire source code. Therefore, I won't be able to give you something like a progress bar for it.
For the first release, I plan this base to cover the most important classes, that is the whole AbstractType tree (all the INI defined stuff basically) and a good part of the AbstractTree (every ingame class) including the whole ObjectClass tree (everything visible).
You must be able to spawn and control units, animations, particles, warheads, etc, in order to make this any useful.
These things are progressing well. In this particular case I might say 66%.

Extra stuff like primitives drawing, SHP drawing and input handling are things I cannot give any progress about, I have nothing specifically planned for it.
You can handle mouse events now and add custom CommandClasses (functions you can bind to the keyboard), draw rectangles and SHPs and make text appear either in the MessageList (top left, like "Warning: Lightning storm approaching" or w/e) or just somewhere on the screen (tooltips, debug info).

The big big thing is callback functions.
Callbacks allow me to actually modify the game's code and add to it.
It is through callbacks that the DLL gets used at all. And I will need to define a lot of them to assure full control.
The largest bunch of callback code done is for SuperWeaponTypes, and in all you can already code your custom SW.

Is there anything that members of the community are likely to be able to help with at this stage? I know nothing about C++ but I understood most of what that code example is doing.

Unfortunately no.
The compiler must compile all my class definitions and function callings and stack frames so that they look and work *exactly* like in the game's executable, thus this is still a kind of hacking process.
That code part is an example of things you will be able to do once we have a good YR++ base to work with.

Defining the callback functions is basically exactly the same thing I did before in order to add or modify functionality, ie this is hacking.

Also, I gather that the intention is that all bug fixes (e.g. neutral MCVs IE) should be fixable through DLLs, or will certain changes that you have in mind require you to directly alter the executable?

The intention of the DLLs are that I don't have to tussle with all the ASM and hex and stack bugs and so on.

Almost everything that exe modifying could do can be done using these DLLs:
- Removing code, by simply jumping somewhere else.
- Modyfing code, by recoding the bit you want modified.
- Adding code.
- Modify rw data, by simply overwriting it.

What we can not do using DLLs is modify read-only data, but right now I cannot think of a point in RP development where that was necessary, except for dialogs.
The modified dialogs can be included in the DLL though, with a different ID than the original, and then you can just change that ID used in code.

In all, the only exe modification is my addition of the DLL loader code, and that does only get used if you run the game via Debugger.exe. If you run normally via gamemd.exe, no modifications are applied, which is a huge benefit IMO.

Wait a minute, where do we determine HouseClass:: Player() ? I'm guessing that refers to the local client in which case that would desync in multiplayer?

You don't determine it, it already is.
HouseClass:: Player() returns a pointer to the current player, sitting at the very computer.
IE online, for you, it will return a pointer to your HouseClass instance, for your friend X, it will return a pointer to his HouseClass instance. For this code that means, whoever clicks will own the MCVs spawned.

HouseClass:: Player() needs to be a function because it reads from the game's RAM directly. And since it's possible that the pointer changes while the exe runs (eg you go back to the menus and start another game), it needs to always the return the pointer as of the time you call it.

wait, you're calling it Ares? thats a peer to peer downloader... my brother uses it.

Yeah, I've heard of it.
If people want to download that filesharing client and all they get is some DLL file, they'll probably notice that something is wrong.

This is no official or commercial or that large project that it should create any confusion.
Since everyone is calling this RP2 anyway, who knows whether that name change will succeed at all...

EDIT:

Code:

virtual void vt_entry_50C(
    DWORD dwUnk,DWORD dwUnk2,DWORD dwUnk3,DWORD dwUnk4,
    DWORD dwUnk5,DWORD dwUnk6,DWORD dwUnk7,DWORD dwUnk8,
    DWORD dwUnk9,DWORD dwUnk10,DWORD dwUnk11,DWORD dwUnk12,
    DWORD dwUnk13,DWORD dwUnk14,DWORD dwUnk15,DWORD dwUnk16)
{
    PUSH_VAR32(dwUnk16);PUSH_VAR32(dwUnk15);
    PUSH_VAR32(dwUnk14);PUSH_VAR32(dwUnk13);
    PUSH_VAR32(dwUnk12);PUSH_VAR32(dwUnk11);
    PUSH_VAR32(dwUnk10);PUSH_VAR32(dwUnk9);
    PUSH_VAR32(dwUnk8);PUSH_VAR32(dwUnk7);
    PUSH_VAR32(dwUnk6);PUSH_VAR32(dwUnk5);
    PUSH_VAR32(dwUnk4);PUSH_VAR32(dwUnk3);
    PUSH_VAR32(dwUnk2);PUSH_VAR32(dwUnk);
    THISCALL(0x41C090);
}

THIS IS WHY NOBODY CAN HELP ME!