Opening documents

Involved development of the OpenMW construction set.
mike29
Posts: 24
Joined: 18 Dec 2012, 19:54

Re: Opening documents

Post by mike29 »

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.
I see bad UI. To open file user will have to drag it to top of a list or change it load priority to higher than others plugins. Maybe it'll not be a problem.
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).
Yes, I read that. It can be fixed by external tool. But more important is that file format will be changed for few headers...
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Opening documents

Post by Zini »

I see bad UI. To open file user will have to drag it to top of a list or change it load priority to higher than others plugins. Maybe it'll not be a problem.
You can not reasonably edit a file in the middle of a content file sequence. First, that data model of the editor simply does not allow that. Supporting such a feature would increase the complexity by a huge amount. Second, if we were going to do that, this would result in a usability disaster.

Scenario: We have a sequence of 3 content files: A, B and C (in this order). The user is editing B. Now he decides to edit record x. Record x is present in B and C. Unfortunately the modifications in C will overwrite whatever changes the user makes in B. So none of his changes will have any effect on the state of record x as displayed in the editor.
Yes, I read that. It can be fixed by external tool. But more important is that file format will be changed for few headers...
I presume that this is an honest attempt to discuss this topic and somehow the point just got lost. I am sorry, but I think that is the 3rd time that I am having this discussion and I am starting to get a bit irritated about it. I am really the only one here, for whom this is totally obvious?

The files produces by the editor will not be compatible with MW. Saving them in a way that they can be mistaken for MW content files (by giving them the extension esp or esm) is a terrible idea. It would cause confusion to no end.

Any arguments about being able to fix these files by running them through an additional tool (e.g. the original CS) are meaningless, because we still have files coming out of the editor that look like esp or esm files and are not compatible with MW esp and esm files. People will produce these and they will upload these. And then other people will get confused about why their downloaded files are not working in MW (or project ProjectAedra, if that ever finishes).
I don't even want to think about the fallout we would get from that.
mike29
Posts: 24
Joined: 18 Dec 2012, 19:54

Re: Opening documents

Post by mike29 »

You can not reasonably edit a file in the middle of a content file sequence.
This use case is insane. I wasn't thinking about it.

I was thinking about scenario with IMO is quite possible. Morrowind plus 30 plugins that depends on it.

Morrowind will be loaded first. And then 30 plugins. Open dialog can't give more help. Now if i want to edit plugin "X" i have to drag it on top of a list before other plugins. If plugins have "weights" I have to edit "X" weight to open it.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Opening documents

Post by Zini »

Sorry, I do not understand what you mean.
mike29
Posts: 24
Joined: 18 Dec 2012, 19:54

Re: Opening documents

Post by mike29 »

Sorry. Actually i wanted to ask two questions.

Usecase:
User wants to load morrowind file and 30 plugins that depends only on morrowind.
User want to edit 1 of 30 loaded plugins.

How open dialog communicate to user witch plugin will be opened?
How user can change file to open?
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Opening documents

Post by Zini »

The edited file is the last file in the file list. So the user would have to make sure that the file he wants to edit is the last in the list displayed in the open file dialogue (via the reordering functionality, which you previously correctly stated as missing from our current implementation).
graffy
Posts: 142
Joined: 06 Feb 2013, 19:30

Re: Opening documents

Post by graffy »

I realize my interjection has created a couple trains of thought going on here - but at the risk of hijacking the conversation, I do want to go back to the profiles point mentioned earlier...

What may work is creating a single "plugin session profile" - one file which stores a list of all of the plugins and any assets that were loaded during each plugin's previous editing session. The only thing we're saving, if I understand correctly, is the plugin name and the paths to loaded assets that were not incorprated into the plugin (and thus made a dependency) in the last session, right?

So, for example, if someone starts a new plugin and loads a few textures, but does nothing else before saving / quitting, the plugin name and texture paths are saved for the next time. The next time the user loads the plugin, let's say he unloads or incorporates those textures before quitting. The entries are removed from the editor's plugin session profile either because they were not an active part of the session on close or had become a dependency in the plugin (and are thus identifiable by inspection of the plugin file itself).

As for housekeeping, any plugins that are deleted / removed should have their entires purged from the plugin session profile but not before the user gets the option of browsing to it's new location (unless all plugins must live in the same directory?). Likewise for any loaded assets that go missing the next time a plugin is opened for editing...

The only issue, of course, is that the recent files list is built off of this single profile. If we keep the last session's data for every plugin ever loaded, we have a potentially large list, indeed. I would suggest limiting the user-configurable option to display the last X files or Y days of sessions with an option to "view more", which coughs up the enitre history of sessions stretching into eternity past...


On an unrelated note, I'll take up the user settings issue, if you like. It may take me awhile to get a grip on it, but I'm game if you want someone focusing on that.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Opening documents

Post by Zini »

The only thing we're saving, if I understand correctly, is the plugin name and the paths to loaded assets that were not incorprated into the plugin (and thus made a dependency) in the last session, right?
Not exactly. List of master and plugin files. No paths.
(unless all plugins must live in the same directory?
All plugins must live in one of the data directories. Edited plugins must live in the local data directory (the name is a bit misleading since its actually a user location), because that is the only data directory where we are guaranteed to have write access.
On an unrelated note, I'll take up the user settings issue, if you like. It may take me awhile to get a grip on it, but I'm game if you want someone focusing on that.
Great! Please take a look at pvdk's launchernext branch, so you don't duplicate any work.
graffy
Posts: 142
Joined: 06 Feb 2013, 19:30

Re: Opening documents

Post by graffy »

Will start looking at pvdk's stuff asap.

On the editor profile issue, will the openMW plugin be the same in general function as an esp / esm? That is, will it be "self-contained" with references to the external content it needs to load and esX dependencies? That's what I'm assuming, so it makes sense to me to not create a companion profile in a separate file...

But for whatever information we need to capture about a plugin, would a single session profile work?
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Opening documents

Post by Zini »

On the editor profile issue, will the openMW plugin be the same in general function as an esp / esm? That is, will it be "self-contained" with references to the external content it needs to load and esX dependencies? That's what I'm assuming, so it makes sense to me to not create a companion profile in a separate file...
Please have a look at the first posting in this thread: viewtopic.php?f=6&t=1312

The names have changed since then (and we are also approaching the header issue differently), but the rest is still up to date.
But for whatever information we need to capture about a plugin, would a single session profile work?
I don't know. Your proposal contains a lot of wrong assumptions (paths, textures, file moving). I am not entirely clear on how that is actually supposed to work.
Post Reply