The DLL Project

[pd]

I'd like to start a discussion thread about this DLL project here.

Firstly, let me inform you about what the "package" contains:

• A minimally edited gamemd.exe. It includes IcySon55's high resolution YR icon for the looks, as well as a disabled launcher notification (ie it can run without ra2md.exe) and, of course, some DLL loader code and required memory.
  The file is probably not going to be changed any further, since all the other edits are possible using the DLL system.
  
• An application currently called "Debugger.exe". It is the new launcher of gamemd.exe that activates the DLL system (running gamemd.exe by itself will run the unmodified game).
  Its name will probably be changed (it's "Debugger" because the app technically acts like one).
  To make Debugger.exe work with gamemd.exe, it has to find a corresponding information file, "Debugger.pdo" (a pdo-file ) which is designed specifically for the target executable.
  I made it a raw data format instead of an INI so people will just leave it alone.
  Debugger.exe currently comes with the YR icon and passes any command line argument to gamemd.exe.
  
• The C++ wrapper for YR 1.001. Put the files into some folder and add it to the include list in your compiler.
  #include <YRWrapper.h> and you have all you need. More on this later.
  

A thing we need to discuss is some coding conventions.
Naming shouldn't be a problem, you can simply adapt to my naming scheme I suppose (I will post a sample header/cpp soon which you can comment on).

Inline assembly is a more critical aspect.
It is essential at many parts, although I will try my best to keep it minimal.
Since I'm writing this on MS Visual C++ 6.0 (which is recommended since the game itself was programmed on it), but its way of implementing inline assembly is different to GCC's way (to name one example).

An example.
MSVCPP:

Code:

_asm{mov ecx, [eax+edx*4+0x3C]}

GCC:

Code:

asm("mov ecx, [eax+edx*4+0x3C]");

As you see, GCC uses just "asm" and uses it as a function taking a const char*, so there's no way to make one notation working for both compilers.
Does anyone know of a compiler-directive that can make out the compiler's internal name?

As you might also see, I use the Intel notation, GCC defaults to the AT&T notation.
The notation can be switched with some flag, will dig it out later.

Finally, as Blade proposed, there should be a central repository for DLLs that are considered authentic.
My current RP2 place can be turned into such a place, I think it would be the best idea.

[TheMan]

hmm sounds very good
I was wondering two smalls things.
Can you write almost everything in a dll file? exempel so voxels can be 2x2 instead of 1x1 and SW clones?
And also how mutch C++ skills is required to write a simple fuction like perma mind controll?

[pd]

There is no "almost" everything, it is everything.

However, some things are not possible in just C++.
The voxel thing for example requires you to find the relevant code in the exe. The code itself can be done in C++ of course, but the place where to hook it you have to find first.
Those are things I will still have to care of.

For new SuperWeapon types and custom Weapons I will most likely deliver good templates.
Perma mind control sounds to me that it just changes the owner but still displays the "captured" anim, things like that will of course be doable.

[Renegade]

I'm still proposing to involve Subversion into this.

I could set up a repository that allows public reading but authenticated writing, so only "real" DLL developers could upload there. DLL source code also be tracked and managed by it.

I just need a few more days to update it, because I can't pull the update over the YaST, and the rpm is putting me into dependency hell -_-
After I updated it, I'll also try to install something like ViewCVS, so we get correct web-access to the repositories once and for all.

[Marshall]

Perma mind control sounds to me that it just changes the owner but still displays the "captured" anim, things like that will of course be doable.

Maybe off topic, but perma mind control also makes the unit un-mind-controllable - so is slightly different to a simple 'change owner' weapon.

[MCV]

Now, I'm not too good with any file that doesn't end in *.txt or *.ini, but, since these Dynamic Link Libraries are extensions of the gamemd.exe, could all the previously implemeted features of RP/RP2 be, for the lack a bettery word, simply ported to a DLL? Without too much hassle? Or would it require a lot of rewriting?

[gordon-creAtive]

This is already planned by pd.

[pd]

OK, here's a first little sample (screenshot and source file )...

This is a way to print information on the screen, either using the MessageListClass (which prints messages similarly to the "LightningStorm created!" message) or using the general text printing routine, which, if hooked correctly, can be used to display always up-to-date information.

In this case I implemented both:
The "MasterKey" function gets triggered if I press whatever key I assigned to "Show Mouse Coords", it replaces that command.
The "PrintDebugInfo" function gets triggered every frame after the map etc. has been drawn.
It comes directly after the -MPDEBUG code, just it doesn't need -MPDEBUG to be enabled.

[TheMan]

Kinda cool. I did not understand a think in the source
I was wondering how long time it took you to write this and how long would it take to write a LS Storm clone?

[Electro]

That. Is. So. Awesome!

[Marshall]

Are MasterKey and PrintDebugInfo wholly new routines, or do they replace pre-existing routines?
If the former, then how does the game know when to call them? Or is this part hardcoded by you?

[pd]

Are MasterKey and PrintDebugInfo wholly new routines, or do they replace pre-existing routines?

They're inside a DLL, ie not even in gamemd.exe, ie wholly new routines.
While you might point out "it replaces that command." from my previous post, that replacement I did on purpose to disable showing the mouse coords.

how does the game know when to call them?

The game does not know, my Debugger does.
Every DLL will come with a control INI file, holding information about what DLL function to call when (ie when the game reaches a specified part of code).
If it reaches one, the Debugger makes gamemd.exe jump to a special piece of code I inserted, attaching the desired DLL to it and calling the desired function.
After that's finished, it will return to where it came from (unless you modify the place to return to using SET_RETURN_EIP).

I will release a long list of code places so you have plenty of options to hook your code.
Giving you new places will stay my job, as that requires exe research like before.

[gordon-creAtive]

The source looks like you could get ready for Gordonpatch

[TX1138]

This is really epic

[~Guest~]

Dupl3xxx~ (I should become a member soon right?)

This is epic indeed! I cann't wait to see what you pd can creat to the game! This is simpely impressive!