Using the override folder with Steam
Proleric
Member Posts: 1,316
A long-standing problem with NWN is that mods installed in the override folder can conflict with those using the structured folders (mod, hak etc).
In the past, builders were advised to avoid override where practical, and players were encouraged to clear the override folder before playing structured mods (no easy matter, as it can easily become cluttered with random stuff of uncertain provenance).
However, Steam users presumably expect this sort of thing to be managed for them. The instructions seem to be positively encouraging new builders to override, too.
I wonder whether those with more experience of Steam have any suggestions?
I've proposed that modules ought to have an optional setting to disable overrides, to prevent conflict, but I don:t know if that will find its way to Trello.
In the past, builders were advised to avoid override where practical, and players were encouraged to clear the override folder before playing structured mods (no easy matter, as it can easily become cluttered with random stuff of uncertain provenance).
However, Steam users presumably expect this sort of thing to be managed for them. The instructions seem to be positively encouraging new builders to override, too.
I wonder whether those with more experience of Steam have any suggestions?
I've proposed that modules ought to have an optional setting to disable overrides, to prevent conflict, but I don:t know if that will find its way to Trello.
4
Comments
This is different from builders using override, which is frowned upon because it interferes with the client's experience in other modules, other builder's work, etc and a hak is a better solution.
As an occasional override user (and avid patch hak user), if you disabled overrides on your module the first thing I would do would be to open it up in the toolset and uncheck that box. My client is my choice, not yours. Similarly, the consequences of that are my problem, not yours.
I can understand the fear of "If an end user downloads a tileset mod that breaks my cutscene camera he could downvote my module." but given the nature of overrides I think it's a non-issue. I'd be supportive of the Vault removing demonstrably unreasonable votes to solve that problem but that's a conversation for that forum.
As for Steam: Steam makes overrides extraordinarily easy because you can have multiple override folders that you can turn on/off with the click of a button if your internet is fast enough. Unlike the old days where you would dump thousands of files into a bottomless pit from whence troubleshooting became difficult, the Workshop allows silo'd subfolders (one override folder per subscribed item). It's a superior method for override content, period.
What I find to be exciting is the potential for something like your modules, CEP, huge PW outlays, or Aielund Saga to be a 1 click download and installation rather than a relatively mystic process of subfolders and 7zs for new users. Workshop also makes forcing dependencies a lot simpler so repackaging CC could be a thing of the past for builders who don't want to hassle the player with 50 hak downloads, unzips, and cut and pastes.
Just to take one random example that's immediately at hand, I'm currently playing Rich Barker's N1 - Against the Cult of the Reptile God. Rich writes:
Well-informed players may take responsibility for this, but the whole direction of Steam seems to be to take folder management out of the hands of the player, and, as it stands, the instructions for builders are actively encouraging overrides, so the problem can only get worse IMO.
If there were a module switch to disable overrides, the conflict would cease. Of course, players who understand the toolset (a tiny minority, I suspect) could change my module to disable such a switch, but the moment they touch my code, they're unsupported. If that became a problem, builders might respond to the threat by not distributing the source code, which would be a terrible step backwards for our informal open source community, in which builders learn from one another's work.
I'm interested in your comment about Steam managing multiple overrides. That's not at all clear from the instructions. Perhaps Beamdog can comment - are override subfolders supported, or does Steam somehow keep track of which files belong to each mod, allowing regression?
A module switch already does exist. You could easily include the resources you are using within your module hak so they can't be overwritten by either override or patch hak method. Does that introduce a few MB of unnecessary hak bloat? Sure, especially if you're talking about forcing people to not use tileset overrides. It's highly feasible for scripts/2das though and probably worth it if you're that concerned about someone screwing up their own game.
Alternatively, why don't you put a message in your onEnter script saying something along the lines of: "Heads up. I HIGHLY recommend you don't play this module with overrides as they may break my module." If that type of warning is good enough on things like "Don't drink bleach, that's not how it's intended to be used" or "Don't mow your hedges with this lawnmower or you might cut your fingers off" then it's definitely good enough for a video game where someone actively went out of their way and sourced an override for their client.
Back to Steam: Each "mod" project (in the traditional sense, not the NWN) is a folder within your Steam Workshop subdirectory inside your Steam installation. Within each mod project can exist an override, a hak, a module, a tlk, etc folder.
I currently have 4 mods subscribed to on the Workshop, all of which are traditional overrides (Zwerks' Facelifts dumped from hak format to override, Cervantes' Creature Compilation, Beamdog's Aribeth, and Savant's RealSkies dumped from hak to override).
Despite those 4 subscriptions resulting in 4 override subfolders, they all work in game. Similarly, if I downloaded a module that had 4 external hak subscription dependencies, those haks would be housed in 4 different hak subfolders within 4 different project directories but still work with the module. Beamdog has created a pointer system so that all those independent subfolders are seen in addition to what is in your Documents.
The beauty of this is the ability to unsubscribe/subscribe at the click of a button and the files going to the right place automagically.
For Single Player and self-hosted Multiplayer players can still manually override the author's decision, but in case of an online PW they shouldn't be able to, period.
The option of adding all resources to haks doesn't really work, as it's not only the single resource that would break if overridden, it's also the consistency across the whole range of resources that can be affected by overrides. Anybody using NWNCQ is going to have a very different game experience than intended, when playing on an online server.
Having to override the override folder by adding the protected resources to a set of hakpacks definitely isn't the best solution
I then create an "override" folder in my game files. bingo, a fresh empty override folder. when I finish playing the mod, I can delete this folder and copy-paste the backup folder back into my game, if I need something in that folder to play the game or another mod that does not care if there is something in the override folder.
freestone
A player downloads a project simply by clicking the Subscribe button on a Workshop Item.
There's no indication of whether the project uses overrides or not, so the player can't tell whether it has compatibility issues. That pretty much knocks on the head any notion that players can manage compatibility.
Steam doesn't store Items in the central Documents folders (override, modules, hak etc). Instead, each Item has its own folder within the EE folder within the Steam program files on the PC. These folders are numbered, with no meaningful names, so only dedicated explorers will find them.
Each Item has its own override, modules, hak etc sub-folders as required.
When you play NWN on Steam, it aggregates across those folders (and anything in Documents). So, when starting a new game, it will list all the modules it finds. My understanding is that it also applies anything it finds in any override folder for any Item, not just the selected module.
So even if the player wants to disable overrides, there's no easy way to do it.
I'd say that's an overwhelming case for a builder-controlled module switch that disables overrides.
Also, I'm on the fence about wanting a "Overrides Begone" switch on modules. I definitely understand that I'm totally biased on this, but I've spent many hours tweaking the animal companions to be how I like them (to the point that its probably a little obsessive), and the obvious intention is that I want to use them in a module. If I enter a module and realize I can't choose to play with the Shark companion I had been working on just for the fun of it, I'd be pretty upset. Of course, this isn't the module maker's fault - for example, I didn't realize that the Aielund Saga also had buffs to the Animal Companions in numerous ways (Inherent regeneration, buffed AC, shared buffs and healing between the Druid and the Animal, etc), so I found my reworked spider companion (which had progressively higher AC, damage as it leveled, and ability and feat progression as if they were player characters) to be much tougher than I was anticipating. Or, even worse, a player could have made an Animal Companion with the sole intention of being an OP god creature, completely ruining any challenge in the module by basically cheating. Also, a module that uses haks to overwrite the Animal Companions obviously wouldn't let me use the Shark I had previously mentioned. (But that implies there are new animals to choose from, or at least they reworked them themselves, which could freshen up the experience) Basically, the rational side of me agrees with you, but me as a player who mods his experience to make it more fun wouldn't want to see it.
It's a really tricky proposition to leave mod authors with the burden of providing tech support for 16 years worth of haks and the wealth of incompatibilities that is to follow from people smashing mods together.
Likewise, players should ultimately have control of what they want to do with their game. After all, that's what makes NWN so special.
Players need to have final say and mod authors need a file structure they can work with to avoid everyone the headache of dealing with incompatibilities.
Edit: I think ultimately everyone wants the same thing. Users and creators both want it all to "just work" but how graceful that solution can be depends on a 3rd party entity (Valve).
Also... I would be lying if I said that my experiences with Greenlight and the Steam Forums has not colored my perception of the workshop. And because of that I haven't given it the chance it probably deserves. But couple that with the shutdown of NWVault and I'm not sure I trust steam as a primary host... but that's an entirely different discussion.
It would need to be for EE in general, not just Steam (my impression is that the .ini files are common to both).
Players would need to set it before playing, not in game, since scripts can be borked from OnModuleLoad onward.
That way, we don't have to trust Steam, just exploit them as a shop window to draw in more players.
To be fair, it's 5am and I have been watching Australian children programming for longer than I care to admit so I may not be operating in my greatest capacity...
However, I have two things to offer:
1: I fully plan on having anything I release to the public go first and foremost to The Vault. It's just safer that way and I don't think we are alone in that estimation.
2: The Wiggles are like if David Lynch had a polka band that played slightly inappropriate tunes at childrens birthday parties.
Tell me if anything should be added to the card.
As much as I am normally against Proleric's hate towards overrides I have to agree there. The way how steam lets players install overriding packages makes it unclear and uninformed to players. They are not informed that they are downloading "override" (and won't realize that themselves since they don't need to manually place files into override folder as in preEE era) and also it gets harder for them to remove them - the subfolders implementation of steam is cool but also makes the usual recommended action "clear your override then try again" impossible.
So I acknowledge that it is a problem and we should find a solution how to fix it.
I dislike that module builder will be able to controll overrides though. Plus it won't solve the problem at all. It will solve the problem only for Proleric and handful builders who are still updating their modules at this time. It won't solve the problems for older, no longer maintained modules though.
If this is seriously considered, then there is also a question of implementation - will this switch work only on overrides from steam workshop or also on override folder in NWN user folder or maybe even on patch-haks or /ovr folder in NWN install directory that uses community patch?
It cannot even be coded this way. It just cannot be a ini setting player can toggle because then, everyone will untoggle it as a first thing after installing NWN:EE (and I will be the one who will recommend them doing it).
And if this will be coded so it will be module specific then it doesn't solve the issue at all since only handful of the module builders will be able to use it. So basically you say this has nothing to do with steam. Steam is just an excuse to kill every content that works as override which you dislike.
And btw yes /ovr should not be used, but it can be. And if BeamDog foolishly listens to you and implement this then everyone who wants to use any kind of overrides will use /ovr folder instead. I don't think BeamDog can implement this feature in a way it will also block /ovr because then it would also killed new stuff from patches that BeamDog has in this folder.
Anyway, thank you. You persuaded me this is terrible and half-baked idea. Imo, the issue is on steam and workshop, they or authors/re-posters of the content should better inform player what is he downloading and thats all. Ultimately player should be always in controll of how he plays a singleplayer module. If you dislike this, do not publish your module as singleplayer but publish it as PW.
In your world, apparently, this is "hate".
Objectively, the way overrides work in NWN puts modules at risk. I know you think you're entitled to impose your mods on us, regardless of the harm done or the risk entailed, but, really, if you have no capacity to meet us half-way, why should anyone listen to you?
Conflict can be a wonderful tool to forge ideas and sharpen solutions.
But making personal remarks is not.
Let's not venture into the territory of the latter.
Its really upset because i m trying to build a anticheat script but there are tons of possibilities.