Revert change which undid separate registry settings per version about nifskope HOT 5 CLOSED

Separating settings into a per-version registry sounds great. One thumb up for this!

Next to your 'Restore Defaults' I suggest a 'settings copy' from actual version to new version when creating registry entries for the new version. By this the user doesn't have to setup again and again with every new version. @jonwd7 And I think there's much to come since you're in charge now ;-)

from nifskope.

@skyfox69 Yeah, you can see the old migration code in 2862caa ... I think that maybe instead of keeping some settings (texture paths) version independent, that they could still all get migrated, but if you don't want some portion coming over to the new version, you can restore defaults to just that tab/category.

So maybe instead of just one Restore (All) Defaults, it's split out into one Restore per settings section. Only issue is that some of the registry keys have no explicit representation in the UI, e.g. Render View defaults. So in the Render settings tab it may have to be clarified that Restore Defaults also clears camera defaults. Or actually include options for the default camera mode / position (but that's for another issue # 😄)

Then of course in addition to Restore Defaults per tab, have a Restore All for the lazy. 😉

Another Idea: Have settings per game/install? I'm not well versed with Windows installers, but I would assume it's feasible. I'm not sure what happens currently, when you try to install NifSkope more than once in different locations.

The installer could act similarly to 3ds Max plug-in installers, where you check each version you want to install for...

from nifskope.

NifSkope already has some auto-detection of game installs so you could look into that. I don't know what installer is used by NifSkope but I suspect that it is NSIS which is horrible to code.

But I suppose it is also a case of how easy it is to add new games and maintain that system as users tend to install in non-default locations

from nifskope.

Noting here that we've discussed having one single dev-specific registry entry created when using dev builds, regardless of version.

That way dev builds can be messed with without ruining your settings for the official release.

from nifskope.

Also, there's a typo for a registry entry. When list mode = "hirarchy". Inconsequential, but I wanted to note it here.

I was thinking that the registry entry should include the install path for the EXE. I noticed that the application awkwardly searches for some things like the XML files, the shaders/lang folders, etc. It should first look in the current application directory, then look for the install path in the registry.

This would also help when the EXE is outside of its normal location like when we do dev builds, though we could still integrate post-build processes into the NifSkope.pro file to copy those files over.

from nifskope.