Loading trigger files without overriding existing ones

If we could get a programmer to look at the format of the trigger file then perhaps we could merge files external to the editor but otherwise there's no way that I know of.
 
requiem_for_a_starfury said:
If we could get a programmer to look at the format of the trigger file then perhaps we could merge files external to the editor but otherwise there's no way that I know of.

I was hoping I might get lucky that someone already did it. I googled around the net, and didn't find any solutions on .trg files. Passed around the office, no one seemed interested. Now we need a programmer who is interested and familiar with custom file formats reverse engineering. I hex edited the trigger files by using control groups and can make out file header and body. Without knowing the file format, it will be a tedious process to pick it apart using hex. I guess we will go from here.

I also emailed Micro Forte, hoping to get some answers on this. Someone posted a year ago in this forum stating he was getting some answer back from Micro Forte (that is refused to release the source code). We are not asking for source code this time, just file format. The format might have been something cooked up by some developer not working there anymore. But we might get lucky.
 
Hello.
Saved triggers in TRG file are compressed with deflate algorithm. First two 4 byte doublewords mean the size of decompressed TRG file. The rest of data is a compressed data of a script file. Here you can download the example files. The example files contain only one trigger:
Name: Exit
Conditions: Always
Actions: Turn Exit Grids 'On'

Decompressed scripts can't be loaded into trigger editor.

Because TRG file contains only scripts you won't be able to add a completely new script functions, only that which are coded in bos.exe file.
 
The first tutorial mission contains conditions that aren't available in the editor, though you can save the triggers and import them into other maps. Would there be a way of telling if there are any other unavailable scripts then?
 
I examined missions: "tut1.mis" and "tut1.bak" and found four new conditions:
Gui 'None' is open
Gui 'Loot' is open
Gui 'Char' is open
Gui 'Inv' is open

Next exported triggers from both missions. These trigger files have an identical contents.

Here you can download compressed and decompressed trigger file from tut1.mis file and check that. I think that triggers editor shows all triggers even that unsupported by the editor, but didn't test this.
 
jarekfall said:
Hello.
Saved triggers in TRG file are compressed with deflate algorithm. First two 4 byte doublewords mean the size of decompressed TRG file. The rest of data is a compressed data of a script file. Here you can download the example files. The example files contain only one trigger:
Name: Exit
Conditions: Always
Actions: Turn Exit Grids 'On'

Decompressed scripts can't be loaded into trigger editor.

Because TRG file contains only scripts you won't be able to add a completely new script functions, only that which are coded in bos.exe file.

Thanks, Jarekfall. How did you decompress the TRG file? I removed the first 8 bytes from a compressed TRG file and try to decompress it using 7-zip (which can decompress deflate compression). The operation was failure.
 
requiem_for_a_starfury said:
Would there be a way of telling if there are any other unavailable scripts then?
I decompressed tut1.mis and calculated the size of the triggers section directly in the file which size is 12030 bytes, the same as the size of exported file of triggers after its decompression. This means that editor shows all triggers even that unsupported.

I edited bos.exe and found actions and conditions names section which offset is from 0x4ABCB0 to 0x4AE148. I casually looked through the contents and found new conditions:
ObjDudeAlive
WeaponModeEquals
WorldPlayerModeEquals
RightClickOnTab
and more names for condition: Gui 'name' is open

It seems to me that there are no new actions.
ryuga said:
Thanks, Jarekfall. How did you decompress the TRG file? I removed the first 8 bytes from a compressed TRG file and try to decompress it using 7-zip (which can decompress deflate compression). The operation was failure.
This is not so easy, in order to decompress only a compressed data you can't use any of archiving tools because they look for a specified archive structure, you have to download "zlib" library and code your own application. These 8 bytes, exactly first four because the second four are useless, are important for proper memory allocation for the decompressed data.
 
jarekfall said:
requiem_for_a_starfury said:
Would there be a way of telling if there are any other unavailable scripts then?
I decompressed tut1.mis and calculated the size of the triggers section directly in the file which size is 12030 bytes, the same as the size of exported file of triggers. This means that editor shows all triggers even that unsupported.

Are the MIS files also deflate compressed? How did you find out what file format for those MIS and TRG files? Did you use tool or just domain knowledge or both?

