On the face of it, the Enigma Island custom module, which has always relied on scripts in the hak overwriting scripts in the module, is now failing every time with a fatal error, strongly suggesting that the script version in the module itself is now taking priority.
For historical reasons, the module checks the hak version by executing a script (bh_hak) in the module load bh_mod_def_load. Enigma4.hak contains a version of that script which stores the hak version number in the module variables. The client enter script x3_mod_pre_enter checks that the version is correct.
However, since 1.79, the latter script reports a fatal error because the version is “unknown”. The only way that could happen is if the version of bh_hak in the module itself has taken priority,
Clearly, the version could be checked differently. That’s not really the point - if the resource hierarchy hak > module is no longer operational, there could be all sorts of problems with fan-made modules?
P.S. According to the release notes for 1.79, Documents > Neverwinter Nights is now supposed to have top priority over all other resources (unlike override). Sadly, that doesn’t seem to be working in this case, either. EDIT …but see correction below.
Well, it is certain that the module version of the script is being run by ExecuteScript, rather than the hak version, because the error message includes a value which is only set by the module version.
It doesn’t necessarily prove that the resource hierarchy is inverted for all purposes. The only thing for sure at this stage is that during the module load event, .ncs from the hak is no longer taking priority.
Further evidence that the hak has taken low priority - if I copy the script from the hak into Documents\Neverwinter Nights\development, the module works, so clearly that new folder takes priority over the module, but the hak doesn’t.
To be fair, checking my own modules, there are no other current instances which depend on hak trumping module.
On the other hand, historic releases 1.01 to 1.05 of Dark Energy, which used a hak to patch bugs, will now regress to all the bugs in 1.00. Maybe not a big deal, as 1.07 is OK, but there clearly could be issues for other modules.
I think that proves that the resource hierarchy for scripts is now development > module > hak, which is definitely not how it used to work.
If I’m reading this correctly (and I hope I’m not), it is an absolutely devastating change. It will break, wholesale, all of the (many) modules (including mine) that were built using the “patch hak” design approach, which count on the resources in haks taking priority over those in modules.
@Andarian@Proleric and other SP module authors: Yes, this is horrible, yes it breaks many modules and yes it must be fixed. However, I’m curious, if you had a choice between the old and new approach for new modules, which one would you prefer?
I’ve personally always found the hak-trumps-module to be very annoying quirk of the load order, and more often than not you’d be working against it and not with it. Suppose the module had a switch that let it go above haks (in the hypothetical scenario, all modules without that switch would default to OFF to preserve 1.69 behavior), what would you set it to?
If some standard hak, like CEP or a popular tileset perhaps, needs an override, it goes in the top hak. Typically, most of those tweaks couldn’t be included in the module, in any case.
Hak-trumps-module, on the other hand, is useful for patching, without forcing the player to download the entire module / package again. Having said that, it is tricky to deploy safely on Steam Workshop, because hak changes there impact saved games, whereas module changes do not.
A switch is a bit nasty to do (you normally specify the priority when you load a thing, but here you’d need to have already loaded the module to check the switch, etc), but doable. The patching of scripts seems like a two edged sword, but I do see a possible use there.
The module-trumps-hak approach is more useful IMO for cases when your haks have some palette entries you want to edit. Or even modifying the scripts that come with CEP. Right now you need to have an additional top hak to override any e.g. CEP resources. And that’s cumbersome because it takes extra effort to edit a thing in the module, and then re-export it to the hak.
I agree with @clippy that vanilla the hak > module precedence is a PITA when you try to override imported resources. Especially scripts which you have to test in runtime.
A module is a consumer of game resources, which haks and override provide or alter. Since it is the part of interface closest to the user (and thus has highest dynamics), it should’ve had the authority over the rest of content from the beginning.
But that’s not how thing are. Since backward compatibility is most important, here are two possible solutions to bridge 1.69 and EE in this matter:
On custom content tab, when you choose a hak to add you can choose whether this hak overrides the module or not.
The module itself appears on the hak list and can have haks put above it:
patch_hak
override_hak
<module>
cep_hak
foo_hak
This should allow emulation / compatibility layer of 1.69 behavior. #2 has no switches and should be easy to implement and understand by users (a module becomes another hak, just directly editable in the toolset).
Module trumps all would have made overrides useless too. None of the post OC content upgrades people used would have worked.
I generally think scripts in haks is a bad idea. I get it for patching things (and as Proleric is using it to validate which hak version is present). But scripts are hard to maintain in haks. CEP’s crp scripts in hak was a design mistake that has been fixed…
Oops, I meant that override provides content. Naturally it should have topmost priority. Too bad it’s not possible to put stuff in subfolders to patch just specific module(s).
This could be done w/o scripts by placing a 2DA with a version string inside the hak, no?
Yes, to some extent, if one were working from scratch. But backwards compatibility is more important in my opinion. Just off the top of my head I can think of several dozen appearances in my haks that are meant to override bioware default appearances. With the module taking priority, you would essentially render useless every aspect of this.
Further, there is nothing wrong with having scripts in haks. Especially when you have a team working on a project and you want to make sure some scripts don’t get tweaked the wrong way. Been using this for years without issue.
Sure could probably use a 2da, but I’m not interested in re-engineering Proleric’s working (… formerly working…) stuff here. That’s kinda beside the point…
As to scripts in haks I’m also not interested in arguing about that. I think it’s a mistake and a maintenance headache. Especially in something for common use like CEP. People are free to disagree
I like the 1.69 ordering just fine. Overrides and patch haks allow me to play the OC and older modules with better looking content. And I have a ton of experience with top haks and they are not in the least bit a of a PitA for me at all. And sometimes content gets broken by a NWN update (cough 1.79 cough). In that case, it is so much easier to build a patch-hak, override, etc. to fix the problem.
