plans for love.filesystem

[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

[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.

[Merkoth]

rude, I suppose you do realize that your anti-script-kiddies solution won't fool anybody, right?

[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]

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

[rude]

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.

Convert the string it returns to a table: [etc]

It's good that someone actually answers the question.

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.

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.

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?

[Kaze]

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]

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