Advanced Usage - hakasapl/PGPatcher GitHub Wiki

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.

Processing Options

Allowed Record Types

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.

Mesh Allowlist / Blocklist

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 named folderA at any point of its path
  • meshes/folderA/a_mesh* - This will match any meshes in folderA that start with the name a_mesh*
  • *a_mesh* - This will match any mesh with a_mesh within its path

Texture Rules

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.

ESMify Plugin

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.

Multithreading

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.

Enable Mod Dev Mode

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

Enable Debug / Trace Logging

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.

CLI Arguments

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!

--console

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.

--autostart

Enabling this flag will skip the launcher window. PGPatcher will just start patching with the previously saved settings.

--highmem

Enabling this flag enables high memory mode. This caches every mesh in memory on the first read to avoid re-reading the mesh later in the mesh patching process. This uses a lot of memory, way more than the raw size of the mesh files, since it is decompressed in memory. If you have a lot of RAM to spare and want a few extra seconds saved, you can try this. If your system runs out of memory with this option enabled, the runtime will be significantly slower.

--force-light

Forces light mode in the GUI (here for parity, the GUI is already light mode)

--force-dark

Forces dark mode in the GUI. This is experimental but seems to work well for most people.

--force-always-cm

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.