No time like the present. IF you're making such changes as to require a full uninstall, you may as well go ahead and change the names now before you get stuck with them down the road and it annoys you to no end. Sort of like how I wish I'd had all my village mods attached to a master file, but didn't bother, and now wish I had but can't. It annoys me greatly. Don't let this happen to you

Added all the above.

Unrecognized mods:

THShadowArmor.esp (Clean Checksum: B5B16A1D)
Link: [http://tes.nexusmods.com/downloads/file.php?id=40629]
Mod adds an armor called Shadow Armor. Armor has a script which makes it act like Chinese Stealth Armor from Fallout series.

AO_Personalized_Outfit.esp (Clean Checksum: E7304A27)
Link: [http://tes.nexusmods.com/downloads/file.php?id=41364]
mod allows you to customize the look of your armour without affecting the looks of corresponding armour in the world. Adds a set of armour that can take on the attributes and enchantments of any piece of armour you find in the game while allowing you to choose the model of the armour independently.

-Dubious-

Not sure if those are the checksums of the original files, which are incidentally clean, or the checksums of files that you've cleaned.

Wrinklyninja,

You're more likely to see this here, so I'll post it here. It'd get lost on the Skyrim side anyway

With the Workshop now up, BOSS may need to seriously consider including redating support for BSA files in order to match them to the datestamps on their ESP files. I am presuming that load order on them will matter for Skyrim now, and since every Workshop mod consists of an ESP+BSA pair, they really should match.

I assume that the BSA loading system still uses plugin names, eg.

Plugin Name.esp
loads
Plugin Name - 1.bsa
Plugin Name - 2.bsa

If so, I see no problem with adding a function to redate any BSAs with the same timestamp as the plugin they match. It would be pretty trivial, in fact. Is there any reason why this may not be a good idea to do in games other than Skyrim, or would it be safe to do generally?

Yes, the BSA loading is still based on ESP names. It should still be the same system as usual where "Plugin Name.esp" will cause both of those variants to load.

It won't cause any harm to redate them in other games, but Skyrim appears to be the only one where it's being assumed it actually matters. We didn't have a lot of time during the beta to get to stuff like this. It never came up.

You'd want to coordinate with Lojack though so that Bash doesn't end up undoing all of this with the BSA redating it does.

OK, thanks for the heads-up.

Point. I'll work on making that clearer. As you said, they do not need cleaing.

-Dubious-

May also want to make sure how this works out with OBMM's redating of BSA timestamps.

Except that loose files need a newer timestamp to ensure they override a file in a BSA... like in Oblivion.

But yeah, definitely needs serious investigating to pin down the exact mechanism used, so we can work it out.

[ignore this post, posted in wrong forum]

Added.

Unrecognised Plugin:

http://tes.nexusmods.com/downloads/file.php?id=41359

It's clean.

Viva BOSS !

Added.

Double post, but:

I'm planning on removing the semi-automatic updater for those with manual installs. The updater will instead inform the user of an update, and provide links to download locations. This is instead of BOSS downloading the update files and installing them apart from the update for the executable you're running, which requires you to manually delete and rename the files.

My decision is based on people reporting that the updater wasn't working when they simply hadn't done this last manual step, despite being prompted to do so before exiting BOSS, and this update procedure taking up more bandwidth than downloading manually (because the files aren't compressed), and being quite messy workflow-wise, as it wasn't totally automated.

The update path for those with installer installs will remain the same, that'll be automatic, I'm just talking about the behaviour for those with manual installs.

What do people think?

Having a manual install (and a slight pet peeve about automatic updates), I agree with this.

New one (and looks good) a water mod with no requirements:

• Skyrimized Water HD BLUE eng.esp Version 1.6 http://tes.nexusmods.com/downloads/file.php?id=41599

There is also normal version (no BLUE in the esp name)

EDIT: not sure if it needs {C.Water} Tag or not though!

As one who has done both approaches, I think those who prefer manual installs will be perfectly happy with a simple notification that an update is available. That's what most other vendors offer and it's what those who want to retain control over the process are familiar with.

As always, appreciate your thoughtfulness.

-Dubious-

+1 to modifying the update procedure. Unseen automatic updates bug the crap out of me, and I imagine they bug the crap out of anyone wanting to keep control of their systems.

Even though I don't even use BOSS

This one is recognized, but not yet listed as "dirty".

http://tes.nexusmods.com/downloads/file.php?id=26346
CRC = 1433B9E8
TES4Edit reports:
ITM = 0
UDR = 14

Viva BOSS !

So I've almost finished getting BOSS to work location independently. Here's how I've set things up:

1. If the game is not set to autodetect, BOSS runs as if it is installed locally for that game (locally = BOSS folder next to Data folder).
2. If the game is set to autodetect:
2a. and it is installed locally for one of the games, it runs for that game.
2b. and it is not installed locally for one of the games, it looks for the games in the Registry, and:
2ba. if none are found, exits with error.
2bb. if one is found, runs for that game.
2bc. if more than one is found, asks the user to choose a game and then runs for the game chosen.

So there are basically two types of install with this system:

1. Installed locally to a game. BOSS will always operate as it does in the current release.
2. Installed to some location that is non-local to any of the supported games. BOSS will ask which game to run for before continuing.

As such, the installer will need to be updated to reflect these two install types. How should it operate? Should it continue to provide the options to install to each game and an "Other" path? What should the default non-local install location be?


-------------------------------------------------------------------------------------------------

Added.
Added.

My approach has been to install to the Program Files folder. BAT and BUM then detect as much as possible and then provide a menu to select which game to operate on. Always remembers whatever was selected last and runs that again when the program is restarted. Preferences and settings are stored in AppData\Local to avoid any writes to Program Files. Any other data files are stored in the relevant Game folders. Finally, also provide the option to allow the user to specify specific locations in case they can't be automatically detected

Key advantage is only having to have one version of the program installed regardless of how many games it is supporting.

I suppose for BOSS, it would make sense to have the Masterlist and Userlist still maintained within the Game directory structure.

Probably makes sense to choose one approach rather than add complexity of supporting separate installs for each game - so my vote would be for a single location for the program and help files and Game specific locations for the game dependent data (Masterlist and Userlist). Finally, use an accepted read/write location for maintaining settings and user preferences.

Hope this helps.

Well, I've already got a directory structure sorted too (showing all possible files: metalist.txt is still hypothetical):


with the uninstaller in the Common Files folder (can't remember where that is exactly, Program Files?). I'd rather not have files all over the place... That would also mess up the operation of local installs unless I made things more complicated.

Yeah, Common Files is in Program Files.