I was signaling my support for whatever the Vault community ultimately decides, in order to fix the current situation with NWN:EE projects, and also providing my personal perspective/input - as was solicited from all community members in the initial post.
Apparently there is still disagreement about how to refer to basic terminology about the different games. I guess that’s not surprising.
Yes, that was in part the point I was making at the end of my previous post. This needs to get sorted.
I’m not sure I understand this. In my own case, Sanctum is not “EE Only.” It’s compatible with both EE and NWN1, but it’s not showing up in the NWN1 list. EE only mods (if we had a way to specify that) should be excluded from the module lists for NWN1. Arguably, NWN1 modules should show up on an EE search (but not an “EE Only” search) because EE is supposed to be backward compatible.
That was Proleric’s quote, so I’m not sure which mods he’s talking about specifically.
In general, I believe the point is that people looking for NWN:EE - only projects should be able to sort them from mods that are not NWN:EE - only (and vice versa). Honestly I don’t much care how. Perhaps the technical folks could weigh in on what the most practical solution might be?
I will note that NWN1 / NWN2 / NWN:EE is how the game categories are sorted on the Vault Discord, which I’ve found helpful for categorizing chat discussions. If that’s not deemed appropriate for the actual Vault, so be it.
As a test, I just changed Sanctum’s “game” field from EE to NWN1. It now shows under an NWN game module search, but not an EE game module search. And now, there are only seven modules showing up on the EE game list. A lot more were showing there last week when this discussion started on the previous thread (see Proleric’s link).
I’m concerned about this, because I think that people with EE are naturally going to come to the Vault looking for modules they can play with EE. When they do, if they see EE as a separate game, they’re going to search on that, not for NWN1 modules. This is one of several reasons why I’m partial to the original suggestion that EE be added as a requirement rather than as a separate game. It seems to me that seeing “EE” in a field that says “Requirements” serves the same purpose as adding an “EE Only” field. Why add a field that’s already there? Unless we can’t currently search on it?
To get across to players that NWN1 modules are “EE Compatible,” I think that the best way is probably to only have “EE” appear in the form of an “only” or a “requirement” field. That way, players just search for NWN modules, and EE doesn’t even come up except for the handful that actually say you have to have it.
If you want to render actual compatibility, and are generous enough to think of EE as the evolution of NWN 1.69, one obvious solution would be to refactor the “expansion pack” mechanism into a “patch version” mechanism (i.e. build required for module - 8186 - or human-readable version - 1.69, 1.78, etc). Then lump it all into a combined NWN1 category.
That way, people wanting to play 1.69 stuff can filter by that patch level (or select the preset link for it), and people wanting to play EE can select anything > 1.69.
I don’t immediately know how to do this with Drupal w.r.t. including previous patches in the topmost selection, but I’m sure it’d be a surmountable problem.
@niv I’d support that, too, in principle, because it would achieve the same end result.
My niggle there is that probably most of us don’t know the patch version for EE (a tribute to Beamdog’s brand marketing for the Extended Edition). No doubt there are some new players who won’t know what 1.69 is, either.
I imagine, though, that Beamdog might release 1.79 one day, which could stamp modules saved in the toolset as unplayable under 1.78.
Unfortunately, we don’t know what the minimum release is for all the legacy modules, but arguably that doesn’t matter much.
So, building on your idea, I suggest we go for a Minimum Patch Version Required, selecting a value from
1.69 or earlier
EE 1.78
EE 1.79the last entry illustrating how future EE patches could be handled, but not an option on day 1.
It’s safe to assume that some (most?) players won’t even know the version of the game they’re running (EDIT: by version I mean 1.68, 1.69, etc - not Diamond vs EE). Nor they should care about it - we should assume they’re running 1.69 or whatever is the latest EE version. Therefore I think it’s too excessive to break the filter down to individual patches. There is also the issue of not being able to modify a setting after some records were added to db, as @Fester_Pot demonstrated.
However @Carlo raised another important point:
Assuming content creator can choose only between “Classic” and EE (or from a set of patch periods), what should they do when they release a module made for both games? They’ll probably want to attach two files on the same Vault entry. Like @Wendigo211 recently did. If they choose any of the options, they’re locked out from the other one in the filters.
Based on the above, I’m thinking of there could be a “both” option to choose or a two-checkbox field, like the current “requirement”. This however brings another issue of posters who will be selecting both checkboxes for 1.69 content, since “it runs on EE too…”.
@NWShacker I would have been happy to limit the Minimum Patch Version Required to
1.69 or earlier
EEwhich would have been exactly equivalent to “EE Required - Yes/No”. However, @niv’s post got me thinking about what would happen if Beamdog released 1.79 at some point. How does your comment address that?
Regarding the possibility that an author produces two versions of a module, one requiring EE and the other not, I don’t see any need to complicate the classification. If they choose to put both on the same page, EE is not required to play that module, period. The author will need to describe both files so that it’s clear that one requires EE.
Correct me if I’m wrong, but I’m guessing nothing would happen? Just like there were no issues when they released 1.71, 1.72, 1.74, etc. As long as the patched product is called NWN:EE, everything should be good (read: fall under EE criterion). Unless, of course newer EE versions are not backward-compatible, but I doubt that. This simplifies both the filter and troubleshooting - users just need to “get the latest patch” rather than wonder if they need a specific build to run a certain module when they don’t.
Very well, it makes sense. Though some may perceive this like a drawback because their dual-game work won’t appear on “EE required” filter (and thus may not promoted as made with the new, shiny game version). However it’s safe to assume that this filter will be used mostly by Diamond users to filter EE out, not in, which is more important anyway.
Bottom line: I support the binary "EE Required - Yes/No” property, as long as it is feasible for Vault admins to implement.
Regarding patch levels, the issue isn’t backward compatibility. The problem would arise if modules made with, say, 1.79 could not be played on 1.78 (which is the case with 1.78 and 1.69). That is likely to happen, because features of the new release are simply not available in the old one.
Bioware always made new patch releases available for free to existing customers. If Beamdog does the same, the problem goes away, but we have no control over that.
Bottom Line - I’d support “EE Required - Yes/No” too, if we are prepared to accept that risk.
Apologies, I mixed up like a dumbass. I meant that newer version can run modules made with older versions, so as long as users can freely update, for now we can conflate everything post-1.69 as generic “EE” (and redirect those with outdated game to latest patch). But as you insightfully say, this may not be always the case and the proposed change should be future-proof.
Since EE is in constant development (and thus new NWScript functions are rolled out), we should naturally assume there will be no backward compatibility between its own versions.
In hindsight, if we use the dropdown selection, we should be able to add new entries as they arrive in the future. Just like “NWN:EE” was added to “Game”. I believe @Fester_Pot can confirm that. But if we wanted to have such opportunity, the name of the field should reflect that. Perhaps broader “Game version required” is actually the way to go (with “1.69” and “EE” options for now). It would also be good if @Fester_Pot could verify that such “EE” could be later renamed to “EE something”. It might also be a good idea to rename the current “requirement” label (over OC/XP1/XP2) to “expansion” to avoid confusion (since even the URL contain the word when you click on them: https://neverwintervault.org/expansions/oc).
In hind-hindsight, there is yet another option, a bit more aggressive. For now there could be two dropdown menus:
with second being a used to narrow search scope of the first. If there is a XP-like paid EE “expansion” released, we add similar menu called “NWN:EE package required”. This seems like a quite flexible and future-proof approach. Naturally, the hard part is replacing current “requirements” OC/XP1/XP2 with the above. Thought?
@NWShacker I’d keep it simple - building on your first proposal, Minimum Game Version Required as a dropdown for future expansion, with initial values
1.69
EEStrictly speaking, there are plenty of modules that will run under earlier releases than 1.69, but on reflection it was pedantic of me to say “1.69 or earlier”, since few early modules specify the version required, and everyone can upgrade to 1.69 for free.
I still lean towards doing nothing about the OC XP1 XP2 thing, being no fan for change for its own sake.
For the benefit of newcomers to the thread, I’ve changed the opening proposal to that effect (striking through the original so that the discussion still makes sense).
What do other people think? Are we converging on a solution here, or going off at a tangent?
Very well, let’s roll with that. It appears we have converged close enough to an optimal solution for this time. The list values are also self-explanatory, which is yet another advantage.
All the other stuff I wrote in the last post can be considered a future expansion in case another modification is needed (i.e. an EE expansion appears). Dropdown lists seem to have higher flexibility than radio buttons, so in any case they should be the way to go.
Excellent. I’ll keep this thread open for a few days in case there are serious objections, but otherwise I don’t think we need another poll and could move to implementation.