For my opinion this issue is critical / block and should be fixed ASAP.
So basically we need to wait for 4.8 to ship / make games on Android? How we can open levels with this issue not being fixed? From what I see Mobile for Epic is low priority unfortunately you guys will lose indie mobile developers quickly (those which don’t have programmer that can fix those issues before Epic did)
I can not remember properly, but I think I was trying to avoid a nasty UMG bug, so I branched to 4.7 in hopes it was gone. Then I did a lot of stuff and my Blueprints are not compatible with 4.6 anymore. So I’m locked in 4.7.
I haven’t even upgraded to 4.6, so I can’t share thoughts on your specific problems, but I agree on the amount of work that still needs to be done for mobile (I don’t know about Apple/iOS, but Android definitely has serious problems that need to be addressed asap)
I did think about using any other Engine, but at the moment I’m just hoping that Epic will fix things in the near future … (Especially as I’m “just” using 2d graphics with major problems )
Do you need 4.7?
For development, as opposed to experimentation, I would think to regress to 4.5, or even 4.4 or 4.0, and find a version of UE4 that works. Older versions are more likely to be stable and functional enough for most uses.
And it would be nice if Epic would focus more on mobile support.
As for blueprints, is there a way to print the diagram out? Such that they could be rebuilt by hand, quickly, in another version of the engine?
I am just wondering, as it appears that I will have to freeze my engine version in order to get work done, so as to release a working project.
There may be a need to manually translate an old blueprint into the latest, greatest version of the engine.
I share your feelings about the mobile support. And even though it’s a bit off topic I need to say I am a bit disappointed with the progress over the past two months, I expected more. I was planning to get serious with mobile around December, but at this point it still feels unstable and support for devices isn’t ideal. I hope things will get better soon, cause I am mostly interested in deploying to mobile, therefore I may find myself forced to consider another engine :(.
Have you posted your problem(s) on the Answer Hub? I realize it can be frustrating to not get an immediate fix, however, this is the best way to make our developers aware of the issues mobile developers are experiencing. One problem is Android doesn’t run the same on all hardware so when the engine is in testing, there may not be problems on the devices tested here vs the device you are deploying to.
Our goal is for every official release to not have any issues which would block users from development or deployment. If an issue is found, we work as quickly as possible to remedy it with a Hotfix or QFE. However the Master branch from GitHub (4.7 at this point in time) is under heavy active development and should always be considered as an unstable release. We strongly discourage anyone from pursuing active development out of the Master branch, and if you do decide to test your project on the Master branch, please always ensure that you are only updating a copy of your project, and not the original.
Thank you for reporting the issue that you have discovered in 4.7. We have observed some long load times, but not on all Android devices. The scope of this is being investigated.
Currently older devices like Samsung Galaxy S3, S3mini etc. got very “very” serious problems. I can open and play my game on ASUS Fonepad 7 but on Galaxy S3 mini, it looks like a 1997 game with whole lot of flickering, crashing, graphic issues beyond your imagination.
But anyway, Epic really should look into mobile gaming a bit more. Lots of the features of Unreal Engine looks like “we have it…” rather than “it’s functional!” . Better performance on wider device range, more tutorials and documentation about making games to mobile, google play, in app purchase tutorials etc. We need these. And please… please…PLEASE, make player control input axis be directly bindable to UMG Widgets. In player controller, I am bound to that awful virtual joystick. No input axis can be binded to UMG buttons.
Yeah, I could see how that’s going to be a giant pain. I looked at how the existing slate virtual joystick is implemented, it looks like we need a better solution there. Currently it fakes the input by messing with UI focus and then forcing Slate Application to pretend new controller input is coming in. I think instead we’re going to need a Blueprint accessible calls at the player controller level that allows you to set the state of the input directly. Will ping the framework team for their thoughts and see if there’s some improvements we can make here.