Plugin run-time files


Shortcut Table for run-time plugin files
DLL File (Dynamic-Link Library)
BTN File (BuTtoN file)
          Syntax of Button file
          BUTTON# Tag
                    Some examples about BUTTONs:
                    Usage of special SWAP option
                    The swap.bin file
                    Extra infos in swap.bin file
                    Example of Program using Swap.bin file
          The root path for Button tag and Secondary Files
          NAME# tag
          LOGO# Tag
          OBJ_RENAME# Tag
          COPY# Tag
EXE File (EXEcutable)
          How to manage command line argument in our program
          The DataPath.bin file
          Structure of DataPath.bin file
          Visual Basic code to read DataPath.bin file
          Syntax of mnemonic constants
          Comment and syntax prototype for script commands
                    Placefolder for newline character
OCB File
          Syntax of OCB file
          Mixing your ocb codes with others
TXT File
TRG File
          Syntax of .trg file


          In this document I will talk about plugin files in the meaning of run-time files, while, if you are interested about single C++ source files you should read Table A - Meaning of Source Files
For "run-time" files, we mean those files that will be used from some program (tomb4, ng_center, NGLE) while it is running.
For instance, the ".script" file it will be used while the ng_center program is running.
The ".trg" file it will be used by NGLE program ect.
Differently, the source files used to build the .dll plugin, are not (standalone) used from some tomb raider program but only they will be used to build (in compiling time) the dynamic library.

For each run-time file you should learn from what program it will be used and what syntax it will have.
Most run-time files are, inside, common text files, but they have an extension different than ".txt".

Shortcut Table for run-time plugin files

Run time files of TRNG Plugin

Note: in spite in this table it said where to copy each file kind, it's better let to NG_Center the target to perform this operation, using the [Install New Plugin] button of [Plugin] panel. Indeed, other the copy of right file in right folder, ng_center will create also a sub-folder with your plugin name in its folder to host other files of your plugin and it will perform also some operation to assign a univoque id for your plugin in ng_center
Extension Folder Description
.BTN NG_Center folder BTN = BuTtoNs file
Buttons file is a text file with info about buttons you wish was created by NG_Center program and showed in plugin panel when you plugin become the current plugin.
Each button will launch a .exe program or some help (document) file you added to your plugin run-time files.

Note: This file is required for level builders wishing using your plugin to build a level but it's not necessary for players to play final game.
.SCRIPT NG_Center folder SCRIPT = Script file
.script file is a text file with declaration of your mnemonic constants for your script commands.
Note: This file is always required when you set other files linked with ng_center

Note: This file is required for level builders wishing using your plugin to build a level but it's not necessary for players to play final game.
.OCB NG Center folder OCB (Object Code Bits)
This is a text file with description of new ocb codes you created or changed.

Note: This file is required for level builders wishing using your plugin to build a level but it's not necessary for players to play final game.
.TRG TRLE folder TRG = TRiGger file
The trigger file is a text file where you type the infos about your new flipeffect, action or condition triggers.

Note: This file is required for level builders wishing using your plugin to build a level but it's not necessary for players to play final game.
.TXT Own folder in NG_Center TXT = Text file
This is a file with no rule about internal syntax.
Ng_center will use the text of your Plugin_yourname.txt" file to fill the description frame in plugin panel.
.DLL TRLE folder DLL = Dynamic-Link Library
This is main executable of your plugin.
You'll build it using Microft Visual Express program.
You have to copy it to trle folder and when tomb4 program will run, it will load and link you dll plugin.
.EXE Own folder in NG_Center EXE = EXEcutable file
This is an optional file. If you wish supply extra settings or tutorial about usage of your plugin you can create a Plugin_yourname.exe file.
When you use this chance you should add also a .btn file to inform Ng_center about the name of the button to launch this exe, and further argument to pass to the program on command line.

Note: This file is required for level builders wishing using your plugin to build a level but it's not necessary for players to play final game.
Others Own folder in NG_Center All files enclosed in your plugin's installation package but different by above described files, will be copied to your own plugin folder.
These secondary files will be ignored by NG_Center but they could be used from your plugin.exe file that it will find them in same its execution folder (always your own plugin folder inside ng_Center folder)
Note: it will be seen as "secondary files" that file that, in spite it has some known extension, like ".exe" or ".txt", has not the same your plugin_name.
This means that, if the name of your plugin is: "plugin_LoveBoat" and you insert in your files a file "description.txt", this file will be not seen as your .txt file, because that it should ne named "plugin_loveboat.txt"
Anyway the "description.txt" it will be copied, as secondary file, in your own plugin folder.

