Table B - Sections of Main Source (Plugin_trng.cpp)

In this table we mixed (in first column) functions names with ideal sections of the source. In spite this mixage was not so correct, it is a way to describe the position where you have to put your code to do it working fine.
The different section are in same order you find, from top to bottom, in main source and also their names (jn first column of this table) (*) are the same you find in Plugin_trng.cpp source, as comment lines.
(*) Really only in start and final plugin sources there are same section names. In other specific plugins for Crane, SW Robot, MechWarrior, Cleaner robot, the section names could be missing or labelled with a bit different description.
Functions/Sections Contents (To type inside) Decription
Top/Header section #include "Tomb_NextGeneration.h"
#include "structures.h"
#include "DefTomb4Funct.h"
#include "functions.h"
#include "macros.h"
#include "SomeNewHeader.h" // new header created by you
This section is that at top of plugin_trng.cpp and here it will be typed the #include directive to read header files, like "trng.h" or "structures.h"

The #include directive has been used also in NG_Center and also in C++ has same target: the compiler, when it is parsing the main source, if it finds a "#include" directive, it will load in its temporary memory, the content of give header file to have references about its content, that it could be used in main source.

For instance we can see the #include directive at top of plugin_trng.cpp source:

// ------------- INCLUDE HEADERS (.h) FILES -------------
#include "stdafx.h"
#include "string.h"
#include "stdio.h"
#include "math.h"
#include "bass.h"
#include "Tomb_NextGeneration.h"
#include "structures.h"
#include "DefTomb4Funct.h"
#include "functions.h"
#include "macros.h"
#include "macros_mine.h"
#include "constants_mine.h"
#include "structures_mine.h"
#include "Tomb4Discoveries_mine.h"
#include "trng.h"

It's not probable you had to modify the #include directives in top section, but let's say you wish adding a new .cpp source to your plugin...

It may be that you wished divide the code for arguments and so you add a new source named "triggers.cpp" with all code about your new triggers.
Technically it's easy adding a new .cpp file to your projet. Just creating a common text file with notepad but saving it with .cpp extension, placing this file in same folder of your plugin and then selecting the menu command: "Project->Add New Item" and click on "C++ File (.cpp)" item.

The new triggers.cpp source at begin it will be empty but, everytime you need to call some functon placed in other sources, or using a structure or a mnemonic constant, you'll need to give a reference for this stuff to the compiler.
For instance if you wish using the " SendToLog()" function, you'll have to type at top of "triggers.cpp" source, the directive:

#include "trng.h" // list of trng functions imported from trng.cpp source.

Because the SendToLog() function is in trng.cpp source and its reference (to be called) are in "trng.h" header file.
If you wish using some tomb4 structures, like StrItemTr4, you need to add at top of your triggers.cpp source the directive:

#include "structures.h" // structure of tomb4 program and trng dll

Since "structures.h" file contains the definition of all tomb4 structures.

Interesting fact, if you mean call some function present in "plugin_trng.cpp" file, you'll have to create a new header file, with a name like "plugin_trng.h" file (do you see the different extension?! ".h" for header and ".cpp" for C++ source)

Let's say you wish call a function typed in plugin_trng.cpp source, like this:

bool IsMissingWall(StrItemTr4 *pItem, short LookDirection, int *pHeightLimit)
{
int IncX, IncZ;
DWORD TargetX, TargetZ;
// .... other code .....

}

In this case,you'll have to type in your new "plugin_trng.h" header file this line:

bool IsMissingWall(StrItemTr4 *pItem, short LookDirection, int *pHeightLimit);

And then type at top of your "triggers.cpp" source the line:

#include "plugin_trng.h"


Early function declarations DWORD RobotSW_ReadSettings(int ItemIndex);
bool IsValidCeiling(short Direction, int BaseCeiling);
In this section you should type the declaration of local functions (in same source) to avoid the error messages from compiler to have used in advance (called it before its definition) a function.

An easy example to clear the situation:

int MyAnalyse(void)
{
int Alfa;
int Beta;
int Tot;

Tot = PerformMyCompute(Alfa, Beta);

return Tot;
}

