ESX selector and stuff

Involved development of the OpenMW construction set.
graffy
Posts: 142
Joined: 06 Feb 2013, 19:30

Re: ESX selector and stuff

Post by graffy »

Good! Glad to see it's getting there ;)

Now that you mention it, I do remember seeing the fully qualified file path in the new dialog. Whoops. That's fixable.

Speaking of minimalism... Don't suppose you might want to ditch the label to the right of the filewidget lineedit in the new file dialog, given that the adjuster widget immediately below explicitly states the full filepath?

Also, I will be unavailable to work on anything OpenMW pretty much through Thursday (doing training at a statewide terrorism task force conference)... Just an FYI.

edit: I should also point out that my implementation of your widgets into the dialog is, frankly, horrible. I have an idea of making it better, but there are other refoctoring issues that need to get dealt with, first. One major complicating factor, however, was the fact that I had to mix UI that was built in designer with programmatically generated components. It worked well enough, but Qt's workflows don't really seem to accommodate mixing the two very well. :?
Last edited by graffy on 23 Sep 2013, 12:09, edited 1 time in total.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: ESX selector and stuff

Post by Zini »

Speaking of minimalism... Don't suppose you might want to ditch the label to the right of the filewidget lineedit in the new file dialog, given that the adjuster widget immediately below explicitly states the full filepath?
That sounds reasonable.
graffy
Posts: 142
Joined: 06 Feb 2013, 19:30

Re: ESX selector and stuff

Post by graffy »

Zini wrote:Nope. Also your fault ;) The way the signal from the file dialogue is used to create the document is incorrect. Will fix.
I presume my omission was the call to setLocalData() from the editor?
graffy
Posts: 142
Joined: 06 Feb 2013, 19:30

Re: ESX selector and stuff

Post by graffy »

Zini wrote: ...However to get a .omwaddon file, all you have to to is to make a copy of an esp and change the extensions. Likewise you could get an .omwgame file by making a copy of Morrowind.esm and change the extension.
Just tested *.omwgame and *.omwaddon, and they seem to work fine. The only problem is my *.omwaddon file didn't show up when the *.omwgame file was selected. Since all I was the copy you suggested above, I'm going to guess that the *.omwaddon is explicitly referencing Morrowind.esm (instead of simply "Morrowind"), hence "Morrowind.omwgame" isn't going to work.

In any case, that's the problem that I see. I tried to hexedit the file and change the master from Morrowind.esm to Morrowind.omwgame, but, of course, the Esm file reader didn't care for that trick. :)
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: ESX selector and stuff

Post by Zini »

If the .owmaddon was created with an .omwgame as dependency, the selector should list the .omwaddon when the .omwgame is selected. Otherwise we have a bug.
graffy
Posts: 142
Joined: 06 Feb 2013, 19:30

Re: ESX selector and stuff

Post by graffy »

Agreed. I'm just saying I can't copy a *.esp to *.omwaddon and it's corresponding *.esm to *.omwgame and expect it to work, because the dependency is still listed as a *.esm in the addon's header. Since the file reader is looking for fields based on byte position, it throws an error because the "omwgame" extension overruns the next field.

However, what I *do* see is the model behaving exactly as I would expect - the copied *.omwgame shows up in the combo box, but the copied *omwaddon appears when I select the *esm for the reasons stated above. I would fully expect a properly-created *.omwaddon file to appear if the *.omwgame is selected, however.

