splash screen bug or a new feature?

Hi all,

Since build 2017.3067, and the new upgrade on Xcode i had to do on mac, my builds crash on splash screen plugin. i usually have the image on a folder. i puted that image on the main path and the build was success. my question is, this is a bug? or a new feature that now the image needs to be in the resource path like the fonts needs.

regards,

Carlos.

Can you produce a test case where it fails and share that with me?

Do you know the last version that worked for you?

Thanks

Rob

Hi Rob,

it worked fine before version 2017.3064. On version 3065 when corona upgraded code for IOS 10.3 broke splash plugin.

my code before was:

splashScreen = { enable = true, image = "images/generic/first\_page.jpg" },

now to work it needs to be:

splashScreen = { enable = true, image = "first\_page.jpg" },

i tried in older projects i had that i never had this problem and all started to have this problem with the new corona build.

on pc i don’t have the problem only on mac and only when doing a IOS build.

the error it gives is: “ERROR: faild to copy splashScreen.image file: images/generic/first-page.jpg”

the file was on that folder “image/generic”, and like i said worked fine before upgrade Corona.

Engineering is looking into it, but we are having to try and duplicate the problem and we are not reproducing the exact problem. This is why having a demo project can help speed up our problem solving.  A zip file with your main.lua, build.settings, config.lua and splash screen in the folder causing problems that demos the problem would be really helpful.

Rob

Daily Build CoronaSDK 2017.3068 which should fix this is now available.  Let us know how it goes.

@corona, I know you guys are working real hard to push the framework forwards but you gotta ensure backwards compatibility.  A lot of posts here are “this used to work but now doesn’t” and this wastes everyone’s time.

All we want as devs is a stable platform with iterative improvements.

Hi @adrianm. We fully understand your concern, but this is how our development cycle works. We produce two types of builds, public builds which are rigorously tested with a focus on making sure “regression” bugs don’t make it into the next public build. In other words we shouldn’t regress between public builds.

Daily builds on other hand contain the latest features and changes. This can allow temporary bugs to get into a daily build, but they are usually fixed with in a couple of more daily build cycles. We’ve always encouraged developers if stability is important, they should stay with public releases. Developers using daily builds should expect bugs to creep in from time to time.

Rob

thanks guys for the fast fix. version 3068 resolved the problem.

Can you produce a test case where it fails and share that with me?

Do you know the last version that worked for you?

Thanks

Rob

Hi Rob,

it worked fine before version 2017.3064. On version 3065 when corona upgraded code for IOS 10.3 broke splash plugin.

my code before was:

splashScreen = { enable = true, image = "images/generic/first\_page.jpg" },

now to work it needs to be:

splashScreen = { enable = true, image = "first\_page.jpg" },

i tried in older projects i had that i never had this problem and all started to have this problem with the new corona build.

on pc i don’t have the problem only on mac and only when doing a IOS build.

the error it gives is: “ERROR: faild to copy splashScreen.image file: images/generic/first-page.jpg”

the file was on that folder “image/generic”, and like i said worked fine before upgrade Corona.

Engineering is looking into it, but we are having to try and duplicate the problem and we are not reproducing the exact problem. This is why having a demo project can help speed up our problem solving.  A zip file with your main.lua, build.settings, config.lua and splash screen in the folder causing problems that demos the problem would be really helpful.

Rob

Daily Build CoronaSDK 2017.3068 which should fix this is now available.  Let us know how it goes.

@corona, I know you guys are working real hard to push the framework forwards but you gotta ensure backwards compatibility.  A lot of posts here are “this used to work but now doesn’t” and this wastes everyone’s time.

All we want as devs is a stable platform with iterative improvements.

Hi @adrianm. We fully understand your concern, but this is how our development cycle works. We produce two types of builds, public builds which are rigorously tested with a focus on making sure “regression” bugs don’t make it into the next public build. In other words we shouldn’t regress between public builds.

Daily builds on other hand contain the latest features and changes. This can allow temporary bugs to get into a daily build, but they are usually fixed with in a couple of more daily build cycles. We’ve always encouraged developers if stability is important, they should stay with public releases. Developers using daily builds should expect bugs to creep in from time to time.

Rob

thanks guys for the fast fix. version 3068 resolved the problem.