Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Categories

Dark Dreams of Furiae - a new module for NWN:EE! Buy now
Attention, new and old users! Please read the new rules of conduct for the forums, and we hope you enjoy your stay!

NWN EE userpatch.ini unofficial FAQ

GrymlordeGrymlorde Member Posts: 121
Disclaimer -- I do not have nor ever had any affiliation with Beamdog or BioWare. What follows is in no way official. It is just a collection of experiences from the members of Neverwinter community and my own.

What is the userpatch.ini?
Userpatch.ini is an initialization file in plain text format that tells NWN.exe to load a set of haks before a module is loaded. This is done for every module, similar to the override folder. In 1.69, this file was called nwnpatch.ini. With EE you can still use nwnpatch.ini but it does not appear to load any GUI elements whereas userpatch.ini will do so.

Why should I care about userpatch.ini?
Because it is a clean and easy way to upgrade the visual appearance of the game. Don't like the standard goblins? No problem, load up Cervantes' Creature Compilation and now all goblins look a lot better (IMHO). Don't like the astroturf-looking fake grass in the rural tileset? Load up BioRural from Zwerkules or Toro's Expanded Rural and get a much, much better looking rural tileset (IMHO). Another consideration is that there is performance boost from preloading haks rather than filling up the override with individual files. In v1.69, having too many files in the override became an issue. This might be fixed in EE or might now.

Awesome! How do I set it up?
Create a text file using your favorite text editor (e.g. Notepad) in your Neverwinter Nights directory (e.g. \My Documents\ Neverwinter Nights) and save it as "userpatch.ini" Then add the following lines:
[Patch]

PatchFile000=XYZ

PatchFile001=Another Hak

PatchFile002=Yet_Another_Hak
Where "XYZ" is a particular hak you wish to pre-load. Note that there is a blank line between [Patch] and the first PatchFile entry and between the first and subsequent PatchFile entries.

Note that the order is important. The first hak is loaded first, the second is loaded second and so on. The second hak overrides the first, the third overrides the second, and so on. This is important to know because some haks have some overlap with others. So if you like LoW's ghouls better than the one in Cervante's hak, then make sure you load Cervantes' hak before you load Low's Ghoul hak.

Updating your nwn.ini file
In order for NWN to know that it has a userpatch.ini to use, you must first change your nwn.ini file. Find the "[Alias] section and copy & paste the path to the hak files and rename "Hak=" to "Patch=":
Hak=C:\Users\YOURNAME\Documents\Neverwinter Nights\hak
Patch=C:\Users\YOURNAME\Documents\Neverwinter Nights\hak
Note that your actual path may look different from this. Just ensure that "Patch" points to the exact same place as "Hak" does.

Are there any limits?
Yes! In NWN v1.69 (might be different in EE) there is a limit of 56 haks that can loaded in total -- this includes all the haks in the module itself. There does not however, appear to be a limit in the size of an individual hak itself.

Are there any bugs or issues with this method?
In 1.69 (not yet tested in EE), all haks had to have significantly different names. According to PsteMarie, “x4_females” were originally named “x4_anatomy1,” “x4_anatomy2,” and “x4_anatomy3” respectively; it appeared that only “x4_anatomy3” was loading. This would seem to indicate some sort of hardcoded value that the engine limits the number of strings the engine reads from the filenames in patch.ini. If the files are the same name up to this string value, only the topmost file is in the hierarchy is loaded."

What about the override folder? Is it obsolete?
It just might be... I'll leave it to others to make a case for still using the override folder.

Warning for Builders!!!
It should be obvious, but it's worth saying -- If you build your module with userpatch haks instead of including haks in the module, then that content will NOT appear when you distribute your module. Not only that, but it will load in the toolset without warning the user that a particular hak is required. My advice is to include all haks in your module that you need rather than counting on the user loading them in the userpatch.

There is no patch directory! Do I have to create one?
No you do not. In 1.69 you either had to copy your haks into the patch directory or change the nwn.ini file to have the patch point to the hak directory. In EE, the nwn.ini file defaults to pointing patches to the hak directory.

Credits & Thanks
Thanks to @virusman, Dagesh, @Pstemarie, @Shadooow , & Bannor Bloodfist for contributing to the original discovery and discussion on the old social.bioware boards. Thanks also to @Symphony for telling us to use userpatch.ini instead of nwnpatch.ini and to @Proleric for discovering that userpatch.ini loads UI elements whereas nwnpatch.ini does not.