DLL File (Dynamic-Link Library)

This file will keep all the code to manage your new skills.
It will be created using Microsoft Visual Express and you'll stand in TRLE folder from where it will be loaded by trng engine when tomb4 program has been just launched.
You can see a description of source files used to build your library file: Table of plugin source files
The .dll file is only one file that it's surely necessary for final user (the player).

BTN File (BuTtoN file)

The button file is a text file with .BTN extension where you type setting to customize NG_Center interface for your plugin.
This file has to be placed in NG_Center folder and it will be loaded by NG_Center program at start-up.

Note: This file is required for level builders wishing using your plugin to build a level but it's not necessary for players to play final game.

Syntax of Button file

Inside of your button file you can use some "tags", i.e. some given words that work like commands.

As you'll see, the syntax of all tags uses the # character to divide different fields
For above reason you cann't use this special character (#) as description or command line options, you can use it only as separator following the syntax rules for that tag.


With button tag, you can force the creation of a custom button in your plugin panel and choosing what to do when user will click on it.
You can have upto a max of eight (8) custom buttons.

The syntax of button# tag is:


Note: if as ProgranName you use the keyword "OPEN" you can use the BUTTON to open some file with default application for that kind of file extension.
In this case you'll type as CommandLineArgument the file to open.

Some examples about BUTTONs:


Now we'll have a button named [Help] and when the user will click on it, the file "demo_help.chm" will be opened by windows with application associated for ".chm" files.


In above case, it will be created a button named [Settings] and when the user will click on it, the (default) program "Plugin_trng.exe" will be launched.
In this case we omitted any command line argument

BUTTON#Fix Collisions#Plugin_trng.exe#-C

Above example it's a bit more complicated...
In this situation we suppose that your plugin had an utility to fix some stuff about collisions of moveable items, probably to be handled correctly from some skills of your plugin.
This case is very alike of that of "Tools" panels of ng_center. I created many utilities and for each of them there is a button to launch it.
When you create some utility it's better do not supply a lot of little programs but, differently, create all these utilities in same default .exe of your pluging (in our example it is "plugin_trng.exe") and then using an argument on command line to dispatch different utilities.

In our example, the "-C" option is that we have tought to force the section about collisions in our exe.
Then we can use any other option for other utilities and, in spite the program that will be launched it is always the same (our default program), inside of that, we could dispatch different sections in according with current option of command line.
See How to manage command line argument in our program

Usage of special SWAP option

BUTTON=Edit Script#plugin_trng.exe#SWAP

Usually you can choose yourself the options to pass to your program, anyway the SWAP option has a special meaning recognized by NG_Center.
When a button has a SWAP option (alone or mixed with other, divided by spaces), NG_Center will save in your exe folder a file named "swap.bin"

The swap.bin file
The swap.bin file contains current script.txt and strings loaded in NG_Center program.
Using these data you can know current script and change it.
About this speech, it's important you understood that you cann't, with your program, simply modify script.txt or english.txt files in script folder, since NG_Center has own copy loaded in memory and your changes on disk files will be ignored.
Fortunately, using swap.bin file, you can have always the current script loaded in NG_Center, to parse it or to change it.
Once you changed it, you can send a special message to NG_Center to force the updating of script with your changes, always saved in swap.bin file.
Other that reloading your modified script (or strings), you can also set some basic command to ng_Center, like to build the script or to change currently showed panel.

Extra infos in swap.bin file
Other that current script and strings, swap.bin file contains also a list of window handles that gets possible a greater control, from your plugin.exe, of NG_Center interface.
You get the handles of all main listbox, comboboxes, other that the handle of RichTextBox of NG_Center, where script is currently loaded.
Using above handles you could get same target (to receive/update script) performed with swap.bin file and sending of update message.
Anyway, who is not an advanced programmer, it will find easier usign other method of swap.bin file also to send changes to NG_Center.
In the plugin_trng.exe vb sources, you find a "Mod_PluginExe.bas" module, that contains most important functions and constants to handle this interaction with NG_Center program.

