Opening documents

[Zini]

Went over the description again, but without success. Sorry. I can not figure out how that is supposed to work. Maybe you should rewrite your proposal; without the stuff about paths, textures and housekeeping stuff.

[graffy]

I must have a completely wrong-headed view of how this works - I'm not really familiar with TES or modding workflows, so I figure I have to be completely clueless on something, or else I'd have made sense by now.

Anyway, when building a plugin in the editor, I'm assuming the following:

1. The user must indicate what omwbase/esm and/or omwext/esp files the new owmext will be built upon.
2. A load order / stack order needs to be specified
3. "Assets" (nif files, sounds, ...?) are going to be used and will need to be represented in the editor

Regarding point 3, I guess I was anticipating users needing "media libraries" of their custom assests at hand, as well as the deafult content. In all honesty, I was thinking of workflows I've seen in other environments - like UDK's media library tool, for example... I've never really had a chance to see how TES managed that (or if you've already got that figured out and I've yet to stumble on the thread). I think that's really the idea, though - does the editor allow for user-defined media libraries to visually represent custom content which may or may not be incorporated into a plugin? Suppose they're creating a door and are testing out different meshes and open/close sounds? If I were in the middle of that, I'd like to have all of my meshes / sounds at hand and restored the next time I load the plugin for editing...

On the other points, I can't quite visualize the stack order issue, though I understand the importance of it and I assume it would be necessary to define that during the development of the plugin. but if that's the case, it seems to me the profile defined at the editor level will be relevant to the launcher as well...

I'll stop there before I make this any more confusing.

[Zini]

1. The user must indicate what omwbase/esm and/or omwext/esp files the new owmext will be built upon.

Mostly correct. Just keep in mind that an esm is not always a omwbase file. And obviously there is also the case where the user creates a new omwbase file that depends on nothing.

2. A load order / stack order needs to be specified

Correct.

3. "Assets" (nif files, sounds, ...?) are going to be used and will need to be represented in the editor

Asserts have absolutely nothing to do with this.

On the other points, I can't quite visualize the stack order issue, though I understand the importance of it and I assume it would be necessary to define that during the development of the plugin. but if that's the case, it seems to me the profile defined at the editor level will be relevant to the launcher as well...

Editor profiles and launcher profiles are the same. We are not using two separate profile systems. Usually the sequence of ESX files you load into the editor will be the same you are loading into OpenMW (when testing or playing).

[graffy]

Editor profiles and launcher profiles are the same. We are not using two separate profile systems. Usually the sequence of ESX files you load into the editor will be the same you are loading into OpenMW (when testing or playing).

That was probably the one thing that had me most confused.

I don't see a better solution than a separate file for the profile for each plugin, then - especially as it's used by both the editor and launcher. The only thing I dislike is that it's two files instead of one. I see two ways around it - either the stack order is built into the plugin (either directly written or "compiled" into the plugin as a last step in the development process), or both files are stored in an archive...

[Zini]

We are clearly going in the wrong direction here. I try to explain it once again:

Each ESX file consists of a collection of records, that make up the game world.

When loading a list of ESX files into the editor or OpenMW, the records of each file are added to the record storage. Records with the same ID are overwritten and ESX file can also specify records as deleted.

And that is why the load order matters. Let's say we have 3 files A, B and C, loaded in this order. A defines record x. B changes record x. C is changing record x again. If B and C were loaded in the inverse order, this would result in a different game.

Each ESX file contains a couple of dependency information, that can be used to build a suggested load order. We should probably look into improving this system in the future (after 1.0), but for now it really is only a suggestion.

Independently of this suggestion the user should be able to manually define the load order, i.e. a list of ESX file names.

And if we add a name tag to such a list of ESX file names, we have a profile.

[graffy]

Each ESX file contains a couple of dependency information, that can be used to build a suggested load order. We should probably look into improving this system in the future (after 1.0), but for now it really is only a suggestion.

Independently of this suggestion the user should be able to manually define the load order, i.e. a list of ESX file names.

And if we add a name tag to such a list of ESX file names, we have a profile.

Right. That confirms my understanding of it. Pardon my remarkably bad job at explaining myself.

My only question is, where does that named list of ESX files reside? In a separate file? That appears to be the suggestion, anyway...

[Zini]

The profiles are currently stored in launcher.cfg. Since they will be shared between launcher and editor we may consider moving them to a separate file. profiles.cfg?

[pvdk]

The profiles are currently stored in launcher.cfg. Since they will be shared between launcher and editor we may consider moving them to a separate file. profiles.cfg?

That was my idea exactly.

About the dialog: am I going to implement it or graffy do you want the task?
I was thinking: we could make one FileDialog class and have to separate functions, something like:
- QStringList FileDialog::openFile(const QString &title, const QString &buttonText)
- QStringList FileDialog::newFile(const QString &title, const QString &buttonText)

And then set the button text and window title in these functions before showing the dialog. That way you can re-use the same GUI for both tasks.

[graffy]

The profiles are currently stored in launcher.cfg. Since they will be shared between launcher and editor we may consider moving them to a separate file. profiles.cfg?

That was the idea I had at first, as well... But there's one thing I don't understand yet:

If the stack orders for the plugins on one system are all stored in profiles.cfg, and the stack order is critical to loading the plugin in-game, then if I wanted to share my plugin with someone else, how does the stack order get passed along? That's what has me tihnking you have to have a separate file for each plugin's profile.

While I'm at it, will the plugin tab in the launcher go away as a result of this? (I had originally assumed it was there to let someone choose any number of random plugins to apply to the game, but that appears not to be the case).

---

Pvdk: So far as the open/new dialogs go, if you want it, go right ahead. If I get bored or run out of stuff to do, I'm sure there's some progress bars I can go paint or something.

In any case, I'm all for reusable file dialogs - that's a trick I've used before, too. I would point out, though, if Qt already provides 90% of the functionality, and you're only coding some slight variations in the layout, then it probably doesn't really matter which way you go with it. IMO, barring any obvious maintenance issues, I'd implement whichever requires the least amount of effort - unless Zini has a different view, of course.

[Zini]

If the stack orders for the plugins on one system are all stored in profiles.cfg, and the stack order is critical to loading the plugin in-game, then if I wanted to share my plugin with someone else, how does the stack order get passed along?

You don't. Because that other person may not want to use the same stack.

That's what has me tihnking you have to have a separate file for each plugin's profile.

There is no such thing as a "plugin's profile". Profiles are not specific to plugins. In the context of the editor recent file function we should label the profile related to the plugin being edited. But that does not make it the plugin's profile. Further more there can be more than one profile "for" a plugin.

I had originally assumed it was there to let someone choose any number of random plugins to apply to the game

That is a very good description.