Prior to Vista and Win7, I would have recommended Suzaral's approach of putting it in "Program Files" by default. However, given MS' apparent opinion that only their "programs" need to modify anything in "Program Files" once installed, I would no longer recommend that. I have for more than 20 years advocated installing everything that will permit it to another "Apps" partition, for many reasons I won't bore you with here. Vista+ are just further instances validating that reasoning.

In this case, I would suggest your "default" location be to it's own directory next to and on the same level as "Oblivion". (I don't see any issues with still putting the uninstaller in "Common files".) Isn't that what most of us do with other "tools" for Oblivion that shouldn't be under the game folder? You might check for an existing folder at that level with "Tools" in the name and put it under that.

As for "how should it operate": explain a "local" versus "global" choice, with your interpretation of each path as you have discovered it as examples. Provide the installer a default location with a "browse folders" capability so they can navigate to their desired location. Perhaps a radio button for "local" versus "global" to set the default in the navigation window.

Please do not make the mistake of assuming everyone puts everything on drive C.

-Dubious-

OK, here are some examples of what I'm talking about.

A local install:
C:\Program Files\Oblivion\Oblivion.exe
C:\Program Files\Skyrim\TESV.exe
C:\Program Files\Oblivion\BOSS\BOSS.exe

BOSS will only ever see Oblivion.

A non-local install:
C:\Program Files\Oblivion\Oblivion.exe
C:\Program Files\Skyrim\TESV.exe
C:\BOSS.exe

BOSS will see both Oblivion and Skyrim, and you can choose which it runs for each time it runs. I will also be adding a setting that lets you choose a default game to run for when there are several options, bypassing the startup selection. There will also be a GUI menu for changing the game it is running for after startup, selecting from a list of autodetected games.

I think that if a user has

• Only one supported game installed: BOSS's installer installs BOSS locally for that game by default.
  
• More than one supported game installed: BOSS's installer installs BOSS non-locally by default.
  
• None of the supported games installed: BOSS's installer should provide a blank editable path for the user to select an install location.

All paths would be editable and have a folder selector dialog, as is normal. For comparison, the installer currently displays a path for each game detected, plus a blank "Other" path, to install to.