Hence my quetsion to you (since I don't have time to create a proper *.omwaddon file), is what's the error you're seeing? Does the omwaddon not appear when the omwgame is selected?

BTW, I just pushed changes to my esxSelector branch which fixes the filter issue for the addon files. All files dependent upon the selected *.esm are listed. I don't claim it's perfect, but it's closer to what we want, I think.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: ESX selector and stuff

Post by Zini »

Agreed. I'm just saying I can't copy a *.esp to *.omwaddon and it's corresponding *.esm to *.omwgame and expect it to work, because the dependency is still listed as a *.esm in the addon's header. Since the file reader is looking for fields based on byte position, it throws an error because the "omwgame" extension overruns the next field.

However, what I *do* see is the model behaving exactly as I would expect - the copied *.omwgame shows up in the combo box, but the copied *omwaddon appears when I select the *esm for the reasons stated above
Yeah, that sounds right.
I would fully expect a properly-created *.omwaddon file to appear if the *.omwgame is selected, however.
That is an interesting point. My first instinct was to answer with a no, because I consider the extension as a part of the file name. However that would cause problem when editing a content file that is a dependency for another content file. I am honestly not sure how to best handle this situation. Dropping to notion of the extension being part of the filename might be our best bet.
Hence my quetsion to you (since I don't have time to create a proper *.omwaddon file), is what's the error you're seeing? Does the omwaddon not appear when the omwgame is selected?
I do not understand what this question is referring to.
graffy
Posts: 142
Joined: 06 Feb 2013, 19:30

Re: ESX selector and stuff

Post by graffy »

Zini wrote: Edit: Also, unless I am missing something here, the selector is still not showing .omwgame and .omwaddon files.
This is what I've been referring to the entire time. You indicated that the selector was not showing the omwgame / omwaddon files. When I tested the extensions, they did show, but according to the conditions I've previously stated...

I can't seem to replicate the problem you've cited. However, I haven't made any "real" omwaddon files (using the "save" feature), so I can't really prove the model filter code works. I was thinking perhaps you had and it still wasn't working?
Zini wrote:That is an interesting point. My first instinct was to answer with a no, because I consider the extension as a part of the file name. However that would cause problem when editing a content file that is a dependency for another content file. I am honestly not sure how to best handle this situation. Dropping to notion of the extension being part of the filename might be our best bet.
Although this is a slightly different train of thought... it does raise an interesting question. Humor my penchant for grossly overthinking an issue for a moment... :)

You've forced this issue by expressly prohibiting saving to legacy formats via Feature #588. Any esp modded in OpenCS would require saving it as a new omwaddon file, leaving the existing esp still in place, assuming it would be preferrable to retain it (unless the user wants it deleted and replaced with the omwaddon).

If you choose to retain extensions for dependencies in omwaddon headers, this creates a maintenance hassle if an "upstream" dependency is converted from the legacy format. (Upstream is closer to the gamefile, here). Managing that would require something like these options:

1. Provide an option "batch convert" every file which depends on the old esp so that it will use the new omwaddon instead. Maybe a popup dialog listing all files that reference the dependency and allow the user to cherry pick what "dowmstream" esp's they want converted to omwaddons... Not hard to do, since we already know (or can very esaily determine) which files those are.

2. Simply save the new omwaddon, leave the old esp, and not worry about any dowmstream files which depend on the old file. The user is responsible to know that any downstream esp cannot depend upon an omwaddon, and any downstream omwaddon that already depends on the esp must be told to use the converted omwaddon dependency instead. Perhaps passively manage this issue by alerting the user to any dependency issues like that.

If you eliminate dependency extensions in the omwaddon header, the omwaddon will load any upstream esp or omwaddon that matches the name. However, suppose both formats exist with the same name? I see one of two options, here:

1. Choose the omwaddon over the esp (unless the user overrides and opts for the esp). Issue a warning that this is what is happening.

2. Choose both dependencies, but place the omwaddon downstream - this follows sorting by date logic - an omwaddon is always gong to be "newer" than an esp of the same name. Still provide a warning that two formats of the same dependency are being loaded.

There are other options I see, but I imagine this is probably loaded with enough misconceptions that I should probably quit while I'm ahead. :lol:
graffy
Posts: 142
Joined: 06 Feb 2013, 19:30

Re: ESX selector and stuff

Post by graffy »

And FYI - I have pushed changes that have partly implemented auto-checking / unchecking of dependencies. I don't think it's quite right, but it's close. I can't look at it again until Friday at the earliest. Need a pull request before I go?
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: ESX selector and stuff

Post by Zini »

This is what I've been referring to the entire time. You indicated that the selector was not showing the omwgame / omwaddon files. When I tested the extensions, they did show, but according to the conditions I've previously stated...
Well, that was a while back. It definitely works now.
If you eliminate dependency extensions in the omwaddon header, the omwaddon will load any upstream esp or omwaddon that matches the name. However, suppose both formats exist with the same name
That is another good point. Okay then, my first instinct was correct. Extensions are part of the name.


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 ...

And FYI - I have pushed changes that have partly implemented auto-checking / unchecking of dependencies. I don't think it's quite right, but it's close. I can't look at it again until Friday at the earliest. Need a pull request before I go?
Nah. What I have now is good to continue working (even though with some extra steps during testing). i'll wait for you to finish this stuff, before I merge.
Post Reply