ESX selector and stuff

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

ESX selector and stuff

Post by Zini » 21 May 2013, 09:08

We are now progressing at a decent speed with the editor and to get to the point, where we can showcase it in a video, we only have to add a few more features (see here).

The open dialogue/ESX selector is a relative big topic here. We need to move it to the new file scheme, we need to polish it and we still need to finish the discussion about how to handle the "recent file" feature in the start dialogue.

If we want to keep up the pace of development, we need to sort these issues out in 0.25.0. I will write more about that later this week. Consider this posting a call to arms for everyone involved in this part of OpenCS (and OpenMW). I think we can count graffy in, but I guess pvdk might want to become involved too.

User avatar
pvdk
Posts: 517
Joined: 12 Aug 2011, 16:34

Re: ESX selector and stuff

Post by pvdk » 21 May 2013, 10:11

Certainly, count me in. Maybe we can discuss the sorting too. Up until now I haven't had much time to spare but that's going to change.

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

Re: ESX selector and stuff

Post by Zini » 21 May 2013, 11:17

Actually, my current line of thinking is not to bother with sorting for now. We have enough complications ahead of us and sorting is a topic that we might be able to address better post-1.0. For now offering a default order based on the timestamp and the ability to manually change the order should be sufficient.

User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: ESX selector and stuff

Post by sirherrbatka » 21 May 2013, 18:00

Hi, zini.

What should we do about icons? At the moment we miss many of top level icons but we have all record types icons. Although there are some changes needed in my ld icons (remove emblems) It won't take to much time. Top level icons is a different story, but If nomadic1 would make few more and I would get back to inkscape we could possibly push something more or less complete.

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

Re: ESX selector and stuff

Post by Zini » 21 May 2013, 19:01

Not sure what exactly you mean with top level icons. Anyway, having the record type icons and the record state icons should be enough for now. We won't use anything else for the time being.

User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: ESX selector and stuff

Post by sirherrbatka » 21 May 2013, 19:51

top level recrod type

We do have all referenceable record type icons.

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

Re: ESX selector and stuff

Post by Zini » 21 May 2013, 20:00

I see. Actually, the top level records are the only onces we currently need icons for (referenceable records are also part of this category). If something is missing, we can just use a placeholder for now. It doesn't have to be perfect at this stage.

User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: ESX selector and stuff

Post by sirherrbatka » 21 May 2013, 20:26

Right. I see now. I think that We are in a good situation since majority of icons is done. I will remove emblems from my vector icons and consult with nomadic1 about the missing ones to split this task effectivly.

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

Re: ESX selector and stuff

Post by Zini » 23 May 2013, 11:13

First the relevant issues:

* Modify ESX selector to handle new content file scheme
* Editor: Adjust name/path of edited content files
* Editor: Start Dialogue


These are the points we need to discuss/work on:

1. Profiles

There has been a lot of confusion about profiles. Several times people had problems with understanding what they are. That makes me think that maybe I chose the name for this feature poorly. Should we consider renaming it? "Named content stack" maybe? Or just "content stack"? Not sure if these names are much better. Suggestions welcome.

2. Overwritten profiles

When loading the launcher the master/plugin settings in openmw.cfg are lost. That is not good. I think the launcher should pick a matching profile (if one exists) or automatically create a new one (assuming there are any master/plugin settings in openmw.cfg at all).

3. Recent file list

We still need to discuss how to handle the recent file list in the start dialogue. The discussion has kinda come to an halt. I'll sum up my original idea here (slightly refined): The recent file list can be based on the profile feature. Since the content stack loaded by the launcher and OpenCS are always a profile, all we have to do is append it to the list. The question here is how we deal with changed profiles. That would make loading a recent file sometimes resulting in loading something else than the first time. That may be the desired behavior though. Or maybe not, in which case we need to do something about it.

One way to do that would be to make a copy of the profile on load and list this copy instead of the original (unless there is already a matching copy listed).

4. The new file scheme

This is the biggest part. I'll describe it once more for the sake of completeness: We will two new file types from now on (reminds me that we still need icons for them; completely forgot about that). These are .omwgame and .omwaddon. Every valid content stack consists of exactly one .omwgame file and 0 or more .omwaddon files.
Old format files are mapped automatically to the new onces. .esp to .omwaddon and .esm to .omwgame (if it does not depend on anything) or .omwaddon (otherwise). We basically just pretend that esx files are omwaddon or omwgame files (which they are, except for the name).

This requires several modifications:

4a. OpenMW

We need to replace the --master and --plugin switch with --game and --addon switches. Except for a rename and that we change --master/--game from 1 or more files to exactly 1 file nothing changes here.

4b. The ESX selector

That is the biggest change. We need to implement the mapping. And we need to redo the UI. The master list needs to be changed to a single selection scheme. I suggest a simple combo box, that is moved above the plugin/addon list.

4c. Saving in the editor

We have a problem when we load legacy format files for editing. The editor can not write these formats. Therefore on save a name change occurs, e.g. SomeRandomPlugin.esp -> SomeRandomPlugin.omwaddon. We need to communicate that to the user (and make sure we don't overwrite anything accidentally).
The question here is, should we handle this on load or on save? On load would be cleaner, but you might not always want to save after loading (when loading just for viewing and not for editing) and in this case we would bother the user needlessly.

Please note that actually saving is not implemented yet (and won't be for a while). Currently the editor is just pretending that is saves something. But that is not relevant for the problem at hand.

5. Usability

After working extensively on the OpenCS I got a lot of usability testing out of the ESX selector. And I found a problem. The dual selection scheme (file selected via a highlighted row and file selected via checkbox) is confusing. That was already a problem in the old CS. I ran several times into a situation where I selected a row and then was confused because the file wouldn't be loaded (even though I know how it works). IMHO the dual selection scheme is exceptionally counter-intuitive and we should try to find an alternative.

fraang
Posts: 7
Joined: 26 Apr 2013, 13:48

Re: ESX selector and stuff

Post by fraang » 23 May 2013, 11:44

Zini wrote: 4c. Saving in the editor

We have a problem when we load legacy format files for editing. The editor can not write these formats. Therefore on save a name change occurs, e.g. SomeRandomPlugin.esp -> SomeRandomPlugin.omwaddon. We need to communicate that to the user (and make sure we don't overwrite anything accidentally).
The question here is, should we handle this on load or on save? On load would be cleaner, but you might not always want to save after loading (when loading just for viewing and not for editing) and in this case we would bother the user needlessly.

Please note that actually saving is not implemented yet (and won't be for a while). Currently the editor is just pretending that is saves something. But that is not relevant for the problem at hand.
In my oppinion there should be a message when loading the plugin because it would be frustrating to edit a plugin only to recognize that it is not possible to save it in a vanilla Morrowind compatible way. You basically lost all your work.

To not annoy the user there should be a simple checkbox "Don't show me that again.". This way the user can hide the message in the future and new users who closed it to fast/by accident can get it again.

Oppinions?

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests