Here's a little problem I just encountered. I notice this with the mods that add "useful extra" files, like TNM and 2027. What's going on with these "useful extra" files (like the OTP UI fix, renderers and so on) is that if something else is using the file (in other words, the file was already there on install), the uninstallers will take the file out.

This will happen with the renderer files (if I put them on manually & install them manually, or use something like my loader) in 2027, but the most ready example is the UI scaling fix. TNM and 2027 both will install these files. Both uninstallers will remove these files, too. Which means, if I uninstall 2027 and run TNM, I'm likely to get an error. The reverse would likely happen too as it applies to the UI scaling files. I can address it by replacing the files, of course. But really the issue is that these installers / uninstallers are not keeping track of whether files were already present or needed so the correct decision of whether to terminate the file is made.

To state what I observed with the renderer files, 2027 overwrote my existing DX9 renderer with ENBSeries upon install. And then the uninstaller removed ENBSeries, completely leaving my install without the DX9 renderer.

Anyway, I wanted to start this thread to toss around some ideas on how to handle these file collision issues in a nice way, without having to replace the files if the uninstall choice is made. Like with the loader I wrote, I thought about putting those files together into a little installer so they can be added if necessary (since the loader already effectively "installs" them into the settings files). That might be a solution (authors willing), but the obvious thing with these installers is that they need to preserve the files if already present.

Thoughts on how to address/handle it?

Don't we put all our stuff in the separate TNM folder? If so, surely it shouldn't be a problem - no other uninstallers have any business messing with that folder.

TNM and 2027 both throw things into DeusEx\System, which is where the problems are starting. I got the chance to troubleshoot things now by playing with TNM and 2027 in a virgin DX install. I checked the patch versions as well as the originals to be sure one of the patches wasn't throwing files there, too.

Let's start by installing both TNM and 2027. Now we uninstall TNM. I get the following when attempting to run 2027.

This window pops up.


Then this one pops up.


As a result, 2027 fails to run. 2027 installs the OTP UI scaling fix, which includes detoured.dll. The TNM installer log confirms that it throws detoured.dll into DeusEx\System, and a check of the directory confirms detoured.dll is missing. Replacing this file then allows 2027 to run normally.

Edit: I'm not so sure now that I think about it that 2027 will run normally, since I didn't play it for any length of time after I performed this part of the experiment (I just got to the menu). I notice TNM seems to make a backup of the original OpenGL dll. I would guess the uninstaller deletes its OpenGL renderer and replaces it with the backup. But given 2027's graphics, I'm not sure it would work well.

Now I repeat the experiment the other way. I uninstall 2027, then reinstall both TNM and 2027. I then uninstall 2027 and run TNM.

I get this screen.


Followed by this screen.


I was mistaken in thinking TNM had the OTP scaling fix within it. But TNM seems to use detoured.dll for another purpose. Replacing this file will enable TNM to run, but we have another problem. TNM will then proceed to run using software rendering.



This is because TNM installs it's "Enhanced OpenGL renderer". But 2027 installs one as well, along with ENBSeries and DirectX 10 renderers. On 2027's uninstall, it wipes the OpenGL renderer, causing this issue. Replacing the OpenGLDrv.dll file from Chris Dohnal's OpenGL package will fix this issue, since I really am not sure that the original OpenGL driver is something that TNM can use well.

Hopefully that explains what I'm trying to point out more. Anyone moderately technically competent can fix these things, but in some ways it would be nice to come up with something better. The obvious best solution would be for the installers/uninstallers to be more intelligent about handling what they throw to DeusEx\System. But this might not be the best solution, especially if stock installers are written this way and there are more things coming down the pipeline that will try to install the same files.