Support the request for improvements in packaging addons!

General discussion about LÖVE, Lua, game development, puns, and unicorns.
Post Reply
atheros
Prole
Posts: 3
Joined: Mon May 02, 2011 7:40 am

Support the request for improvements in packaging addons!

Post by 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.
Last edited by atheros on Fri Aug 05, 2011 9:38 pm, edited 1 time in total.
User avatar
Ensayia
Party member
Posts: 399
Joined: Sat Jun 12, 2010 7:57 pm

Re: Support the request for improvements in packaging addons

Post by 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.
User avatar
kikito
Inner party member
Posts: 3153
Joined: Sat Oct 03, 2009 5:22 pm
Location: Madrid, Spain
Contact:

Re: Support the request for improvements in packaging addons

Post by kikito »

atheros wrote:(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.
When I write def I mean function.
User avatar
Elvashi
Prole
Posts: 45
Joined: Sat Jul 04, 2009 9:17 am
Location: Australia

Re: Support the request for improvements in packaging addons

Post by 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.
"We could make a program for doing this for you, but that is for the LÖVE IDE, planned to be released in March 2142." ~mike
Networking with UDP uLove Proposal CCG: Gangrene
User avatar
kikito
Inner party member
Posts: 3153
Joined: Sat Oct 03, 2009 5:22 pm
Location: Madrid, Spain
Contact:

Re: Support the request for improvements in packaging addons

Post by 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.
When I write def I mean function.
atheros
Prole
Posts: 3
Joined: Mon May 02, 2011 7:40 am

Re: Support the request for improvements in packaging addons

Post by 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
Prole
Posts: 3
Joined: Mon May 02, 2011 7:40 am

Re: Support the request for improvements in packaging addons

Post by 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
Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 4 guests