plans for love.filesystem

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
Post Reply
Mr. Strange
Party member
Posts: 101
Joined: Mon Aug 11, 2008 5:19 am

plans for love.filesystem

Post by Mr. Strange »

I haven't checked to see if the lua default io commands are working in 0.4.0 (they were in 0.3.2) but I recall mention that they would be going away.

I really like to have non-lua text data files drive my projects, and with love only supporting "all or nothing" reads (as opposed to the line by line reads supported by lua 5.2) I don't have any easy way to do this.

As an example, I want to let designers build a level with a text file like this:

OOOOOOOOLO
OOOOOOOOLO
OOOOOBLBBBB
OOOOOOLOOO
OOOOOOLOOO
BBBBBBBBBBBB

O = space, B = solid block, L = ladder.

Ideally I would read this one character at a time, and populate a level grid with this data. This is a pretty simple example, but it shows the type of interaction I want to have with my text files. I wonder if anyone has any thoughts about a useful workaround for me, or if other people have run into limitations with the file system structure present in love.

--Mr. Strange
User avatar
rude
Administrator
Posts: 1052
Joined: Mon Feb 04, 2008 3:58 pm
Location: Oslo, Norway

Re: plans for love.filesystem

Post by rude »

Standard io still works. You presented some good arguments in your one of your previous posts, so instead of dealing with it right away, I let it silde *again*.

For those who haven't been paying attention, here's the problem:
  1. Standard io has access to everything on the host computer. People can easily make a .love file which overwrite system files or do worse things.
  2. We would like to keep the code LÖVE uses identical to "vanilla Lua". If we make small changes here and there, we'll eventually end up with a throbbing abomination of horror, like GMod Lua.
Which means that simply removing "io" and "os" isn't good enough.

Suggestion:
Remove io and os by default, but add a command line option which includes them. This will allow .love demo mongerers (like me) to feel safe when they click on .love files, and allow game designers (like Mr. Strange) to use io and os if they so desire.

Ok, now, about your problem. Some new stuff will be added to love.filesystem in the next release:
  • A function which returns a line iterator.
  • You'll be able to use filenames directly, like: contents = love.filesystem.read("data.txt"). No need to open of close the file.
  • I've added a PhysFS loader to package.loaders, which means that you can now use standard require().
  • love.filesystem.read() has been fixed to not include all the BS-characters at the end of the string.
  • love.filesystem.load(), which does the same as loadfile().
I don't know if that's good enough for your needs. As you all know, I'm open to suggestions.
User avatar
Merkoth
Party member
Posts: 186
Joined: Mon Feb 04, 2008 11:43 pm
Location: Buenos Aires, Argentina

Re: plans for love.filesystem

Post by Merkoth »

rude, I suppose you do realize that your anti-script-kiddies solution won't fool anybody, right? :D
User avatar
conman420
Prole
Posts: 33
Joined: Sun Aug 31, 2008 8:46 pm

Re: plans for love.filesystem

Post by conman420 »

Convert the string it returns to a table:

Code: Select all

function string.table(str)
	local len = string.len(str)
	local t = {}
	for i = 0, len do
		table.insert(t, string.sub(str, i, i))
	end
	return t
end
Mr. Strange
Party member
Posts: 101
Joined: Mon Aug 11, 2008 5:19 am

Re: plans for love.filesystem

Post by Mr. Strange »

rude wrote: Suggestion:
Remove io and os by default, but add a command line option which includes them. This will allow .love demo mongerers (like me) to feel safe when they click on .love files, and allow game designers (like Mr. Strange) to use io and os if they so desire.
So you mean that when running love I'd call love.exe -io? That seems like a pretty solid way to go. Then again, focusing on PC security concerns is not my specialty. I'm thrilled with this solution.

Ok, now, about your problem. Some new stuff will be added to love.filesystem in the next release:
  • A function which returns a line iterator.
  • You'll be able to use filenames directly, like: contents = love.filesystem.read("data.txt"). No need to open of close the file.
  • I've added a PhysFS loader to package.loaders, which means that you can now use standard require().
  • love.filesystem.read() has been fixed to not include all the BS-characters at the end of the string.
  • love.filesystem.load(), which does the same as loadfile().
I don't know if that's good enough for your needs. As you all know, I'm open to suggestions.
Those sound hot. I've never been a fan of calling open on files before I can use them, so I'm especially keen on that change. One possible consequence of that, however, is that I'll want to lean more and more heavily on love.filesystem, so I'll keep pushing for functionality. That might be good or bad, I suppose.

It's thrilling to be using a product with an engaged development team. You guys rock.

Current request - integrate gamepad support into the next official release!

--Mr. Strange
User avatar
rude
Administrator
Posts: 1052
Joined: Mon Feb 04, 2008 3:58 pm
Location: Oslo, Norway

Re: plans for love.filesystem

Post by rude »

Merkoth wrote:rude, I suppose you do realize that your anti-script-kiddies solution won't fool anybody, right?
Preposterous! It is bulletproof and can not possibly fail.
conman420 wrote:Convert the string it returns to a table: [etc]
It's good that someone actually answers the question.
Mr. Strange wrote:So you mean that when running love I'd call love.exe -io? That seems like a pretty solid way to go. Then again, focusing on PC security concerns is not my specialty. I'm thrilled with this solution.
Yes: love.exe -io game.love, for instance. If you're OK with this, it might be the final solution.
Mr. Strange wrote:It's thrilling to be using a product with an engaged development team. You guys rock.
:) Keep pushing for love.filesystem functionality, that can only be good.
Mr. Strange wrote:Current request - integrate gamepad support into the next official release!
That's the plan. The current delay is dealing with all the requests regarding love.physics, and the ever-present life outside LÖVE (gasp!). Did you use the preview build I sent you? Any comments?
User avatar
Kaze
Party member
Posts: 189
Joined: Sat Jul 19, 2008 4:39 pm
Location: Dublin, Ireland

Re: plans for love.filesystem

Post by Kaze »

conman420 wrote:Convert the string it returns to a table:

Code: Select all

function string.table(str)
	local len = string.len(str)
	local t = {}
	for i = 0, len do
		table.insert(t, string.sub(str, i, i))
	end
	return t
end
It would need to be split by the line breaks, also.

This will make a 2D table, table[line][character]

Code: Select all

function string.table_nl(str)
	local len = string.len(str)
	
	local ti = 0
	local t = {[0]={}}
	
	for i = 1, len do
		local char = string.sub(str, i, i)
		if (char == "\n" or char == "\r") then
			ti = ti + 1
			t[ti] = {}
		else
			table.insert(t[ti], char)
		end
	end
	
	return t;
end
Mr. Strange
Party member
Posts: 101
Joined: Mon Aug 11, 2008 5:19 am

Re: plans for love.filesystem

Post by Mr. Strange »

rude wrote: Did you use the preview build I sent you? Any comments?
I did indeed (rude sent me a 0.3.2 build with gamepad support enabled) and found it to be totally workable.

My comments are not very helpful, but I will say that all gamepad support suffers from the problem of non-normalized outputs. What I really want from a joystick is a direction and a distance from center, but instead I get some arbitrary output which I have to convert. That's not a weakness in your code, it's just a weakness in controller code in general. Plus the fact that some inputs are analog and others are digital is a pain to support.

--Mr. Strange
Post Reply

Who is online

Users browsing this forum: Amazon [Bot], Bing [Bot] and 39 guests