Opening documents

[Greendogo]

Also, as far as I know, there is not any difference between the format and construction of ESMs and ESPs, except for their extensions, which dictates how they are treated by the engine and the CS.

I believe Bethesda created the distinction in order to prevent hasty modders from editing the masters directly. Regardless of why they did it though, I don't think OpenMW's editor should enforce these restrictions. That was one of the CS's faults: that it didn't give the user enough flexibility.

[Greendogo]

Yeah, but the CS is clueless. Also, ESMs can depend on other ESMs.

And I'm sure you could hack an ESM reliant on an ESP, just for the lulz.

Edit: i.e.- All the ESP/ESM/ESS files are just big data structures that either create a piece of data, or modify a piece of data from another file. It's pretty basic stuff, theoretically.

[mike29]

I believe Bethesda created the distinction in order to prevent hasty modders from editing the masters directly. Regardless of why they did it though, I don't think OpenMW's editor should enforce these restrictions. That was one of the CS's faults: that it didn't give the user enough flexibility.

IMO ESM is for specifying new content and ESR changes or uses it. But new content isn't adding to stuff in existing cells but only new cells. What flexibility they didn't give? Can you give me some example? I don't see it.

[Zini]

You can add new cells in ESPs, if that is what you mean.

[Greendogo]

IMO ESM is for specifying new content and ESP changes or uses it.

No, that's incorrect. They can accomplish all of the same things.

Also, side note, you keep referring to ESPs as ESRs (note the last letter, which is P for plugin).

[mike29]

I didn't say what you can do with these files. I said what could be intention of this split.

[Chris]

Also, as far as I know, there is not any difference between the format and construction of ESMs and ESPs, except for their extensions, which dictates how they are treated by the engine and the CS.

I'm not sure about Morrowind specifically, but at least with Oblivion (and early versions of Skyrim) there are actual differences between ESMs and ESPs. There's a value in the header that's set to 1 for ESM and 0 for ESP, and the engine will always load ESMs before ESPs (based on that bit, not the file extension).

[pvdk]

I don't agree. There is a need for file selector and load order in both places and it could be done with common widget. Using some files from one app in other can only bring troubles because someone can make changes that works for launcher but forgot about editor.

I have no idea what you mean with a common widget here, but really, the only part you'll need to move into components is the stuff in launcher/model. The sorting should be implemented in this model, and the views that display the data in the launcher are normal QTableViews, so there is no need to re-use those. The only thing I can think of would be the profiles, but I'm rewriting it, and that code should be re-usable.

I moved it there only because i wanted to create one common widget.

Can I see this common widget?

There is no need for graph structure so we don't need topological sort. IMO we can make it easier for user than mlox.

We'll need topological sorting to sort based on dependency. The graph is not a visual thing, it is a way to represent data internally.

I was thhinking about something very similar to current widget with two lists. Left one can show available files and right will specify loading order. When there is small number of files tere is no problem. Right list could be normal list box. Using drag and drop and arrows user can easily manage loading order. [...] What do you think?

If we implement sorting based on dependency the user won't need to move plugins around, or at least only in certain edge cases.

[mike29]

I have no idea what you mean with a common widget here, but really, the only part you'll need to move into components is the stuff in launcher/model. The sorting should be implemented in this model, and the views that display the data in the launcher are normal QTableViews, so there is no need to re-use those. The only thing I can think of would be the profiles, but I'm rewriting it, and that code should be re-usable.

DataFilesPage can be shared. It doesn't matter if some stuff is easy or not but if it can be easily shared.

We'll need topological sorting to sort based on dependency. The graph is not a visual thing, it is a way to represent data internally.

But now there are no deep dependences (a->b->c). Maybe there will be with new format.

If we implement sorting based on dependency the user won't need to move plugins around, or at least only in certain edge cases.

There is no enough information to do this in files. Otherwise tools like mlox would be unnecessary.

[pvdk]

DataFilesPage can be shared. It doesn't matter if some stuff is easy or not but if it can be easily shared.

I'm not saying it can't be shared, I'm just pointing out that there's no need to do so. Please have a look at the code because sharing the complete DataFilesPage makes absolutely no sense whatsoever. That's all I'm saying, you seem to know better anyways.