OpenMW CS - Merge

Questions specific to OpenMW-CS can be asked, and content development related topics can be discussed here
User avatar
psi29a
Posts: 5356
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: Openmwcs-merge

Post by psi29a »

AnyOldName3 wrote: 12 Jul 2018, 12:17 I definitely consider it well within the scope of the CS, even if it's provided as a plugin rather than a built-in feature.
I agree with approach, we can provide tools then link them into OpenMW-CS as plugins.
kuyondo
Posts: 243
Joined: 29 Mar 2016, 17:45

Re: Openmwcs-merge

Post by kuyondo »

Polemos has a wrye mash fork that aims to implement support for openmw. Wrye mash has the merge feature built in.

Just saying, in case you guys are interested http://en.uesp.net/wiki/Tes3Mod:Wrye_Mash. I do not know to what extent it could help with the development of merging .omwaddon .
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: Openmwcs-merge

Post by AnyOldName3 »

Wrye Fl/B/Mash is obsolete. Mator Smash and Mator's Merge Plugins do a much better job (for example, they merge records other than levelled lists). I don't think they support Morrowind, though, as they're based on xEdit. If we make the plugin system nice, I don't imagine it would be too difficult to persuade Mator to port his work to our framework or let one of us do it.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Openmwcs-merge

Post by Zini »

A plugin isn't really an option. We would require an extensive API, way more than I expect to have ready in the early post-1.0 phase. Considering that a better merge tool is essential for projects like TR, I really want this to be ready for 1.0 or at least not far after 1.0. Besides if we do integrate the new merge tool into OpenMW-CS then it makes sense to run it in the main code, because that allows for a large amount of code reuse (not to mention the performance benefits; this stuff requires heavy lifting).

I still think this is not a great idea, but here is the concept. Note that this is the only option we have if we want to go down this route. The data structures of OpenMW-CS don't allow for anything else.

Let's assume we have a gamefile A and three addons B, C1 and C2. B depends on A. Both C1 and C2 depend on B. The user wants to merge C1 and C2 into B.

The user would then load all three addons (A-B, A-B-C1, A-B-C2) as separate documents. We may later add an advanced feature where only B is loaded manually and OpenMW-CS loads C1 and C2 automatically.

Afterwards the user goes to the B document and activates the merge feature. He would then be presented with a list of loaded addon documents with matching base content file list (e.g. C1 would match because it is A-B-C1, with A-B being the base part which matches the B document). The user can select which addons he wants to merge and in what order.

After that follows the check phase, where OpenMW-CS runs through all records and checks for conflicts (e.g. records that are changed by both C1 and C2). The user will be presented with a list of these records and he can decide for each how to resolve the conflicts.

In later versions we could add some pretty cool advanced features, like an auto-merge options for land records when both C1 and C2 make modifications to the same land record but without any overlap.

We could also allow the user to jump from the conflict list straight to the respective documents (like clicking on an error in the script subview jumps you to the line of code).

Once all conflicts are resolved the merge tool creates a new document in memory from the merged content files; with an option to run an automatic verifier stage and (if verify didn't find any errors) an automatic save.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Openmwcs-merge

Post by Zini »

Oh great, now that I am thinking about it I feel an almost irresistible urge to get on with coding that thing. As if I weren't busy enough :(
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: Openmwcs-merge

Post by AnyOldName3 »

Is it not conceptually simpler to merge C1 into B and then merge C2 into the new B as a completely independent operation? If we compare to Git, we've got the equivalent of trying to merge two branches into master at once, when really we should merge one branch, then resolve any conflicts this causes with the second branch by editing the second branch, then merge the second branch once it doesn't conflict any more.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Openmwcs-merge

Post by Zini »

Can't do that, because after the merge B isn't B anymore. It is a new content file (B'). To do it in order, you would have to port C2 to B' first. There are no benefits to this approach, especially since you lose the ability to aromatically detect conflicts.
User avatar
psi29a
Posts: 5356
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: Openmwcs-merge

Post by psi29a »

Zini wrote: 12 Jul 2018, 20:02especially since you lose the ability to aromatically detect conflicts.
The smell test? I'm curious...
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Openmwcs-merge

Post by Zini »

lol. Auto-correct and still overheated brain.
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: Openmwcs-merge

Post by AnyOldName3 »

Zini wrote: 12 Jul 2018, 20:02 Can't do that, because after the merge B isn't B anymore. It is a new content file (B'). To do it in order, you would have to port C2 to B' first. There are no benefits to this approach, especially since you lose the ability to aromatically detect conflicts.
Surely the conflicts still exist between C2 and B' and can, therefore, be detected? If there's a rebase kind of thing as an intermediate step, it should notice that there are incompatible changes.

I was under the impression that the Fallout 4 and Skyrim SE creation kits have a merge tool built in which is intended for use in version control and has basically the same workflow as Git. It's what was used to build the games in the first place. That's the concept I have in my mind for this kind of tool, and I don't see any reason it shouldn't be feasible if Git itself is feasible. Someone should probably investigate what the official Bethesda tools do as that's a good thing to try and emulate if it's fit-for-purpose.
Post Reply