OpenMW CS - Merge

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

Re: Openmwcs-merge

Post by psi29a » 12 Jul 2018, 12:21

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.

User avatar
kuyondo
Posts: 221
Joined: 29 Mar 2016, 17:45

Re: Openmwcs-merge

Post by kuyondo » 12 Jul 2018, 14:04

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: 1091
Joined: 26 Nov 2015, 03:25

Re: Openmwcs-merge

Post by AnyOldName3 » 12 Jul 2018, 15:36

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.
AnyOldName3, Master of Shadows

User avatar
Zini
Posts: 5504
Joined: 06 Aug 2011, 15:16

Re: Openmwcs-merge

Post by Zini » 12 Jul 2018, 17:16

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: 5504
Joined: 06 Aug 2011, 15:16

Re: Openmwcs-merge

Post by Zini » 12 Jul 2018, 18:00

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: 1091
Joined: 26 Nov 2015, 03:25

Re: Openmwcs-merge

Post by AnyOldName3 » 12 Jul 2018, 19:44

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.
AnyOldName3, Master of Shadows

User avatar
Zini
Posts: 5504
Joined: 06 Aug 2011, 15:16

Re: Openmwcs-merge

Post by Zini » 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.

User avatar
psi29a
Posts: 4200
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: Openmwcs-merge

Post by psi29a » 12 Jul 2018, 21:07

Zini wrote:
12 Jul 2018, 20:02
especially since you lose the ability to aromatically detect conflicts.
The smell test? I'm curious...

User avatar
Zini
Posts: 5504
Joined: 06 Aug 2011, 15:16

Re: Openmwcs-merge

Post by Zini » 12 Jul 2018, 21:20

lol. Auto-correct and still overheated brain.

User avatar
AnyOldName3
Posts: 1091
Joined: 26 Nov 2015, 03:25

Re: Openmwcs-merge

Post by AnyOldName3 » 13 Jul 2018, 01:54

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.
AnyOldName3, Master of Shadows

Post Reply

Who is online

Users browsing this forum: No registered users and 5 guests