Bobvodka you will change your mind when it starts happening to you.
[=Bobvodka;297778]
I don’t think your point has any legs; blue prints are being used day in and day out by people, both in Epic and externally, only a small segment are seeing the engine crash with ‘pulling a wire off a node’ - a fundamental operation which if there was an easy to catch or easy to see problem would be showing up all over the place including internally at which point it would be a high priority fix because it would be hurting internal projects.
So clearly this is a corner case, a corner case being caused by something those who are experiencing it at doing but something that most people AREN’T doing and Epic ARENT’T doing internally either - which comes back to the ‘testing’ aspect; how do you expect them to test this when it is being used internally heavily and not showing up? More to the point, with the general call to ‘get all the bugs’ how do you practically expect them to test it? How long is ‘long enough’? Because however long they test it for they WILL miss things, heck heavy usage has apparently missed this problem, and so even if they tested for 6 months you’d STILL get bugs, heck you might even get this type of problem of appearing because the usage patterns of people are not the same as the usage patterns internally.
The fast release coupled with previews is the only reasonable way to test bugs on a large scale otherwise you won’t get the coverage because not is doing the same thing.
[/]
Two things to relate here.
-
This corner case might well be hitting hundreds or thousands of people. You’re lucky if you haven’t had a crash and that’s fine for you, but IMHO I think most people I’ve seen using the engine have had at least a few crashes in a working day. If they don’t I think they can feel lucky. You’re right it can never get to 0 bugs, but that surely has to be the aim? Or at least you have to try and improve the processes you use towards that aim. If you have a new tool that you can use that gives you 10% fewer bugs, would you not choose to do that? Epic can do the cost/benefit here of course, but I think we’re asking them to maybe err more towards the “more testing time” side of that analysis.
-
Your recognition that people are using the toolset differently than Epic is spot on. But that is kind of the point here. Epic’s guys are probably so used to the crashes and mines in the minefield that they simply walk round them by nature now. Everyone else is still treading on them. Do we just say “don’t tread on the mines” or do we actually look for them and remove them? Not to mention that Epic are now having tens of thousands of new people using the engine by their own choice, so I think changing some of their thinking about how they develop is inevitable (and lets face it, that’s what they are already doing, so we’re simply suggesting some new ideas to that direction).
My point is that Epic chose a new route with their engine and that requires a bit of a different mindset when it comes to QA and development. I can see them already dealing with some of those changes to be sure, but I think there are improvements to be made still. I’m not suggesting that there’s anything wrong, but that things can be improved if we don’t pretend that releases are more stable than they are. I’m assuming you’ve never watched a livestream where someone from Epic manages to crash the engine doing something pretty trivial?
I’m sure and can read this thread for themselves and distill any useful ideas from it. I don’t think it needs anyone defending the engine’s stability or the development/release process as it currently is. Critique of a thing is not always intended as criticism.
[]
Critique of a thing is not always intended as criticism.
[/]
Was it George Washington or Jefferson who said “Our ciritics are our friends, because they give us clues about our errors”… 
yep, im not saying these things because im a hater.
im trying to keep this topic hot because i want to use ue4 but i cant because of fundamental instability.
there is only so much you can take before you use a different engine, which i am doing, but i want to use ue4 in the future.
A blueprint stability push would be great - BP corruption is the single most frustrating thing I run into daily, and the primary reason I have started making all structs and helpers/macros C++. Even in 4.8p3 I’m still hitting BP save corruption errors - just last night I had the infamous ‘cannot save’ problem with a blueprint, which unfortunately happened right after I renamed the blueprint. Now there are BPs in the project with references to a BP that doesn’t exist (was never saved, due to bug) and cannot be replaced (because the engine still thinks the BP is there - and doesn’t let you manually delete references). Luckily it was just a test project, since I was using the preview build, so scrapping it was no biggie - but had this happened on my project it would have been catastrophic.
[=;296849]
If it would be consistently the same group, I would agree.
But there is some migration.
I, for example, used to belong to the “Well, it runs fine for me…” group.
If you look at some of my more ancient posts, I always ststed that UE4 runs stable, unless you do something silly/extreme.
That continued to be until around verson 4.5. There I got my first bluescreen with UE4. More followed, but still not that frequently.
It got worse in 4.6 and in 4.7 I see them consistently.
And I didnt to any different stuff than I did in the older versions…
So it definitely has changed a bit.
Today I made a test and deliberately saved, closed and reopened the editor in short intervals (45 mins). That greatly improved stability.
It seems there might be a subtle memory leak somewhere as well…
[/]
I was finally able to manage a repro of this extended use crash. I’ve entered a bug report, UE-16176 to be assessed by the development staff. It looks like what is occurring is that after doing intensive tasks such as building geometry/lighting, the editor is retaining most of the resources it was using during these tasks. It builds up over time (~7.5 hours) and eventually crashes due to using too much data at once. When I left the editor alone it didn’t have a problem, it was only when I performed a build that it seemed to be eating more resources. If you save and close before or just after resource intensive tasks as you said you should be able to avoid this buildup until we can find what is going on or if it happens in 4.8. I tested in 4.7.5 to get as close to your reproduction as possible.
Hi ,
Thanks for your efforts looking into this
[]
It looks like what is occurring is that after doing intensive tasks such as building geometry/lighting, the editor is retaining most of the resources it was using during these tasks. It builds up over time (~7.5 hours) and eventually crashes due to using too much data at once …] it was only when I performed a build that it seemed to be eating more resources.
[/]
Yepp. This matches my observations exactly.
[]
If you save and close before or just after resource intensive tasks as you said you should be able to avoid this buildup until we can find what is going on or if it happens in 4.8
[/]
That is exactly the workflow that I use. Before I build lighting on a larger level, I close the editor and build lighting first thing after reopen. That seems to work for now.
Cheers,
I am of the opinion that it shouldn’t only be a bug killing exercise but “fixing” basic functionality of the Application.
Functions sorely missing
-Undo Camera Movements
-Locking Camera (freezing transforms does nothing if you move camera in viewport)
-Separate Viewport - independent from Map Tabs
-Freeze Objects / Actors in viewport (so they cannot be selected)
-Hide skyboxes in viewport causes skylights to no longer work until lightbox is unhidden
But honestly… the biggest 2 from a workflow perspective (Camera movement Undo, Freezing Objects)
Edit: Forgot but was quickly reminded…
-Ability to move the mouse freely when ejected in PIE mode (currently only 90 degree movements are allowed so you have to unclick repeatedly to “roam” freely as you would normaly in the viewport)
-Ability to select actors when ejected… currently everything else can be selected except actors.
[=;299811]
But honestly… the biggest 2 from a workflow perspective (Camera movement Undo, Freezing Objects)
Edit: Forgot but was quickly reminded…
-Ability to move the mouse freely when ejected in PIE mode (currently only 90 degree movements are allowed so you have to unclick repeatedly to “roam” freely as you would normaly in the viewport)
-Ability to select actors when ejected… currently everything else can be selected except actors.
[/]
Hey ,
I tested this in 4.8 and I’m not able to see what you are talking about. I can select any actor within the level out of PIE and rotating the mouse seems to be working freely. Which mouse button are you using? They have two different types of functions depending on what you are looking for.
Hi .
I see in 4.8 preview i can rotate camera freely. I use R-Click and fly around with wasd. In 4.7.6 camera seems to be restricted to only 90 degree movements at which point you must unclick and reclick… but if its working 4.8 awesome
As for selecting actors i cannot do it in 4.8 either.
Everything except actors can be selected.
Its not too big a issue but if you want to get information from a specific actor you have to cycle through the actors in the world outliner which can be troublesome if you have 30 instances of a specific actor.
[=;300494]
As for selecting actors i cannot do it in 4.8 either.
Everything except actors can be selected.
Its not too big a issue but if you want to get information from a specific actor you have to cycle through the actors in the world outliner which can be troublesome if you have 30 instances of a specific actor.
[/]
Not sure, but sounds like this could be the simulate/resolution bug that was reported back around the time of 4.7? It still doesn’t seem to have been fixed. Go to Settings | ‘Engine Scalability Settings’ and ensure that ‘Resolution Scale’ is set to 100%. If that’s it, you can also uncheck ‘Monitor Editor Performance’ to stop this from being automatically reduced in the future.
+1 for increased stability focus, and c++ documentation too. I don’t need any more features, I already spend all my time trying to work out how the existing ones work!
Hey ,
I’m currently in 4.8 Preview 4 and I am able to select actors while I am ejected. I’m using the left mouse button to select the actor.
Hi .
Seems was correct. Once i set resolution scale to 100% i can select actors fine while ejected. Thx
“Quality of Life Improvement Release”…as in UPDATE ALL videos that are meant to teach us “how to”…update to a current released version so the video actually works.
The number of hours I have spent watching “how to” only to have some ‘menu’ or whatever NOT be there and I cannot continue. Thats harsh. I think some newer import character videos are necessary to say the LEAST. Importing from Unity, Blender etc. and how to get animations to actually work along with a proper skeletal how to. I have not once been able to get an external actor character to even begin to funtion in UE4.2-4.8. NOT one single time. I find and download my characters from Unity Store. Use Unity and Blender as I am not savvy enough to build my own. None of them import to UE4 correctly. Some help would be GREAT!!!
You can’t simply expect that characters from the Unity Store will work in Unreal Engine 4. They are designed for Unity, not for Unreal Engine, so they might use a wrong FBX file format or other stuff that UE4 does not support.
I think could be cool to set up trello/equivalent voting system, where Epic employees put up known bugs, and the community gets to vote on the ones they would like to be prioritized. Epic could use that as the base for their priority queue. (I say base because there are other variables to be concerned with than just the votes).
I am bumping this again because there is still too many issues in 4.8.0 even when some bugs were reported in preview stage. I hope Epic will focus now more on stability, and Q&A testing and 4.9 will be super stable.
[=SaviorNT;275534]
At this stage, it would seem appropriate to do a massive “Bug-Squashing”, existing tool improvements, and optimization release.
[/]
Yes, I would really appreciate that. The current state in terms of quality and stability feels really at the edge now, especially in terms of VR and Blueprint. I reported about 40 bugs in less than 3 months now but it feels like there are more issues than ever. I got about 20-30 editor crashes a day and since 2 weeks, VR is completely broken in the official release 4.8.0 for example (4.8.1 didn’t fix this). It’s obvious that this wasn’t really tested.
I know, UE4 is a insanely complex project but this can’t go on like this forever. So please take your time and focus on more quality. It will pay off in the future.
[=;295190]
When using blueprint it feels very odd/frustrating to have to handle things like structs or circular references with kid gloves lest your blueprint corrupt and force you to have to completely recreate it.
(…)
I have 3 class blueprints that no longer compile if I use them with blueprint function libraries unless I recompile the function libraries. No warnings, no other errors. These are base classes for my game and recreating them from scratch to fix an error that nobody understands or knows how to prevent again is a tough sell.
Editing a struct corrupts references to that struct about 20% of the time. No way to predict why, or how or when this will happen. The structs just disconnect and you suddenly have 5, 10 blueprints that won’t compile.
[/]
My god, this are exactly my problems, too. I thought I’m going crazy. So these are just another UE4 bugs. Hmm, should I feel releaved now…?
[=JohnAlcatraz]
The problem is basically that everything I try to do will hit a point where I can’t really continue due to bugs. So for example in my game I use a lot of structs which store information about almost anything, and structs did not work in 4.7 at all. So I could not run my game without getting really weird behavior. So I worked on different parts of the game where I don’t use structs, like the UI. So I created a nice UI, until I saw it looks way too ugly because the engine uses wrong MipMaps for the textures. And while working on the UI I want to see how it really looks, not how it looks with bugs. So I stopped working on the UI and instead worked on the trees. For trees I use Hierarchical Instanced Static Mesh Components, because they are made for foliage. But I saw that dynamically spawned HISMC won’t work, they only work if manually added as a component to a blueprint! So I could not continue working on this. So I moved to the Wall System, and since walls are destructible I also experienced a lot of bugs there and had to create a lot of workarounds to make it work. But it’s still buggy, my physics actors are falling through my landscape, I can’t use an object pool because setting locations of physics actors is not working correctly and so on.
[/]
Yep, that’s exactly what it feels. No matter what you do, some killer bug will stop you on your way.
[=;318193]
My god, this are exactly my problems, too. I thought I’m going crazy. So these are just another UE4 bugs. Hmm, should I feel releaved now…?
Yep, that’s exactly what it feels. No matter what you do, some killer bug will stop you on your way.
[/]
To be fair, from the outside looking in, 4.7 was a purely business driven decision. Start of GDC was a hard limit and they released what they had.
I don’t know about a long term stable release with only bug fixes for indies/smalls vs large studios.
I would like a release that all documentation is verified to 100% match that release and is complete for that release. But maybe that is a long term stable release im thinking about.