I don't know where they're saved to if you don't specify a file. Probably C:\Users\bla\bla but it's usually best to set it yourself anyway, like this: Start of frame: Set File to Apppath$+"data.ini".
Using Apppath$ will put the file in the same folder as your game.
oooooooooooooh ok. well that will be useful. another quick question... is there a way to detect if the ini has been created? i want to have an event that hides the continue button if no ini file has been created.
[Game design makes my brain feel like its gonna explode.]
You can use the File Object to detect if a file exists. Just use the same apppath$ approach to get its location.
Or, alternately, you can include a value in your ini file like "exists", which you set to 1 as soon as you make the file. If you test that value and the save file exists, it will find the value and return 1. If the file doesn't exist and there's no value to retrieve, it will default to 0 and return that instead.
INI's used to be placed in the windows directory by MMF created executable, but now I think it's in the %appdata% folder now, which is an environmental variable for "C:\Users\Admin\AppData\Roaming" on most machines.
I prefer ini's to be in the same directory as the exe myself though to keep the application directory portable.
Urban is right; while INI files are being written to, edited, or read from they store in C:\Users\%CURRENT_USER%\AppData\Roaming" directory or "C:\Documents and Settings\%Current_User%\AppData\Roaming" depending which OS you use. Problem is - most Windows OS's erase roaming profiles periodically. Mine erase every time I reboot. Limited user accounts and guest accounts might have issues saving too.
If you plan on making any data persist between game or app sessions you'll need to save your INI to a location that Windows doesn't treat as a temp directory or periodically deletes. That just means you'll need to save your INI to a directory that remains persistent between computer reboots. Also, you should make sure guest accounts and limited user accounts aren't blocked from saving by directory access restrictions.
I believe there is a command similar to AppPath$ that allows access to the system directory and another to access the system's temp directory but I can't remember either and I can't find any sort of reference to the other commands online. If I find some time I'll look through my tutorials and help files - see if I can find something that describes the other commands. If I do find something, I'll write up an article for tDC.
It's pretty safe assuming the user has a "c:\program files\" directory, so writing your INI files to a static filepath like "c:\program files\%Game_Name%\ini\default.ini" would make sense especially if you plan on using an installer. In the same spirit, though; you could simply use AppPath$+"\ini\default.ini" instead. Same difference. AppPath$ is especially important if you're planning any sort of portable game or application you plan on running from removable media. Using AppPath$ allows the drive letter to change without upsetting directory-nested dependency files and externally saved data.
Update: You might still be able to use AppDrive$ to at least determine which DRIVE the game is installed to. Follow AppDrive$ with whatever string filepath you need. Back in the day we used to use AppDrive$+AppDir$+"filepath_string.txt" in Games Factory to do the same thing AppPath$ does in MMF2 now.
Edited by The_Antisony
ChrisD> Employer: Say, wanna see a magic trick?
ChrisD> Employee: Uhh… sure, boss.
ChrisD> Employer: Your job! It just disappeared! Pack your things and leave! Pretty good trick, huh?
Appdrive$ Returns the drive letter the application is found on.
Appdir$ Returns the path where the application can be found, minus the drive letter.
Apppath$ Shortcut for Appdrive$ + Appdir$.
AppTempPath$ Returns the path of the temporary folder where the application is extracted during runtime.
Appname$ Returns the name of the executable, minus ".exe" or ".ccn"
BinFileTempName$(path) Returns the name of the last extracted binary file.