Can't save progress in Monkey Island episode 1 - UAC is disabled
It's not only save games, but also my preferences (screen resolution, whether or not subtitles are turned on, etc.) which are not saved.
UAC is disabled, and I am running from an admin account.
UAC is disabled, and I am running from an admin account.
This discussion has been closed.
Comments
If it is enabled, it works behind the installer translating paths (and registry keys) that you don't have regular access (even as an admin on Vista/W7*)
Short and easy way to solve this: enable temporarily UAC and run the installer
Shenanigans. I have UAC disabled on my Vista admin account, and have had for quite some time now. No problems installing the game, saving, or saving preferences.
Nebu, where do you have the game installed? In the default Program Files, or elsewhere? I know other games (Elder Scrolls III: Morrowind, specifically; others on hearsay) do have difficulties with save games if they're installed to the default Program Files folder. Try reinstalling the game elsewhere (say, C:\Games\Telltale).
The location the save files are stored in (on Vista) is Users\<name>\Documents\<...> which doesn't exist on my machine - the Documents folder is repointed to my E drive. This, I suspect, is what causes no gameplay or settings to save.
Unreal Tournament has the same issue, with it being resolved by providing a "-nohomedir" command line flag (or similar, I can't recall if that's the exact command) which saves all preferences, etc. to the install directory.
A possible cause for Telltale QA to look at...(if they're listening)...
My Documents folder is set into another location than the default one (\Users\<username>\documents). Many others game that use Documents system folder has no problem at all writing savegames and settings into the new location, but TOMI does. I had to move Documents folder to default position in order to play the game.
I've tied and the result is the same. Seems like the game is not writings any saves/prefs unless the documents folder is the default one.
Here's where things get a bit fuzzy: It'll probably ask you whether you want to move whatever is currently in your documents folder to the new location. I think I said "yes", but I'm not 100% sure about that.
Another thing to note is that it seems everyone who is affected with this bug has moved their location to a different drive (I've set my location to "D:\"). Perhaps saving works fine if the location is on the same drive (i.e. "C:\"), but it fails when it's on a different drive?
Is there any resolution to this yet? I bought the game and want to play it but can't due to this bug. It is seriously annoying and puts me off buying other similar games from TT in future.
HOWEVER, if I set my Documents folder to an actual folder on the
It seems, at least in my case, that the problem is the Documents folder being a root folder. None of my other games currently have this problem, but Mass Effect did originally, before they fixed it with a patch.
The Details - Short Explanation
The Windows OS function call available to get the location of the Documents folder returns a "NULL" when the Documents folder is set to the root of a drive. There is no other way Microsoft gives us to find the location of your documents folder under this condition.
Currently the only fix is the same as before: You can't have Documents at the root of a drive. Any application that refers to the Documents folder without using the Open/Save window will not work when documents are at the root of a drive.
The Details - Developer (Longer) version
In order to get the location of the Documents folder, the engine calls the function SHGetFolderPath() with the target of CSIDL_PERSONAL. This function works from Windows XP and above, even though from Vista on up the preference is to use the newer SHGetKnownFolderPath().
As first the speculation was something with SHGetFolderPath() wasn't catching the location change. When engineering did tests, they discovered both functions still returned "NULL" when the Documents folder was set to the root of a drive. When the location wasn't root, everything worked as expected. How it is that your Windows OS open/save dialog box works yet SHGetFolderPath()/SHGetKnownFolderPath() doesn't is beyond logic, but that's the situation. Maybe it's a security "feature", even with UAC turned off.
If anyone out there has a contact with Microsoft related to this issue, please put them in touch with me.
I wonder if it's been fixed in Win7 -- if so, my problem will go away in a few months.
Something like using CSIDL_LOCAL_APPDATA when the path for CSIDL_PERSONAL comes back as NULL possibly?
As for the previous episodes, it will have to wait till we go back for the DVD disc when update plans are figured out.
Nice one