Resource hierarchy broken in EE 1.79?

Neverwinter Nights 1 Toolset, Scripting, NWNX
#22

The paramount consideration is backward compatibility, to avoid breaking modules, so the default has to be hak > module > override.

N.B. override does not trump module and never has.

I have fixed my module, but most authors are not around to fix theirs.

As long as the default is restored, I don’t really care whether it can be customised in future or not.

As it happens, in newer work, I’m already using 2da for hak version control, but that’s beside the point.

The new “development” folder at the top of the hierarchy is a new way of tweaking resources, which I’m using for my fix for now.

Sadly - and this may not be a popular view - the “development” folder is wide open to abuse. The use of overrides has always been controversial, since modding the game that way has global effect which can compromise module integrity. That was partly mitigated by the module > override rule. Development > module enables global mods to do far more damage. However, on past experience, all we can really do is encourage players to remove override & development mods before reporting issues.

1 Like
#23

I agree with Proleric. There’s no benefit to module content taking precedence over hak content that I can see. And there are several serious problems with it.

Patch hak-ing developed (at least as I remember it, and this is why I adopted it) because it was the only real way to “patch” a running game. All of the module resources are copied into the first savegame, and without a patch hak, that version of the module is fixed thereafter as the one the player is playing. If a player found a bug halfway into a playthrough, you could address it by putting the fix into a patch hak for them to download. Otherwise, they would have to start the game over again from scratch.

Gradually, and as I came to use the approach more and more over the course of a decade, I found that it came to make more sense to just build resources in one module, and then share them into another via the hak. The remake of Sanctum 2 is full of examples of this: things that I had re-done in the remake of Sanctum 1, and then just found it easier and more convenient to add to the (shared) haks to use them in Sanctum 2.

It’s also how I made it possible for players with an ending savegame from the first module to simply load it (with the updated haks) and launch the sequel, even if they’d saved that game years ago, rather than forcing them to do another whole playthrough. This is also how I planned to make the same thing possible for players of Sanctum 3 (if and when I get time to finish it) for people who want to use an old saved game from Chapter 2.

I shudder to think of how many weeks or months it would take me to restore my modules to working order if this change isn’t reversed. I’m not sure if people who haven’t used and relied on this technique fully understand how useful and powerful it can be, and how much it can speed module development and testing, but I definitely think that it does.

Regarding a switch: as long as the switch’s default is consistent with how it’s always worked, and as long as the switch is set in the module and not by the player, I don’t see a problem with it. Otherwise, many (my guess would be scores or hundreds) of modules whose authors aren’t around to maintain them any longer will cease to work. NWN:EE was developed and released on the premise that backward compatibility was one of its fundamental principles. A change like this, if it stands, would be a major default on that commitment.

Just for the record, I’ve found the opposite to be the case. Scripts are one of the things I rely on most, and find it easiest, to put in haks.

2 Likes
#25

If the company is unwilling to rollback this change for whatever reasons, what I proposed in my first post could be a way to make everyone happy:

  1. want 1.69 behavior - put module at the bottom
  2. want 1.79 behavior - put module at the top
  3. want something in between (i.e. patch.hak > module > tileset.hak) - put module somewhere in between

The thing we want is backward compatibility, so if the module lacks above information (i.e. encoded as one extra field in module.ifo with “next hak below module” data, where null = bottom), engine should default to #1.

In addition to not breaking things this:

  • would give a fine-grained control over data flow to the module builder
  • requires no explanation about this quirk - everyone could see which resources are loaded and when on a panel they knew for years
  • can probably be implemented in one evening
  • is a good PR move

I don’t see why this would be an unpopular opinion when one misplaced file can break everything. But perhaps in the future another switch (developer mode?) could be implemented to allow global or per-module ignore of data in this folder.

#26

@Andarian Your point about patching scripts in saved games is spot on.

I’d forgotten that, but in the past it has often been a life-saver to be able to slip a script into a hak, to enable a player to continue a saved game without starting over.

I could live with your proposal, but the pedant in me feels bound to point out that if the 1.69 status quo were adopted as the default, Beamdog would be rolling back the change!

I’d support that, as long as the default is development > module, and the switch is under module author control.

At risk of derailing the thread, on past experience, there is a vocal lobby who want to see their creations in every module. Many of those creations are benign (i.e. they don’t break any modules) but some are harmful. There has been a (sometimes heated) reluctance to allow module authors to protect their work against the latter.

1 Like
#27

To whoever is reading this: this is a proposal of a compromise solution.

True, but note that default would apply only to 1.69 modules played on EE = backward compatibility is maintained = modules are safe (for now).

With modules edited in EE toolset authors would have a choice: stay in “diamond-compat” mode, go with 1.79 behavior (aka the “new default”), or do whatever they want. This would also allow the company to go with whatever they are planning for. In any case - problem solved.

