@jfperusse - this is for latest version, just installed. When in editor mode, tapped on Assets in right hand menu - provides a list of projects, examples etc - great. But, there are four texts displayed at the bottom of the list saying ‘Built-In’. They don’t respond to touches so I assume they are redundant ?
Hi @Bri_G,
Would it be possible to share a screenshot please?
I tried on different devices here but everything seems normal and I only see the Built-In category once.
Thank you!
@jfperusse - here is a photo. I just noticed that there is a ‘Built-In’ entry in the previous version after the external resource download packs but above all other assets present on my system. That is present in the current version but in the photo attached you can see there are 5 entries at the bottom of the assets list.
Edit: just looking at the folders I have in my Codea root. I have five folders with just a name and two folders with name.asset - all providing assets for my projects. I understand that this version accepts name.asset, apart from the naming is there any other added features to the Codea system naming of folders like the old files used to have an icon.png and an icon@2x.png and a text file present list.info ?
1 Like
@jfperusse - another thing I noticed, may also have been in the previous version, is that the two icons in the top left of the editor are often faded when a file is first loaded. They both function properly - it’s just the appearance.
I’m sure this has been mentioned before but - when you attach an image to a project for the project icon, the icon doesn’t appear initially but does appear when the project is re-run.
Bug: spriteSize no longer returns the number of pages of a PDF. The third value is just nil.
Interestingly, I can still detect a PDF by testing:
local w,_,_ = spriteSize(readImage(<asset>,1,1,1))
if w == 1 then
-- asset is a PDF, or just happens to be an image of width 1
end
I’m not sure if this is the intended behaviour, thougj, so I’d rather not rely on it. What’s happening here is that the presence of the fourth option on a non-PDF asset causes it to ignore the specified width and height.
But also this only helps with detection - to get the number of pages I’d have to loop through until I got a nil from readImage which means loading in mulitple images and this gets quite memory intensive.
1 Like
Questions about require:
- does it handle nested requires (so a
requirein a file that’s been required)? - Can it load into the local scope, or are all requires global?
- If a file has already been required into the current project, and it is requested again, what will happen?
1 Like
On spriteSize: Good find. I will look into that and see if it can be fixed for the next build
On require:
- It should do! But please let us know if not
- It works exactly the same as Lua’s
requireinternally, except it maps and reads the asset key. Basically we call Lua’srequire, and our version ofrequireis actually written in Codea Lua - I believe it will be ignored. Same as Lua’s require since it uses that underneath (it keeps track of required paths and does not re-require them)
Found the bug with spriteSize, thanks so much for the report. Issuing a new build of Codea 3.9.10 now with the fix
Excellent! Thanks for the quick fix - I have a PDF manipulation program that I use a lot for work so it’ll be great to have that working again!
It might be related, but readImage is behaving a little oddly with PDFs, in that readImage(<pdf asset>,10,10,50) will return an image even if the PDF doesn’t have 50 pages, but in those circumstances then readImage(<pdf asset>,nil,nil,50) will return nil.
I suspect that if the width and height are specified then Codea sets up the image and so even if it fails to get a page from the pdf then there’s still a (blank) image to return and it doesn’t notice that the rendering failed.
Thanks - I’ll play around with require and see what happens. In short, I’m wondering if it is now time to retire toadkick’s amazing cmodule library in favour of it.
I have fixed readImage for the next build so that:
readImage(<pdf asset>,10,10,page) will return nil when page is out of bounds
1 Like
Thanks @Bri_G, next version will include a fix to exclude these which are likely empty project collections on your device.
@jfperusse - just picked up another issue with the ‘Built-In’ extra lines - the addition of named folders in Codea root also adds a line to the the bottom of the project list in the main Codea window. The ones with the > symbol at the end of the text which switches to a v when the line is touched. They are used for tidying up the Codea main window by dragging projects to them which on release are moved to the folder and out of the icon list of projects on the main Codea window. Will your mods make these lines disappear too ?
Hi @Bri_G,
My change would not impact the main project selection screen.
It would be normal for folders added to the Codea root to be visible in the project selection screen to allow you moving your projects there.
However, if you are not seeing the folder name that would be an issue. If so, please provide a screenshot, and maybe check if you have some special characters in your folder names.
Thank you!
@jfperusse - thanks for the update all in order now.
@jfperusse - not sure just when this happened, I think it occured over the last two updates - when trying to share between pads by long pressing on a zipped project Codea is not in the list of apps either the initial horizontal list or the vertical drop down list. I’ve been using the sharing quite frequently recently.
1 Like
@sim Any idea? Could this have been removed part of a cleanup?
Codea is still showing up for me in my share sheets. @jfperusse if you long-press a zip file in the Files app, and share it, does Codea show in your list of apps?
@sim Actually, it’s also showing up for me properly.
I made sure I had the latest beta, launched it, then I went to the Files app, long pressed a zip file, tapped on Share, tapped on the “…” button to view all the available apps, and then tapped on Codea, which properly opened Codea and asked to import the project.
@Bri_G Did you try restarting your device? Maybe it’s an OS bug…
1 Like
Aaah guys,
Think I’ve found the problem. The zip file I was trying to load didn’t have the usual icon. It just had an icon with a question mark on it. Tried a few others with the usual zipped icon and they worked.
Looking further, I noticed a few other folders which should have the normal folder icon on them. They were just ordinary folders, but they did open when tapped on and gave me access to the files inside. Which were useable.
Looks like this may be an iOS issue, haven’t seen this before. I’m using the latest iOS version and the latest Codea beta.
Edit: I think the ? on the folder which opened OK was due to me naming it in the form folder.assets. So iOS doesn’t know what it is to provide the folder image. Not sure how that works with a zipped folder.
1 Like