Access to the directory of the game?

[louie999]

Haven't visited this site in awhile

Just a question, is there such a function that I can use to read an external file (like a '.txt' file) from the directory of my game.

If, example, my game's .exe resides in "D:/Stuff/MyGameFolder" and there's a text file in "D:/Stuff/MyGameFolder/Data" then would it be possible for me to directly access (read/write) to that file? Or is it impossible for Love2D?

[murks]

I wonder since a long time and was just about to ask that

The reason in my case is that I would prefer the config file to be easily accessible by the user, so I'd like it to be a text file right next to the .love file. Is this possible?

[zorg]

That's one thing that's possible:

Code: Select all

-- since technically, it's not in an external directory, if you main.lua is in "MyGameFolder", then anything "inside" that will be "internal"
local filepath = 'Data/like_a.txt"
for i,v in love.filesystem.lines(filepath) do
-- iterate over lines, for example
end

Edit: If you mean files next to, but nevertheless outside the .love file... Well, technically, you can still get back the directory the .love resides in, but you do realize that you have one additional folder that your game can access; The save folder is just for this reason, and that's both accessible and writeable by your application. Be sure to set your game identity in love.conf first, otherwise löve can't know what directory it's allowed to access. Also, if you run your project as a packaged .love file, the path to the save folder will be exactly one folder shorter, since it won't include "LOVE" before the identity folder. Edit: Only if you run it fused with the --fused cmdline switch.
The [wiki]love.filesystem[/wiki] article on the wiki helps.

[murks]

Thanks zorg,
I did not even know there was a save directory...

Do I understand the wiki page correctly that I could read a config file that is next to the .love but not write it?
Example:
games/mygame.love
games/config.lua

I guess I could read user settings from config.lua and write them to conf.lua inside mygame.love?

[zorg]

You can't modify/add/delete/create anything inside your .love file, it's the same if you had your project un-zipped and not in a .love file.

Code: Select all

arbitraryPath/sourceBaseDirectory/

The above is the base directory of your project, it can be named anything, it should contain at least the main.lua file, and if you want to use it, the conf.lua file.

It is the same as the topmost level in your .love file, which is a zip archive containing the contents of that directory (and not the directory itself).

Anything outside your .love file is almost exactly like anything outside your projectBaseDirectory, with one exception.

The exception is that you can use [wiki]love.filesystem.getSourceBaseDirectory[/wiki] if your project is fused (Whether by using a commandline parameter or combining that with the love executable on windows).

You can mount the directory returned by the above function, meaning you're basically allowed to read, and only read the folder where your .love (or .exe, or main.lua) resides.

Code: Select all

<OS-Specific-Path>/Love/saveDirectory/
<OS-Specific-Path>/saveDirectory/

The above is the only folder your project has writing/modification/deletion/creation permissions to (along with reading, of course).

The wiki page on [wiki]love.filesystem[/wiki] explains where this folder usually is.

The first one is used when the project is not fused in any way, the second one is used if it is.

The saveDirectory's name will be determined by what you set as your project's identity, either by setting it in the conf.lua, or by calling the relevant function ([wiki]love.filesystem.setIdentity[/wiki]).

Yes, this means that if you set it to something that another project is using, Löve won't complain about possibly overwriting or deleting data there, so one should be careful.

[murks]

Thanks.
The fused/unfused distinction makes things a tad more complicated. I also want to avoid using the save directory for things a user might want to access because that gets complicated as well. So far I have always developed my little games on Linux and packaged for OSX and Windows. Linux was unfused, whether OSX is considered fused I have no idea and I fused for Windows for convenience. All three have different save game directories, telling the user to configure something in there is something I want to avoid.

So based on the code from https://love2d.org/wiki/love.filesystem ... eDirectory I could do something like:

Code: Select all

local function read_config()
    -- read conf file (e.g. "coolgame/config.txt") and set stuff using love.conf()
end

local dir = love.filesystem.getSourceBaseDirectory()

local accessible
if love.filesystem.isFused() then
    -- handle the case that mount fails
    accessible =  love.filesystem.mount(dir, "coolgame")
else
    -- unfused should not give any trouble
    accessible = true
end

if accessible then read_config() end

That would mean that the only difference between fused and unfused is that in the case of the fused game, the directory needs to be mounted before it can be read?