Example of Program using Swap.bin file
In "PLUGIN_SDK_STORE\Plugin\plugin_exe_VB6_sources" folder, you can find the Visual Basic 6 sources of plugin_trng.exe demo, where the program show current script and strings, gotten from NG_Center, and then allows to update in NG_Center the changes and giving the command to build the script.

The root path for Button tag and secondary Files

You should avoid to type a path (with folders) for the exe file to launch or for your secondary files to OPEN.
Remember that all files of your plugin will be copied to same folder and ng_center when it will execute the code of your custom buttons, will set always the default folder to the folder with your plugin files.
Technically, this folder is not the main folder of NG_Center because there could be the risk of name conflicts for (*)secondary files of different installed plugins.
Your plugin will have its own sub-folder with same name of your plugin, hosted in main folder of ng_center program.
So, if for instance your plugin has then name "plugin_stukas.dll", in NG_Center folder there will be a subfolder named "PLUGIN_STUKAS" and in this sub-folder there will be all files of your plugin.
About the circustance that it's necessary that the .script file of your plugin it was in main ng_center folder, this is not a problem. Ng_Center when the user will install your plugin, it will copy the .script file in the main ng_center folder.
In this case, indeed, there is no risk to confilict since all plugin will have a different name and the .script file is a default plugin file.

(*)Note: For secondary file I mean those files those are not default plugin files. In this document you are seeing what are the default plugin files: all these files have same file name ("plugin_yourname") with different preset extensions: .dll, .script, .btn, .exe, .txt, .trg

When you insert in the zip file of your plugin, other files, not standard, like a file named "help_about_my_plugin.doc", this is a secondary file.
Since secondary files could have any name, it could happen that two or more plugins had two secondary files with same name and it is own to avoid this problem that each plugin will have its own sub-folder.

NAME# tag

You can have only one Name# tag in your .BTN file.
With name# tag you can set a descriptive name for your plugin.

NAME#Descriptive name of plugin

Usually you'll type as descriptive name the extended name with version data and your name (of the author)
For instance:

NAME#Demo of plugin features by Paolone (version 1.0)

The descriptive name you typed in this tag will be showed in plugin panel in a single row belove the plugin combo list.


With logo# tag you can set an imge that it will be displayed in plugin panel when your plugin has been selected.


For instance:


Above example will draw the image "mylogo.jpg" that you have enclosed in your plugin package on the plugin panel when your plugin is that selected.

Note: the image will have a size of 941 x 265 pixel, once it has been drawn on plugin panel, anyway you can supply images of any size and ng_center will resize it to fill the 941x265 image area.


This tag allows to rename the name of some moveable item. The new name you supply it will be visible in NGLE (ex room editor) and Wad Merger program, other that in all tools using objects.h file to get the object name list.


For instance, if you wish rename the moveable with slot ID = 420 (and old name "DEATH_SLIDE") as new name "BLASTING_WALLS" you can use this tag:


It should be better do not overindulge in this renaming chance, because with many different plugins, if each of them changed (renamed) many slot names this could create a chaos between level builders when they had to talk about moveable item and their names.
For this reason my suggestion is taking care before renaming a slot, in according with following rules:


Copy tag will be performed only in the phase of installation of your plugin.
When a level builder install your plugin using the [Install New Plugin] of Plugins panel, NG_Center will perform a copy of some file of your plugin in the pre-set folder you set with COPY# command.


PluginFile will be a file you supplied in your plugin files, while TargetFolder is the path where you wish that file was copied.
In target folder field, you can use preset-folder for current trle folder, typing the "$TRLE$" macro.

For instance if you wish copy a file to current trle folder you can use a tag like this:


In above example you have supplied in your plugin files the "DivPlayer.dll" and with above command NG_Center will copy this to current trle folder.
In this way you plugin_yourname.dll will be able to use the "DivPlayer.dll" since it is already in same trle folder where plugin.dll stands.

You can add also sub-folders to pre-set macro.
For instance if you wish copying a file to DATA folder of current trle folder, you can use a tag like this:


In above example the file "newlogo.bin" it will be copied to current trle\data folder.

EXE File (EXEcutable)

If you wish supply an additional program for your plugin, you can create your program and then reame it as "Plugin_yourname.exe"
Then you should supply also a .BTN file with at least the definition of one custom button for your plugin panel.
When you set above stuff, the user will se one (or more) button in your plugin panel, and clicking on it, your program will be launched.

