I figured I would add my two cents, I’m new to Unreal… I’ve only been learning it for a few months now. I have an extensive programming background, so the C++ problem isn’t that big of a deal for me.
For me personally, (and these are pretty nit picky), I would like to see Epic focus on improving the reliability and stability which was mentioned in the OP. I have had countless times where I try to add an asset to a level which is much too large and the only way out is to wait for hours for it to load or end task. Yes, that is my fault for not looking closer at the asset to see exactly how large it is (Looking at you open world demo assets :P), however I really think something as small as adding a cancel button to the asset loading screen would go a long way.
The last thing I’ll gripe on is nit-picky too :P. It goes hand in hand with the versioning system. I personally believe Epic should differentiate between their released builds. They need a stable and a latest branch. Perhaps stable builds are only pushed every 6 months and a latest build could be pushed once a month. Along with this though it would allow for much more consistent documentation. I really love what Epic is doing with their Youtube channels, but I think some of that would be greatly benefited from converting to words too. By leaving documentation updates for only stable releases I think it would be less of a chore for Epic to keep up with.
One example of that last part is the mounds of threads in the ‘Blueprint Visual Scripting’ topic related to basic networking alone. I think a lot of confusion could be eliminated with a little more thorough documentation. That said, there are great external resources and ‘compendiums’ on the web which fill this void for Epic.
Anyways, those are the two small things I have noticed thus far.
At the end of the day, it really is a treat to use Unreal. The pricing model is just fantastic and Epic genuinely seems like they want people to succeed at making games.
I’m using master branch of engine on my project (switched from promoted recently).
If you are not not modifying engine code directly, it makes sense (at least for me). Yes I have issues as master branch have latest and untested code, but on the other hand, maintaining my own code is easier. Since I don’t have to make big changes every release (when there is a lot of changes at one time).
You have to be aware that VISUAL forced you to upgrade, not UE4 ? Right ?
I mean it’s not even true, it didn’t force you to upgrade, but when you upgraded Visual, there is no way in hell UE4 could have worked. You can’t release a software and make it future-proof because you’d have to be a godamn psychic.
I have made minor projects only using blueprints but in few bigger used little c++. I am not experienced c++ programmer, but no big problems. Some engine problem with 4.11 and 4.12 and i can’t change my shooter project which has made 4.10 to 4.12 because it crashed. but it is better than Unity, not perfect but can any game engine be perfect
AH So Version 4.12 crashes all the time as soon as I open up the particle emitter editor and soon as I change one number in
the particle emitter settings, CRASH goes down the editor every single time.
Because of this I can’t set up my tripmine in 4.12 because it uses a particle emitter.
So 4.12 crashes soon as i change a setting in that particle emitter editor.
And when I open the emitter editor up in in 4.8 lo behold, it stays up and don’t crash at all when I change
the emitter properties .
I never had this kind of trouble with the Red Engine, you could copy any game assets anywhere you pleased
to add it into your projects before doing your packfile and red wouldn’t have a problem packing it
and running it or loading old files
But This engine, has been coded back to front. You can’t migrate certain files if engine versions are not
exact or higher. You can’t copy files like you can in windows normally to transfer files between assets.
this engine requires you to do things backward through file dependencies, and jump through all the hoops
of China to try to get it working. The engine always breaks something sooner or later even when you upgrade.
people losing blueprint files if theres a major crash with the code, It’s ridiculous. And even the hud editor
doesn’t even have any pages for putting your dialog on if you want to have introductory dialog
and its only got one page to do your hud screens on by the looks of it., forcing you to keep on creating
multiple hud blueprints.
We never had all this trouble with Red, with red, you make all your level with the editor and
then PACK save and run and play and have a map finished within a few days to a week.
But Unreal is taking A YEAR OR MORE because of all this engine probs people are running into
is why its not very user-friendly.
Let me guess. Now you have two copies of health blueprints, and your ammo blueprint has just been overwritten and you lost the ammo blueprint.
What if you had 200 meshes in your level all with Null static lighting Errors on 20 of them or 50 or on all of them and then you gotta go through each one to individually fix. We never had this kind of trouble with Red. With red you just hit the combination keys to build the lighting, and and it renders it. But Red only had a few basic shaders in it so lighting was very fast… But this engine has got advanced shaders in it so it takes HOUR OR LONGER for lighting to all calculate and with that come in all the troubles with meshes fussiness from the engine but underneath all the nice graphics, the code is brittle, its all in millions of pieces, and shatters quite easily. So you really need to know what you’re doing in this engine because its fragile.
So my tripmine weapon now all works fine in Version 4.8 but now there’s no way for me to migrate that over into my project which is in 4.12 and its all thanks to the particle emitter editor constantly crashing the engine in 4.12 to prevent me from setting up the laser particle emitter for the laser tripmine so I had to set it all up instead in Version 4.8 which is ALOT MORE STABLE with the emitter editor than Version 4.12 was. but now the laser emitter is now marooned outside my project and I can’t get the particle emitter object now into my project. All I need to do is only migrate the particle emitter settings for the laser over into 4.12 but it won’t do it.
That is a time where you really wish the assets would just transfer over into a higher version of the engine instead of saying, cannot
import uassset, this file format is not supported.
How am I supposed to fix up the file redirectors folders so it recognizes the 4.8 uasset file that I want to migrate? because its not showing up in 4.12. even when I select 'fix up redirectors in folder. If I go ‘Show in Explorer’ in 4.12 then go to the 4.8 project folder and then try to drop it into 4.12 you get the "unable to import, unknown file extension error uasset.
This engine is beginning to sound like a "DEAR HENRY, DEAR ELIZA problem to me’ with the file assets not being backward compatible even though they are using the uasset format.
Great, so does that mean there’s no plan c
if migration from an old project into a new project fails (project just falls straight out through the big hole that’s in the bucket) then all your assets remained all trapped and sealed up forever in the old engine version stuck with all the bugs.
always use deprecated on an intermediate release when changing C++ functions.
In the last release OnHit(AActor* OtherActor, UPrimitiveComponent* OtherComp, FVector NormalImpulse, const FHitResult& Hit) changed to OnHit(UPrimitiveComponent* HitComp, AActor* OtherActor, UPrimitiveComponent* OtherComp, FVector NormalImpulse, const FHitResult& Hit)
so everyone who used that function could not compile anymore, if there were just an additional function with the old one deprecated it would work out.
Remove Fix objectredirect, really what’s the point in that? Directly move and update all references would be far better.
remove .uassets when not necessary, additional metafiles would be better
Probably 99% of Engine would be deprecated then I guess.
What do you expect when changing the engine version? Stick to one version and you won’t have problems like this.
Right…so Unreal is a big fluffy bunny that does pathetic tiny little hops. That is what it means by migration huh. one tiny little teensy weensy hop at a time instead of being able to do a big jump to get the project into the latest version. Not only is that a huge massive waste of my limited bandwith having to download all those engine versions just to do the hopping, its also very inconvenient.