Post edited by Grymlorde on
JFKsquattingmonkDerpCityProlericthirdmouseFlashburnSymphonyAtrophiedericdunahanpscythevoidofopinionCalgacusIsewein
«1

Comments

  • SymphonySymphony Member, Developer Posts: 142
    Things are getting a little weird with Workshop override folders and install/game directory separation, but using patch haks, which is a method I used from an "ancient" tutorial @Pstemarie put out, is a much much cleaner way of packaging and using altered "permanent" changes to the game, than dumping thousands of files into your override folder and trying to wonder which ones came from which install.

    Additionally, there are some game resources, that only seem to go into effect if placed in a hak instead of in the override folder.

    To this date, for checking work in game, instead of using the override folder I use a hak called override.hak that's in my patch folder, which allows me to turn off my work in progress at a moment's notice if I need to go be a dungeonmaster for an afternoon on short notice.

    Thanks for the post @Grymlorde .

    AtrophiedericdunahanGrymlordeIsewein
  • JediMindTrixJediMindTrix Member Posts: 299
    Apologies for the thread necro, BUT:
    My installation did not automatically have a PATCH path in nwn.ini, and it took me a while to notice this as I tried in vain to get userpatching to work.

    Add this underneath [Alias]
    PATCH=patchpathhere

    AtrophiedericGrymlordeIsewein
  • BalanorBalanor Member Posts: 172
    edited May 2018
    Is it intentional that patch haks do not display their changes in the 1.74 toolset? For example, when I open up areas in the toolset that have tiles which are changed by my patch hak, it's just their default appearance that is displayed. Only when I launch the client can I see the changes that a patch hak has made.

    This was not the case in 1.69 as you could see what the patch hak modified when you opened a module in the toolset. It may not be the biggest deal, but it was still nice to be able to see what things will really look like in-game when designing in the toolset.

  • GrymlordeGrymlorde Member Posts: 121

    Apologies for the thread necro, BUT:
    My installation did not automatically have a PATCH path in nwn.ini, and it took me a while to notice this as I tried in vain to get userpatching to work.

    Add this underneath [Alias]
    PATCH=patchpathhere

    @JediMindTrix - thanks so much for catching that missing step! I'm very sorry about that. I've updated the FAQ. And by the way, no need to apologize for a thread necro as this is a sticky.

    JediMindTrix
  • GrymlordeGrymlorde Member Posts: 121
    edited May 2018
    Balanor said:

    Is it intentional that patch haks do not display their changes in the 1.74 toolset? For example, when I open up areas in the toolset that have tiles which are changed by my patch hak, it's just their default appearance that is displayed. Only when I launch the client can I see the changes that a patch hak has made.

    This was not the case in 1.69 as you could see what the patch hak modified when you opened a module in the toolset. It may not be the biggest deal, but it was still nice to be able to see what things will really look like in-game when designing in the toolset.

    @Balanor - Wow! You're right! I'm so used to building with the haks I want that I didn't notice the patch haks not showing up in the 1.74 toolset. That is definitely a bug! Please report it. I don't work for BeamDog so I can't help in that way. Having said that, I very strongly encourage you and all other builders to put haks in your modules rather than relying on the userpatch method if you ever intend to distribute your module. As builders, we can't assume that all of our players will have the exact same userpatch.ini that we do. Whereas by including haks in our modules, we know that the content will always be there.

  • RoiDesCreoles_NWnRoiDesCreoles_NWn Member Posts: 7
    question, if a hak is in a userpatch and in a module would that crash things?

  • ProlericProleric Member Posts: 908
    No, the module version takes priority.

    This is done at the resource level, so if the resources are not identical, the module versions prevail, except for any resources which are only in the patch hak.

    SymphonyGrymlorde
  • CalgacusCalgacus Member Posts: 272
    edited August 2018
    This userpatch.ini approach does not seem to work for me in the latest dev branch on windows 10. Anyone else having trouble? I am trying to use it with the beamdog client version, not steam. My install folder is:
    D :\Beamdog\00829

    My PATCH entry in C:\Users\calg\Documents\Neverwinter Nights\nwn.ini
    PATCH=C:\Users\calg\Documents\Neverwinter Nights\hak

    My userpatch.ini:
    [Patch]

    PatchFile000=MageWeapons.hak

  • Sylvus_MoonbowSylvus_Moonbow Member Posts: 1,056
    [Patch]

    PatchFile000=MageWeapons

    CalgacusGrymlordeZwerkules
  • CalgacusCalgacus Member Posts: 272
  • Allanon81Allanon81 Member Posts: 227
    Does this mean I can use CEP with Original content by creating a userpatch.ini and then commenting each .hak of CEP in the Patch lines?

  • GrymlordeGrymlorde Member Posts: 121
    @Allanon81 Yes, but only for those standard sources that get overwritten. If the module builder didn't build with CEP, then you won't get the CEP unique content.

    The purpose of the userpatch.ini is to overwrite existing content, not to add new content. To add new content, you need to edit the module in the toolset and add the haks. For example, I like Cervante's Creature Override Compilation and use that because I prefer the way those monsters look rather than the stock NWN ones. I also like the footman's mace in CEP but there's no way to add it to a module without editing the module itself.

  • Allanon81Allanon81 Member Posts: 227
    @Grymlorde Ok, forget about CEP. Can I use Community Patch Project (CPP), Project Qv3.0, and Project Resource Compendium (PRC) in the OC? And I've tried adding all these using the userpatch.ini method, but haven't noticed any changes. Only the override seems to work. :neutral:

  • GrymlordeGrymlorde Member Posts: 121
    @Allanon81 Can you be more specific about what works in the override and not in userpatch?

  • Sylvus_MoonbowSylvus_Moonbow Member Posts: 1,056
    You cannot use PRC as a patch hak as it adds new content.

    You can use Project Q as a patch hak as it overwrites existing content.

  • Allanon81Allanon81 Member Posts: 227
    @Grymlorde I put the Grand Override Compilitation in there and its great, I'm also understanding now(if Im correct) that the official campaign .nwm files need to be modified in order to use said haks.

    @Sylvus_Moonbow Thank you, I think i'm gettin it now. I tried the PRC and it comes with modified original campaign files (.nwm). I put those in the right places, but when I go to create a character my device (Android) hangs at gender. ;) I tried using project Q, but no dice. The OC campaigns have to be modified right? I saw that project q, i think 2.0 comes has modified oc's. Will those work with 3.0?

    Thank you guys for trying to help. There should be a sticky thread or something that lays this out better.

  • Allanon81Allanon81 Member Posts: 227
    edited October 2019
    I got the Neverwinter Facelift working with userpatch. Just wish PRC wouldnt hang.

  • Sylvus_MoonbowSylvus_Moonbow Member Posts: 1,056
    edited October 2019
    @Allanon81 Perhaps this thread will give you more insight. Q works as a patch hak because I use it myself.

    https://forums.beamdog.com/discussion/comment/970346

  • Allanon81Allanon81 Member Posts: 227
    @Sylvus_Moonbow I took out the building and scenery textures from my override and used neverwinter facelift instead. I was also thinking of using Project Q. Are there things in project q that are also in Neverwinter Facelift (biointerior,biocity,etc.)? Also the lower I go in the userpatch.ini that increases priority? ie; PatchFile003 has higher priority or overrides assets in PatchFile001.

  • SymphonySymphony Member, Developer Posts: 142
    @Allanon81 The .haks are loaded one at a time. This starts with 000 and proceeds DOWN the list. I've never liked the word "priority", since it implies some sort of hak battle for the top. While this supports the idea of having conflicting files, it makes things a little confusing, especially once you start to bring module loading, overrides, workshop, etc. into the situation.

    The higher number patches are loaded later, so, overlap, in the form of recurring file names, in later loaded content will replace earlier files with the same name entirely. This isn't much different from what might happen if you "dragged and dropped" a bunch of files on your computer to the same folder, and chose "replace all" for each action. The newer files replace the pre-existing ones.

    In the toolset, these "newer" files would be in .hak packages at the top of the "Custom Content" window list, but in userpatch.ini, these would be the .hak packages with the highest numbers, at the bottom of the list.

    DerpCity
  • GrymlordeGrymlorde Member Posts: 121
    @Allanon81, there is some overlapping content between Q and Zwerk's facelift. For example Q uses most of Zwerk's mines but there is some of Zwerk's content that is not used. My advice is to experiment and see which order works out better for you.

  • IseweinIsewein Member Posts: 420
    I just got the EE and am having some trouble understanding how exactly I should adapt my patch haks. NWN.ini seems to be shorter than it used to be, with most settings now in a different file. How do I enable patch haks now?

  • SymphonySymphony Member, Developer Posts: 142
    @Isewein nwn.ini was never used for patch haks except for the PATCH= directory, which is still in the current nwn.ini.

    The new settings.tml different file you're looking at doesn't have or need anything regarding patch haks.

    Everything is the same as per the guidance above.

    Isewein
  • IseweinIsewein Member Posts: 420
    edited November 2020
    Thanks, I was just confused by the different layout of the nwn.ini to what I remembered. But you are right, the file path is still there.

    PS: In the old days, the conventional wisdom (according to my notes) held that "when overwriting standard game resources, TGA files belong in the override and DDS files belong in a hak. For some reason, TGA files in a hak will NOT overwrite standard resources. Likewise, DDS files in the override will NOT overwrite standard resources." Is this still an issue in the EE?

    Post edited by Isewein on
  • ProlericProleric Member Posts: 908
    All textures belong in a hak now. You can also put them in override or development as a temporary measure when testing (permanent use of either folder is normally discouraged, as they affect all modules, and may break other authors' work).

    The only restriction I'm aware of is that (last time I checked) .tga files don't work in a patch hak (which is different from a regular hak). That might have changed now.

    When texture files have the same name (apart from the .dds or .tga suffix) the rule for which file trumps the others is

    DDS in override >
    TGA in override >
    DDS in ERF (hak, patch-hak, texturepack) >
    TGA in ERF (hak, patch-hak, texturepack) >
    DDS in BIF >
    TGA in BIF

    if I've understood the developers correctly.

    This is different from the resource hierarchy for all other files, which you can see in game - enter developer debug mode (CTRL-SHIFT-F12) then check Resman.

    Isewein
  • SymphonySymphony Member, Developer Posts: 142
    Texture Packs have been removed (highest quality textures now used, only), and there's a few things missing from the "which file gets used" conversation, that might change the outcome, like PLT, TXI, and MTR, however, that gets fairly complicated.

    My personal recommendation is that outside of certain cases (like icons), you should avoid TGA, and use it for prototyping content in /development or /override, convert to DDS to make sure it still works and looks good in /development and /override, and then package into .hak. Or in this case, Patch Hak.

    A lot of the confusion about the hierarchy before was that there was no format hierarchy, it was a time hierarchy. Patch haks were loaded after overrides so they replaced them. Module haks were loaded after base game assets, so those replaced also, when there were name collisions.

    Texturepacks somewhat screwed things up here since they were loaded / unloaded at random times, causing a lot of confusion for overriders with TGA's and DDS's, so we're lucky they are no longer a factor.

    For creation I've personally stopped using TGA all-together (except for icons and other no-DDS assets), and do everything in PNG with Blender and Gimp etc, keep PNG masters, and export my PNG's to /development as DDS's to test content, before exporting those PNG's to DDS for haks. The superiority of the DDS format, however, is worthy of a separate topic.

    Isewein
  • IseweinIsewein Member Posts: 420
    @Proleric : That's odd though, seeing as how a number of prominent patch haks such as Zwerkules' facelift include .tga files which seem to work fine. Does anyone know a definite answer to this .tga in patch haks mystery?

  • TarotRedhandTarotRedhand Member Posts: 1,156
    edited November 2020
    @Symphony Whether or not the current version of dds works any better than the old I don't know but I had problems with the old. So I do not currently use dds. The problem is that dds is a "lossy" format and that screwed up some of the textures that I created. TGA not being "lossy" didn't so I'll continue to use that format.

    TR

  • SymphonySymphony Member, Developer Posts: 142
    Yeah I remember your thin blue lines. DDS runs circles around TGA at 4x the resolution, you likely had use case issues that you needed a different approach too, like TXI options.

    However, it’s most likely that you just needed to use higher resolution textures for specific details, and TGA is a dead anchor in that department.

  • ZwerkulesZwerkules Member Posts: 112
    Isewein wrote: »
    @Proleric : That's odd though, seeing as how a number of prominent patch haks such as Zwerkules' facelift include .tga files which seem to work fine. Does anyone know a definite answer to this .tga in patch haks mystery?

    My textures are all DDS unless they are used for animated textures like water and lava or the small map icons.
    The old version of biomines still has a few TGA textures that could be DDS.

    Symphony
Sign In or Register to comment.