Repository navigation
Advanced Usage
If you do not want to use the more advanced customization options PGPatcher has, you can ignore this page. Most users do not need to care about this.
With this window you can tell PGPatcher which records to patch in plugins. In the list is every record type (using xedit naming conventions) which is modeled (has a MODL record component). These are the only records PGPatcher patches.
Disabling a record type means PGPatcher will never patch that record type and therefore its corresponding mesh. However, if a certain mesh appears in multiple records, but some are still enabled, PGPatcher may still try to patch the mesh for those records that are enabled. If a mesh needs to be patched for this case, PGPatcher will duplicate that mesh as part of its mesh permutation system and leave the original mesh unpatched to ensure that the record type that is ignored remains fully untouched including the mesh attached to it.
These windows allow you to tell PGPatcher which meshes to patch based on file paths. I would generally recommend not using this unless absolutely necessary as relying on file path rules can be hit or miss. There are default blocklist rules that should not be removed unless you know what you are doing.
If any rules exist in the allowlist, PGPatcher will only patch meshes matching those rules. PGPatcher will not patch any meshes that match rules in the blocklist. The allowlist is processed first, then the blocklist after that.
The rule syntax is very simple. The rules match file path relative to the data directory, with support for wildcards. Here are some examples:
-
meshes/folderA/folderB/a_mesh.nif- This will match exactly 1 mesh -
meshes/folderA/*- This will match any meshes in folderA and its subdirectories -
*/folderA/*- This will match any mesh within a folder namedfolderAat any point of its path -
meshes/folderA/a_mesh*- This will match any meshes in folderA that start with the namea_mesh* -
*a_mesh*- This will match any mesh with a_mesh within its path
The texture rules window allows you to tell PGPatcher what type of texture something is. This is very rarely needed. PGPatcher must determine the type of the textures in your load order to determine how to patch meshes. For instance, for PGPatcher to patch a shape for parallax, it has to know that a certain texture is a parallax map. PGPatcher determines texture type by first reading every mesh in your load order and analyzing shader types and texture sets to infer texture type. If a texture does not show up in any meshes, PGPatcher uses standard suffixes to infer the texture type. In almost all cases, this results in an accurate determination of texture type.
For very rare cases where this automation doesn't work (always due to mod authors not following naming conventions properly), you can set the type of a texture manually in this window. The left column should have the path of the texture relative to the data folder. For example: textures/folderA/folderB/texture.dds. Texture rules do not support wildcards. The right side will give you a dropdown to select the texture type.
Texture rules can also be used to tell PGPatcher to completely ignore a texture when considering patching. You can do this by setting the texture type to unknown.
Enabling this will ESMify the PG_X.esp plugins in the output. You should only enable this if you know what you are doing and your entire load order is ESMed.
Enabled by default, disabling this will force PGPatcher to use a single thread for processing. This will make it much slower, however, it can be useful in debugging the application should there be a multithreading-related bug.
Enables certain warning messages which aid in mod development for PGPatcher:
- Warning when PGPatcher does not patch a shape due to a missing texture from the output of a PBR json
These options allow you to enable debug and trace logging. These can be helpful for troubleshooting and we may ask you to enable these and provide a log when requesting support. Trace logging is very verbose, expect on the order of hundreds of MB of text files if you enable that.
If a customization option is a CLI argument instead of a GUI option, it means it is either not recommended to use ever or can break things. Here be dragons!
Enables the console. If you used PGPatcher prior to 1.0 you may remember it used to be console only. That backend never changed, but the console is now hidden by default. If you like seeing all the messages live you can re-enable it with this flag.
Enabling this flag will skip the launcher window. PGPatcher will just start patching with the previously saved settings. This argument will always do the Start Patching pipeline not the Update Output pipeline.
Enabling this flag will skip the launcher window. PGPatcher will just start patching with the previously saved settings. This argument will always do the Update Output pipeline not the Start Patching pipeline.
Enabling this flag will tell the Upgrade Parallax to Complex Material patcher to always upgrade to complex material instead of only when required. This will result in no parallax shader in your game, only complex material. This should never be needed, but some people want it.
Disables dynamic cubemap for complex material patching. Only use this if you need to have dynamic cubemap disabled in ENB or CS.
Ignores the check to make sure PGPatcher is running from within MO2 when you have MO2 selected. This is useful only for Linux users.
Considers patching all meshes, not just those that are used by in the game in plugins.
This flag will force PGPatcher to avoid patching any facegen meshes.