Have a mod suddenly stop working on Windows? Try this.

[Galane]

If you're using 64 bit Windows, right click ksp.exe then click properties. Click the Compatibility tab then check the Run as Administrator box. You'll need to know the Administrator account password for your PC.

That is like setting a permanent superuser command. I had to do that to get MechJeb and Blizzy78's toolbar working after the latest updates to Windows 7 x64.

I don't know if this is a problem on 32bit Windows. The only x32 version of Windows I've run KSP on was XP. Won't hurt to try checking that box.

[NathanKell]

This has nothing to do with 32 or 64-bit Windows, and everything to do with running KSP from a protected folder (like within Program Files). If you have the Steam version, and have Steam installed in its default location (Program Files), it will apply to you.

Note that it only applies to Vista/7/8+ with UAC; XP is safe.

An alternative is simply moving the KSP folder out of the protected folder, like moving ksp to a Games folder on your hard drive.

[Galane]

I don't have KSP in a protected folder. I made a new folder on D: just for it, and suddenly today MechJeb went missing and if I tried launching stock ships there was no crew and no staging icons and the blizzy toolbar was also not working.

Setting ksp.exe to run as Administrator fixed it all. There were some updates pushed out for Win 7 last night so I'm betting the fault lies with one of them.

[Kruleworld]

An alternative is simply moving the KSP folder out of the protected folder, like moving ksp to a Games folder on your hard drive.

i've set my Steam to D:\steam rather than on my primary hard drive. My steam is 155GB.

[godefroi]

It's unquestionably a bug in KSP that it modifies files in its folder. It should store and retrieve addons, saves, screenshots, logs, and everything else in the C:\Users\[your username]\AppData folder. This has been correct development practice on Windows for something like a decade and a half, and there's really no excuse for KSP not to do it.

If it didn't do this, running as administrator would not be necessary.

If you run KSP as administrator, be aware that a malicious mod could (for example) install a keylogger which would send your banking website login info to a criminal.

I would STRONGLY recommend NOT running KSP as administrator. Move it somewhere outside of Program Files, and don't run it as administrator.

[Guest]

It's unquestionably a bug in KSP that it modifies files in its folder.

I don't see it as a bug, but as a rather nice feature. It makes it easier to find my game saves without having to dig through a rats nest of hidden files. Keeping everything under the KSP_win folder works just as good. This kind of falls under the "if so and so jumps off of a bridge" category.

[NathanKell]

It's unquestionably a bug in KSP that it modifies files in its folder. It should store and retrieve addons, saves, screenshots, logs, and everything else in the C:\Users\[your username]\AppData folder. This has been correct development practice on Windows for something like a decade and a half, and there's really no excuse for KSP not to do it.

If it didn't do this, running as administrator would not be necessary.

If you run KSP as administrator, be aware that a malicious mod could (for example) install a keylogger which would send your banking website login info to a criminal.

I would STRONGLY recommend NOT running KSP as administrator. Move it somewhere outside of Program Files, and don't run it as administrator.

Uh no. The issue is that KSP needs higher permissions to *load arbitrary DLLs*, i.e. plugins. And it certainly has to be able to do that to run plugins, of course.

If you're not running mods, you don't need to move KSP outside Program Files.

[godefroi]

Uh no. The issue is that KSP needs higher permissions to *load arbitrary DLLs*, i.e. plugins. And it certainly has to be able to do that to run plugins, of course.

If you're not running mods, you don't need to move KSP outside Program Files.

No, you don't need higher than normal permissions to load arbitrary DLLs. This is my day job, and I'm INTIMATELY familiar with what you can and cannot do without administrator rights. What you can do is load .dll files. What you cannot do is write to files in Program Files.