[zorg]

The fused/unfused distinction makes things a tad more complicated.

A bit, yes; though i must confess, i may have made a mistake before; Apparently, zipping up the project into a .love does not make it fused, only combining it with love.exe on windows, or running a game with the --fused command line argument will make it be fused.

I also want to avoid using the save directory for things a user might want to access because that gets complicated as well. (...) All three have different save game directories, telling the user to configure something in there is something I want to avoid.

As i said, if you want to save scores, logs, settings or just about anything, you will need to use the save directory. It's not complicated at all, despite the fact that it's location is different on different OS-es (and that fused games drop the 'love' subfolder); the user will usually ever need to know one path; win users should look in appdata/roaming (vista and above), mac and linux people will figure it out on their own. Don't think your users lack such basic knowledge as to navigate a file system; frankly, i wouldn't let people near computers without that knowledge :/

...whether OSX is considered fused I have no idea...

No idea whether Mac has a special combined thing like executables on windows, but a .love will be unfused by default, and you can use the commandline flag to make it fused.

So based on the code from https://love2d.org/wiki/love.filesystem ... eDirectory I could do something like: (snip)

In theory, that code looks okay, haven't tested it though.

That would mean that the only difference between fused and unfused is that in the case of the fused game, the directory needs to be mounted before it can be read?

If i would have been right in my previous post, yes; but since .love files are not automatically fused, you can not access the folder containing the .love file at all that way, so short version should be:

Code: Select all

source files | love main.lua             | source directory readable
source files | love main.lua --fused     | source directory readable
.love file   | love project.love         | directory containing .love file not mountable, not readable
.love file   | love project.love --fused | directory containing .love file mountable, then readable
.exe file    | project.exe               | directory containing exe file mountable, then readable

[murks]

That would mean that the only difference between fused and unfused is that in the case of the fused game, the directory needs to be mounted before it can be read?

If i would have been right in my previous post, yes; but since .love files are not automatically fused, you can not access the folder containing the .love file at all that way, so short version should be:

Code: Select all

source files | love main.lua             | source directory readable
source files | love main.lua --fused     | source directory readable
.love file   | love project.love         | directory containing .love file not mountable, not readable
.love file   | love project.love --fused | directory containing .love file mountable, then readable
.exe file    | project.exe               | directory containing exe file mountable, then readable

Thanks for the clarification.

That means that due to the filesystem access restriction what I had in mind is not possible across the platforms I care about.

I also want to avoid using the save directory for things a user might want to access because that gets complicated as well. (...) All three have different save game directories, telling the user to configure something in there is something I want to avoid.

As i said, if you want to save scores, logs, settings or just about anything, you will need to use the save directory. It's not complicated at all, despite the fact that it's location is different on different OS-es (and that fused games drop the 'love' subfolder); the user will usually ever need to know one path; win users should look in appdata/roaming (vista and above), mac and linux people will figure it out on their own. Don't think your users lack such basic knowledge as to navigate a file system; frankly, i wouldn't let people near computers without that knowledge :/

Well, I have been quite disenchanted. For a lot of computer users nowadays simple file management is over their head. Given that, a config file might be too complicated as well. As simple as conf.lua may be, you can make syntax errors and mess it up.

I just hoped that I could keep it simple and avoid exposing the settings of conf.lua via a GUI, but I guess I will have to do just that and write the result to the save directory.

Thanks for your help zorg.

[zorg]

To be fair, i myself have a few projects in the making, and the way i did config files were the following:

Game startup:
- If it/they do not exist in the save folder yet, then use internal copies and copy those to the save folder.
- Load the config files from the save folder (and by config, i mean game-specific configurations mostly; audio (volume) settings, (minimal) graphic settings, input settings)
When settings are modified in-game:
- Export the settings with the same structure as before, into a .lua file, so it can be easily loaded. I have some strings in a table denoting lines in a file, and i use string.format to put the variables there too, then simply concatenate the table and write it out, overwriting the previous file. (One could also opt to only serialize the modified settings when the user quits the game, but this is safer.)

[bartbes]

That means that due to the filesystem access restriction what I had in mind is not possible across the platforms I care about.

Wait what? You can fuse on every platform! Also, if you really, really want to, you can still use the io library...