Codea 2.6.2 (127)

@Simeon I had to check Touches in everyone of my craft projects that used OrbitViewer. Also on some of them I had to uncheck Cameras and recheck it for the program to work. Not sure why only a few needed to have Cameras unchecked then checked again.

@piinthesky thanks for that, will change it

@dave1707 I’ll try to have the dependencies fixed shortly

@Simeon I didn’t mean you had to fix the dependency problem ASAP. I went thru all of those projects just to verify that checking Touches would fix them. I just hope you can come up with a fix for the listProjectTabs and other commands like it.

@dave1707 I have fixed them now. Hopefully dependencies will all just work next build. The new behaviour for read/save/listProjectTabs will be to look in the current collection if none is specified, otherwise you can use a fully qualified name to get an exact project.

E.g., if you have the following folders

Documents (default)
    My Project
    Foo

Other Projects
    Another Project
    Foo

If in My Project you do readProjectTab("Foo:Main") it will give you the Main tab from Foo inside the Documents folder. If you do readProjectTab("Other Projects:Foo:Main") you’ll get the Foo from the Other Projects folder.

Similarly if in Another Project you do readProjectTab("Foo:Main") it will give you the Main tab from Foo inside the Other Projects folder.

Build 124 is out with the following changes

• Dependent projects should be fixed up
• Dependent project dependencies should have the same fixups applied
• read/save/listProjectTab APIs updated to support fully qualified names
• If a name is not fully qualified, Codea will assume you are referring to a project within the same collection (e.g., Documents, Examples, Craft)
• Same logic applies to read/save/listProject
• AR Face example should correctly display tracking status on unsupported devices

@Simeon - thank you, the world is back in order.

@Bri_G great thanks for the confirmation that it’s working OK. Might send this one through app review so everyone else can get 2.6.2.

@Simeon - just found a funny one. When using fileapp after starting up, in the Codea app folder, only found 38 files (including folders). Later on, after using Codea, found 248 files/folders.

Also content folders did not display the file type in listing, asset folders did. So far looks like everything is there just not displayed.

Other feature, on the project files page in Codea, I have about 12 content directories. After the upgrade all the one the precede C alphabetically are not displayed and the project files that used to be there are in the general project list.

This is not a problem, I assume most users don’t use the .content folders to organise their files. Have you planned anything for this in the move to adopt the system filing system?

Xtra: just found another funny - the content folders listed on the Codea project page seem to be in random order and don’t respond to the recent versus alphabetic system settings.

@Bri_G the Files app does not refresh properly. The only way I’ve found to force it to refresh is to go into a different app’s folder then back into the Codea folder.

You shouldn’t need to use .collection folders any more, you can just use named folders to sort your files (i.e., no .collection extension).

Yeah the content folders are not properly sorted at the moment, I’ve got that on my list of things to fix. I’d like to allow custom sorting for them soon.

Latest build (127) fixes the Duplicate Project functionality

@Simeon ver(127) Project duplication works OK and filling in the name is OK also. Will try the list project functions as I get time.

@Simeon The read/save/list project functions seem to be working OK. The dependencies look OK also. I was able to just check Craft and Cameras as dependencies and not have to check Touches. The AR Face project displays Face Tracking Not Supported on older devices. Had to reload the examples to get the latest version.

@Simeon - thanks for the update sorting the content folders is low priority. Is there a need to alert Apple to the filesapp limitation?

@Simeon - in your drive to introduce the formal file addressing is there any chance that you could grant access to the photos app resources on the iPad? It could save duplication of resource storage. You can write to it so why not read from it?

Errr - I can’t see readImage() from Photos in the Codea documentation so I am assuming we don’t have that access.

@Simeon or anyone. What’s required to use the AR Face example. Apparently my iPad Pro isn’t new enough.

PS. I found it. The newer iPads have Face recognition.

@dave1707 - I think it’s for the new iPad Pro 2018 which has depth capability in the camera. Our Pros are old hat, ahhhhhh!!!

@Someon - just set up a new folder on Dropbox and can see the files there. Have synced it from within Codea, closed and restarted Codea. But - I can’t load any of the files. Does the sync call require anything new in the new filing system approach?

@Bri_G I am able to draw a sprite after syncing my dropbox by using sprite("Dropbox:SpriteName",...) what happens for you?

@dave1707 @piinthesky @Simeon thank you, I found it. Now the Working Copy app works perfectly fine :)) When I’m having more time next week, I’ll will test out the other new features of Codea

@Simeon - thanks for the reply, got your name right this time.

I have lotsa files in my Dropbox, normally after installation of a beta I have to resync - which takes ages (over 250 files in folders and sub folders). The sync with 127 was much shorter and only covered 75 files. Even so many of the apps returned to normal with 127.

My problem arose when I set up a project to entertain my 14 month old granddaughter. I wanted to have several pages with buttons on, icons and linked sounds. She loves pressing buttons and getting a response. So I downloaded a few free emoji images and set them up in a new Emoji folder in the Codea Dropbox root. Resynced and started Codea.

Tried to load a sprite with readImage(“Dropbox:Emojis/ThumbsUp”) and it doesn’t load the sprite and errors.

The images in there are jpg or png. I tried appending the filetype and (“Dropbox:Apps/Codea/Emojis/ThumbsUp”) with no joy.

I thought the existing files may have survived the installation to explain them running. I suspected the new sync not following the old sync procedure and falling down on new project data on Dropbox. I also wondered about file types and the true path with the new filing approach.

Sorry about the length/detail here.