For the default non-local path, I was thinking that putting it on the same level as the "Oblivion" folder would be good (so default non-steam is "C:\Program Files\Bethesda Softworks\BOSS\BOSS.exe" and default Steam is "C:\Program Files\Steam\steamapps\common\BOSS\BOSS.exe". However, what if the user has non-Steam Oblivion and Steam other games? Which location should be chosen? Neither really makes any more sense than the other IMHO.

So, how about if BOSS were installed to the My Games folder? That avoids UAC, at least. The alternative would be to have a folder in Program Files, eg. "C:\Program Files\BOSS\BOSS.exe" and somehow work around the UAC issue (perhaps I can grant full control to the user via the installer?). I can't see how anything else would make sense.

Oh, and although I've used C:\Progam Files a lot, the actual default paths would be detected via registry, so if you're using a different drive then it would change to accommodate.

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

On a separate but related note, the installer has a "Choose Components" page. I'm inclined to get rid of this: it is useful for customising what is installed, but there is a manual install version and I reckon that most people who want customisation would use that, and people who use the installer are more interested in just getting it installed.

Am I wrong?

My concern here is multiple installs.
As soon as you take the BOSS folder out of the game level folders - i.e. non-local example above, multiple installs no longer have their own modlist.txt. You'll not only need a new way to store that where it can be copied and changed per install, but need a way to launch BOSS per install not just per game.

If this doesn't make sense I may not be thinking it through all the way. I'll have to think about it more.
But please, whatever you do, don't make anything default to Program Files.

Not exactly: non-local installs find game paths using the Registry, and there's only ever one path for each game in there: the path to which you installed the game originally. So BOSS running non-locally won't find any other copies of that game you have. Therefore the issue just collapses down to the current system: you'd just keep your multiple copies of BOSS in the game level folders of your multiple game installs.

Eg. You install Oblivion to C:\Oblivion.
You then copy that install to D:\Oblivion.
The Registry will have a key containing the path to your original install, C:\Oblivion, but won't know about D:\Oblivion.
If you then install BOSS to E:\BOSS, BOSS will only ever find C:\Oblivion.
If you then want to run BOSS for D:\Oblivion, you'd need to install it to (or copy the existing folder to) D:\Oblivion\BOSS. That copy of BOSS will then only ever find D:\Oblivion, as it won't search for non-local games if a local game is found.

I think you have a pretty good handle on the sorts of situations you are likely to encounter. The only one I see missing is someone who is using MOM or mTESManager. (Edit: I see you addressed this with Hanaisse.) But perhaps you are overthinking this a bit. All anyone really expects is for you to provide a "suggested" location as the default, and the means to choose somewhere else if they so desire. Any reasonable default will do. Because you are offering "local" versus "non-local" install points, two suggestions are reasonable, especially as they will serve as examples of the differences. Anyone with more than one game folder or contemplating a structure beyond a simple "local" install should feel comfortable proceeding from that.


As Oblivion is the "senior" game BOSS is intended to work with, I would put it according to the Oblivion install path, whether Steam or not. Unless for some reason it couldn't work properly with the Steam installs if it wasn't under the "steamapps\common" path. (I have zero experience with Steam versions.)


The "My Games" folder is "private" to each user by default, so you would then require a separate install for each person playing on that box. Not much different than multiple local installs. Better to let the user decide. I would recommend suggesting something like "C:\BOSS" if nothing better presents itself when you examine the registry.


No; I agree. "Choose Components" is an unnecessary complication. Those who need such customization should know how to deal with the manual install method. Those who don't will feel completely lost with unnecessary "which do I need" questions.

-Dubious-

Yes, and that's what I'm saying.
MOM will copy BOSS and everything it needs when you make new images today from an install that already has BOSS installed.
Tomorrow, you're saying that won't work and the user will have to re-install BOSS per image. It's effectively breaking a selling point in MOM but if this is what you need to do for BOSS, it's your choice.

I'm unfamiliar with MOM and similar, but if you have BOSS installed locally for Oblivion and then you make a copy of that install using MOM, and MOM copies the BOSS folder too, then there shouldn't be any problem. If you're having trouble understanding what I mean, I can send you an executable (or rather, two) with the functionality enabled for you to try out.

Thanks for the feedback from the both of you.

Right, I get that. Locally isn't the problem, it's your non-local example above we're you've put BOSS in C:\BOSS above the game installs.
Don't worry about it.

What Microsoft are trying to encourage is that the programs (which all instances use) and the data (separate for each user/instance) go in different folders with different update permissions.

Configuration data is data, and you should be able to have multiple copies for multiple games or multiple users.

The tricky part is the meta-data (in BOSS's case the masterlists) which are logically part of the executable, in that they need to be shared, but they're updatable, so they belong somewhere else where they're not a pain to update. I suspect you'll want to maintain those in an "all users" data folder.

So that's three separate folders, not one, for the simplest case, with the per game/user one replicated as many times as needed, and probably kept under "My Games"

If you "locally" install the executable, you have multiple copies, and have to update multiple times. Registry entries reflect the last install, unless you get tricky there too. Which brings up the point of making proper use of HKLM and HKCU properly to separate the machine-wide entries, from the current user settings. In general HKLM reflects "Program Files" stuff (and probably the masterlists), and HKCU reflects "My Games".

I'm not a programming expert, but I understand the principle of data separation and updates in regards to my day job.

It seems to me there should be a structure as follows:

One folder, outside the game system, user selectable with "c:\BOSS" as default, for BOSS containing the master executable as well as any data that would be commonly shared amongst all programs. This is where any updates and upgrades are dealt with.

For each game install, a "BOSS" data folder. This folder has a mini-exe that points back to the master outside the system that would include command lines pointing to data that is specific to that game install, such as custom exceptions.

If you run the master directly, a list of possible BOSS installs for the various games you have appears, and you select which one you want to run, or you can choose to install BOSS on another game install.

If you run the mini-exe directly, it calls the master and does its thing without the pop-up (since it is clear that's the one you want to run). The only time there might be a pop/up is if there is an update to the program, or you have auto-update turned off. Also, if by chance this is a copied game ( using MOM or something similar ), and this particular BOSS install is missing from the list, by calling the master.exe it will add itself to the list.

If copies get deleted, the BOSS master would would naturally cull the list if the files are missing.

You'd only have to update the main master.exe, and if an update was required for the minis, all of those paths would be known.

Dunno how difficult this is programming wise, but it is certainly a more efficient method, and would reduce "BOSS bloat" and make updates much easier on the user.

Programs like wrye bash or multiple game handlers could adapt to the new structure fairly simply by knowing where to point.

Also, if a user wants to uninstall BOSS, or just the BOSS data from one game, they won't have to hunt down every copy, they could do it from one place.

I kinda think this is the direction that folks are suggesting with the line of questioning.

That is horribly complicated. Multiple executables, files all over the place. Not to mention I'd have to maintain even more code for such a system. It may be logical in terms of data separation, but it's a nightmare of an implementation IMHO, compared to just having one folder somewhere that does everything for all primary game installs (ie. paths stored in Registry), without causing "conflicts" between each game's files. You'd then have another copy of BOSS in each copy you made for each game, which would all operate independently of each other and the one that works for the primary installs.

The trouble with what's been suggested regarding data separation so far (IMHO) is that while they make sense, BOSS is not a complex program. It is an automated file redater, with shiny bits. Adding support for per-game (let alone per-user!) data separation (outside of simple sub-folders within the BOSS folder) would be a significant complication of its operation. I just don't see it being worth the effort, so I'll probably just stick with what I've got: the UAC issue should be a non-issue because users should be circumventing it if they're using mods anyway, and the BOSS readme gives instructions for doing so.

I'm not suggesting per user. Your current setup requires multiple updates, one for every separate game instance in which BOSS is installed locally.

I guess my description/logic was very clear. Sorry about that.

One master (ring) to rule them all, in it's own folder. As you have it now, there are already multiple exes, one or each game. But instead of them acting independently and having to be updated independently, they are all tied to a master exe that tracks what's happening and makes sure if one is updated, they all are. Although most likely it's not the smaller exes (or even batch files) that will need to be updated, since they just link the master executable to the game specific data installed in the local game folder.

Anyway, I'm too limited in my knowledge to judge complexity. My skill set is limited to custom databses using the FileMaker engine.

But what I'm doing is having it so that only one executable is needed for all games, unless you make copies of your installs. If you do, then you've already signalled that you're willing to mess with the norm and go a bit further for whatever the reason is that you made the copies. In that case, I don't think it is unreasonable for me to assume that you'd be willing to maintain multiple copies of BOSS (since you're willing to maintain multiple copies of the same game).

Please remember that the percentage of BOSS users that would require more than one copy of BOSS to be installed is tiny. Looking at the download stats for MOM, it's 0.25%, assuming all users of MOM use BOSS and that TES Alliance counts unique downloads. It's just not worth the effort on my part in this case.

I'm with Wrinkly on this one. BOSS appears quite simple and straightforward, something not to be dismissed lightly. Besides, just what exactly needs to be unique to each game? As far as I can see (not digging into the code), only the log output. BOSS needs to know the path to the Data folder in question, but that is apparently all. Why not just create a shortcut in each game folder with the Data folder path as a calling parameter? No need for "local install" at all; just local shortcuts.

Of course, things are rarely as simple as they seem.

-Dubious-

You're almost right: the only differences coded in between games are:

• What the master files for each game are.
  
• What the games corresponding to the master files are (as text strings - internally BOSS just uses integers to denote different games).
  
• What subfolder BOSS should store its game-dependent files in (masterlist, BOSS Log, userlist, modlist), depending on the game it's running for.
  
• Where the Registry entries for each game are.
  
• How to translate legacy masterlist conditionals (the same symbols meant different things for different games, for backwards compatibility with 1.6 and below).

These are all very simple switches, each only a few simple lines per game. All the actual "doing stuff code" is identical, it's just the definitions above that differ.

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

Here's the revised install instructions from the readme:
That isn't too confusing, is it?

Makes total sense. It's slightly different from what I was thinking, but not that far off. And if the MOM percentage is that low, it's definitely not worth the effort (unless someone's gonna pay you to do it for them.)

Hmm. That last sentence might be read as: if you have multiple copies of a game installed, local installs are required. That would only be true if those copies are run from the "current copy path" rather than the "game install path". If, as with MOM, all copies get renamed to the original "Oblivion" install path when "active", only a "non-local" install is needed because the registry has the correct path for the "active" copy. And it avoids the need to update multiple instances of BOSS. Hopefully someone with another multiple copy setup that differs in that regard will speak up.

Otherwise, clear enough.

-Dubious-

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

http://tes.nexusmods.com/downloads/file.php?id=5441
CRC = 62E7808B
TES4Edit reports:
ITM = 54
UDR = 2

Viva BOSS !

Just noticed you're advising turning Lock Times off if Wrye Bash is installed - better to leave Lock Times on, and enable 'BOSS Disable Lock Times'

Hey, just download latest version of BOSS, and when i try to download the Masterlist it just sits there for a few minutes and freezes and says Cannot find online masterlist revision number! Ive tried mulitple times

I've got the same problem - I tried reinstalling BOSS and the same thing happens. Looking at the TESNexus site comments, it appears we aren't the only ones.
The readme says to contact the developers in case of this happening - anyone know how to do that?

Developers = me in this case. Looks like there's an issue with Google Code, though I can't find anything on it. Half the time the updater works, sometimes it's slow, and sometimes it causes BOSS to hang. Nothing we can do about it.

It's working now. Thanks for the quick answer though - I'm glad to know it wasn't me putting a file in a wonky place or something.

Ah yeah me to, thought it might had been an issue with me but glad that i wasn't

Added.
I had totally overlooked that, thanks.

Also, apparently Gabba was a member of the BOSS team and I had never realised (though he's been inactive for a long time). I was going through the committer list matching emails to handles here and found a few committers that had never done anything (removed them), and that Gabba was missing from the members list. The readme's team member table now shows which members have not been active for at least three months, so the actual 'working' team size is 8 as opposed to 19.