Jump to content


Member Since 09 Apr 2007
Offline Last Active Sep 17 2019 03:41 PM

Posts I've Made

In Topic: Request for a new modding tool: a conflict analyzer!

18 December 2015 - 02:28 PM

Ok, thanks for that info Mike. Thats helped clear that up for me. Cheers.

In Topic: Request for a new modding tool: a conflict analyzer!

18 December 2015 - 04:50 AM

Ok thanks, i see now that it uses them later in the DEFINE_PATCH_FUNCTION:

      REPLACE_TEXTUALLY ~[%lnl%%mnl%%wnl%][- %tab%]*$~ ~~ // remove any empty lines
      REPLACE_TEXTUALLY ~^[- %tab%]*~ ~%class_prefix%~ // make sure entries are indented by one space

I assume as the patch its not saved (with OUTER_INNER_PATCH_SAVE), the WRITE_BYTE's inside it arent actually written to any file, just temporarily in memory so that the value is assigned to the string as you said, for later reuse as variables in the patch function?

In Topic: Request for a new modding tool: a conflict analyzer!

17 December 2015 - 09:01 PM

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 :D


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:


  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



From line 733 onwards in setup-g3daletweaks.tp2:


/////                                                  \\\\\
///// Universal Clubs                                  \\\\\
/////                                                  \\\\\


// 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

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.

In Topic: Request for a new modding tool: a conflict analyzer!

06 December 2015 - 12:59 PM

I had considered the regex / wildcard issue with files, and i was thinking along the lines of not so much parsing files and finding conditionals and evaluating them for possible modifications, but more along the lines of potential conflicts generally.


In that instance id only be interested in the commands that potentially modify the files, the WRITE_BYTE in the example above.


Sure you could have a lot of files that are touched to modify by multiple mods, but i think it still would be valid to consider all as potential conflicts until resolved by user reviewing logs or by adding in some sort of exception rules for filtering output - that would be based on info from experienced modders and others that know what is ok and what is not, like it may be fine for any mod to modify byte 1f of an .itm file without issue, or maybe only in certain circumstances - i dont know myself.


If i was writing the above tool, thats what i would be aiming for. Doing most of the heavy collating work and outputing the data and leaving the review/judgement of what is right/wrong for a possible conflict for others - which would also help refine the tool once i know what is ok.

In Topic: Request for a new modding tool: a conflict analyzer!

06 December 2015 - 10:41 AM

The debug files may be of use, but still requires parsing them AND installing each mod. By parsing the tp2 files before installation it would give you the best hope of determining some conflicts.