Also is there situation where stuff do not work in override and must be in hak? What about uncompiled models? TGA/DDS?
And how to fix it?
ty
Modifié par ShaDoOoW, 08 septembre 2010 - 02:11 .
CC behaviour in hak and override
Débuté par
Shadooow
, sept. 08 2010 02:10
#1
Posté 08 septembre 2010 - 02:10
Shadooow
-
- Members
- 4 470 messages
I recently found out that some CC doesn't work in haks - NWNCQ is a good example of this, also one my texture I used for Community Patch don't work also. Why?
Also is there situation where stuff do not work in override and must be in hak? What about uncompiled models? TGA/DDS?
And how to fix it?
ty
Also is there situation where stuff do not work in override and must be in hak? What about uncompiled models? TGA/DDS?
And how to fix it?
ty
Retour en haut
#2
Posté 08 septembre 2010 - 03:21
Invisig0th
-
- Members
- 170 messages
In all seriousness, this is an excellent and important question.
I realize that you are familiar with a lot of this, and no offense is intended, but the first thing you should do is read Axe Murderer's tutorial on Custom Content Mechanics if you have not already done so. It is extremely informative, and it contains a lot of information that may be new or useful even to people who are familiar with such things.
Actually, NWNCQ apparently does work as a HAK. Chico400 has both a HAK version and an /override/ version available to download on the NWVault page. Or is there some specific feature that you found did not work in one or the other?
And as you know, a HAK applies only to a single module, and /override/ applies to every module (entire game). HAK and override have different purposes., and certain differences in behavior will probably be due to this. In fact, even Bioware knows that some files work better in /override/ than in the game resources files. That's why some of the 1.69 files ended up in /override/.
TGA files put in /overide/ will never override DDS files with the same name located in a HAK or in game resources. In addition to standard resource precedence, DDS always trumps TGA. It is also possible that textures of unusual dimensions (ex: 256 x 120) may work in one place but not the other, since the game engine expects one of the standard dimensions.
It is also true that some things may *appear* to not work correctly in /override/ in the Toolset, but work just fine in the actual game. So it appears that the toolset and the game may use the /override/ slightly differently, which complicates things. Most of these should probably be considered bugs, but that doesn't really change the fact that the behavior is actually different.
Here are some other interesting threads about stuff that people say doesn't work the same in both places. Not sure all this info is current or correct, but worth a look. I'm sure there are other things, but this should be a good start.
PRC - areas don't work in override, attaching scripts to events doesn't work in override
modifications to existing game PLTs do not work in override
unable to override OC end of module script using override
I realize that you are familiar with a lot of this, and no offense is intended, but the first thing you should do is read Axe Murderer's tutorial on Custom Content Mechanics if you have not already done so. It is extremely informative, and it contains a lot of information that may be new or useful even to people who are familiar with such things.
Actually, NWNCQ apparently does work as a HAK. Chico400 has both a HAK version and an /override/ version available to download on the NWVault page. Or is there some specific feature that you found did not work in one or the other?
And as you know, a HAK applies only to a single module, and /override/ applies to every module (entire game). HAK and override have different purposes., and certain differences in behavior will probably be due to this. In fact, even Bioware knows that some files work better in /override/ than in the game resources files. That's why some of the 1.69 files ended up in /override/.
TGA files put in /overide/ will never override DDS files with the same name located in a HAK or in game resources. In addition to standard resource precedence, DDS always trumps TGA. It is also possible that textures of unusual dimensions (ex: 256 x 120) may work in one place but not the other, since the game engine expects one of the standard dimensions.
It is also true that some things may *appear* to not work correctly in /override/ in the Toolset, but work just fine in the actual game. So it appears that the toolset and the game may use the /override/ slightly differently, which complicates things. Most of these should probably be considered bugs, but that doesn't really change the fact that the behavior is actually different.
Here are some other interesting threads about stuff that people say doesn't work the same in both places. Not sure all this info is current or correct, but worth a look. I'm sure there are other things, but this should be a good start.
PRC - areas don't work in override, attaching scripts to events doesn't work in override
modifications to existing game PLTs do not work in override
unable to override OC end of module script using override
Modifié par Invisig0th, 08 septembre 2010 - 03:43 .
#3
Posté 08 septembre 2010 - 06:07
Shadooow
-
- Members
- 4 470 messages
Well what I did was that I downloaded override version. But then I needed to have my override clean and NWNCQ messed it too much, so I added the override version into patch-hak (I think there is no difference between normal hak and patch-hak except patch hak is loaded at start overwriting override). And then strange issues happened, some textures didn't worked etc. Now I guess I will try hak version, that should work... I just wanted to know why was this happening.Invisig0th wrote...
Actually, NWNCQ apparently does work as a HAK. Chico400 has both a HAK version and an /override/ version available to download on the NWVault page. Or is there some specific feature that you found did not work in one or the other?
Will go through all links then, thanks.
#4
Posté 08 septembre 2010 - 06:27
olivier leroux
-
- Members
- 590 messages
ShaDoOoW wrote...
But then I needed to have my override clean and NWNCQ messed it too much
In case you don't know it yet, Goudea's NWNLauncher is an easy and comfortable way of managing your override folder, it allows you to have several override folders at the same time and switch between them whenever necessary.
Modifié par olivier leroux, 08 septembre 2010 - 06:28 .
#5
Posté 08 septembre 2010 - 07:07
Shadooow
-
- Members
- 4 470 messages
The multiple overrides is solution I dont want to use. This way you will soon forget what all is in one and what is in the second.
Patch-haks allow you to make special hak for each override content - NWNCQ, spellscripts, BH's itemproperties, heads and then you can disable them easily just via renaming the hak to "_" prefix
Patch-haks allow you to make special hak for each override content - NWNCQ, spellscripts, BH's itemproperties, heads and then you can disable them easily just via renaming the hak to "_" prefix
#6
Posté 23 septembre 2010 - 02:22
Dagesh
-
- Members
- 30 messages
Check out this link:
http://nwn.bioware.c...659212&forum=48
Basically it allows you to preload a hak file instead of only using the override folder.
In nwnpatch.ini add this: (if you don't have the file, make it)
[Patch]
PatchFile000=preload
Then in your patch folder add a hak file named "preload.hak" The game will then load anything in that hak file (even the toolset). This way you don't need to use the override folder. Also, reading that link, you can make several hak files and preload them this way.
Thank Virusman for his post.
http://nwn.bioware.c...659212&forum=48
Basically it allows you to preload a hak file instead of only using the override folder.
In nwnpatch.ini add this: (if you don't have the file, make it)
[Patch]
PatchFile000=preload
Then in your patch folder add a hak file named "preload.hak" The game will then load anything in that hak file (even the toolset). This way you don't need to use the override folder. Also, reading that link, you can make several hak files and preload them this way.
Thank Virusman for his post.
#7
Posté 23 septembre 2010 - 03:48
Shadooow
-
- Members
- 4 470 messages
Yea this is what I mentioned like patch-hak above.
#8
Posté 23 septembre 2010 - 05:05
_six
-
- Members
- 919 messages
And perhaps more importantly, using patch haks (if you have the courage to mess with them, a lot of players seem not to) allows you to swap more than one set of content out at the same time. While with override you'd have to just clone the content in multiple folders, which gets messy and bloats your install.ShaDoOoW wrote...
The multiple overrides is solution I dont want to use. This way you will soon forget what all is in one and what is in the second.
#9
Posté 24 septembre 2010 - 11:59
AndarianTD
-
- Members
- 701 messages
ShaDoOoW wrote...
Yea this is what I mentioned like patch-hak above.
What is "patch-hak?" I've never heard of it as a distinct way of providing content to the game. I understand "patch hak" to refer to a top-level hak in which you put patches to a released module, so that you (a) don't have to do a full module release to fix bugs, and (
can make them available for players who've already started a game. At least that's howI use it.
EDIT: Never mind, I just found Dagesh's link. Learn something new every day.
Also, NWNCQ most definitely works as a hak. I just finished updating Sanctum 1 & 2 to use it.
Modifié par AndarianTD, 24 septembre 2010 - 12:04 .
#10
Posté 24 septembre 2010 - 03:01
TheSpiritedLass
-
- Members
- 765 messages
Too funny. I was just pondering about 2da files this moring. When can they be just on the server machine, when do builders need them and when do players need them. *grabbing Axe's tutorial.* Thanks for the link. =)
-- Mistress
-- Mistress
#11
Posté 25 septembre 2010 - 10:09
Pstemarie
-
- Members
- 2 745 messages
Preloading haks is well documented on the RPG Modding Forums - its the system I use for NwnE. Combined with the override, its the only way to deliver cross-module content without cluttering up the modules.
http://www.rpgmoddin...ghlight=Preload
The nice thing about preloading is the flexibility of the system. You can define the directory the haks are loaded from (the game default is /patch) and easily switch out systems and rulesets just by using a different patch.ini folder - there is no need to change the name of the haks. Furthermore, the amount of haks you can preload appears to be unlimited - I have preloaded as many as 16 haks and never experienced an issue.
I also use the override folder in conjunction with preloading for NwnE. This was necessary because Cervantes and I decided that we did not want to clutter the custom palettes with all the CC we were adding (like the CEP does). The NwnE override folder houses all the itp, template (utc, utp, uti, etc.), and script (nss and ncs) files. The mechanics of the override are thus:
1. NSS and NCS files in a hak cannot be overwritten by the module builder. When the module is compiled, the hak versions will overwrite any changes you have made. However, they can be overwritten if the files are included in the override (Note - if you are overwriting a standard resources you need to include both the nss and ncs files).
2. Template files in a hak will appear on the custom palette. If added to one of the standard itp files, the templates will appear on both the standard and custom palettes.
3. 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.
Another aspect of preloading is that any haks loaded through this method do not count against the module hak limit. For example, if you are using CEP you could preload all the CEP content and then have a range of haks attached to your module. You would only need to associate the CEP tlk with your module. This greatly reduces the size of the module when loading, since the CEP content would be loaded before the module loads. It also reduces lag.
Note - for multiplayer servers: Players logging into the server will have to preload resources. It is not something that can be done solely on the server-side.
http://www.rpgmoddin...ghlight=Preload
The nice thing about preloading is the flexibility of the system. You can define the directory the haks are loaded from (the game default is /patch) and easily switch out systems and rulesets just by using a different patch.ini folder - there is no need to change the name of the haks. Furthermore, the amount of haks you can preload appears to be unlimited - I have preloaded as many as 16 haks and never experienced an issue.
I also use the override folder in conjunction with preloading for NwnE. This was necessary because Cervantes and I decided that we did not want to clutter the custom palettes with all the CC we were adding (like the CEP does). The NwnE override folder houses all the itp, template (utc, utp, uti, etc.), and script (nss and ncs) files. The mechanics of the override are thus:
1. NSS and NCS files in a hak cannot be overwritten by the module builder. When the module is compiled, the hak versions will overwrite any changes you have made. However, they can be overwritten if the files are included in the override (Note - if you are overwriting a standard resources you need to include both the nss and ncs files).
2. Template files in a hak will appear on the custom palette. If added to one of the standard itp files, the templates will appear on both the standard and custom palettes.
3. 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.
Another aspect of preloading is that any haks loaded through this method do not count against the module hak limit. For example, if you are using CEP you could preload all the CEP content and then have a range of haks attached to your module. You would only need to associate the CEP tlk with your module. This greatly reduces the size of the module when loading, since the CEP content would be loaded before the module loads. It also reduces lag.
Note - for multiplayer servers: Players logging into the server will have to preload resources. It is not something that can be done solely on the server-side.
Modifié par Pstemarie, 25 septembre 2010 - 10:33 .
#12
Posté 25 septembre 2010 - 02:33
Khuzadrepa
-
- Members
- 188 messages
I can't view this link, it says I have to be a member of the forum. Apparently, this is nigh impossible, as I had tried a couple of weeks ago to join. I waited to have my account activated by the admin, only to have it be deleted instead, and when I sent an email to the admin to see what was going on it went unanswered. Just tried again, we'll see how that goes...Pstemarie wrote...
http://www.rpgmoddin...ghlight=Preload
However, on the whole preload thing... I think that is an awesome feature.
#13
Posté 25 septembre 2010 - 06:28
Pstemarie
-
- Members
- 2 745 messages
Setting Up NWN to Preload Haks
As anyone knows who has been following the Development forum for NWN Enhanced, I have been working on putting together a HAK version and setting up NWN to preload the hak files.
Why Preload HAKs?
First, preloading HAKs is essentially an alternative method to using the override. Like the override, any resources that are preloaded will become available in ALL NWN games. This includes new content as well as content designed to overwrite standard resources.
Second, from the testing I've done, preloading seems to be more stable than using the override. Furthermore, since both the Toolset and game load rather quickly, it appears that this method uses less memory than placing thousands of files in the override. This would seem to support Brian Chung's statement in this thread on the Bioware forums:
Not surprised - every file in your /nwn/override/ folder takes up memory as the game has to build up a resource table of what is in the core game, and then override it. When you start getting into the 1000's of files, this table can grow pretty large and suck up memory which can hamper performance.
Same for the localvault for your character files.
Not to mention disk fragmentation from so many small individual files, vs. packing them up into a HAK.
Lastly, I have run NWN (game and Toolset) using both the override and preload versions of NWN Enhanced in "windowed mode", with a 3rd-party utility running that monitors both CPU and GPU load. The preload version showed a greatly REDUCED load upon my system than when I was running the override version.
This fact alone makes preloaded resources much more stable for multiplayer and PW use.
How Is It Set Up?
Preloading uses both the patch folder and patch.ini - both of which you'll notice are empty files. Any HAK that is placed in the game's Patch folder (C:\\NeverwinterNights\\NWN\\patch) then listed in patch.ini will be preloaded when the game or toolset starts.
As far as I can tell, load order for resources follows this priority:
1. Core *.bif files
2. Patch *.bif files
3. patch.ini
4. Override folder
5. Module Haks
Therefore anything loaded from patch.ini will overwrite core *.bif resources (i.e. standard resources). Files loaded from the Override folder will overwrite core *bif resources as well as patch.ini preloads. Finally resources in module specific HAKs will overwrite anything lower in the above hierarchy.
The internal hierarchy of patch.ini is the opposite of the hierarchy tree used for loading module HAKs. Files at the bottom of the patch.ini internal hierarchy tree take precendent over files listed earlier in the tree. For example (using the NWN Enhanced patch.ini file):
[Patch]
PatchFile000=x4_textures
PatchFile001=x4_portraits
PatchFile002=x4_supersets
PatchFile003=x4_females
PatchFile004=x4_males
PatchFile005=X4_effects
PatchFile006=x4_items
PatchFile007=x4_monsters
PatchFile008=x4_placeables
PatchFile009=x4_scripts
PatchFile010=x4_2da
The last file preloaded is "x4_2da". Any resources in this HAK will overwrite identical resources in HAKs listed earlier in the hierarchy tree. For example is both "x4_2da" and "x4_placeables" have a "placeables.2da" file, the "placeables.2da" from "x4_2da" will overwrite the version in "x4_placeables".
Also note that the filenames do NOT need the extension. Furthermore, it would appear that the files MUST have unique names. For example, when the files "x4_supersets", "x4_males", and "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 upto this string value, only the topmost file is in the hierarchy is loaded.
Can Preloading Be Used With The Override Folder?
YES. In fact, the current build of NWN Enhanced I'm testing uses the Override folder to load the templates for all the new creatures, items, and placeables included as part of Enhanced. This setup was required to prevent the templates from appearing on both the standard palette (which they have been added to) and the custom palette.
Is It Easy to Uninstall Preloaded Content?
YES. All you need to do is empty or rename your "patch.ini" file to something else. Alternatively, you can empty the contents of the Patch folder. If patch.ini can't find the resources, it doesn't load them.
Can Content Be Directly Preloaded From the HAK Folder?
YES, but you will need to add/change a setting in nwn.ini. Under [ALIAS] change:
PATCH=.\\patch
to:
PATCH=.\\hak
Now any files that you specify in the internal hierarchy of patch.ini that are in the HAK Folder will be preloaded when the game or Toolset starts.
Is There A Limit To The Number Of Files That Can Be Preloaded?
NO. At this time it appears that any number of HAK files can be preloaded using this method. However, this has not been fully explored and it is not known if the Module HAK limit applies to preloading through patch.ini.
---------------------------------------------
The foundation for much of this information was gleaned from this thread on the Bioware forums and some personal discussions with Ragnarok_mr4 and Brian Chung.
That's the thread...
As anyone knows who has been following the Development forum for NWN Enhanced, I have been working on putting together a HAK version and setting up NWN to preload the hak files.
Why Preload HAKs?
First, preloading HAKs is essentially an alternative method to using the override. Like the override, any resources that are preloaded will become available in ALL NWN games. This includes new content as well as content designed to overwrite standard resources.
Second, from the testing I've done, preloading seems to be more stable than using the override. Furthermore, since both the Toolset and game load rather quickly, it appears that this method uses less memory than placing thousands of files in the override. This would seem to support Brian Chung's statement in this thread on the Bioware forums:
Not surprised - every file in your /nwn/override/ folder takes up memory as the game has to build up a resource table of what is in the core game, and then override it. When you start getting into the 1000's of files, this table can grow pretty large and suck up memory which can hamper performance.
Same for the localvault for your character files.
Not to mention disk fragmentation from so many small individual files, vs. packing them up into a HAK.
Lastly, I have run NWN (game and Toolset) using both the override and preload versions of NWN Enhanced in "windowed mode", with a 3rd-party utility running that monitors both CPU and GPU load. The preload version showed a greatly REDUCED load upon my system than when I was running the override version.
This fact alone makes preloaded resources much more stable for multiplayer and PW use.
How Is It Set Up?
Preloading uses both the patch folder and patch.ini - both of which you'll notice are empty files. Any HAK that is placed in the game's Patch folder (C:\\NeverwinterNights\\NWN\\patch) then listed in patch.ini will be preloaded when the game or toolset starts.
As far as I can tell, load order for resources follows this priority:
1. Core *.bif files
2. Patch *.bif files
3. patch.ini
4. Override folder
5. Module Haks
Therefore anything loaded from patch.ini will overwrite core *.bif resources (i.e. standard resources). Files loaded from the Override folder will overwrite core *bif resources as well as patch.ini preloads. Finally resources in module specific HAKs will overwrite anything lower in the above hierarchy.
The internal hierarchy of patch.ini is the opposite of the hierarchy tree used for loading module HAKs. Files at the bottom of the patch.ini internal hierarchy tree take precendent over files listed earlier in the tree. For example (using the NWN Enhanced patch.ini file):
[Patch]
PatchFile000=x4_textures
PatchFile001=x4_portraits
PatchFile002=x4_supersets
PatchFile003=x4_females
PatchFile004=x4_males
PatchFile005=X4_effects
PatchFile006=x4_items
PatchFile007=x4_monsters
PatchFile008=x4_placeables
PatchFile009=x4_scripts
PatchFile010=x4_2da
The last file preloaded is "x4_2da". Any resources in this HAK will overwrite identical resources in HAKs listed earlier in the hierarchy tree. For example is both "x4_2da" and "x4_placeables" have a "placeables.2da" file, the "placeables.2da" from "x4_2da" will overwrite the version in "x4_placeables".
Also note that the filenames do NOT need the extension. Furthermore, it would appear that the files MUST have unique names. For example, when the files "x4_supersets", "x4_males", and "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 upto this string value, only the topmost file is in the hierarchy is loaded.
Can Preloading Be Used With The Override Folder?
YES. In fact, the current build of NWN Enhanced I'm testing uses the Override folder to load the templates for all the new creatures, items, and placeables included as part of Enhanced. This setup was required to prevent the templates from appearing on both the standard palette (which they have been added to) and the custom palette.
Is It Easy to Uninstall Preloaded Content?
YES. All you need to do is empty or rename your "patch.ini" file to something else. Alternatively, you can empty the contents of the Patch folder. If patch.ini can't find the resources, it doesn't load them.
Can Content Be Directly Preloaded From the HAK Folder?
YES, but you will need to add/change a setting in nwn.ini. Under [ALIAS] change:
PATCH=.\\patch
to:
PATCH=.\\hak
Now any files that you specify in the internal hierarchy of patch.ini that are in the HAK Folder will be preloaded when the game or Toolset starts.
Is There A Limit To The Number Of Files That Can Be Preloaded?
NO. At this time it appears that any number of HAK files can be preloaded using this method. However, this has not been fully explored and it is not known if the Module HAK limit applies to preloading through patch.ini.
---------------------------------------------
The foundation for much of this information was gleaned from this thread on the Bioware forums and some personal discussions with Ragnarok_mr4 and Brian Chung.
That's the thread...
#14
Posté 26 septembre 2010 - 01:20
Dagesh
-
- Members
- 30 messages
The above is true. You can also read the above post I left though with much less information and with much less reading overall.
#15
Posté 26 septembre 2010 - 02:29
Shadooow
-
- Members
- 4 470 messages
Some additional informations about this.
Patch-hak have bigger prececence than override and module., this makes it really bad place for scripts, palletes, blueprints and 2das.
The preceddence is this:
bifs < override < module < patch-hak < hak
I would not suggest anyone to change the path from patch to hak. Rather copy haks you want to preload from hak folder to patch folder. If you change path, you could brek compatibility with NWNEnhanced or other projects using patch-haks.
You can't preload TLK, this means its quite useless for preloading haks on PW, like if you would want to allow player to take additional skills/feats etc. in initial character selection, in order to player could see right texts, you must use not custom tlk but modified dialog.tlk. Dialog.tlk is what makes various projects (using patch-haks) incompatible with each other (NWNEnhanced - Community patch)
I would also suggest this not be used by any PW in order to ensure there are no haks required to join the game. Someone could use it for this, but this will bring crashes and can break other modules/PWs especially if patch-haks contains 2das. Its the same bad idea as requiring the player to download special 2das while otherwise not using haks (Antiworld uses(d) this solution for example).
Patch-hak have bigger prececence than override and module., this makes it really bad place for scripts, palletes, blueprints and 2das.
The preceddence is this:
bifs < override < module < patch-hak < hak
I would not suggest anyone to change the path from patch to hak. Rather copy haks you want to preload from hak folder to patch folder. If you change path, you could brek compatibility with NWNEnhanced or other projects using patch-haks.
You can't preload TLK, this means its quite useless for preloading haks on PW, like if you would want to allow player to take additional skills/feats etc. in initial character selection, in order to player could see right texts, you must use not custom tlk but modified dialog.tlk. Dialog.tlk is what makes various projects (using patch-haks) incompatible with each other (NWNEnhanced - Community patch)
I would also suggest this not be used by any PW in order to ensure there are no haks required to join the game. Someone could use it for this, but this will bring crashes and can break other modules/PWs especially if patch-haks contains 2das. Its the same bad idea as requiring the player to download special 2das while otherwise not using haks (Antiworld uses(d) this solution for example).
#16
Posté 26 septembre 2010 - 01:42
Pstemarie
-
- Members
- 2 745 messages
Just to correct ShaDoOow, 2da files in a hak attached to a module will overwrite the 2da files in a hak that is preloaded.
The engine loads resources in the following sequence: BIF, patch.ini, /override, then module HAKs. Thus the precendence would be: BIF < patch.ini < /override < module HAK.
Don't be fooled by the term "patch-hak" that ShaDoOow has coined - it is referring to HAKs loaded through patch.ini as opposed to attaching them to a module. I have been using this method for over a year and have had no issues. You can freely change the patch directory to point to the hak folder if you want - YOU WILL NOT BREAK NwnE (I should know since NwnE is my baby).
The engine loads resources in the following sequence: BIF, patch.ini, /override, then module HAKs. Thus the precendence would be: BIF < patch.ini < /override < module HAK.
Don't be fooled by the term "patch-hak" that ShaDoOow has coined - it is referring to HAKs loaded through patch.ini as opposed to attaching them to a module. I have been using this method for over a year and have had no issues. You can freely change the patch directory to point to the hak folder if you want - YOU WILL NOT BREAK NwnE (I should know since NwnE is my baby).
Modifié par Pstemarie, 26 septembre 2010 - 01:48 .
#17
Posté 26 septembre 2010 - 04:42
Daijin
-
- Members
- 43 messages
I started using Pstemarie's NwnE method about 2 years ago, just using the patch.ini and override (i put ALL haks into patch.ini, and it works flawlessly.
#18
Posté 26 septembre 2010 - 06:35
Pstemarie
-
- Members
- 2 745 messages
Seems I misread ShaDoOoW's earlier post. Looking back at my notes from the conversation with Brian, ShaDoOoW is correct when he says that preloaded HAK resources will overwrite duplicate resources in the override.
Even though the /override is loaded after patch.ini the engine ALWAYS gives priority to resources in a HAK over those in the /override folder. This is another reason that Bioware abandoned this system for patching.
What I thought ShaDoOoW was saying is that module haks would not overwrite duplicate resources in a preloaded hak - which wasn't the case (time to get my glasses checked). Sorry ShaDoOoW.
Now just to clarify precedence according to the engine: BIF < override < HAK. Thus a resource in a HAK will ALWAYS overwrite resources from BIF files or the override.
Even though the /override is loaded after patch.ini the engine ALWAYS gives priority to resources in a HAK over those in the /override folder. This is another reason that Bioware abandoned this system for patching.
What I thought ShaDoOoW was saying is that module haks would not overwrite duplicate resources in a preloaded hak - which wasn't the case (time to get my glasses checked). Sorry ShaDoOoW.
Now just to clarify precedence according to the engine: BIF < override < HAK. Thus a resource in a HAK will ALWAYS overwrite resources from BIF files or the override.
#19
Posté 05 octobre 2010 - 09:00
Grymlorde
-
- Members
- 224 messages
Does pre-loading haks have any impact on compile time? I notice that my compiles are a lot faster if I use overrides rather than haks. Which has caused me to load certain haks only for the final compile.
#20
Posté 05 octobre 2010 - 09:46
Pstemarie
-
- Members
- 2 745 messages
Since the preloaded haks aren't part of the module they shouldn't have any effect upon module compile times. Nor should the override for that matter, since that's external to the module also.
#21
Posté 06 octobre 2010 - 11:08
Grymlorde
-
- Members
- 224 messages
I can't find my patch.ini file. Where is it supposed to be?
#22
Posté 06 octobre 2010 - 11:29
Grymlorde
-
- Members
- 224 messages
Solved it. The file name is 'nwnpatch.ini' and not patch.ini. Also the file is found in the NeverwinterNights\\NWN\\ folder
#23
Posté 07 octobre 2010 - 11:47
Grymlorde
-
- Members
- 224 messages
Just to let everyone know, this process does not eliminate the need for an override. Tileset re-textures which are in TGA format won't override existing resources unless they are in the override. Whereas DDS works fine. For creatures and items, it's hit and miss. In my testing the TGA files do override sometimes.
Compile time is improved using this patch process which makes a noticeable difference with large haks like WoRM's Arbor Falls PW. Map load time is also improved. So I'm going to use this process for my hak files and will incorporate some of my overrides (e.g. models, DDS).
Thanks for letting us know!
Compile time is improved using this patch process which makes a noticeable difference with large haks like WoRM's Arbor Falls PW. Map load time is also improved. So I'm going to use this process for my hak files and will incorporate some of my overrides (e.g. models, DDS).
Thanks for letting us know!
#24
Posté 08 octobre 2010 - 10:56
Bannor Bloodfist
-
- Members
- 929 messages
DDS -->> TGA, that is the order of override. If a PLT exists, it overrides the DDS, if a DDS exists, it overrides the TGA. Placing a TGA into override folder will only sometimes work, whereas if you place the DDS version there, it will override correctly.
So, placing a TGA of the same name as an existing core DDS file, doesn't work correctly, most especially if that DDS exists in ANY of your haks as well.
So, placing a TGA of the same name as an existing core DDS file, doesn't work correctly, most especially if that DDS exists in ANY of your haks as well.
#25
Posté 08 octobre 2010 - 12:11
Pstemarie
-
- Members
- 2 745 messages
Grymlorde wrote...
Solved it. The file name is 'nwnpatch.ini' and not patch.ini. Also the file is found in the NeverwinterNights\\\\NWN\\\\ folder
Sorry, I often refer to nwnpatch.ini as "patch.ini" - didn't think doing so would cause so much fuss
Yes, this method doe not preclude the use of the override. However, as far as NwnE is concerned - which began as an override housed system - using preloading reduced the override from housing ALL files to just housing the itp, template, and script files.
