Game updated and still unable to save data

#1 Sadly, I was unable to work around with this issue. Turning back to 1.5 until 1.6 gets fixed or TGB 2 released

#2 Yes, I believe something is wrong with the way TGB 1.6 chooses file paths in certain common cases. I'm not sure GG is even aware of this major issue, or how it passed their extensive QA testing. It's not only the save function..we also can't get our prefs to save out correctly. I posted in the bug reports forum weeks ago and got no reply. I'm pretty sure the two issues are related.

Link:
www.garagegames.com/mg/forums/result.thread.php?qt=70566#506727


Everything worked fine back when it didn't add crap to our documents and settings folders (under windows anyway). I'm not sure why they decided to change (and break!) a good thing.

#3 @ Joe Rossi ,


I'll back you in that parse

Quote:
"Everything worked fine back when it didn't add crap to our documents and settings folders (under windows anyway). I'm not sure why they decided to change (and break!) a good thing."

Anyway, here is how I fixed my version my fix and I change the pref directory to my current game directory.


Aun.

#4 Hi Isaac,
It seems that the '~' is no longer is necessary or works in 1.6. That '~' denotes that we want to create a relative path to wherever the game happens to be running.

I think part of the reason for the change is that in Vista, saving in that directory the game is running in is usually not possible.

So the correct file path naming would be
$DataPlayer.save(expandFilename("data/savedInfo/" @ $DataPlayer @ ".cs"));

Now this will save, but it will be to a different directory than 1.5.1 would save to. On the mac, for example, it would save to
/Users/username/Library/Application Support/Company/Appname/data/savedInfo/
where Company and Appname is whatever is set in the TGB preferences.
In Windows this would save similarly to the particular user Documents and Settings directory.

It could be argued that this is a better way to handle data saving. As long as you know it's being saved, you don't need to worry whether it's being saved to one particular spot or another.

I'm not sure expandFileName is needed anymore, either. I still use it because it doesn't seem to hurt, but echoing the expanded name doesn't seem to show any difference.

Greg

#5 Actualy the reasion it was changed to documents and settings I believe is because its a requirement for games for vista to pass the games for vista test. Also since vista does this by rerouteing the save paths itself I am sure it just made since to universalize the system with TGB so developers didnt have to hack in a solution for vista and/or xp make them work the same way.

Its also alot better practice to save files and such to documents and settings as opposed to a games directory. This allows the game to be portable with a roaming profile and also prevents security issues from ariseing. One of the big reasions why vista reroutes games save data files to my documents.

#6 Wow, rapid fire answers! Obviously a hot topic!

Greg

#7 Here's a quick repro for my bug:

Run your game with this code somewhere.

$pref::Audio::channelVolume1 =   0;    
 $pref::Audio::channelVolume2 =   0 ;  
 export("$pref::*", expandFileName("common/preferences/defaultPrefs.cs"), 0 );

Now comment that code, insert this anywhere in your code, and rerun the game.

echo( $pref::Audio::channelVolume1 SPC $pref::Audio::channelVolume2 );

It will not print "0 0".

I use version control so I can see my defaultPrefs.cs in the game directory is never getting touched. It writes the file in the documents and settings folder, with the correct prefs values of 0. But that's not the one the game loads by default..so we're stuck with whatever prefs we use in the defaultPrefs.cs in our game directory.

#8 What OS are you running this test on? If it is windows vista are you running the program as an administrator and also running the game in Windows XP SP2 Compatability mode. By running it in compatability mode and giving it administrator access you will bypass vistas system of redirecting game saveing of data.

Its worth noteing while the system redirects the games save location it doesnt redirect where the game will read the data from. Vista treats all programs as if they are a security issue toss not allowing them to save stuff into the program files directory.

#9 @Aun Arinyasak, I tried that fix but it didn't seem to work :(

@Thomas
Thanks for explaining the reasoning behind the change. I'm running it on XP SP2, but not in compatibility mode.

#10 Hmm kinda strange that its doing it in XP SP2. It maybe a change to the saveing system that was missed with the reading side of the files. To be honest I havent play with saving and loading of files in TGB to know what TGB is doing with it. I just understand how Vista handles the redirection.

I will try to put in some time tomarrow and see if I can help you out some by saving and writing to a file and see whats going on.

#11 I guess it's a feature, not a bug... from TDN TGB/FileIO

Changes to exec (for games)

    * Will now execute scripts in both the Game Directory and the Application Data Directory
    * When executing a script, will look for both the raw (*.cs) and the compiled (*.dso) 
[b]before trying the Application Data Directory  [/b]

So it always finds the defaultPrefs in the game directory. To get around it, save and load your prefs in another filename. For some reason I didn't think of that... :P

#12 @ Isaac Barbosa,
I tried the save function code you posted, and it does work for me... if you're using windows the file gets saved in your Documents and Settings folder. Check in there and let us know if you find it.

#13 @ Joe, It is working in 1.5 not in 1.6

So I back to 1.5 ;)

tHANKS!!!

#14 Hi Isaac,
It does work in 1.6.

Re-read my post, if you could. It is not a bug, but a change in the method; so you will need to probably adjust your code to accommodate it.

Greg

#15 Yes in TGB 1.6 save() does produce a file containing the object you want to save. Only it seems to create it in your "documents and settings" folder, not in the game directory. There's no reason to switch back to 1.5, unless you need to for some other reasons.

#16 @Greg and Joe,

Maybe I'm wrong in my code adjustements between versions, but for now i DON'T want more unnecessary pain: I will keep working under 1.5 since for now I have no more problems :)


But for sure I will try 1.6 later

or, who knows? 2.0?


Thanks!!!!

#17 @Greg,

Hi.

I'm desperated.

Your fix is working perfectly in 1.5.1 until I compile the game. Once the game is compiled it doesn't works anymore.

Some idea?

Thanks!