@Simeon - oddity here, ran Codea and updated Dropbox assets. Returned to options screen then tapped to get projects list. The screen refused to respond to touches - couldn’t load a project. Had to drag up to close Codea. Restarted but still same problem, then tapped on new project and got the usual response. After that ran OK. Suspect it may be related to an issue with Dropbox.
@Bri_G I’m running version 252 and haven’t had any issues at all. I wonder if the problems are related to the number of files you have. I think you mentioned in another discussion that you had a lot of files.
@dave1707 - yeah, I alluded to that in the post. Probably limitation on numbers - hence suggestion of mapping or paging
@Simeon - @dave1707 - a demo I have been putting together recently uses files from Dropbox. Most of those files loaded without a problem but some didn’t. I suspected it was a fault in those files. After playing around moving files etc I discovered that the problem is path length. Dropbox claim they have no limit - so, is there a limit within Codea/iPadOS?
Also, the asset system effectively abbreviates the true path - is there any way to measure the length of the true path from within the system?
I was getting errors that there was an asset problem - this has probably been there for some time.
@Bri_G What is the name of your longest file you were having trouble with to see how long it is. Maybe there’s a 256 byte length limit on the total path. I don’t know and never ran into that problem.
@dave1707 - the path was made up of a path link and folder then file from array like:
path = asset.documents.dropbox.modelShip mod = craft.model(path[dir[num]data[num])
where dir is the directory of the file and data is the actual file name drawn from the two respective tables
With folder name of shipVersion01
But I had to put the text in the data filename as
As I have mentioned before with the problem of not seeing the file unless textual filename formatted as above. It works with shorter files. Taking about 8 or 9 characters out of the dir and data text by renaming gave a positive result.
@Simeon - couple of reports sent via crash reporting system. Both related to trying to change skybox. Think I solved it by using collectgarbage() in the draw() function. Seems a little messy - is their a more specific way of doing this - something like entity.destroy() ?
Hi All, just thought I’d post this. Just installed iPadOS 14.4 and started up my iPad. Loaded Textastic to load a web page and it crashed. Reminiscent of the Codea loading a project after first installation of new Codea version. Is this an iOS feature??
@Bri_G Codea always crashes the first time after loading a new version. I haven’t had any other apps crash after loading new versions. I don’t use textastic so I can’t comment on that. I’m also on iOS 14.4
@dave1707 @RonJeffries - not sure if it is something you have changed Ron, but the last 4 or 5 posts on your website were a little problematic. Managed to get them down but the download button was on a much larger window than normal and on one occasion the background to the button had a miniature version of your web page in it. Also having processed the share your web page vanished from Safari. Seem to think it must be with the latest iPadOS update 14.4 - supposedly a security fix.
I’ve not changed anything. Could you send me pics of what you’re seeing? No one else has mentioned anything like this to me.
@RonJeffries Loaded your latest version to try it. I’m on an iPad Air 3 and in portrait mode, the princess health box is off the left edge, barely visible. If I switch to landscape, the princess health box covers the direction arrows. Had no trouble playing the game or downloading it.
Here are pictures taken of the download dialog with enlarged windows, one having a mini screen in it. Dung73 is not linked, 74 has the background image and 75 to 79 had the enlarged window seen in tithe images.
@dave1707 - were you running with iOS/iPadOS 14.4 when you saw the issues above.
@Bri_G I’m on 14.4 . The Codea crashing on first run has been happening for the last couple of releases, so that’s not an iOS 14.4 issue. The Dungeon issues are because it’s not coded for the different sized screens. I believe @RonJeffries codes on an iPad Pro with the bigger screen. If I run it on my iPad Pro in landscape mode, the health boxes for the princess and enemy are OK and don’t overlay the direction buttons. So the games is OK. If I run it on my iPad Air with the smaller screen, then the princess health box is partway off screen in portrait or overlays the direction buttons in landscape mode. I don’t like using the iPad Pro cause it’s too big for the way I code (I hold the iPad while I’m watching TV) and the iPad Air is just the right size. So I don’t think the link you show are causes in the Dungeon code. I didn’t read all the way thru it, so if there’s something specific, let me know.
@dave1707 - The first image with the miniature of the link page is a major change, the download button very small relative to what I have seen previously. But the link said the there were UI changes and issues - that was my major concern in case conflicts with Codea and 14.4 were occuring.
On the game front on my iPad pro the graphics look larger than previously.
@Bri_G I kind of ignore things that are different unless they affect something. I just assume they’re iOS changes and there’s nothing I can do about them.
@RonJeffries I downloaded your latest code and made code changes for me. I changed the code so the direction arrows were based on width/2 (+ and -) and moved them a little lower. I also changed the health boxes to be based on width/2 (+ and -) and moved beyond the direction arrows. Now on my iPad Air, no matter if it’s in portrait or landscape mode, the arrow keys and health boxes are always placed correctly on the screen. You should probably do something similar in the code you post. The game is now easily playable.
i gather you’re both long-pressing the D2 link, to get that popup. i’ve not changed it, it’s just a plain link to the zip. tapping just brings up the dialog. gotta be some ios thing.
both, good ideas on the buttons. i’ll be passing that way soon.
i have no real understanding of how codea sees the different screen sizes. is there something written up that you know of?
thanks for feedback!
@RonJeffries - if you are using on different systems you need to check the WIDTH and HEIGHT then adust accordingly. I started a list of different models and screen sizes, but not kept it up to date. Should be available to all as a dependency.
Yes would be nice to have. I guess it’s a moving target as new models come out, but it seems like for some targets you need to really pre-plan what’s going to happen. And it has to be dynamic at least between landscape and portrait.
I guess I should at least support the sizes you two have.
Maybe I’d be wise to use a square subview for the dungeon, and reserve left or bottom for controls. Does that sound sensible? What might be better?