That’s the point.

1 Like
#28

@Proleric - yes, this has come up when development/ was proposed. It is why the name was picked - to make it obvious it’s only for development and not for distribution. It’s up to us-the-community to prevent anyone from repeating the same mistakes as with override. Please do not use this for anything other than local development/testing. (or on your dedicated servers for whatever you want)

@Grymlorde this still works for better looking content. No module ships textures and models, they’re all in haks or in base game, and that did not change. The question here is purely about about scripts and blueprints.

And I agree fully that default needs to be restored. I was just curious about what people’s thoughts are if the default is “stupid but we’re stuck with it” or “better than this in every way”. I guess the second one is closer to the popular opinion.

#29

Fixed in 1.79 Stable 8193.5 (now hak > module) but sadly that has created a new bug (override > module) as discussed at length elsewhere.

#30

Friends, I’m having problem since last update. Is this related?
The game won’t load old saves and starting new games (modules) will either result in crashing or the button “Play” will be greyed out during character selection.

Tried it on several modules/saves.

#31

@Werelynx by design, as I understand it, Premium module saves no longer work in 1.79 - you have to start over, I think.

All other saves / modules are working for most people.

Worth checking that all files are in the expected folders - paths used to be specified in nwn.ini, but might be in the new config file settings.tml now. Not at my desk, otherwise I’d check for you.

#32

Since the update, I’ve noted that all of Familiars/Animal Companions have reverted back to their default dialogue/AI states even though I have “nw_g_fam.dlg” as my own customized module resource. I assume this will be true for a number of other items for PW’s and module designers like me. Is this by design to change the resource hierarchy in such a way? I’m trying to understand what was done so that I can either undo it, or find a way around it and move forward.

#33

@DM_Wise In game, CTRL+SHIFT+F12 then Resman button will show you the resource hierarchy.

At first sight, I’m puzzled by your issue, because module resources still trump base, according to that report.

#34

I wonder if this is related: https://forums.beamdog.com/discussion/comment/1110550/#Comment_1110550

“Ran into a strange bug today! After taking the portal to the Saqaarin Citadel, my Pixie familiar mysteriously changed into a Dryad. She still operated perfectly fine (was able to fight, open locks etc.), it’s just that she had an entirely different model. This bug persisted even through saving and loading the game, although dismissing and resummoning the familiar turned her back into her usual shape.”

#35

And after you “Unsummon” the familiar the “Summon Familiar” quickslot icon stays as “Unsummon” instead of reverting to “Summon Familiar”

#36

My Gog version does nothing at all since 1.79 stable. So you guys are lucky in that respect.

#37

I’ve been using the OC red cross texture for healing packs. But as of the latest patch, it only shows up in game if I put it in the development directory. I can put it in a hak and it appears fine in the toolset but not in-game. Same with override.

#38

@Grymlorde that sounds like a new issue to me - have you raised a ticket?

#39

Yes, I have. One update – the textures appear in both the toolet and game when in either development or override, but definitely not a hak. I haven’t tested with a patch-hak.

#40

I am not Andarian nor Proleric but my work relates to the resource loading order so I will reply as well.

For my own project, the new behavior would be great since my project IS supposed to have lowest priority. But I am the only custom content creator that ever needed this feature (afaik) and there are other reasons why is hak not suitable for me anyway (the need to add haks into every module you want to play with my patch). So not even I would use that switch. Also, even if this behavior is switchable, in my understanding it will be client-side switch. So that basically means that regular player has an additional settings he has to know and think off and turn it on or off depending what module he plays. Awful. This is one of the reasons I am trying to avoid switches as much as possible. Switches are good but provide far too many and the regular player won’t even get to the game and will not enjoy the game. I experienced this in JA2 community patch 1.13 when there was so many options you could use before starting a game only to find out after 3 or more hours of gameplay that it is not to your liking or it is too easy or too hard.

Anyway, haks having lower priority than module is needless change.

  1. putting scripts into haks is bad practice that is not even needed except for few specific projects like PRC, even with these projects, module builder can always extract scripts and put them into module to avoid the issue with hak version overriding it.
  2. blueprints are not a big deal, user can always make a copy if needed and again one can always extract them and add to the module (which is what I did to save downloading to my players since I use nwsync, except I did not put them into live module, only development module)
  3. basically anything else cannot be in module anyway so this is not a problem, the only other resource I can think of are category palettes and those are weird, it seems I actually must have them in hak to take effect, the same file in module doesn’t work (or I do something wrong)

All in all, I see no real benefits of changing hak priority to be lower than module, only a handful of peoples might benefit from that but all that they get is saving some extra manual work moving the duplicate files in and out of the haks. Not worth it.