Opening documents

Involved development of the OpenMW construction set.
User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: Opening documents

Post by Zini » 28 Feb 2013, 10:37

That might cause spam of additional profiles though. I think we need to throw around a lot more ideas before this feature is implemented.

mike29
Posts: 24
Joined: 18 Dec 2012, 19:54

Re: Opening documents

Post by mike29 » 28 Feb 2013, 11:05

Create one profile per edited file. Keep 5, 10, 20 last profiles. All can be accessible from menu like in other programs. Selection of last profile opens open dialog witch files selected. This allows user to modify it but isn't annoying because quick "enter" tap opens file.

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

Re: Opening documents

Post by Zini » 28 Feb 2013, 12:00

Create one profile per edited file.
This is an interesting point. Can we go with this limitation or will that cause problems? After all you can load a file for editing with varying other content files.
Keep 5, 10, 20 last profiles.
This obviously needs to be configurable. As a defender of the Zero one infinity rule I will not allow such obscene numbers as 5, 10 or 20.

We really need to get our user settings dialogue and backend up and running. Otherwise we will spend the next few months combing through the editor source to replace hardcoded values.
Selection of last profile opens open dialog witch files selected. This allows user to modify it but isn't annoying because quick "enter" tap opens file.
This idea I like.

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

Re: Opening documents

Post by Zini » 28 Feb 2013, 12:36

btw. this
We really need to get our user settings dialogue and backend up and running. Otherwise we will spend the next few months combing through the editor source to replace hardcoded values.
was a call for help. I think pvdk has already done some backend work in his launcher branch, that we might be able to re-use. Any takers?

mike29
Posts: 24
Joined: 18 Dec 2012, 19:54

Re: Opening documents

Post by mike29 » 28 Feb 2013, 12:42

Zini wrote: Then there are two remaining issues:

1. There is no need to select a file for editing. As mentioned before, the editor will always edit the last file in the list. For "new file" we obviously need a field to enter the name of the new file. But that is all. No selection mechanism.
What do you mean by last file in the list? Last selected or clicked? What if last action unselected file? What if that was a dependency of last selected element? If there are many plugins (MGSO) user would have to scroll back to file and check it once more.
Zini wrote:2.Keep the old separated design or switch over to the new one (viewtopic.php?f=6&t=1312).

If we are going for the new one, the new UI can mostly stay, but we still need to undo the merge in the model. A short recap:

Any valid content stack consists of exactly one .omwgame file and zero or more .omwaddon files (I think these are the extensions we agreed upon).
Isn't new file format post 1.0 thing? I have to manually merge bloodmoon, tribunaland and morrowind patch in one file or change them into plugins.

About new UI. Masters and plugins were merged because there are no much masters files. IMO they don't need separate listbox. But I don't really care it can go both ways.
More important for users would be possibility to change loading order. Some plugins have conflicts or bad dependencies and user should be able to "fix" that. What do you think?

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

Re: Opening documents

Post by Zini » 28 Feb 2013, 13:05

What do you mean by last file in the list? Last selected or clicked? What if last action unselected file? What if that was a dependency of last selected element? If there are many plugins (MGSO) user would have to scroll back to file and check it once more.
When loading files into the editor or OpenMW you always have a sequence of ESX files (which I have dubbed as "content stack" in some places). These have a clearly defined order. When loading a content stack into the editor, the last file in that sequence will always be the file to be edited; unless you create a new file. In this case the new file is appended to the end of the list and thus becomes the last file.
Isn't new file format post 1.0 thing?
We had a whole thread about that: viewforum.php?f=6

It got slightly derailed, but for the most part the original posting is still where we stand (the only real difference is that we will be cutting down on the header topic a bit).
IMO they don't need separate listbox.
With the original concept of ESP/ESM files, one could argue one way or another about that. With the new file concept separated UI elements for game and addon files are a must.
More important for users would be possibility to change loading order. Some plugins have conflicts or bad dependencies and user should be able to "fix" that. What do you think?
Obviously. Not sure why this feature has been missing in the first place.

graffy
Posts: 142
Joined: 06 Feb 2013, 19:30

Re: Opening documents

Post by graffy » 28 Feb 2013, 13:27

Ok, what you're saying is what I was originally thinking, but I'm afraid something isn't making sense to me...

If I'm right, it looks like we should be creating / loading profiles, not plugins, with the editor's startup dialog, right? It seems that you mean to store the dependency tree for a plugin using the launcher's profile system. If that's what you mean, then that's where I get confused, because as I understand it, the dependencies are stored internally in a plugin - meaning a recursive algorithm is all you need to build the tree... So why have a profile that records the same info? If that's not what you mean, then what additional data (that is not contained within the plugin itself) do we need to capture using a profile?

Pardon my complete ignorance on the topic of modding - while I admit, I forsook food and sleep to play Morrowind when it was released, I am entirely uninitiated with respect to modding workflows and concepts. So, I naturally assume there's something I'm missing... :)

mike29
Posts: 24
Joined: 18 Dec 2012, 19:54

Re: Opening documents

Post by mike29 » 28 Feb 2013, 13:40

Zini wrote: When loading files into the editor or OpenMW you always have a sequence of ESX files (which I have dubbed as "content stack" in some places). These have a clearly defined order. When loading a content stack into the editor, the last file in that sequence will always be the file to be edited;
What defines order? If dependencies from plugins then it's not always clear witch file to edit. If user have to do it manually it will be a hassle when I want to load many plugins. Or nobody really cares about loading many plugins?
We had a whole thread about that: viewforum.php?f=6

It got slightly derailed, but for the most part the original posting is still where we stand (the only real difference is that we will be cutting down on the header topic a bit).
Changing headers don't look like a huge gain comparing to lost compatibility, but I'm not a expert. Treating Tribunal.esm and Bloodmoon.esm as plugins is great but it don't require file format change.

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

Re: Opening documents

Post by Zini » 28 Feb 2013, 13:46

If I'm right, it looks like we should be creating / loading profiles, not plugins, with the editor's startup dialog, right? It seems that you mean to store the dependency tree for a plugin using the launcher's profile system. If that's what you mean, then that's where I get confused, because as I understand it, the dependencies are stored internally in a plugin - meaning a recursive algorithm is all you need to build the tree... So why have a profile that records the same info? If that's not what you mean, then what additional data (that is not contained within the plugin itself) do we need to capture using a profile?
Yes and no. We are creating and loading plugins (actually content files of any type). But these can not exist in isolation. Unless it is something Morrowind.esm-like (i.e. a game file in the new file scheme), it requires other content files to be loaded. The dependencies specified in the loaded content file (including the dependencies specified in the dependencies) give us a mandatory list of such files. But the user should also be free to add additional files alongside. That can be useful in the editor and it is absolutely necessary for OpenMW.

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

Re: Opening documents

Post by Zini » 28 Feb 2013, 13:50

What defines order?
The one selected by the user. The content file selector UI (in the launcher and the editor) is supposed to create a suggested order based on dependencies specified in the files and time stamps, but ultimately it is up to the user to decide.
Changing headers don't look like a huge gain comparing to lost compatibility, but I'm not a expert. Treating Tribunal.esm and Bloodmoon.esm as plugins is great but it don't require file format change.
I am sorry, but I am not having this discussion again. It has already been explained why we can't save in ESP and ESM format (hint: we can not generated MW script bytecode).

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests