ESX selector and stuff

[graffy]

When someone saves a content files in the CS all legacy files depending on this one will have to be adjusted. That is how it is working now more or less, so there is actually not much change. That means however that we will have to deliver a porting tool with 1.0 (a GUI function that allows to move a content file to different dependencies). I had hoped we could do that post 1.0. Oh, well ...

Well, maybe it's an issue, maybe it isn't. After all, if you simply open an esp in OpenCS and save it, wouldn't it just automatically save it as an omwaddon in the appropriate format?

Assuming it does, I would suggest managing this at 1.0 in one of three ways:

Do Everything: Iterate the list of downstream esp's and automatically load / save them for the user (with appropriate notice, so they know what's going to happen), ensuring all upstream esp's have valid omwaddon ports.

Do Something: Implement #1 above, only supply a dialog allowing the user to cherry-pick downstream esp's to convert (with the warning that uncoverted downstream esp's will not be functional).

Do Nothing: Simply supply a warning and list of downstream esp's which require conversion and leave it to the user to convert them individually / manually.

Anyway, since i have internet access (but no way to do dev), I'm free to brainstorm if you have conundrums to work out. (can you tell I'm bored?).


Edit: I don't see why you have to retain extensions in the header dependency list. It should be no big deal to validate the extensions of files matching the general name, choose only the omwaddon (if it exists), or warn the user / auto-convert the esp (if it exists). Heck, you could ignore extensions and use Esm::Reader to quickly validate the file layout.

The only question is, what is the value-add for eliminating the extension from the header dependency name?

I'd say worry more about making dependency management as painless to the user as possible. Whether or not you retain the extension in the header is immaterial in my mind since I don't see that a little extra file validation code would incur much time or effort... unless there are complications I'm simply not aware of?

[Zini]

You already mentioned the complication: If you load and save x.esp you will end up with both x.esp and x.omwaddon in the data directory. Now assume you have y.esp, that depends on x.esp. How to choose between x.esp and x.omwaddon if the extension is not part of the dependency information? And that might important here, because x.omwaddon is a modified version of x.esp and y.esp may not work with x.omwaddon.

[Chris]

If you load and save x.esp you will end up with both x.esp and x.omwaddon in the data directory. Now assume you have y.esp, that depends on x.esp. How to choose between x.esp and x.omwaddon if the extension is not part of the dependency information? And that might important here, because x.omwaddon is a modified version of x.esp and y.esp may not work with x.omwaddon.

Similarly, x.omwaddon may intend to supersede x.esp, as an alternative "OpenMW-enhanced" version that's compatible with existing vanilla mods that use the vanilla version, but uses OpenMW-specific features where applicable. I expect this to be a fairly common case; especially early I expect people will make both vanilla and OpenMW versions of mods (or at least an OpenMW version of an old mod, leveraging a few new features) while OpenMW is maturing and gaining traction among players.

[Zini]

I agree on the use case, but that is not the optimal approach to handling this situation. If I want a vanilla mod and an enhanced version of that mod, I would create a vanilla mod and an additional mod that depends on the vanilla mod and adds in the features not available in vanilla MW. Easier to maintain than two full copies of the mod and it is also less likely to cause problems with other mods depending on this one.

Anyway, I think these are all clear arguments for keeping the extension as a part of dependency information.

[Zini]

The save feature is fully implemented now (saving branch), minus records that aren't loaded yet and minus cells and references (requires other issues to be sorted out, that I am not willing to tackle right now).

I won't merge the saving branch into master for now, because it is kinda broken. Still need a few things from graffy (mainly a fix for the load content file function) and because of this issue. I won't have a go at the later right now (having other plans, that already got delayed because I had to spend half the day on bug hunting). It would be great, if someone else could pick it up, since it is kinda urgent.

[graffy]

errr.. what fix for the load content file fucntion? Is that bug #588?

[Zini]

As far as I am aware you didn't even start on this feature, so bug may be the wrong description. I haven't looked at the code, but that is the last thing you told me about it. Also, the layout is messed up.

Edit: I checked now. At least in my saving branch its still the old code. Stuff isn't properly hooked up to the AdjusterWidget, which means the loaded documents are broken and can not be saved.

[graffy]

Bug.. Feature.. whatever... I seem to recall someone once describing bugs as "undocumented features..."

Anyway, no, I know I've not addressed this. So if a user loads a legacy file, makes changes and wishes to save, two conditions need to be identified: 1. The legacy format will not be retained - the changes will be save in the appropriate OpenMW format. 2. The saved file can *only* be saved to data-local, regardless from where it was loaded.

Apart from coding that, we'll obivously need to notify the user. I'm assuming a single popup detailing that one (or both) of these coditions has occured and what is going to be done as a result is sufficient? Do we want Ok only, or Ok/Cancel? (the action doesn't overwrite / endanger existing data... assuming we're not saving over a file in data-local, of course)...

[Zini]

These features already have been written. The AdjusterWidget is taking care of it. But currently the data generated by the adjuster widget is thrown away. It does not go into the new document.

[graffy]

Ok. I think I've got the file dialog for OpenCS almost there. I'm running into a bit of a difficulty for opening an addon, though. The order of the select files isn't related to their dependency order, of course. So that appears to cause problems because when I try to open a file that has an addon as a dependency, the dependency gets listed as the file that's beng edited. I'm trying to sort through the Document class and understand how load order is interpreted there and it's not clear.

So I guess I'm needing to know - do I need to make sure the string list of selected files is ordered according to their position in the dependency heirarchy?