It was exciting to see we could now have folders in our local assets because it gave me hope for having local Craft texture packs!
Having jumped through the hoops necessary to make a custom voxel texture pack (Complete Craft Texture Pack), it seemed like far too much work to make it worth doing again…
…but if a local folder could be used with the voxels.blocks.addAssetPack command, that might breathe new life into the whole thing.
Unfortunately I couldn’t make it work, as this code explains:
function setup()
assert(OrbitViewer, "Please include Cameras as a dependency")
-- Create a new craft scene and assign it
-- to main so you dont have to manually call
-- update or draw for it
scene = craft.scene()
craft.scene.main = scene
-- set up draggable camera
v=scene.camera:add(OrbitViewer, vec3(0, 20, 0), 40, 0, 2000)
v.rx, v.ry = 30, 45
-- define voxel space
scene.voxels:resize(vec3(5, 1, 5))
scene.voxels.coordinates = vec3(0, 0, 0)
vox = scene.voxels
-- three tests of loading asset packs
-- change commenting to choose one to run:
--test = "default" -- works like example projects
test = "custom" -- works but not self-contained
--test = "local" -- self-contained but doesn't work
if test == "default" then
-- this will work for anyone
vox.blocks:addAssetPack("Blocks")
local glass = scene.voxels.blocks:new("Glass")
glass.setTexture(ALL, "Blocks:Glass")
vGLASS = {name = "Glass"}
elseif test == "custom" then
-- If you make a folder in the main Codea folder
-- and call it "CustomBlocks.assets"
-- and copy to it the Glass sprite from the
-- Blocks.assets folder in the main Codea folder
-- ...then this should work (it does for me)
vox.blocks:addAssetPack("CustomBlocks")
local glass = scene.voxels.blocks:new("Glass")
glass.setTexture(ALL, "CustomBlocks:Glass")
vGLASS = {name = "Glass"}
elseif test == "local" then
-- If you make a folder in your project assets
-- and call it "TestBlocks.assets"
-- and copy to it the Glass sprite from the
-- Blocks.assets folder in the main Codea folder
-- ...then this will NOT work, sadly :(
vox.blocks:addAssetPack("Project:TestBlocks")
local glass = scene.voxels.blocks:new("Glass")
glass.setTexture(ALL, "Project:TestBlocks:Glass")
vGLASS = {name = "Glass"}
end
-- draw a line using block defined above
scene.voxels:fill(vGLASS)
scene.voxels:line(0,2,7,10,2,7)
end
@UberGoober - correct me if I’m wrong but - if you create say blocks.assets folder in Codea root and add your assets to that together with a plist file (and probably an icon.png with an icon@2x.png) you can access them from the assets folder. Shouldn’t they the be included in your exported project?
Not sure if this changed with the new asset addressing regime?
It sounds like you’re saying that files external to the project’s own local assets would be included in an export, and that’s not a thing as far as I know. Am I misunderstanding you?
I may be wrong but I thought any files recognized by the Codea file browser would be added to exports. That may have changed with the introduction of regular folder access, but I see the asset directories in my Codea file manager. I’ll check it out later.
@UberGoober - checked this out, read in a sprite and displayed it centre screen. Then checked out export options.
Copy code to buffer for pasting.
Export as a zipped Codea file.
Export as an Xcode project.
All went through the motions, option 2 was what I was expecting to save the assets but I found nod files at all in the unzipped project folder.
Option 3 save the expected Xcode package and I found the image in the assets folder there.
The dialogue for Xcode exporting has a window which gives you the option to include assets, which defaults to saving them.
Looks like we need a similar dialog option for exporting the zipped project.
@dave1707 could you. Check out this behaviour on the latest beta. I couldn’t also get the exported unzipped Codea file to open/share with Codea (not surprising really as the folder was empty - note Inhave tried this on my iPad not my Mac). Also I used readImage() and not a defined path to an image.
@sim - any chance you could include the export assets option in the save project in a zipped form.
@Bri_G I don’t do anything with Xcode or on a PC with Codea. I very seldom zip any files other then to post on the forum rarely. I don’t mess around with other folders either. My involvement with Codea right now is just what I can do on the iPad and what’s available there.
@Bri_G@Sim you can access almost every kind of asset there is in one of the three locations: the documents folder, the built in folders, and the local storage. It would be good if you could do that with voxel volumes, blocks, etc too.
I don’t agree that we need an option for including external assets on zip files. An option for including assets from outside the project makes sense for Xcode but it doesn’t make sense for zipped files, it seems to me.
In Xcode you’re working with a brand-new file structure that can be adapted to whatever the Codea project needs, but when you’re importing a zip file from somewhere else you don’t want it messing with your own documents folder. An imported file should stick to its own assets and the builtin assets only, it seems to me, or there’s just too much opportunity for mayhem.
@UberGoober - hmmmm. I’m afraid I disagree with you on the asset file inclusion with exported zip files. If you post on the forum code with a few novel assets that you used in their development but didn’t include on the forum then the user would have to provide their own assets.
Inclusion of assets with stored finished zipped files woul enable loading projects directly from remote storage and should be deleted when the project is deleted. That way you don’t rack up a massive load on the Codea memory allocation.
After all I was suggesting an option, which could be set to on or off, so that the user could decide - exactly like the Xcode option offers.
The precedent has already been demonstrated, in effect, by WebRepo where you can directly load a finished project with all relevant assets.
@Bri_G but the entire problem is solved if you can include any asset in your projects. Your solution unnecessarily brings up a whole pickle around overwriting assets of the same name.
@UberGoober - I don’t follow that argument as all assets downloaded with a project from a zip will contain assets in the root/documents folder. They should also disappear when you trash the project leaving your local assets untouched.
@Bri_G I have to admit you’re confusing me, sometimes I really don’t understand what you’re saying because it seems completely opposite to my experience. Maybe it’s because we’re talking about different use cases? It might be we’re talking at cross purposes.
So maybe just to restate: block-texture asset packs, unlike almost all other kinds of assets, don’t work from inside a project. They also don’t use the new asset-referencing system, they only work with the old-style strings with folder names and a colon. That’s inconsistent, and therefore possibly even a bug.
If they did work inside a project, or if you could address them with the new asset system, it would make the creation of texture packs a thousand times easier, which could open up a lot of fun options for texture packs—
—especially now that we can create subfolders in our projects. Before, it was impossible to create a folder called “MyFolder.assets” from within the asset browser—but now we can—but we can only do it inside a project—and that’s the very place we can’t load texture assets from!
My point is that it seems only logical to want it to be consistent, especially when it being consistent would also be more fun.
@UberGoober - we may have been confusing the issues and I am not yet confident with the new system - if so my apologies for any confusion I have introduced.
But, I have been setting up and using asset folders for years as I described in this thread - by creating a folder named e.g. draughts.assets and adding a bare info.plist file to it with an icon.png and an icon@2x.png to the folder. That enabled the use of those assets on the Codea asset browser - showing the images etc and allowing the inclusion of their asset path in code. I must have at least a dozen of them on my Codea installation.
I’d like to see a more detailed description of asset packs, their features and construction, in Codea from the recent introduction of folders - any chance on that @sim ?
@Bri_G well, OK, but I hope the fact that it has become a routine to you doesn’t prevent you from understanding how convoluted a process that is. If you haven’t done it a million times it’s a lot to ask, especially for newcomers. I hope it’s clear that to be able to do all that from inside the app, not having to jump back-and-forth between the app and the file system, would be great for people who aren’t used to doing it all the time.
And still, getting the whole voxel system on the new asset system would be a really good thing to do. It’s not just block textures, by the way, many (if not all) volume-saving-and-loading functions require the old “Documents:YourFileName” system. May it rest in peace one day.
