Dropbox Again

All - I have had repeated problems with Dropbox, but haven’t encountered them recently until I dug out and oldproject whilst testing 118. I modified my code to load files from subfolders within my Codea backup I.e. Dropbox:Folder1/Folder2/File. Problem is I have two files named the same with different file types like duck.obj and duck.mtl. This throws up errors when you try to load the files in your project.

I think it’s a Dropbox problem, I get errors from file managers if I try to copy the files into the folder reserved for them but I can copy a folder containing them into the first folder level. You can get round it by renaming the files but , in the above case, you also have to edit the files as one file effectively calls the other.

Not a great limitation - just annoying, but can soak up a lot of time chasing errors within Codea that dot exist or confuse the issue with the files your using.

@Bri_G I’d like to remove Codea’s explicit Dropbox integration in favour of allowing you to select and load assets from the standard iOS file picker.

You’d have to import the files into your project initially, then use them from there.

Is Codea’s craft.model failing to load a model when you have an additional file with the same name and different extension?

@Simeon - when I ran into the problem I had files which were in a folder in the root of the Codea app on Dropbox. They ran without problem. In a fit of tidying I moved many of theses folders into a single models folder and changed the addresses in the Codea loading project, that’s when I hit the problem - since Dropbox only has limited file recognition and the files are in sub-folders I think Dropbox can’t differentiate the files properly.

I have tried with File Explorer Pro to set up a sub folder by transferring the individual files - and it throws out an error when transferring them. Many of the models I have been using have files named like object.obj and object.mtl so I think that is where the clash is - Dropbox can’t differentiate them. I can modify the names, but it means modifying the addressing in the .obj or .mtl file.

Another oddity I have with Dropbox is that when I sync through Codea the icons in the Dropbox window disappear. Once re-synced you would expect the Dropbox resource window to be re-populated with images of the assets.

A further oddity is that - I can change 1 or 2 files on Dropbox but when I sync after counting it cycles through a greater number of files on the counter.

The standard iOS file picker would resolve some issues and tidy up the assets folder a little. I am not sure that it will deal with the issues described above. Would syncing occur automatically?

One other feature, just discovered, is if you re-sync Dropbox you have to reboot Codea so that the Dropbox changes are recognised. That explains the empty Drobox assets viewer after re-sync. I probably read about these before in the forum, but that’s what old age does for you !!!

p.s. digging through these older files has been annoying as they have dependencies in them which need renewing all the time with 118.

@Bri_G if you are on iPad you can install the App Store version of 2.6.1 which fixes the dependency bug.

I think we need to redesign how assets are managed for projects. I’m not sure on exactly what that looks like yet.