Note: really it's not necessary that your .exe file had a "plugin_yourname.exe" name. Anyway it should be advisable give that standard name for main executable used to support your plugin in generaly way, while you can add other executables, with any name, for some specific targets.

How to manage command line argument in our program

We could do an example in visual basic to manage the arguments on command line.
We should place following code in management of "Form_Load" event, in main form.

Private Sub Form_Load()
Dim Argument As String

Argument = Command
Select Case Argument
          Case "-C"
                    'detected "-C" argument on command line: show only the window (form)
                    'to manage collisions
                    Unload Me
                    Exit Sub

          Case "-V"
                    'detect "-V' argument on command line: show only the window (form)
                    'to manage vehicles
                    Unload Me
                    Exit Sub
End Select
'no argument on command line: continue to load main window (form)
End Sub

Seeing above code we can see that:
  1. The argument will be present in default global variable "Command"
  2. When we find the option "-C" we'll launch the form "FormCollisions" where we'll placed all code to manage collisions
  3. When we find the option "-V" we'll launch the form "FormVehicles" where we manage some stuff about vehicle
  4. When we don't find any option, we'll let loading the main form of our program

Note: above abstract it is only a chance to manage this swapping, of course. You can organize the management of command line arguments in many other ways.

The DataPath.bin file

Just a moment before launching your exe file, NG_center will save a little file named "'datapath.bin" to same folder where is your exe file.
In this file there are some info about important folders for trng/trle management.
You find the trle folder (selected currently in ng_center), the ng_center folder and other folders of populars tomb raider tools that users had set in ng_center program: trviewer folder, wad merger folder, strpix folder and metasquoia folder.
If your program needs to know some of above folder (usually the "trle" folder), just you add the code to read the content of "datapath.bin" file in same root folder where your program stands.

Structure of DataPath.bin file

In datapath.bin file each folder path has a fixed size of 256 characters.
When the real path is shorter than 256 characters, the extra characters (at right or after...) will be filled with spaces.
The sorting of folders in datapath.bin file is this:


Visual Basic code to read DataPath.bin file

To read datapath.bin file and extracting the folder names you can use a function like following (written in visual basic 6 syntax):

Public Function ReadPathDataInfo() As Boolean
Dim NF As Long
Dim FileName As String

FileName = App.Path & "\datapath.bin"

On Error GoTo ErrorHandler

NF = FreeFile
Open FileName For Binary Access Read As #NF
Get #NF, , DataPath
Close #NF
ReadPathDataInfo = True
Exit Function
Call MsgBox("Error trying to load 'datapath.bin' file: " & Err.Description, vbCritical)
ReadPathDataInfo = False

End Function

Above function should be copied to some .bas module (since it is "public") or you can change it as "private" and copy everywhere you wish.
Above code use a global (public) structure (datatype) that you should declare at top of some .bas file in this way:

Public Type Tipo_PlugigPathInfos
PathTrle As String * 256
PathNGCenter As String * 256
PathWadMerger As String * 256
PathStrPix As String * 256
PathMetaSequoia As String * 256
PathTrViewer As String * 256
End Type

Public DataPath As Tipo_PlugigPathInfos

Then you'll use above stuff in this way:

dim PathOfTrle as String

          if (ReadPathDataInfo() = false) then
                    'error already displayed: abort, quit
          end if
          'the datapath it has been read correctly, now to copy to your variable the path of trle (for example) we can do in this way:
          PathOfTrle = Trim(DataPath.PathTrle)

Note: We use the "Trim()" function to remove the non meaningfull space from paths stored in DataPath structure. If you do not use visual basic you should find anyway a trim function in your programming language.
In the missing of this you should parse the 256 character of the path beginning from last character (with index = 255) and coming back until you find spaces. When you detect first non space charfacter from right you'll have reached last meaningful character of current path


Also the .script file is a common text file.
In the "plugin_yourname.script" file you type your mnemonic constants for Customize= and Parameters= commands.
Since each Customize or Parameters command has different syntax and argument number in according with their CUST_ or PARAM_ first value, you can use this method to have your custom commands.
Note: Differently by other optional files, the ".script" file is always required, at least when you supplied any other file (like .btn) to link your plugin with ng_center.
In the (weird) case you have no need to declare own constants you can use an empty "plugin_yourname.script" file but it's necessary supply anyway it, because ng_center will allocate a record for plugin only when it detects the presence of .script file.

