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.
Opening documents
Re: Opening documents
And I'm sure you could hack an ESM reliant on an ESP, just for the lulz.Zini wrote:Yeah, but the CS is clueless. Also, ESMs can depend on other ESMs.
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.
Re: Opening documents
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.Greendogo wrote: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.
Re: Opening documents
You can add new cells in ESPs, if that is what you mean.
Re: Opening documents
No, that's incorrect. They can accomplish all of the same things.mike29 wrote:IMO ESM is for specifying new content and ESP changes or uses it.
Also, side note, you keep referring to ESPs as ESRs (note the last letter, which is P for plugin).
Re: Opening documents
I didn't say what you can do with these files. I said what could be intention of this split.
Re: Opening documents
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).Greendogo wrote: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.
Re: Opening documents
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.mike29 wrote: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.
Can I see this common widget?mike29 wrote:I moved it there only because i wanted to create one common widget.
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.mike29 wrote:There is no need for graph structure so we don't need topological sort. IMO we can make it easier for user than mlox.
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 wrote: 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?
Re: Opening documents
DataFilesPage can be shared. It doesn't matter if some stuff is easy or not but if it can be easily shared.pvdk wrote: 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.
But now there are no deep dependences (a->b->c). Maybe there will be with new format.pvdk wrote: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.
There is no enough information to do this in files. Otherwise tools like mlox would be unnecessary.pvdk wrote:If we implement sorting based on dependency the user won't need to move plugins around, or at least only in certain edge cases.
Re: Opening documents
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.mike29 wrote:DataFilesPage can be shared. It doesn't matter if some stuff is easy or not but if it can be easily shared.