If it ever works without administrator permissions in the Program Files directory (I haven't personally tried it, as I run it outside of that folder), then it's because the files it's writing are ending up in the "virtual store", which is a workaround Microsoft created for broken applications that write to files in Program Files. Google for UAC Virtualization if you want more information on how that works.

See the certification requirements (section 10, but lots of sections are relevant here): http://msdn.microsoft.com/en-us/library/windows/desktop/hh749939.aspx

Edit: also see the Namespace Usage Guidelines for the Windows Vista File System

Edited May 6, 2014 by godefroi

[Faark]

One possible situation where higher permissions might actually have an effect could be Microsoft's lovely security feature for foreign files:

But the better solution would be to find out what dll files don't load and unblock them manually in such a case...

[Galane]

I would STRONGLY recommend NOT running KSP as administrator. Move it somewhere outside of Program Files, and don't run it as administrator.

I already said I have it in its own folder directly under the drive root, so that is not at all the issue!

Some fairly recent Windows update is apparently blocking KSP from loading some mods like MechJeb, Blizzy78's toolbar and even part of its own files that it needs to function. The crew icons wouldn't show up, couldn't get any crew info right clicking the hatch, and with the Kerbal X there was no stack of staging icons so the ship couldn't be launched.

Setting it to run as an administrator not logged in as Administrator fixed ALL of those problems.

What may be a part of it is if you have *copied* instead of *moved* some mods, craft files etc from an old KSP setup used on Windows XP to a freshly created KSP folder structure under Windows Vista or 7.

These newer versions of Windows have a stupid thing going on about allowed permissions on some files and folders created with XP. You're not allowed to save files into the folders. You are allowed to open old files in those folders but cannot save changes to them - but a *copy* of the file with a different name can be saved to the same folder or use the same name in a different location. Then the new file can be copied over the old file, and with a click of the button to override with Administrator-fu, you now have full access rights to *that* file.

How to tell if you have one of these problem folders. Right click then go to New. If the only option is New Folder, you have the problem. Create a New Folder then open it and right click - and you have the full list of New things you can create.

I have tried Microsoft's official method of taking ownership, I've tried Registry mods that add Take Ownership to the right click menu but none of them have corrected this problem with Windows 7 x64 and old files and folders that where never ever in a protected location with XP.

It's like a bank where the teller refuses to allow you to deposit money in your accounts, and the vault door has a sign saying "Absolutely No Admittance" - with a button under it and another sign that says "Press Button to Open Vault".

It is a broken thing in Windows for which the only full fix is apparently to *move* all files and folders affected to a different location, then if you need them where they were, move them back.

But back to KSP. I made a new folder to put all the KSP stuff into, and extracted a fresh copy of the latest KSP 0.23.5. I then copied mods from my 0.23 setup which were already at their latest version. For all mods that had been updated since I last played, I did new downloads and installed them.

100% of that all worked until a few days ago! Then KSP suddenly had the problems listed above and the only thing that fixed them was running KSP as an administrator, which is similar to running a program as SU in Linux.

I haven't tried *moving* my 0.23.5 setup somewhere else then moving it back to see if it'll run with the default permissions a user account with Administrator rights has. I suspect it may not since some of the non-working parts were part of the stock KSP game.

[Galane]

But the better solution would be to find out what dll files don't load and unblock them manually in such a case...

A list of such DLLs to manually unblock would be very useful, especially since some of the blocked ones seem to be part of vanilla KSP.

[Faark]

A list of such DLLs to manually unblock would be very useful, especially since some of the blocked ones seem to be part of vanilla KSP.

Seriously? You have an "Unblock" button on e.g. files in KSP_Data\Managed\ ? Afaik that shouldn't be the case and doesn't the KSP installer make sure of this?

[agises]

To unlock all the plugins dlls at once download this tool http://technet.microsoft.com/en-us/sysinternals/bb897440.aspx then: streams.exe -d -s pathtogamedatafolder. ie : streams.exe -d -s F:\ksp_win\GameData

If you want to get rid of this permanently (I don't recommend that):

run: gpedit.msc

go to: User Configuration > Administrative Templates > Windows Components > Attachment Manager

Enable: Do not preserve zone information in file attachments

Salud.

[Xaiier]

It's unquestionably a bug in KSP that it modifies files in its folder. It should store and retrieve addons, saves, screenshots, logs, and everything else in the C:\Users\[your username]\AppData folder. This has been correct development practice on Windows for something like a decade and a half, and there's really no excuse for KSP not to do it.

Except that minor thing about how KSP is multi-platform and thus the inane method of using "AppData" won't work on other OS's, and making different layouts for different builds is just a pain.

[Moon Goddess]

Except that minor thing about how KSP is multi-platform and thus the inane method of using "AppData" won't work on other OS's, and making different layouts for different builds is just a pain.

Except for the fact that on every other OS is going to REQUIRE you to use their equivalent of AppData. OS's built with security from the ground up don't let you get away with nonsense.

There is no reason the average user should be running anything as Admin except an installer, and no reason anyone should ever be running a game as admin, especially one that has arbitrary code you downloaded from strangers on a forum.

[godefroi]

Except that minor thing about how KSP is multi-platform and thus the inane method of using "AppData" won't work on other OS's, and making different layouts for different builds is just a pain.

So on Windows it's %APPDATA%, on Linux it's $HOME, etc. The directory names change, the techniques are the same. Mono (and therefore Unity) provides this functionality via:

System.Environment.GetFolderPath( System.Environment.SpecialFolder.XXX )

In this case, one would likely want to use System.Environment.SpecialFolder.ApplicationData or System.Environment.SpecialFolder.LocalApplicationData.

[godefroi]

Except for the fact that on every other OS is going to REQUIRE you to use their equivalent of AppData. OS's built with security from the ground up don't let you get away with nonsense.

There is no reason the average user should be running anything as Admin except an installer, and no reason anyone should ever be running a game as admin, especially one that has arbitrary code you downloaded from strangers on a forum.

Well, either you have to use the equivalent of AppData, or you have to run as administrator, or you have to put the game somewhere where you have write permissions. All EXACTLY like you have to do on Windows. There's no difference. Windows is not more lenient here, it's just that every time someone sees the UAC prompt on Windows they go Google for "turn off UAC".

Can you imagine the outrage if one were required to run KSP on Linux with "su"? That's what Windows users are being asked to do.

[Xaiier]

Except for the fact that on every other OS is going to REQUIRE you to use their equivalent of AppData. OS's built with security from the ground up don't let you get away with nonsense.

There is no reason the average user should be running anything as Admin except an installer, and no reason anyone should ever be running a game as admin, especially one that has arbitrary code you downloaded from strangers on a forum.

Actually in most cases the user has admin privileges by default, not that that's necessarily a good practice but its how it is. Also, you are being a bit paranoid about mods, by forum rules they HAVE to post source code, so anything sketchy happening is fairly unlikely.

So on Windows it's %APPDATA%, on Linux it's $HOME, etc. The directory names change, the techniques are the same. Mono (and therefore Unity) provides this functionality via:

System.Environment.GetFolderPath( System.Environment.SpecialFolder.XXX )

In this case, one would likely want to use System.Environment.SpecialFolder.ApplicationData or System.Environment.SpecialFolder.LocalApplicationData.

That's a decent idea actually, and while it is technically good practice to utilize those resources, it is going to be a pain to switch and use them. It means KSP would have to come with an installer rather than being a single package and would probably discourage the average user to investigate modding.

Well, either you have to use the equivalent of AppData, or you have to run as administrator, or you have to put the game somewhere where you have write permissions. All EXACTLY like you have to do on Windows. There's no difference. Windows is not more lenient here, it's just that every time someone sees the UAC prompt on Windows they go Google for "turn off UAC".

Can you imagine the outrage if one were required to run KSP on Linux with "su"? That's what Windows users are being asked to do.

As I said before, in almost every case you are running it as administrator, in fact I can't even count the number of times the fix to some application not working was "run it as admin"

Except in a myriad of other cases "run it as admin" is the fix to something not working, because the AppData solution doesn't work for everything. There would be no outrage if it had become as standard to do such a thing on other OS's.

I'm curious as to why steam chose to use Program Files for the game directory. I'm fairly certain it uses the AppData equivalent in OSX.

[godefroi]

Actually in most cases the user has admin privileges by default, not that that's necessarily a good practice but its how it is. Also, you are being a bit paranoid about mods, by forum rules they HAVE to post source code, so anything sketchy happening is fairly unlikely.

Not all mods come from the forums. In fact, now that Curse is hosting the mods...

That's a decent idea actually, and while it is technically good practice to utilize those resources, it is going to be a pain to switch and use them. It means KSP would have to come with an installer rather than being a single package and would probably discourage the average user to investigate modding.

Why? You don't need to have an installer to save files into AppData. Or to ask Mono where the AppData folder is.

As I said before, in almost every case you are running it as administrator, in fact I can't even count the number of times the fix to some application not working was "run it as admin"

Except in a myriad of other cases "run it as admin" is the fix to something not working, because the AppData solution doesn't work for everything. There would be no outrage if it had become as standard to do such a thing on other OS's.

If UAC is enabled, even if your user account has administrator privileges, your processes run without administrator privileges unless you "run as administrator". I.e. if UAC is enabled and you don't get the popup, your process doesn't have administrator privileges. If the fix to any given problem is "run it as administrator", then I would suggest finding a less-broken replacement for that software, or running it from somewhere else, if it's broken-by-design like KSP. World of Warcraft used to do this, but I think it was the first expansion, or maybe the second, where they fixed the problem and stopped using the program folder for addons, screenshots, and logs.

I'm curious as to why steam chose to use Program Files for the game directory. I'm fairly certain it uses the AppData equivalent in OSX.

Fantastic question. I curse Steam for their choice, and that's why my Steam is installed under D:\Games\Steam

[Xaiier]

Not all mods come from the forums. In fact, now that Curse is hosting the mods...

Good point. I wonder if the standards will be the same.

Why? You don't need to have an installer to save files into AppData. Or to ask Mono where the AppData folder is.

No, but as KSP loads all the standard parts and stuff as if they were a mod, they would either have to redesign that or have those things install into the appdata area. Might not be that big a deal. Also it would have to generate a shortcut to the folder because they are hidden by default.

If UAC is enabled, even if your user account has administrator privileges, your processes run without administrator privileges unless you "run as administrator". I.e. if UAC is enabled and you don't get the popup, your process doesn't have administrator privileges. If the fix to any given problem is "run it as administrator", then I would suggest finding a less-broken replacement for that software, or running it from somewhere else, if it's broken-by-design like KSP. World of Warcraft used to do this, but I think it was the first expansion, or maybe the second, where they fixed the problem and stopped using the program folder for addons, screenshots, and logs.

Good point, but I still don't think its necessary to change how KSP works for the sake of something fairly minor.

Fantastic question. I curse Steam for their choice, and that's why my Steam is installed under D:\Games\Steam

Yeah, seems very odd.

[Galane]

As I said before, in almost every case you are running it as administrator, in fact I can't even count the number of times the fix to some application not working was "run it as admin"

Except in a myriad of other cases "run it as admin" is the fix to something not working, because the AppData solution doesn't work for everything. There would be no outrage if it had become as standard to do such a thing on other OS's.

On Windows, Run as AN administrator is not the same as running AS Administrator (logged into the Administrator account). There are three main types of Windows user accounts, the Administrator (note uppercase A), which is much like Linux Root but there are still some things one cannot do.

Regular user with administrator rights, you can run any program, access almost any folder - but with some things you have to click the "Yes I really want to do that" button and the ability to "Run as an administrator" on a one shot basis using the right click menu or always by setting it in the file's properties. That does not confer *all* of the power of the Administrator account, and you must know the Administrator password to set that in properties. Then there's the pretty much useless (in its default settings) Guest account.

If you have a program that's being balky about working properly, the easiest first thing to do is Run as administrator. If that works and you trust it, no problem. Or you can dig deeper and figure out exactly which bits of it Windows is blocking and see if just those parts can be unblocked.

For me, I just set KSP to Run as administrator and *#%@ trying to decipher exactly what Windows' problem is with it or what recent update is messing with it. It works and that's what matters to me for KSP.

[godefroi]

On Windows, Run as AN administrator is not the same as running AS Administrator (logged into the Administrator account). There are three main types of Windows user accounts, the Administrator (note uppercase A), which is much like Linux Root but there are still some things one cannot do.

Regular user with administrator rights, you can run any program, access almost any folder - but with some things you have to click the "Yes I really want to do that" button and the ability to "Run as an administrator" on a one shot basis using the right click menu or always by setting it in the file's properties. That does not confer *all* of the power of the Administrator account, and you must know the Administrator password to set that in properties. Then there's the pretty much useless (in its default settings) Guest account.

If you have a program that's being balky about working properly, the easiest first thing to do is Run as administrator. If that works and you trust it, no problem. Or you can dig deeper and figure out exactly which bits of it Windows is blocking and see if just those parts can be unblocked.

For me, I just set KSP to Run as administrator and *#%@ trying to decipher exactly what Windows' problem is with it or what recent update is messing with it. It works and that's what matters to me for KSP.

You shouldn't be giving out advice on Windows user setup and management. Your information is not merely wrong, it's dangerous.