Support the request for improvements in packaging addons!

[atheros]

Hello,

I am asking everyone to read this issue https://bitbucket.org/rude/love/issue/2 ... -to-search and if you find those improvements usefull, say it either here or comment the issue.

What will you get from those improvements?

• Ability to pack addons (like maps with additional graphics)
• Provide updates for your game (that update only part of your resources)
• Prevent pollution of filesystem, an addon can be deleted by deleting only one single file
• Addon content will be available as if it was extracted in your game dir (no additional code is needed to handle that kind of resources)

Thank you for your support.

[Ensayia]

Really now? You already tried to make your case on the IRC and it was shot down because the devs don't like your current idea of how to implement it. Instead of doing a little research and work you bring your argument to the forums which I guarantee you is only going to frustrate the devs even further.

If you want support for your cause, do some more research on how to implement this in a secure way. Even better than that, get a copy of the source and start prototyping, you don't need to ask permission to do that. If you come up with a sound solution or even have a prototype a dev can look at, you can build upon that instead of an empty argument.

[kikito]

(stuff)

Unless I'm reading it incorrectly, everything you ask (addons, updates, etc) is already doable in LÖVE. You just use a specific folder per game (outside of the zip file, yes) to download any files you need, and then load them/patch them/whatever.

Being able to modify the original zip file, as the opened issue asks, doesn't provide any additional advantages over the current implementation. The time would be better spent in more needed features.

[Elvashi]

The original post isn't as clear as it should be, what he's asking for is the ability to mount additional archives, not modify existing ones (Indeed, he's seems pointedly aware that PhysicsFS considers archives read-only). So you could have, say, a "hires.zip" pack, "extra_maps.zip", or a "chaos_battles.exp" pack or whatnot.

[kikito]

I still think that addons, etc are perfectly feasible without having to open zip files anyway. If the user has to install the add ons manually, "copy this zip file on this folder" is just slightly more difficult than "uncompress this zip file on this folder". On the other hand, if the application itself has to download the files from the internet, then http compression can be used to minimize the load time, without having to handle compressed files directly.

This said, there's a pure-lua implementation of gunzip inside kadoba's Advanced file loader.

[atheros]

I'm making a multiplayer action game. 'addons' will be downloaded from the server you connect to. Of course you could download a set of files manually, but that has some issues:

• you need more code to verify all the files a specific server requires
• if several addons modify the same resources, you will either need to re-download them repeatedly, specifically check for conflicts and add caching code, or add filesystem abstractions like...well, PhysicsFS...which Love already has.

Other suggested solutions involve using some Lua compression code. Of course, it can be done. That has however some downsides too:

• It is slower than native implementations
• It would either require you to add additional code from your part to extract ALL those files (possibly conflicting with other addons/archives)
• Should a bug be found in the decompressor, everthing that uses that lib would have to be manually updated. ...as opposed to simply being fixed in the next love release.
• It would make a mess of your filesystem after a few of such addons
• It would make it virtually impossible to remove the addons you don't want anymore without corrupting the other addons

Yes, some of you will tell me that it is possible to solve all of those issues. It will however require you to add additional code, probably too specific for you game, and many people will have to code similar workarounds and hackish code over and over again.

So my question is why do all this if there is a more elegant and efficient solution? Love uses PhysicsFS internally, which was basically designed to do this. it already implements archive and directory mounting (which love2d uses) so we simply exposed that.
Here is what we already implemented:

• mount/umount archives (using whatever mountpoint you want)
• archives can only be loaded from locations provided by conf.lua
• automatic mounting of archives from 'conf.lua' (those can not be umounted and can be loaded from wherever you want)

Its not yet complete, our TODO list:

• globbing for automount (and to expose in love.filesystem in addition to enumerate or to replace it)
• maybe add restrictions to where an archive can be mounted (but is it really needed?)
• review the C++ code we already have and make it a bit better

There is currently only one known issue, love.filesystem.lines() doesn't play nice with mounted archives. If you call it on a file in a mounted archive, you won't be able to umount it. I will try to fix this tomorrow.

For everyone interested in trying it out: hg clone https://bitbucket.org/atheros/love-mount

Now we will be focusing on adding more real-world examples to show you the benefits of being able to mount other archives and hopefully catch all the bugs in the process we didn't encounter yet.

[atheros]

Changes:

• added love.filesystem.basename()
• added love.filesystem.dirname()
• added love.filesystem.find()
• you can now use wildcards for automount (like addons/*.zip)
• it's safe to use love.filesystem.lines() now

Platform status:

• unix build files are working
• MSVC2008 and MSVC2010 were update, however I have no means of checking them
• MacOS X build files wern't updated