Improve support for assets inside project folder

readImage, saveImage and sprite all work using the undocumented (AFAIK) form "Documents:projectname.codea/imagename".
Exporting to XCode will even correctly create an AssetPacks/projectname.assetpack folder with the relevant images - though haven’t tested whether the code runs fine without modifications (any volunteers?)

This feature of having assets live within their relevant projects is a sensible thing IMHO (especially when one takes full advantage of dependencies).

But I’d like to know the community (and TwoLivesLeft’s) opinion on the matter, and (assuming we all agree that it’s a desirable thing to have) on these enhancement proposals:

  • spriteList currently does not work with the aforementioned “hack”; it should be allowed. (The spritepack parsing only understands “Documents” or “Dropbox”, so apparently the hack relies on Codea believing that projectname.codea/imagename is a valid _file_name (sans extension). But then it’s weird that XCode exporting works so nicely…)
  • sound and music should also work with files stored inside the .codea project folder
  • there should be similar APIs for sounds: saveSound(filepath, data) (it should be smart enough to distinguish between “raw” soundbuffer objects and .wav/.caf bytestreams), readSound(filepath) (which would return a soundbuffer object), and soundList(folderpath)

The reason for all this is that I’m trying to integrate asset management in xCodea, but there’s no sane way to do that at the moment; xCodea cannot create .assetpacks, just like it can’t create projects, as there’s no programmatic way to make folders from Lua; I’m not sure such low-level functionality would be a good fit for TwoLivesLeft’s “mission” of a simple, intuitive API (which I fully agree with).

My personal opinion on this is that TwoLivesLeft should just ship lfs and luasocket - and possibly some other library - in Codea, leave them undocumented so that only the sanctioned, elegant and easy-to-learn API is exposed to regular users, but let power users get horribly burned - with the nice side effect of creating awesome Codea tools for the community in the process.

@lowne @simeon has talked about allowing assetpacks for each project. I would expect we would see that in a future update.

luasocket has also been discussed. I’m hoping for that as well :slight_smile:

@lowne I agree on lfs and luasocket. Though I’d still like to document lfs.

I’ve been thinking about the API design for project related data for some time, as well as the extension of spriteList towards generic assets.

I think it might be better to deprecate spriteList and introduce assetList with the following API:

assetList( location ) -- list all assets at location
assetList( location, type ) -- list all assets of type at location
assetList( location, type1, type2, ... ) -- list all assets of types at location


Where type is one of "sprite", "sound", "music", "shader" (+ whatever future types are introduced).

The same goes for `saveSound` / `readSound`: I'd *like* it to just be `save` and `read` (or `saveAsset` and `readAsset`), and then figure out the format based on the value passed.

Relating to project-stored data, I've added support for "Project" to `spriteList` in the next version (so you can do `spriteList("Project")` to get a list of assets in the currently running project's folder.

@Simeon yay for lfs and luasocket!
(also I’m glad about spriteList(“Project”), although it won’t help xCodea asset management - since xCodea itself is the currently running project :slight_smile: )

Totally agree with unified asset APIs.
How about this for maximum consistency (and code-assist-fu):

readProjectTab(loc)    -- done
saveProjectTab(loc,data) -- done
listProjectTabs(loc)    -- done - returns string array

-- intermission (if lfs doesn't happen, these would be sweeeet)
listProjects()    -- pretty please? ;)
createEmptyProject(loc)   -- ....pleeease? 
-- /intermission

readAsset(loc, type) -- filter for safety and code clarity (perhaps unnecessary?)
listAssets(loc, type) -- in order to return a naked string array 
-- (and given that extensions are banished), 
-- type filtering has to be mandatory?
-- (not that I see any downsides)


:smiley: always wanted LFS. I’ve made a project that’s unbearably close to creating a Codea project via code, but I needed LFS for the final step.

As for sound/music saving, that was the first thing I did after Codea 2.0, it can easily be done with file IO. Just wait and see for Sky Assets. :wink: