POLL: Merged versus Separate in MO

[z929669]

Agree with all that. The only 'consistency' that the Nexus API offers in terms of data is reliant on the MA being consistent in naming the file. Then "name" is something MO can use to check for version change/status (concurrently with "uploaded_timestamp") in the json.

Nexus needs "versionID" under constant "fileID" to provide anything reliable.

There are clear advantages of separating and not merging (and they outweigh the benefits of merging, IMO), but it would be much more advantageous if Nexus' data collection from the MA were more robust (and leveraged in the API). The FOMOD/bundled-installer also remains. It would be easy to include versionID as a component of fileID in FOMOD XML. It's all under-specified.

[DoubleYou]

At least for the patches provided for KHO, installing separately definitely allows MO2 to check for updates per file. Just saw the update for "kryptopyr's Patch Hub - Saints and Seducers (CC) __ TCIY" file, updated on Dec 26. This is what the update check did and then correctly shows per-file versions:

[z929669]

Just circling back on this:

We have confirmed that he MO versioning only works on Main Files with versioning matching the global version. Any Main File with mismatched version will be flagged for update in MO. Both Optional and Miscellaneous Files can use custom versioning that does not match the global version, and MO will track these properly.

We still don't know about Update Files yet.

EDIT: Versioning is separate from global for all but the Main Files files.

[Mousetick]

1 hour ago, z929669 said:

Both Optional and Miscellaneous Files can use custom versioning that does not match the global version, and MO will track these properly.

As long as the base file name doesn't change from one version to another. It seems like obvious common sense, but it's dependent on the MA uploading new versions with the same name, which is far from guaranteed.

It happens that MO's version tracking works well with kryptopyr's patch hub because the maintainers use a consistent naming scheme across patches and versions. But it's just a happy coincidence.

Let's say you upload the next version of 'Step Patch - Lighting and Weather' to Nexus and name it 'Step Patch - Lighting & Weather' this time. I'm pretty sure MO won't see it's the new version of the same patch: the currently installed previous version 'Step Patch - Lighting and Weather' will still be considered up to date.

I wonder how Vortex handles update tracking. Anyone know? I'd bet it just flags the mod as updated whenever any new file is uploaded, like the Nexus web site does, without any granularity.

[z929669]

11 hours ago, Mousetick said:

As long as the base file name doesn't change from one version to another. It seems like obvious common sense, but it's dependent on the MA uploading new versions with the same name, which is far from guaranteed.

It happens that MO's version tracking works well with kryptopyr's patch hub because the maintainers use a consistent naming scheme across patches and versions. But it's just a happy coincidence.

Let's say you upload the next version of 'Step Patch - Lighting and Weather' to Nexus and name it 'Step Patch - Lighting & Weather' this time. I'm pretty sure MO won't see it's the new version of the same patch: the currently installed previous version 'Step Patch - Lighting and Weather' will still be considered up to date.

I wonder how Vortex handles update tracking. Anyone know? I'd bet it just flags the mod as updated whenever any new file is uploaded, like the Nexus web site does, without any granularity.

Yes, the name must be unique and consistent for versioning to work for that file. But if it's a Main File, I believe it must always match the global version, but I'm unable to test this explicitly until we update next.

EDIT: Well, maybe even the Main File doesn't need to match global version as long as the file name remains the same, but the true test is still pending.

[z929669]

So I tested this, and most of our working assumptions are correct:

Optional and Misc Files sections on Nexus are interpreted independent of global version by MO. As long as they are version 'updates' to a particular file in one of those sections, MO does not flag the file/mod for update and displays the correct version as current. Now, I assume --but have not tested-- that using Nexus' "This is a new version of an existing file (optional)" toggle associates the updated version with that which it is replacing, regardless of the file 'name'.

However, both Main Files and Update Files are compared to the global version on the Nexus page. If they don't match, they are flagged for update in MO. Ultimately, the Nexus data lacks the necessary differentiators. For example, it appears that in the json, "mod_version" always equals "version" for the same mod. This is nonsensical and redundant. If mod_version always used the file version entry and version always used the global entry, then Nexus could add "mod_previousversion" to the json for mod managers (and Nexus) to use as a comparison (looking only at most recent timestams for json entries of a given file). Version is largely redundant, since the mod page is not always 1:1 with files available for download. The fileID should also remain consistent with the original for updated files so that machine-generated integers can be compared rather than name strings created by humans.

In fact, there are lots of ways to do this 'right', so I'm miffed that Nexus hasn't landed on a more viable solution.

[notcyf]

I don't see the reason why you would merge. 

• Merging makes reinstalling mods more tedious, because you can't just right click "reinstall", since that will only reinstall whatever you installed last.
• You have better file & conflict management by separating every mod download
• It's easier to detect & fix user errors made when you don't merge!

ESPECIALLY the last part is what is the reason why every single separate mod file you download be separately installed. If you made a mistake somewhere, and you don't know, it's much harder to tell where the mistake was made, IF it was made due to a merge issue.

MO2 is MADE to separately install every zip file added to the Downloads section of MO2. The more you separate, the more you can let the VFS handle, the better you let MO2 shine in its functionality. Merging = Bad and should never be used in MO2.

[z929669]

5 hours ago, notcyf said:

I don't see the reason why you would merge. 

• Merging makes reinstalling mods more tedious, because you can't just right click "reinstall", since that will only reinstall whatever you installed last.
• You have better file & conflict management by separating every mod download
• It's easier to detect & fix user errors made when you don't merge!

ESPECIALLY the last part is what is the reason why every single separate mod file you download be separately installed. If you made a mistake somewhere, and you don't know, it's much harder to tell where the mistake was made, IF it was made due to a merge issue.

MO2 is MADE to separately install every zip file added to the Downloads section of MO2. The more you separate, the more you can let the VFS handle, the better you let MO2 shine in its functionality. Merging = Bad and should never be used in MO2.

You should add your pick to the poll.

[Eliian]

I always separate now. This poll has thought me the way. Been doing it the last few weeks and version updates are easier to track for mods like At Your Own Pace. Separating does not always work, but at least files are more organized.