I started some preliminarily coding to test the viability of creating a tool as mentioned in the above posts. So far the test program does the following:
- Recursively walk base game folder to collect all existing files and to collect tp2 files seperately for later parsing
- Process main game chitin.key for resource entries (filenames) which are used later for pattern matching
- Custom parser, parses tp2 files to handle the keywords of interest
- Support for INCLUDE keyword, which recursively calls the parse function
- Build file lists from COPY, COPY_EXISTING
- Build file list array from ACTION_FOR_EACH, which is used to build a file list for %file% or other %<var>% type variables found in COPY_EXISTING
- Build file list from pattern match using PCRE library for COPY_EXISTING_REGEXP GLOB
Still not sure of the results of all of this, as in the information collected may be too much to break down into meaningful analysis, or may not be enough. Or i may go mad trying to figure it all out
Some keywords ive skipped processing for the moment as they would require even more heavy coding to catch all specific examples: INNER / OUTER keywords that read data from existing IDS files and apply these to a %<var>% for later use in COPY_EXISTING, or OUTER_INNER_PATCH where filename to apply to is not clear or is not used till later on in the tp2 file. Anyhow ill have to do some more reading of the weidu docs to figure some of it out.
Although if someone can help explain the following and how it applies to the tp2 file and in particular where and how in the script that would be helpful:
In setup-g3daletweaks.tp2 (just as an example test file to try and process) it has an include for extra_regexp_vars.tpa that contains the following:
OUTER_INNER_PATCH ~12~ BEGIN WRITE_BYTE 1 0x09 READ_ASCII 1 tab (1) // 0x09, tab WRITE_BYTE 1 0x0a READ_ASCII 1 lnl (1) // 0x0a, Linux WRITE_BYTE 0 0x0d READ_ASCII 0 mnl (1) // 0x0d, Mac READ_ASCII 0 wnl (2) // 0x0d0a, Windows END
From line 733 onwards in setup-g3daletweaks.tp2:
/////\\\\\/////\\\\\/////\\\\\/////\\\\\/////\\\\\/////\\\\\ /////\\\\\/////\\\\\/////\\\\\/////\\\\\/////\\\\\/////\\\\\ ///// \\\\\ ///// Universal Clubs \\\\\ ///// \\\\\ /////\\\\\/////\\\\\/////\\\\\/////\\\\\/////\\\\\/////\\\\\ /////\\\\\/////\\\\\/////\\\\\/////\\\\\/////\\\\\/////\\\\\ BEGIN @202000 DESIGNATED 2020 GROUP @9 // this file does nothing, it just allows other mods to detect this component COPY_EXISTING ~sw1h01.itm~ ~override/cdi02020.g3~ INCLUDE ~g3daletweaks/lib/extra_regexp_vars.tpa~ // needed for regexp matching // some really clever coding stolen from bg2t // this does the work of our description patching when fed a few regular expressions and replacements DEFINE_PATCH_FUNCTION ~REMOVE_MAGE_LINE_FROM_USABILITIES~
Is there somewhere later in this part of the DEFINE_PATCH_FUNCTION that the OUTER_INNER_PATCH info from the extra_regexp_vars.tpa file is used? As in where and how is it evaluated in this specific example. Any help will be useful. Thanks.