We now have a more or less functional merge tool in OpenMW-CS (file->merge). This merged all the loaded content files into a new omwgame file.
As you can see on the screenshot, it still has bugs. Well, one bug at least that I know of. If someone else can find other bugs I would like to hear about that.
Merge Tool
- psi29a
- Posts: 5356
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
Re: Merge Tool
Yay!
\o/
So this will be in the 0.37 release?
\o/
So this will be in the 0.37 release?
Re: Merge Tool
That depends entirely on how quickly I can find this bug (and on how fast scrawl proclaims the OSG port ready for prime time).
Re: Merge Tool
And there also seems to be a race condition with land record data loading, because the merge tool runs in a separate thread. This looks like a pain in the arse to fix.
Re: Merge Tool
Little update: I think I know how to deal with the race condition. The land texture bug evades me though. I even went into the component/esm code and added debugging statements into the load code. As far as I can tell everything is okay. Both LAND and LTEX records look correct. But the renderer (both in OpenMW and OpenMW-CS) does not agree with me.
Either I am missing something extremely obvious or there is a fundamental error in my understanding on how terrain in MW works. Out of ideas for now. Will sleep over it, but if I won't come up with a new idea, I will have to dig into the terrain renderer code. That could take a while because I haven't the slightest idea how that thing works.
Either I am missing something extremely obvious or there is a fundamental error in my understanding on how terrain in MW works. Out of ideas for now. Will sleep over it, but if I won't come up with a new idea, I will have to dig into the terrain renderer code. That could take a while because I haven't the slightest idea how that thing works.
Re: Merge Tool
To look up a land texture record from a ESM::Land::mTextures index, you need to subtract 1 from the index. Have you taken that into account?
https://github.com/OpenMW/openmw/blob/m ... e.cpp#L283
https://github.com/OpenMW/openmw/blob/m ... e.cpp#L283
Code: Select all
// NB: All vtex ids are +1 compared to the ltex ids
const ESM::LandTexture* ltex = getLandTexture(id.first-1, id.second);
Re: Merge Tool
Bloody hell, who makes up this kind of nonsense? Someone need to suffer for this atrocity.
Anyway, it is working now. Thanks. I will try to finish up the merge tool today.
Anyway, it is working now. Thanks. I will try to finish up the merge tool today.
- sirherrbatka
- Posts: 2159
- Joined: 07 Aug 2011, 17:21
Re: Merge Tool
You were expecting this.Either I am missing something extremely obvious or there is a fundamental error in my understanding on how terrain in MW works.
Re: Merge Tool
Yes, I did. Actually I was suspecting that the indexing was somehow off by one. But I couldn't make any sense of it.
Anyway, back to the race condition: The problem here is that the actual land data is loaded only on demand, which can happen from several threads. I disabled this mechanism for now. With the commit that I will push in a bit all land data is loaded during the initial load. We may add some kind of lock mechanism later that allows us to return to the previous approach, but personally I see that as a waste of time.
Reasons:
- No noticeable difference in loading time
- For the vanilla esms memory consumption goes up by about 55 MB (an increase of about 15% on my system), which really isn't much, unless you try to run OpenMW-CS on a toaster
- Delayed loading is actually kinda dangerous because we can not guarantee that the file still exists in an unmodified state later. Someone might load it into a second document and modify it there. Of course you shouldn't do that, but it is an mistake that is easily made and we would have to add a guard against that.
- OpenMW-CS has some functions that need all of the land data to be loaded anyway. Merge is the only one for now, but we will get others (not much) later.
Anyway, back to the race condition: The problem here is that the actual land data is loaded only on demand, which can happen from several threads. I disabled this mechanism for now. With the commit that I will push in a bit all land data is loaded during the initial load. We may add some kind of lock mechanism later that allows us to return to the previous approach, but personally I see that as a waste of time.
Reasons:
- No noticeable difference in loading time
- For the vanilla esms memory consumption goes up by about 55 MB (an increase of about 15% on my system), which really isn't much, unless you try to run OpenMW-CS on a toaster
- Delayed loading is actually kinda dangerous because we can not guarantee that the file still exists in an unmodified state later. Someone might load it into a second document and modify it there. Of course you shouldn't do that, but it is an mistake that is easily made and we would have to add a guard against that.
- OpenMW-CS has some functions that need all of the land data to be loaded anyway. Merge is the only one for now, but we will get others (not much) later.
Re: Merge Tool
Done. The merge tool is in master now.