Vista is messing with my game
by Nmuta Jones · in General Discussion · 07/14/2009 (4:09 pm) · 16 replies
Ok, so I used NSIS (NullSoft Scriptable Installer) to make an installer to install my game to a hard drive. The installer works great, and I've used it before. It even has an option to recursively preserve file attributes for entire folders.
But here's the problem:
In my game I use a checkpoint system based on triggers. When you trip a trigger, I write to starter.fps/client a .cs file named after the current user.
when you start a game, then in game.cs I look to see if your name matches what's in the client folder. If it does, then you respawn at the most recent spawn point based on the prefs in the .cs file.
The system works great and I've been using it for several months now. The problem is that after installing the game to new computers with the installer disk, when you pass a checkpoint, the file is not writing to disk.
I'm almost sure its a WINDOWS VISTA security issue of some type. Because when I disable the UAC (User Account Control) in Vista, the problem goes away.
The problem is that I don't want my users to have to go and fiddle around with files and permissions etc just for my game to work.
I tried unchecking "read only" on starter.fps/client but in Vista, no matter what you do, it does not seem like you can make this check box go away. When you go back to it, it will remain checked. I've Googled this extensively, and people seem to say that they have the answer but nothing seems to work.
Even in the original working game on my PC I am writing to files but the starter.fps/client folder still says "read only". But its not read only because I am in fact writing to it.
This is all kind of crazy! Any ideas? Help please!
But here's the problem:
In my game I use a checkpoint system based on triggers. When you trip a trigger, I write to starter.fps/client a .cs file named after the current user.
when you start a game, then in game.cs I look to see if your name matches what's in the client folder. If it does, then you respawn at the most recent spawn point based on the prefs in the .cs file.
The system works great and I've been using it for several months now. The problem is that after installing the game to new computers with the installer disk, when you pass a checkpoint, the file is not writing to disk.
I'm almost sure its a WINDOWS VISTA security issue of some type. Because when I disable the UAC (User Account Control) in Vista, the problem goes away.
The problem is that I don't want my users to have to go and fiddle around with files and permissions etc just for my game to work.
I tried unchecking "read only" on starter.fps/client but in Vista, no matter what you do, it does not seem like you can make this check box go away. When you go back to it, it will remain checked. I've Googled this extensively, and people seem to say that they have the answer but nothing seems to work.
Even in the original working game on my PC I am writing to files but the starter.fps/client folder still says "read only". But its not read only because I am in fact writing to it.
This is all kind of crazy! Any ideas? Help please!
About the author
Lead Developer for MediaBreeze Multimedia
#2
07/14/2009 (6:40 pm)
Are you installing into the C:\Program Files folder ? Vista by default doesent allow programmes to write to that folder or something stupid along those lines, its why they made the My Games folder within documents etc, anyways, installing to C:\ would work
#3
Yes, I was installing to C:\Program Files
I will try to set the installer to install to MyGames. Or just to C:\
07/14/2009 (7:18 pm)
AndyYes, I was installing to C:\Program Files
I will try to set the installer to install to MyGames. Or just to C:\
#4
07/14/2009 (7:24 pm)
Or follow the design guidelines of the operating system since WinXP: Don't write to the installation folder.
#5
07/14/2009 (7:35 pm)
Don't write to the installation folder.... so should I be writing to a "temp" folder? Please advise. These are saved games for player so I need them to be written to a folder that I've created. At least that seems to make sense to me. I just installed to C:\ and testing that now. 
#6
07/14/2009 (7:40 pm)
If you are using Visual Studio 2008, you can write to your program files folder. You just need to be sure you are using a manifest. This should be on by default, unless you have imported an old solution. If you are not using a manifest, then vista will redirect your reads/writes from your application directory into your personal folders. This should be transparent.
#7
07/14/2009 (8:56 pm)
Installing to C:\ worked, even with UAC active. Thank you. 
#8
Another mystery of the universe solved!
07/14/2009 (9:03 pm)
This is all good to know, then. I often wondered (not very hard obviously) why various games stuck all my save game info in /mydocuments and not the programfiles/thatgame folder.Another mystery of the universe solved!
#9
07/14/2009 (10:04 pm)
Quote:Whoever came up with UAC was the numpty ;D
Oh the curse of UAC ... why do people still use it, it's only there to stop you from deleting your system32 folder incase you are a numpty.
#10
Chicken and Egg ?
07/15/2009 (1:09 am)
If it wasn't for the numpties in the first place, they wouldnt have come up with UAC...Chicken and Egg ?
#11
What they should have done when people try to write anyway is writing the same path under a game-specific folder, and try there first when reading is detected to be under the protected. The warnings when doing admin tasks aren't as useful as popping up a password, either.
But non-system saving should happen in a user's environment, and it has been like this for at least nine years on consumer versions of Windows :)
07/15/2009 (2:33 am)
UAC is an annoyance, but it's the patch for a stupid design decision of old Windows versions. You must never write to the program's installation directory after installing, only to the individual user's data directory. Windows is more like grown-up operating systems now.What they should have done when people try to write anyway is writing the same path under a game-specific folder, and try there first when reading is detected to be under the protected. The warnings when doing admin tasks aren't as useful as popping up a password, either.
But non-system saving should happen in a user's environment, and it has been like this for at least nine years on consumer versions of Windows :)
#12
07/15/2009 (3:14 am)
UAC.. the burden of all Windows users. Windows 7 is the worst! I can't even zip to my C:\ (even with admin access, from the security menu). Reason why I'm going back to XP, Windows of today is a pain in the ***
#13
Doing so is just bad engineering and nothing more. Proper place for user data is user's data directory. Under windows you can type %appdata% into address bar in explorer, then go to folder named after $Game::companyName set in your game. Ough! What surprise - your game already have written there something?
One problem is that TGB would not let you compile anything there so if you have problem with that you would need to fix engine source and remove obstacle.
Cheers!
07/15/2009 (5:05 am)
Windows 7 may be or may be not a pain in the a** but under MacOSX you also wouldn't be able to write in installation directory. Also any potential distributor would not let you install only on C:\ drive (which does not exist under MacOSX by the way).Doing so is just bad engineering and nothing more. Proper place for user data is user's data directory. Under windows you can type %appdata% into address bar in explorer, then go to folder named after $Game::companyName set in your game. Ough! What surprise - your game already have written there something?
One problem is that TGB would not let you compile anything there so if you have problem with that you would need to fix engine source and remove obstacle.
Cheers!
#15
Torque Owner Jaimi McEntire #6
07/14/2009 (9:40 pm)
>> If you are using Visual Studio 2008, you can write to your program files folder. You just need to be sure you are using a manifest.
Wouldn't the manifest only work as you are describing if you specified the need for administative priviledges in the manifest? (I'm not sure.)
I did kids games and many parents would prefer for their 7 year olds NOT to have admin priviledges. I spent some hours retrofitting TGE with options to open and write to the users folders. I would rather GG add this as an option under Windows if they don't want to put some cross platform veneer over it. Why should everyone have to develop their own system for basic stuff like this?
07/15/2009 (6:38 pm)
Torque Owner Jaimi McEntire #6
07/14/2009 (9:40 pm)
>> If you are using Visual Studio 2008, you can write to your program files folder. You just need to be sure you are using a manifest.
Wouldn't the manifest only work as you are describing if you specified the need for administative priviledges in the manifest? (I'm not sure.)
I did kids games and many parents would prefer for their 7 year olds NOT to have admin priviledges. I spent some hours retrofitting TGE with options to open and write to the users folders. I would rather GG add this as an option under Windows if they don't want to put some cross platform veneer over it. Why should everyone have to develop their own system for basic stuff like this?
#16
On our first test run trying to get a (non-Torque) game to work under WinXP Limited User Access (LUA) (strangely, even touchier than Vista), the game crashed because some ancient C language library or other we were using used the oldest possible C interface for opening a temp file = crash. It was effectively opening it in the root which as discussed is another no-no. Most people probably wouldn't even know what a "temp file" was anyway, any more. Unless they learned programming in FORTRAN on cards or their grandfathers talked about them. :)
07/15/2009 (6:58 pm)
(Slight change of topic to answer a variation of a small question above about writing to temp files. The real answer is discussed above and is to study Windows UAC / LUA and follow their guidelines.) On our first test run trying to get a (non-Torque) game to work under WinXP Limited User Access (LUA) (strangely, even touchier than Vista), the game crashed because some ancient C language library or other we were using used the oldest possible C interface for opening a temp file = crash. It was effectively opening it in the root which as discussed is another no-no. Most people probably wouldn't even know what a "temp file" was anyway, any more. Unless they learned programming in FORTRAN on cards or their grandfathers talked about them. :)
Associate Steve Acaster
[YorkshireRifles]
The only way around (that I am aware of) UAC is either turning it off or adding the program to UAC permissions. Read/write won't help, it's UAC you have to reason with directly. I've had 3A software crash on me/fail to save 'cos of UAC.
So, not a helpful answer really, but I reckon you'll have to use a readme to inform the poor sap using UAC that they have to add your game to the UAC leave-me-alone list.