LÖVE

The purpose of this thread is to work out an interface for the forthcoming "safe" filesystem via PhysFS. The point is that the standard Lua io library is removed, and game creators only are allowed write access to a single folder.

The folders could perhaps be:

Windows: C:\Documents and Settings\<user>\Application Data\love\<game>\save.lua
Linux: /home/<user>/.love/<game>/save.lua
Mac (if ever): /Users/<username>/love/<game>/save.lua

I first suggested that <game> could be the name of the file being run. Mike suggested that it could be the name of the file being run if there was no id attribute in the config file, in which case that would be used instead.
This way game creators can be extra sure that there's no folder conflict with their game. There might be better ways to solve this, so by all means; speak up if you can think of anything.

Ok, on to the interface: I understand that some people would want file:write( "hello") etc instead, but in that case we would also have to change love.graphics:draw(image, x, y) to image:draw(x, y) etc. We have discussed this forever, and have so far gone with the former. If you prefer one strongly over the other, please start a separate thread for that discussion as it has nothing do with love.filesystem .

Example use, saving the highscore as a string, but loading it as a Lua table. Of course, it should be possible to get the string as well, without parsing: My only major problem is love.filesystem:enumerate, as I am not very keen on creating a Lua table containing all the files internally. A newline separated string could also work. (dir1\ndir2\nfile1\nfile2\nfile3\netc).

I haven't thought of everything, so please speak up if you see something you don't like. (Or if there's something you would like to see).

Two questions: Is there any way to open a file in binary mode? Include behaves like Lua's include or more like require?

And maybe this can help you with the Mac question: http://www.jmu.edu/computing/mac/filestructureOSX.shtml

I was going to ignore the binary mode, for now ... not completely sure how to do it yet. The important thing is that we get something up and running at all.

love.fileystem:include() works like require. The same file will not be re-included. Note that love.filesystem:include( string ) exists now, but it looks for files in the .love archive.

Thanks for the MacOS link!

What would be the problem about opening a file in binary mode?
Couldn't you just make a love.filesystem:read(file, numOfBytesToRead), function to wrap to a C++ function that would read the number of bytes given, if there are that many bytes, and return it as an array (or table or whatever lua uses).
The open function would have to change too, to open it in binary mode (I guess it is required to specify whether you open something in binary or text mode(ascii/utf/whatnot) in C++), either add a boolean, or an int at the end to set the mode (there are constants and/or enums in lua right?).
If overloading isn't supported in lua, it might be hard to do a binary write function, without naming it something else, but love.filesystem:write( file, bytes[] )

???

Yeah, I guess what we would want is: Unfortunately, that can't be done right now, as SWIG (the Lua interface generator we're using) doesn't support "manual" native Lua functions inside objects.

I plan to split the modules (love.graphics, love.audio) into actual separate SWIG modules one day. When that it is done, these kind of functions will hopefully be possible to implement. Meanwhile, it's possible to save anything you can represent in Lua, although it will use way more disk space:

Explain the dire need for binary files, plx. I can understand that people who create more complicated games could use more complicated files, but aren't text files adequate since LÖVE can (and will, with your help in recommending things in the future features thread) do a lot of things for you?

For highscore tables, savegames, tilemaps, etc. Granted, it's not critical, but it can be useful. It's not like we need it right now, though