int PerformMyCompute(int First, int Second)
{
return First+Second;
}

In above code, we called the "PerformMyCompute()" function before it has been defined in the source.
When compiler will parse the line:

Tot = PerformMyCompute(Alfa, Beta);

It yet doesn't know the "PerformMyCompute()" function and for this reason, there will be an error message.
To fix this problem it will be enough to move (cut and paste) the body of PerformMyCompute() function, above where it will be called, i.e. above the "MyAnalyse()" function, anyway another method is to type in advance, in "Early function declaration" section, the declaration of "PerformMyCompute()" fucntion.
In this example, to avoid the error, we will have to type the declaration of PerformMyCompute() in this way:

int PerformMyCompute(int First, int Second);
Global Variables Section int MyVariable;
char MexWarning[]="Warning: not yet enabled camera";
short VetNumbers[] = {20, -40, 0, 255};
StrItemTr4 *pLara;

In "Global Variables" section you should type the declarations of global variables, initialised or less, that you mean using in different functions of your source.
About this speech, remember to declare in this section ONLY the really global variables. It should have no meaning to declare variables as globals, when they will be used in only one function. In that case you'll define that variable as local, and this means that you'll declare it, inside of function where it will be used.

Note: about initialised variables, like this:

char MexWarning[] = "No door has been found";

Remember that, if you define it as local variable, inside of some function, you should remember always to type also "static" directive:

static char MexWarning[] = "No door has been found";

Otherwise, if you omit "static", the compiler will create dinamically the text (in above example) and this operation will be repeated everytime that function will be called. A terrible wasting of time.
Differently, when you use "static", the compiler assign a fixed address for that string.
This speech about "static" directive on local variable, is valid only for initialised variables. While when you declare a unitilalised variable, like:

int MyValue;
char Buffer[256];

You have not to use "static", with only one exception: if your function return the address of this local variables, like:

return Buffer;

In this new case, ok, you'll have newly to prefix with static directive that local variable:

static char Buffer[256];


Utilities section // verify if in relative Direction respect to object with index = ItemIndex at given Distance
// there is a free an compatible (for height and slope type) sector where the object is able to go
bool IsFreeWay(int ItemIndex, short Direction, int Distance, int HalfWidth, int TopSideY)
{
int IncX;

// .... other code ...

}
This section is very generic...
Anyway this is a good zone where you could type those your functions that will be called from many other, bigger, functions in your main source.
I called them "utilities" because they could be little functions to help other main code.
It's better place here, these utils functions, because they should be above main code, and so: no error from compiler when they will be used, below in the code, and because they are below global variables zone, to be able to use also them these global variables.
Patcher Functions section int PatchPerFastRollingBall(void)
{
static BYTE VetBytes[]={0x66, 0xB8, 0x0, 0x0, 0xFF, 0x15, 0x78, 0x82, 0x62, 0x0,
0x90, 0x90};

return ApplyCodePatch(0x414E8F, VetBytes, 12);
}
In this section you'll copy the functions used to patch dynamically tomb4 code.
You get these function using Trng Patcher, with "Assembly->Create Dynamic Patch Generator" menu command.
In the case your plugin doesn't use patches, you'll let empty this section, of course.
CreateMyCodePatches() function SET_PATCH(PatchPerFastRollingBall) Inside this "CreateMyCodePatches" function, you'll call the patch generator function we saw in previous section.
The syntax is very easy, you'll use the SET_PATCH() macro, typing inside the parenthesis the name of above patch generator function.
Working with previous example, you'll call the generator function PatchPerFastRollingBall, in this way:

SET_PATCH(PatchPerFastRollingBall)

Please, note that using the SET_PATCH() macro, you have to omit the final semicolon ";" character.
Assembly Procedures section // patch_0 to increase falling speed of rollingball when there is OCB 0x80

