OpenMW Merge Tool (request for comments)

4 posts / 0 new
Log in or register to post comments
Last post
(Reply #1) Posted on Mon, 2018-07-16 11:45
psi29a's picture
psi29a
Joined:
2016-01-03 22:36
Last seen:
6 years 5 months ago

Hey guys... been awhile, but still around and lurking.

We at OpenMW have been busy bees but wanted to reach out TR on a few things to see if we can make your lives easier.

This is a call out to all modders and game makers over an OpenMW Merge Tool. We need your input! What are the things you guys need and/or would like to have to make your lives easier when working with things like leveled lists, merge conflicts and etc.

Content from my PM with Zini

Sent: 15 Jul 2018, 10:01 

From: Zini 
Recipient: psi29a 

Hey, do you still have contacts at TR? With Redemption gone they should be the biggest user of our merge tool. Might be a good idea to have them weight in on this discussion: https://forum.openmw.org/viewtopic.php?f=39&p=56665#p56665

What do you guys think?

Cheers!

(Reply ) Posted on Mon, 2018-07-16 17:07
MinerMan60101's picture
MinerMan60101
Exterior ReviewerInterior Reviewer
Joined:
2016-10-09 23:10
Last seen:
1 day 1 hour ago

Here's a link to our Discord, we're extremely active there: https://discordapp.com/invite/9T6TtNU
Also, here's Project Tamriel's (who we work with closely): https://discord.gg/waZcqnF

(Reply ) Posted on Tue, 2018-07-17 22:11
Atrayonis's picture
Atrayonis
Developer EmeritusInterior DeveloperQuest Developer
Joined:
2015-09-28 20:13
Last seen:
2 years 8 months ago

Hi psi29a, good to see you are around still.

I'll reply directly in the OpenMW forum (same name), but for completion's sake, I'll post my reply here too.

Our workflow seems to be a bit different from that of Redemption.

As our assets are kept in the Tamriel_Data.esm and BSAs, modders just make esps adding to or overriding assets. They are first merged in a TR and PT data addon esp and merged into the real Tamriel Data later. Deletion notices are placed in text form and the lead developer tasked with merging the files has to go and do these manually. This is PT's call, as they have been leading efforts on Tamriel_Data.

The claim workflow is similarily compartmentalised: first we cut our heightmap files (TR_RestExterior) into section files, chop off worldspace bits (3x3 cells or larger) and then put them out for developers to claim. There's some border (landscape) matching happening at this stage, but that is between individual modders and claims and the esps themself never exceed their original cell boundaries.

Interiors are similarily posted and developed individually: one interior, one claim. They have temporary names until they are merged back into the section files.

Both exterior and interiors are stitched together into the section file. As these files are either using assets implemented globally in Tamriel_Data or claim-specific ones (using existing assets but a unique ID), there are (theoretically) no ID or cell conflicts.

Once exteriors and interiors are finished enough, we have NPC/Dialogue and quest claims, which is where the merge complexity actually comes in.

What I would really like:

  • Better dialogue conflict resolution. When dialogue has gone wrong, it drops to the bottom of the order, something to help re-stick a bulk of changed replies would be a godsend.
  • Conflicting cell names (for interiors specifically) would be really good. With the size of TR, there have been cases of duplicate cell names which weren't caught until months after merging as the content of the interior cells were spaced too far apart to actually visibly conflict.
  • Automatically discarding empty "edited" wilderness cells and landscape edits without corresponding cell edits (this has actually happened).
  • An option to automatically discard duplicate entries between an esp and an esm.
  • A pipe dream would be a way to merge deletions of existing assets.
(Reply ) Posted on Tue, 2018-07-17 22:40
Rot's picture
Rot
Quest Developer
Joined:
2014-03-16 17:45
Last seen:
2 years 1 week ago
Repeating another point from chat, as I saw it the main block for merging in TR comes not from the merging process itself but from the ESM instance index being what forces you to cut and replace portions and never directly edit any cells, wrye mash updating aside. I don't know why beth's CS generates a different cell index every time a plugin is saved and if openMW-CS doesn't do that, the issue is already gone. Maybe the CS does it to save time when saving files, an option to not do it would be good enough.

Re: " When dialogue has gone wrong, it drops to the bottom of the order " in Atrayonis' post, that comes from a dialogue entry not being able to find its previous entry reference. The CS gives an error message but modders often don't know to wait for them and skip all warnings from the first one, and when they save the file the dialogue is saved at the bottom of the list and there isn't an error anymore. It's something the loading process for plugins needs to pick up on, but since loading plugins is the first thing a merging tool does, all these checks are necessarily part of it already.

Welcome to the Forums

A quick overview of new and updated content can be found in your dashboard. If you are interested in our ongoing development, check out the claims browser and the asset browser.