love.filesystem and the absurdity of Love2D's file limitations

[Bloxis]

Outside of the clickbaity title, is there any LEGITIMATE reason to not allow Love2D executable from accessing their root folder or any folder? I mean, outside of the possibility of becoming a virus which I am certain if someone really wanted to make a virus they'd build it from scratch outside of maybe the coding language... Seriously. I want to load a bunch of files outside and I want a very specific structure. It'd go like this.
C:\Program Files(x86)\*GAME*
Then I would load things from \Externals\*Type of external data to load* and then the game would be under \Version\*Release version*.
Why can't I do that outside of the arbitrary limitation of sticking it in %appdata%\LOVE\*GAME*? I'm making a kids game and the requirement of loading stuff from %appdata%\LOVE\*GAME* instead of like the desktop or %documents%\*GAME*\*LEVEL FILES* is absurd and stupidly complex.

And thus, I want a reason for that. I get that Love2D may be used maliciously, but if there's a will, someone will find a way anyways, so why limit the rest of us who want to make games with customizable levels?

[bobbyjones]

When you make a release version it won't be in the LOVE folder I believe. It's only there now because of if every single game you ran from this forum created a folder it will be hard to locate save files if needed.

[zorg]

When you make a release version it won't be in the LOVE folder I believe. It's only there now because of if every single game you ran from this forum created a folder it will be hard to locate save files if needed.

They do create folders, just in appdata/love/<identity> if you run them non-zipped (non-fused) or in appdata/<identity> if fused.

Anyway I can't comment on the why; but i can say that there are at least two ways to work around this for now;
- You can use lua's io in a smart way, or
- you can wait on me to release a lib that mounts root into the virtual PhysFS filesystem löve uses, so you can use löve's own constructor functions with any path.

[Bloxis]

I'm most likely going to try to use C++ at this point due to this issue. Love2D is a capable engine, sure, but I really need those directories as they're easy to get to.

[ivan]

The appdata/roaming folder determines how files are supposed to be synced between devices and has equivalents on Linux and OSX.
It is absolutely the most standard and straightforward way of handling save files.
First of all, if you are expecting your game to work across different platforms, you can forget about "C:\Program Files(x86)".
Also, you must have administrative privileges to modify the program files (so your app won't work for limited or guest accounts on Windows).
So it's not a limitation but the standard way of how modern applications work
Once you learn how to use the "appdata folder", you might find that it makes a lot of sense.

[zorg]

I'd argue about my dissenting opinion about how modern does not always equal utmost good, and why i prefer to takeown *.* on my computer, and stuff other people might cringe at, but the truth is, i like to have control of the tools i use, and an OS telling me how to do things is not an idea i like to entertain.

Along that line, i can understand some frustration regarding such limitations as one specific place for applications to store data, but then again, windows isn't really all that compliant either (e.g. games may have data in appdata, documents/(my?) games/ or in a few other places; I myself prefer if programs are portable in the sense that they don't touch the towering obelisk called the registry, and just have all settings and files in their own folder to which i unpacked them; and this includes a dislike for installers for them may include subtle things they might add to some paths that i didn't ask for. (i't a tad better if they do ask and give you an option to opt out)

I'm not saying how it works now doesn't make sense, it does in some ways, but for others, it certainly doesn't. Ivan's right in the regard that having one more or less standardized place where a program can store and even edit data be more secure than any other option, but this too implies sacrifices that have been made in order to satisfy some other constraint others found to be more important. (contrast: you can't really implement undertale's or oneshot's special mechanics on consoles).

Whether löve should give you the option to access the whole filesystem or not is a moot point though, for a few reasons:
- it still retains lua's io functionality, and saying that that's lacking (no dir listing, etc.) is more of a reflection on the language itself, and not the framework that is löve,
- second, if you are adamant on using PhysFS, you need to understand that that was specifically written to work the way it does (mostly, probably still has some bugs or functionality quirks, as some people have found out on discord)
So, in a way, it already allows you to do most of the things you'd want, without the need to do any shenanigans; the rest, people might find/code/share solutions. I've personally seen about 3-4 libs in the past, dealing with either file dialogs, or the bruntwork behind them, i.e. better, or at least different ways from the two built-in ones, to access the filesystem. Note that most still had shortcomings (and i'm not saying mine doesn't have them either, but i can work around a lot, thanks to the efforts of those before me)

...tl;dr: I like peaceful debating, and both sides to the discussion have good points for different reasons... in reality, it's hard to be objective on things since the objective of the different approaches are different, naturally.

[ivan]

I'm not saying that the appData idea is perfect but it does make sense and it is far from "absurd".

and just have all settings and files in their own folder to which i unpacked them;

Yep, this is the old-school style typically done on Windows using .ini files.
Although I do find the old style charming it does have some downsides.
For example, allowing each programs to write in its own folder means varying app size (due to save files, cache files, etc).
Suppose you install an app on your machine that requires 128 MB but after using it for a while you find that it takes up 512 MB.
Something like that could be an issue on mobile platforms where space is limited.

[le171138028]

Game.love, the program runs, and is loaded into memory.
However, not all resources need to be loaded into memory.
When it is used, it is a more sensible choice to load. This is particularly important in the Android system. Not all mobile phones have large memory.