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.
ESX selector and stuff
Re: ESX selector and stuff
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.
Re: ESX selector and stuff
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.
-
sirherrbatka
- Posts: 2159
- Joined: 07 Aug 2011, 17:21
Re: ESX selector and stuff
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.
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.
Re: ESX selector and stuff
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.
-
sirherrbatka
- Posts: 2159
- Joined: 07 Aug 2011, 17:21
Re: ESX selector and stuff
top level recrod type
We do have all referenceable record type icons.
We do have all referenceable record type icons.
Re: ESX selector and stuff
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.
-
sirherrbatka
- Posts: 2159
- Joined: 07 Aug 2011, 17:21
Re: ESX selector and stuff
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.
Re: ESX selector and stuff
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.
* 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.
Re: ESX selector and stuff
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.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.
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?