Table A - Meaning of Source Files
Source Alterable Description
PlugIn_trng.cpp YES This is the main source.
In this source you'll type the code to "animate" your triggers or script commands, or to change/improve old trng features.
This main source has different procedures with different targets. You'll type your code in one procedure or other in according with the kind of target you wish get.
To examing in depth the main source and its procedures see also the Table B - Sections of Main Source (PlugIn_trng.cpp file)
trng.cpp NO The trng.cpp file contains code with utilities you can "call" from your main source, the plugin_trng.cpp source, but you cann't change this source. It is a code interface with tomb_nextgeneration functions and it could be changed in next updates to improve its features.
Tomb_NextGeneration.h NO This is an "header" file, like all files having the ".h" extension.
An header file is like the MNEMONIC CONSTANTS list of reference panel of NG_Center program: it contains flags and constant, values, with an assigned mnemonic name that you can use in your Plugin_trng.cpp file.
The Tomb_NextGeneration.h source, contain (almost) all constants you see in MNEMONIC CONSTANT list of NG_Center program and very often they will have same name.
For instance reading this header you can find lines like following:

#define MIR_WEST_WALL 0
#define MIR_FLOOR 1
#define MIR_CEILING 2
#define MIR_INVERSE_WEST 3
#define MIR_EAST_WALL 4
#define MIR_SOUTH_WALL 5
#define MIR_NORTH_WALL 6

for mirror command, or other list like:

#define TGROUP_USE_FOUND_ITEM_INDEX 0x0001
#define TGROUP_USE_TRIGGER_ITEM_INDEX 0x0002
#define TGROUP_USE_OWNER_ANIM_ITEM_INDEX 0x0004
#define TGROUP_SINGLE_SHOT_RESUMED 0x0008
#define TGROUP_OR 0x0010
#define TGROUP_NOT 0x0020
#define TGROUP_ELSE 0x0040
#define TGROUP_CONDITION 0x0080

Above are flags for TriggerGroup script command.

You can use in your code these values like they were numbers, own like it happened in script.txt when you typed some of above constants.

Note: the "0x" pair of characters have in C++ language the same meaning of "$" charachter in MNEMONIC CONSTANTS list: "0x" introduces an hexadecimal value.
Constants_mine.h YES This header file has same meaning of Tomb_NextGeneration.h source, but this is yours.
In this source you can type your mnemonic constants, using same method already seen.
Use #define and then the name you wish assign to some value, and at right the value.
For instance:

#define KEEP_ALWAYS 1
#define KEEP_NEVER 2
#define KEEP_ON_SHOOTING 3

then in your plugin_trng.cpp you'll be able to use above values with their names:

if (Timer == KEEP_ALWAYS) {
... code when timer of trigger is = 1
}

if (Timer == KEEP_NEVER) {
... code to perform when timer is = 2
}

ect.

Note: when you use numbers to identify a given feature, behavior or action, it's always better using it as mnemonic constant, otherwise in the futute it will be complicated for you understanding your (old) code.
structures.h NO We said that the header (.h) files contain #define to assign mnemonic constants but in the reality the headers could contain also other stuff.
The structures.h file contains definition of structures.
A structure is a group of variables, all assigned to some "object".
You can think that a structure about Lara is like a form about a person, where you'll find different rows with a blank space to fill its value:

First Name: ______________
Second Name: _____________
Phone Number: __________
Age: ____
Address: _________

ect.

Native tomb raider program used intensely structures to describe all different moveables, statics, collisions, rooms ect.
Well, in structures.h header there are the definitions of all tomb raider items, other that some trng strctures to host data of script command or triggers.
We'll work very often with these structures, for instance when you wish change some data of Lara we'll use her structure: pgLara
If you try (after having called GetLara() to copy to pgLara the contents of her structure) a text like this:

pgLara->
you'll see a list of all fields of lara structures, with their coordinates (x,y,z), flags for mesh visibility, current stateid or animation ect.
You'll be able to compare these values to have a condition about them, or you can change them simply typing something like:

pgLara->MeshVisibilityMask = 0;

With above instruction lara will have all mesh as invisible.
While to let visible only the head:

pgLara->MeshVisibilityMask = 1 << 14;

Note: the text "1 << 14" means:

multiply by 2 the value 1 for 14 times (binary left shift of 14 positions)
It is a way to get the bit for mesh number 14 (the head) and copy only the absolute value of that bit in MeshVisibilityMask field of lara.

Anyway you can type also directly the absolute value:

pgLara->MeshVisibilityMask = 0x4000;
structures_mine.h YES This header file is yours, you can type here the definition for your own structures.
If you understood what is a structure you can understand that it's a way to organize better your variables in a single group when all these variables are about the same object or feature, trigger ect.

If you read the content of this header you'll see that is not empty.
The reason is that plugin_trng sources have already some stuff added by default to hanle basic features, like catching your customize or parameters script command, saving or reloading your variable in savegame files ect.
You can add to the defintion of:
typedef struct StrMyData {
}

the variable you wish having always available with your MyData global structure.
For instance if you type inside of brackets pair { } of StrMyData structure this line:

int DistanceFromTorch;

When you, in plugin_trng source, you'll type:

MyData.
(look the period .)
Visual Express will show to you the list of all your variables (fields of MyData structure) and in that list now there will be also "DistanceFromTorch"
DefTomb4Funct.h NO We call "function" a block of code that performs some target.
There is a function to burn lara, another function to detect if lara is colliding with some moveable or static ect.
A function is like a trigger that performs something...

A program like tomb4 (but also your plugin.dll library) is a compilation of functions.
Across the years I discovered the target of many tomb4 functions.
The names and arguments they use, it has been defined in DefTomb4Funct.h header file.
Thanks to these definiton you'll be able to call from your plugin these tomb raider function.
For instance:

DisableBaddieAI(Index);

using above code, when in Index variable there is the index of some enemy, you'll toggle to him the AI skills, and it will freeze like an animating.

The infos to use the function DisableBaddieAI() are in DefTomb4Funct.h file but really also in other definition file named "functions.h" source.
While in "DefTomb4Funct.h" there is the list of arguments (in above example "index" is the only one argument of "DisableBaddieAI" function), the functions.h header, contains the memory address where the code of that tomb raider function begins.
See following row in this table...
functions.h NO In "functions.h" header file there are all addresses for tomb raider functions that I discovered.
This header works in according with "DefTomb4Fucnt.h" header file to be able to call tomb raider function from your plugin code.
Tomb4Discoveries_mine.h YES This header is your version of "DefTomb4Funct.h" and "functions.h" files.
If you discovery what is the target of some tomb raider function, you can type in this header the info to call that function using a mnemonic name.
Look the contents of "DefTomb4Funct.h" and "functions.h" source to understand the syntax to use.
A little example about syntax to use.
If you discover that at address 0x4216B0 of tomb 4 code, there is a procedure that receives two argument: an index of moveable item and a constant value and you suppose that this procedure affects some ai stuff, you could type in your "Tomb4Discoveries_mine.h" source following text:

// definition of ChangeAI_Item function:

typedef void (__cdecl *TYPE_ChangeAI_Item) (short EnemyIndex, int Parameter);

// declaration and assignment of value of ChangeAI_Item function:

TYPE_ChangeAI_Item ChangeAI_Item = (TYPE_ChangeAI_Item) 0x4216B0;

Now in plugin_trng.cpp source, you'll be able to call that code in this way:

ChangeAI_Item(Index, 32);

In above instruction we passed to the function the index of some moveable (stored in our "Index" variable) and the constant value 32 (as Parameter).
trng.h NO The "trng.h" source is the header for "trng.cpp" source code.
This header is like a bridge between the trng.cpp source and your plugin_trng.cpp main source.
Thanks to this "bridge" you'll be able to call the functions of trng.cpp source like they were in you plugin_trng.cpp source.