jarekfall said:
I edited bos.exe and found actions and conditions names section which offset is from 0x4ABCB0 to 0x4AE148. I casually looked through the contents and found new conditions:
ObjDudeAlive
WeaponModeEquals
WorldPlayerModeEquals
RightClickOnTab
and more names for condition: Gui 'name' is open

It seems to me that there are no new actions.
I looked at offset 0x4ABCB0 to 0x4AE148 with ultraedit, and the bytes are not readable. Did you decompiled bos.exe?

jarekfall said:
ryuga said:
Thanks, Jarekfall. How did you decompress the TRG file? I removed the first 8 bytes from a compressed TRG file and try to decompress it using 7-zip (which can decompress deflate compression). The operation was failure.
This is not so easy, in order to decompress only a compressed data you can't use any of archiving tools because they look for a specified archive structure, you have to download "zlib" library and code your own application. These 8 bytes, exactly first four because the second four are useless, are important for proper memory allocation for the decompressed data.

Thanks. That is one step I need to do for an external program to combine triggers in TRG files. I was wondering why the 2nd 4 bytes were repeating the 1st 4.
 
The weaponmodeequals sounds interesting I wonder if the script is still in there or just the condition name in the exe. If we were able to get a trg file with that activated we could dispense with tagging weapons for silent attacks and just have a silencer mode and silencer entity.
 
Jarekfall,

One more question for you. For the decompressed trg files I noticed that the first 7 bytes (between string "<TriggerManager>" and "<Trigger>") at offset of 0x10h seems to be different for different TRG files. Any idea on what they represent?

Thanks ahead,
ryuga
 
ryuga said:
Are the MIS files also deflate compressed? How did you find out what file format for those MIS and TRG files? Did you use tool or just domain knowledge or both?
Yes they are. The game probably uses the "zlib" compression library. These files are deflate compressed: SPR, TRG, MIS, SAV. SPR is more complicated. Not compressed files: ZAR, ENT, TIL. These files have often a small size. So it is better to place them all in a single compressed archive instead of compressing each small file which would give worse compression degree. I wasn't the first who had discovered that game files are deflate compressed. This is the only thing that I had to know in order to decompress these files. The data is compressed when it doesn't have repeating values in range, for example 10 bytes. I used knowledge, as I said earlier I had to write my own program. I tested it on compressed files in debug mode. You could use "Ftdewo" tool for the MIS decompression, which should be in NMA files, but before that you would have to do some HEX editing.
ryuga said:
I looked at offset 0x4ABCB0 to 0x4AE148 with ultraedit, and the bytes are not readable. Did you decompiled bos.exe?
No I didn't. I used old and primitive but very good for quick HEX editing DOS application "DOS Navigator". I have never worked with "UltraEdit" but worked with other advanced programs. I advise you to look for the data section viewer, every modern app. should have such option.
ryuga said:
One more question for you. For the decompressed trg files I noticed that the first 7 bytes (between string "<TriggerManager>" and "<Trigger>") at offset of 0x10h seems to be different for different TRG files. Any idea on what they represent?
The game creators used in every file type (trg, mis, spr,...) the same naming convention. First is the string "<TriggerManager>\01\0" describing the type of file and version of this file (offset 0x00 - 0x12). Next is DWORD value describing the number of triggers in the trigger file (0x13 - 0x16). The rest of the data contains description of each trigger.
 
Thanks for the help, Jarekfall. Your help made writing the program much easier.

I am using .net 2.0 deflate, and got compression and decompression working over the weekend for the TRG files. Hardest part after your help was figuring out .net 2.0 deflate uses RFC 1951 instead of RFC 1950 (RCF 1950 is zlib; which seems agree with you that MicroForte used zlib); which means I need to chop off first 10 bytes instead of 8 for decompression.

The next part is combining the TRG files which is why asked you about the 2nd DWORD in decompressed file.

Thanks again. Hopefully I can get the program tested and out by this weekend.


requiem_for_a_starfury said:
The weaponmodeequals sounds interesting I wonder if the script is still in there or just the condition name in the exe. If we were able to get a trg file with that activated we could dispense with tagging weapons for silent attacks and just have a silencer mode and silencer entity.

We need to find out the syntax for the weaponmodeequals condition, then it should be easy to add it into TRIGGER program I am writing. I will take a look once combine trigger function is complete.
 
Just finished CombinedTrigger program, console version. Now it is time to put a GUI on it.
 
Back
Top