I am not sure if this is a bug or just me doing coding bad practices, but I will explain it anyways.
I use the same Splash Screen for all of my projects, so I have it in a dependency. The splash screen uses images contained in it’s own project assets folder; readImage("Project:Logo"). When I run the Splash Screen as a project it works flawlessly. However, when I run the Splash Screen as a dependency it will throw an error stating that img is a nil value.
I found 2 ways to work around this:
Run the Splash Screen project as a stand alone project once. This seems to load the images into Codea’s memory. After that, the other project that is using it as a dependency runs without an error. If Codea is completely closed, the error returns.
Instead of using Project Assets, if I put all the assets in Dropbox and use readImage("Dropbox:Logo") the error never occurs, even after restarting Codea. I would rather not do this, since it clutters my assets folder.
@exomut The project Storage is for the currently running project. Since you’re trying to read the project data from a dependency, it isn’t going to work. There isn’t any way that I know of to read the project data of another project. There’s always Global Storage, but I like using Dropbox for shared info.
@dave1707 Thank you for your quick reply! You’re right. The more I think about it, that makes sense, since the dependencies code is what is being loaded and not the whole project itself.
I am not trying to directly access the Project assets of the dependency. I want the dependency to access its own Project assets. However, since the dependency is being called from another Project `readImage(“Project:Logo”) is searching through the current project’s assets and not the dependency’s project assets.
It seems the reason I am able to have it work after the dependency is run as a project first is because the memory is not being cleared after the project is closed. I believe @simeon has already fixed that issue in the next release, so that “work around” will no longer work.
It would be nice if that was possible. I will just stick with using Dropbox Assets for dependencies. Thanks again for your help!
@exomut this is bad behaviour in Codea and due to me not thinking dependencies through
Going to have a think about the best way to handle this. I’d like to change behaviour so that included dependent projects always load from their own project asset folder (regardless of whether the including project has an identically named asset)
Ultimately I’d like to remove Dropbox and move everything to Project assets, with no more “global” asset packs (they’ll be there but using them will automatically import the asset into the project). Then incorporate support for the iOS File Picker so that you can choose documents from any cloud service
@Simeon Sounds great! I am totally for removing Dropbox and switching to depend more on the iOS Files. (I am not sure everyone would agree though.) I am syncing my Project folders into Working Copy, so it would be wonderful if I could just open the project from Working Copy!
You have a lot on your plate right now with Codea 3.0. Which I am extremely excited for! Being able to quickly test my Projects on an iPhone without building in Xcode first is going to be amazing in the Universal app. Keep up the good work and take your time!
I’ve modified Codea to recursively search for project assets in dependencies. This will be out shortly in v2.8
I can’t easily sandbox each project, so it’s possible to “override” assets from dependencies by having an asset with the same name in the current project
It’s will also be possible to explicitly specify a type of asset if you have two assets with the same name. E.g., MyFile.png and MyFile.jpg
You would refer to it as Project:MyFile.png to get that particular version. Dropping the extension will give you one of them but no guarantee on which
@exomut you should be able to go to the Working Copy location in the Files app and tap on a Codea project to have it open in Codea for editing
Currently however you can (1) for the dependency, with the first time it being run, you can save the project title, and (2) use readImage(projectTitle .. “:” .. imageDirecory). Or for (1), you can hardcore the name.
But still, from what I’ve read we can just wait for Simeon to fix it. Having a familiar problem currently.
@exomut - not quite sure if this was you were wanting to do but I found you can read data from dependencies if you include it in a function in the dependency.
Two files here trying to show this’ll:
-- BackDepend
-- Use this function to perform your initial setup
function setup()
— back = readImage("Falling:Sky_DV")
newBack()
end
-- This function gets called once every frame
function draw()
-- This sets a dark background color
showBack()
-- This sets the line thickness
strokeWidth(5)
-- Do your drawing here
end
You need to change the three graphic files and play with commenting to see what works and what fails. NewBack() loads the image from the dependency and showBack() puts it in for the background.
-- tab 1 on dependency file
-- BackDepend
displayMode(OVERLAY)
-- Use this function to perform your initial setup
function setup()
--
back = readImage("Falling:water_DV")
end
-- This function gets called once every frame
function draw()
-- This sets a dark background color
showBack()
-- This sets the line thickness
strokeWidth(5)
-- Do your drawing here
end
The second tab includes the called function
-- tab 2 on dependency file
--
function newBack()
back = readImage("Environments:Night Back")
end
function showBack()
--
sprite(back,WIDTH/2,HEIGHT/2,WIDTH,HEIGHT)
end
This could be a temporary measure until @Simeon introduces his changes.
I encountered problems with dependency initially having to close Codea to get it to work The new editor kept losing the dependency when running without closing and re-opening Codea.
Note: edited the sprite size in showBack() to fill the screen and newBack() function.
@TokOut@Bri_G Thank you so much for your help. I will look in to both of your ideas.
@Simeon I never knew you could open Codea projects from the iOS file manager. That’s so cool. I think I am using dependencies a little too much for my projects, new problems keep occurring. Opening from Working Copy works great, however it can only use dependencies stored in Codea’s directory and not ones stored in Working Copy. I will stick with Working Copy’s sync feature for now.
I noticed in Codea’s iOS settings menu, that you can choose Document Storage. I tried changing the storage to Working Copy and iCloud, but nothing seemed to change. What does that setting do?
I am sorry for taking so much of your time and asking so many questions. All of the issues I am having, have work arounds, so I can keep on working on my projects.
I really appreciate how helpful you and all of members on this forum are. Thank you everyone!
@Simeon Tried reading a project Asset using a dependency and it works fine. I also tried readProjectData with a dependency but that didn’t work. Don’t know if that needs to be done but it might be nice that what can be done from a project can be done with that project if it’s used as a dependency.
PS. Also noticed that Codea starts with displaying the Projects list and not the Reference, etc screen…
I wonder about that, because saveProjectData() would always save in the currently running project. But maybe it would be good behaviour to have for readProjectData as well
@Simeon I think save and read project data should save and read depending on the project they’re in. If project B is a dependency of project A, then any read and save functions in project A would use project A area. If the read and save functions are in project B then the read and save would use project B area even though they’re called from project A. I don’t know if that’s possible or not.
@dave1707 unfortunately not easily possible, which is why I implemented this for assets by checking “up the chain” if it wasn’t found in the current project
Basically the way dependencies work is that the code is executing as if it is part of your current project. What I would need to do would be to set up a sandbox environment for each dependency — I think this is something we should do, but it’s definitely a design and engineering overhaul of how projects run and will take some time
@Simeon I thought it would be a problem separating the two, but thought I’d ask anyways. I don’t use dependencies for anything I do so it’s not a problem for me.