In fact, another stuff we can find inside an header file is an extern declaration of functions or variable.
When you write the code of a function in a source, for example we call this source code: "alfa.cpp" source, and then you wish use that function in a different source code (for instance "beta.cpp"), the compiler cann't "see" that function.
Example:

------- Alfa.cpp source --------------

char * GetString(int StringIndex)
{
.... code of this function, to return the text of string with given StringIndex
}
------- end of Alfa.cpp source -------

Another source is beta.cpp:

------ Beta.cpp source -----------

char *pText;

pText = GetString(32);

---- end of beta.cpp source

In above situation, the compiler (microsoft visual express) is not able to locate in "beta.cpp" source the code of "GetString()" function, because it has been written in another source (the alfa.cpp source)
To solve this problem, just informing the compiler about the existence of that function, giving its name and its arguments, using an extern declaration in beta.cpp souce, like this:

extern char *GetString(int StringIndex);

In this way you can use functions written in different sources.
In trng.h file there is a list of all functions written in "trng.cpp" source but that (thanks to "trng.h" header) you can use in your "plugin_trng.cpp" source.

Note: the example of external declaration above:

extern char *GetString(int StringIndex);

It's right and it works fine, anyway the "extern" keyword is not necessary for functions because the compiler is able to recognize the extern declaration from the main code function.
The trick, to distinguish them, is looking what there is after the final ")" character.
When there is immediatly a semi-colon character ";", it is an extern declaration (since there is no commands in this function), while when after the ")" there is an open bracket {, it will be the main code of that function.
To save time I've not used the "extern" keyword in front of extern declarations of functions but you can use it if you believe that the code was more easy to be understood with that syntax.
macros.h NO With this header we discover another stuff we could find in header file: the macro definition.

A macro is a simple "find & replace" text skill, but it may be very nice to simply the job to write code or to get this job more understandable.

Some commands that I created for level builders (those in CAPITAL letters) are own macros.

Main advantage to use macros is to reduce the text to type to have a given code.
We'll use this chance when we have to type same code many times with only a little difference.

The main difference between a common #define assignment and a macro is that the macro has arguments.

For instance we can see the definition of BEGIN_ASM_PROC macro, in macros.h source:

#define BEGIN_ASM_PROC(ProcName) \
__declspec(naked) int ProcName(void) { \
__asm {

In the round parenthesis there are arguments, in above case only one "ProcName"
The "\" character at end of each row means "the macro goes on to next row and here you (the compiler) will have to do a new line.

Above macro definition will be used in this way:

BEGIN_ASM(GetFireSize)
... asm code to manage the size of fire...
END_ASM

The compiler will expand our macro definition

#define BEGIN_ASM_PROC(ProcName) \
__declspec(naked) int ProcName(void) { \
__asm {

in this way:

__declspec(naked) int GetFireSize(void) {
__asm {

}

Pratically the compiler did a "find and replace" of text set as arguments in the text after first "\" character.
Note: above macro used to introduce a function with assembly code.
Since the syntax for these function is a bit complicated, using this macro we can get an easy way to type the same code.
Instead typing everytime functions like these:

__declspec(naked) int GetFireSize(void) {
__asm {

we can type simply:

BEGIN_ASM_PROC(GetFirseSize)

The macros are used very often own to manage assembly code, since the main problem with assembly is that it's necessary typing many rows of code only to get a little result, but with a macro we can type a single row (a macro) that it will be expanded in an higher number of assembly rows.
macros_mine.h YES This is your own header to define your macros.
When you understood how to create macro definitions you'll add in "macros_mine.h" header all these definition of macros and then you'll be able to use your macros in plugin_trng.cpp source, like they were functions or new commands.
StdAfx.cpp
and
StdAfx.h 		NO StdAfx files are not interesting for us.
They have been created from Microsoft Visual Express and added to our sources for technical reason.
They have been used by compiler to improve the speed of compiling about many windows header files.
We do not use them but it's better let them in our project avoiding to modify them.