BEGIN_ASM_PROC(Patch_00)
ADD WORD PTR DS:[ESI+20h],6
test word ptr [esi+ItemFields.OcbCode], 080h
jz MissingOcb
// add more acceleration:
add word ptr [esi+20h], 4
MissingOcb:
LEA EBP,DWORD PTR DS:[ESI+40h]
MOV AX,WORD PTR DS:[ESI+20h]
retn
END_ASM_PROC
In this section you should type the assembly procedures used for your numerical patches.
In our example (at left) you can see the code used to improve the speed of rolling ball.
The macro BEGIN_ASM_PROC() start a zone of inline-assembly code. All following rows, until the END_ASM_PROC macro, should be typed in assembly language.
Usually, if your plugin will create patches on tomb4 code, you'll type here a collection of your little assembly procedures that tomb4 code called.
The name of asm procedure will be typed into the parenthesis of the starting macro:

BEGIN_ASM_PROC(Patch_00)

Then, that name (Patch_00), should be typed in the array used to dispatch the call for different patches:
void *SubPatchArray[] = {

// TYPE_HERE your asm procedure names to call from tomb4 code
&Patch_00,
&Patch_01,
NULL
};

This matter has been described in plugin_sdk_2.htm tutorial about numerical patches.
MainPatcher() asm procedure // All your patch in tomb4 code will call this procedure passing to it, in ax register,
// the number of subpatch to call
BEGIN_ASM_PROC(MainPatcher)
and eax, 0ffffh
mov eax, dword ptr [SubPatchArray+eax*4];
jmp eax
END_ASM_PROC
Really you have nothing to type in this function, anyway I added it to the list in this table, to set the end point of previous "Assembly Procedures" section.
You'll to type all your assembly procedures above the MainPatcher() function
CallBack functions section
// callback procedure to add "Lara's home" level in main title menu
int cbProcTitleMenu(WORD PHASE_Type, DWORD * pInputFlags)
{
RECT MyRect;

if (PHASE_Type == enumPHASE.TITLE_MENU) {
// draw sprite with Lara's home picture
// position in microunits
// 767, 698, 201, 249
MyRect.left = 767;
MyRect.top = 698;
MyRect.right = 201;
MyRect.bottom = 249;
ConvertMicroUnits(&MyRect);

DrawSprite2D(&MyRect, enumSLOT.CUSTOM_SPRITES,
3, 255, 0);

if (*pInputFlags & enumCMD.DRAW_WEAPON) {
// draw_weapon is the space
// we force the loading of level #6
return 6;
}
}
return 0;
}
In this section you'll type the callback functions, i.e. those function that will be called from tomb4 code when a given event (or some kind of moment) happens.

Note that, also in your starting plugin sources, there are already some callback functions in this zone.
For instance, here we have a short list:

cbActionMine() // called when an Action triggers of yours has been performed
cbInitLevel() // at start of a new level
cbSaveMyData() // to save in savegame your data
cbLoadMyData() // to reload from savegame your data

The point is that you could type some code also inside of these default callbacks, in according with their target and your needs


RequireMyCallBacks() function GET_CALLBACK(enumCB.TITLE_MENU_MANAGER, 0, 0, cbProcTitleMenu); In this function you'll use the GET_CALLBACK() macro, to require a callback.
In this request, you'll supply the callback function to call, of course, and this callback function it will be place in previous described section.

For instance:

GET_CALLBACK(enumCB.TITLE_MENU_MANAGER, 0, 0, cbProcTitleMenu);

Note that in this RequireMyCallBacks() function, there are already some callbacks. They are default callbacks.
You could remove them, of course, anyway they are almost always useful for you, so I added them in advance, to permit you to have already some functions where type your code for main targets.
InitializeAll() function // perform all your patches
CALL_CHECK(CreateMyCodePatches)

// call the function that requires all callback you need
CALL_CHECK(RequireMyCallBacks)
In this function you can type code that it will performed only once and when the game (tomb raider screen, splash screen ect) have not yet started.
In this function you can also showing msgbox or other graphic comunication tools that they didn't work when tomb raider game , and direct x interface, has been already enabled.
ReleaseAll() function FreeLevelResources(); In this section you can free all resources used by your level, in the progress of whole game.
This function will be performed only once, just a moment before quiting tomb raider program.