Syntax of mnemonic constants

For each constant you'll type a single row divided by 2 or 3 fields, following this syntax:

ConstantName:ConstantValue;Description of constant

The last field, "Description of constant" is optional, anyway it's advisable typing always some description for each constant.
Note: please take care that while first separator is a colons ":" to divide name by value, the second separator is a semi-colon ";" to introduce the comment
For instance:

PARAM_FOLLOW_TARGET:32 ;Force enemy to follow the target you set with previous flipeffect trigger

In above example we declared a new PARAM_ constant with name "PARAM_FOLLOW_TARGET" and value "32" (decimal) and as comment the text "Force enemy to follow the target you set with previous flipeffect trigger"

Note: the ConstantValue will be seen as decimal by default, anyway you can type hexadecimal values typing dollar sign ("$") at begin of the number.


In above example we typed three constants, probably flags, using hexadecimal values.

Comment and syntax prototype for script commands

The comment that you type after a semi-colon character is important not only to describe the meaning of the constant but also to inform NG_Center program about the prototype of script command linked with current constant.
For "proto-type" we mean a description of number and names of different arguments of some given script command.
For instance when you type in this script a text like this:

Customize= CUST_AMMO, _

In quick info row of ng_center program you'll be able to see infos about next argument to type and also the list of following arguments for current script command:

To have same infos also for your Customize or Parameters commands, you have to add to the comments of the given CUST_ or PARAM_ constant, a row with those information.
For instance we could type following text in our .script file:

PARAM_FOLLOW_TARGET:32 ;Used by Parameters=command.>Syntax: Parameters=PARAM_FOLLOW_TARGET, IdParameter, IndexNewTarget, IndexEnemy, Flags (FOLF_...)>Force enemy to follow the target you set with previous flipeffect trigger

Placefolder for newline character
Above example is a bit messed, the reason is that to simulate the carriage return and new-line character, the syntax of .script file requires to use the "greater than" character ">"
This is necessary because all data about a mnemonic constant has to stay on only one row, anwyay ng_center will expand all ">" characters as new-line.
So we can repeat above example, showing like it will be exapaned, since it's more clear to understant in this shape:

PARAM_FOLLOW_TARGET:32 ;Used by Parameters=command.
Syntax: Parameters=PARAM_FOLLOW_TARGET, IdParameter, IndexNewTarget, IndexEnemy, Flags (FOLF_...)
Force enemy to follow the target you set with previous flipeffect trigger

Once it has been expanded, the comment maybe also multirows and in particular way it's useful the row beginning with keyword "Syntax:"
When NG_Center finds in the (expanded) comment of a constant, a row beginning with "Syntax:" keyword, it will use the remaining of that row like proto-type infos to show in ng_center program when the user is going to type the corresponding command and mnemonic constant.

Note: You can place (or remove, temporarily) the ">" characters manually, anyway if you use the "text-editor" program supplied in plugin sdk binaries, you can use the command menu "Filter" to remove new-line and replace them with ">" character of selected text, or perform the vice-versa.

The easiest way to work, indeed, should be to type normally the text with real new lines, and only when you typed all description and syntax for current constant, you'll select whole text and then with "Filter->Toggle returns and put ">" characters" menu command, you'll convert the multi-linee text to correct single line with fake new-line characters.

OCB File

The .ocb file, is a common text file where you'll type the description of further new ocb codes that you created or changed for yours or by others, objects.
The descriptions you'll type, will be showed in reference panel of NG_Center program in the "OCB LIST" section.

Note: This file is required for level builders wishing using your plugin to build a level but it's not necessary for players to play final game.

Syntax of OCB file

Description of the ocb code
of current object.

In ocb file there are NO separator characters, excepting the new line character used to divide the name of the object with the description for its OCB codes.
It's necessary introduce the name on a single row with the keyword "#START_TAG#=", followed by the name of the object.
The name of object should be the same you see in "OCB LIST" section, otherwise in the ocb list your ocb description will be hosted in some duplicated item of another object.
For instance in "OCB LIST" section you find the object "_NEW SideCar".
If you wish add your ocb to this object you should use exacalty same name "_NEW SideCar" because if you used a name like "MOTORBIKE", in "OCB LIST" section, it will be create another new item with name "MOTORBIKE" but levelbuilder could be confused to see two different names for same object.


$200 = Requires lara had fired torch in her hand
$400 = Requires lara had switched off torch in her hand

In above example we added two ocb codes for object "SWITCH_TYPE3" and we'll find this description in OCB LIST section at the row with SWITCH_TYPE3 in first column.

Mixing your ocb codes with others

With your plugin you'll be able also to add new ocb codes for objects having already some OCB (of default tomb4 engine or trng) and in this case your description will be added to previous description of that object.
To help level builders to discover the news, the plugin addons will be added at top of the description, in spite they are newest and perhaps it should be more logical adding to the end, like the end of a improvement path.
Anyway I believe it was better getting more visible the news and since the first row will be showed just in OCB list, also before clicking on that row to see full description, the earliest plugin will have their ocb at top, then older plugin, and at end the default tomb4 or trng ocb settings for that object.

In this situation it could happen that you wish rewrite the description of some already used OCB value.

This situation is a bit problematic, since NG_center is not able to recognize single ocb values in the description to replace their description.
For this reason you'll have to describe this situation when you explain the changes you did on that ocb value.

For instance the current (tgrn) description for "_NEW Boats" begins in this way:

Boats, rubber boat or motorboat, accetp the same type of OCB:

You can use of following values or a sum of them to enable in same moment different features:

1 = Show lights in front of boat

and then other texts...

If you changed the source of boats to have a different behavior for ocb 1 about lights, you'll type this change in your plugin_yourname.ocb file, creating a section like following:

1= With OCB 1 now the lights of the boat will work in a different way: the light will change in according with the lightness of current room.

Above it's only a example, of course, but it's good to explain how inform level builder that some old ocb now has a different behavior thanks to your plugin.
About this speech, note please that it's not necessary you introduce above description with the name of your plugin: "When you use Plugin_Fedora the ocb 1 will change this way", because NG_Center will divide each ocb description with the name of its plugin.
For instance coming back to our example for ocb 1 of boats, the level builders will see in the description of "_NEW Boats" objects this text:

---------- FROM PLUGIN: Plugin_Fedora ---------------------------
1= With OCB 1 now the lights of the boat will work in a different way: the light will change in according with the lightness of current room.
--------- FROM TOMB4/TRNG ----------------------------------------
Boats, rubber boat or motorboat, accetp the same type of OCB:

You can use of following values or a sum of them to enable in same moment different features:

1 = Show lights in front of boat

In above example we supposed your plugin was "plugin_Fedora", of course.

Note: the "_NEW" in front of some object it's not a real keyword but it is only a little trick to place at begin of the list the new ocb (set by trng) for some objects.
Anyway that _NEW is a part of the name of the given object in the list, therefor, if you wish add ocb for some object with "_NEW" in front, you'll have to type that prefix also in the name of the object in your .ocb file.

TXT File

You can manage the content of this file as you wish, anyway since Ng_center will use the text of this file to fill the description frame in plugin panel, you should type here a short description of main features of your plugin, date of creation, release, trouble shooting, ect.

I suggest also to give a short description for your furthrer extra tools engaged with custom buttons of your .BTN file

About text files to add to your plugin files, I suggest also to add a generic "read_me.txt" file where you'll give to the users, a short info about how to install the plugin.
For instance:

To install this plugin:
1) Launch NG_Center program
2) Move on [Plugin] panels
3) Click on [Install New Plugin] button and choose the zip file or the folder where all files of this plugin have been saved.

TRG File

To create your new triggers you have to pass to NGLE (room editor) some infos about the description of the trigger: its internal number and its further arguments.
All these data will be typed in a text file with extension ".trg" (like .TRiGger) and with the same name of your plugin.
In spite that its extension it's not ".txt" (warning to avoid to save it as a common text file) the content will be only text.
For instance, the file name for trigger file of "Plugin_Trng", it will be: "Plugin_trng.trg"
To be read from NGLE program, it's necessary that your TRG file was in trle folder.

Note: This file is required for level builders wishing using your plugin to build a level but it's not necessary for players to play final game.

Syntax of .trg file

Internal syntax of .trg file is a bit complicated, anyway you can have a full description in How to add new Triggers help file