I know people who work for Epic on the engine, trust me when I say they are using the same thing as you guys code wise and Titan-X are by no means ‘standard’ across the company; desktop machines are running NV cards but it isn’t Titan-X across the board - at best people will be running 980 cards, many probably on the generation before that, a select few get the shiny new stuff and they are likely limited to the Cary office; the UK/EU guys won’t be running them for example.
[]
Indeed the fact that some of you are hitting problems that others aren’t seeing does, for me, make the whole ‘stability/zero bugs’ thing somewhat unworkable.
[/]
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…
[=;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…
[/]
Its not even that simple. I’ve seen people crash the editor by simply dragging a wire out of a blueprint node. Reload the project only for the editor to say the blueprint they were working on is corrupt and cannot be loaded. I’ve seen others where a blueprint wont compile, but the project will still run without the compile, but of course the student isn’t able to fix a minor issue with that blueprint now. I’ve seen blueprint nodes being replaced with REINST_ nodes after a crash and become unusable.
This isn’t edge case seat-of-your-pants stuff. This is a bunch of students making some blueprints work. Sometimes I can help them, sometimes the only option is to redo the work. Sometimes they can roll back versions (if they use source control as they are instructed) but sometimes even that doesn’t work for some unrelated reason.
I know its a complex system, so there are very likely crashes. I can kind of live with those edge case crashes that live in the least travelled parts of the engine/editor. I really wouldn’t feel bad about something like Phat crashing every once in a while. But anything related to the core workflow, like blueprints, like making and adding/removing/moving/editing objects should be rock solid and reliable. Loading and saving similarly so. Which is why I go back to the feeling that there’s a fundamental bug somewhere within the engine that happens in semi-rare circumstances. A bit like the blueprint circular references etc. I guess at this point I don’t trust blueprints, which is kind of a problem given everything is blueprint-centric in the editor.
But the ball really is in Epic’s court in this situation. They are realistically the only ones who are going to be able to debug something as core as blueprint bugs. What I’d like to see, maybe, is a bit of transparency about how these bugs are handles, about regression, coverage, functional testing on the engine etc. I’d love to see some documentation on the core build system and especially the blueprint build/serialization setup, because right now I’ve got nowhere to point the students to for more information on how to fix their bugs beyond normal C++ debugging practice.
I guess this is all a long term issue though. Worth having an open chat about it.
[]
I’ve seen people crash the editor by simply dragging a wire out of a blueprint node.
[/]
That even gave me a bluescreen once . :rolleyes:
[]
. Which is why I go back to the feeling that there’s a fundamental bug somewhere within the engine that happens in semi-rare circumstances. A bit like the blueprint circular references etc. I guess at this point I don’t trust blueprints, which is kind of a problem given everything is blueprint-centric in the editor.
[/]
From my expierience, the BP system does not take too kindly on changing variable types etc.
If you are not following the exact ritual of:
-Unwiring all pins of that variable in use
-Change the type of the variable.
-Recompile the BP
-Refresh nodes where still neccessary
-Rewire again
If you follow that, it works, if not, you are playing Russian Roulette and each time another round gets added to the drum…
The same goes for:
-Create a struct
-Create a variable of that struct and fill it with values
-Change the type of one of the struct members
Sometimes the variable of the struct is just “blank” again, no values stored.
But again, it sometimes crashes the editor.
I havent made extensive tests, but this seems to happen only if the former type that was changed from was “pointer style” like a mesh or material reference.
If it was just a float or int, etc, its usually ok…
This makes iterations, especially for beginners who fiddle a lot, extremely “difficult” 
I think you all know that I have experienced a lot of bugs with UE4, and almost every day I find new ones, but being honest, I have to say that blueprint corruption was never really a problem for me, which seems to quite strange after reading what describes. Once I had a corrupted blueprint in 4.5.1 if I remember correctly, but taking an old version out of the autosave folder made it work again. Apart from this one time, I never had blueprint corruption. And I’m really using a lot of blueprints. Of course I saw a lot of REINST Errors, but they either were caused by a function library which I have to compile manually after every project restart and the REINST Errors are gone, or they were fixed by just deleting the node and add it again, this happened sometimes in the behaviour tree, but this seems to be fixed in 4.7. And I got structs which don’t work and making the Engine crash, but they were not corrupted, it just was a bug in the engine and after it was fixed (in 4.8) all the structs work again. And I also got blueprints which just don’t want to compile (I click compile and they stay dirty) but that’s just cosmetically, the engine only shows they are not compiled, but they actually are and they work without any problems in game, except that every time before starting the game I get the message “There are blueprints with compile Errors…”.
So I experience a lot of bugs, but they don’t corrupt anything, they just make things not work.
The bugs I have the most problems with are these tiny little bugs which just no one has ever experienced (or reported) before. So Epic does not know about these before I report them. Because there are so many of them. And if you do stuff which is not usual, so not tested by Epic, you experience a lot of these bugs. And there are parts of the Engine were Epic knows really well that they are buggy, but all the bugs are “backlogged” if they don’t cause crashes, for example destructibles. I think they should make such things experimental until they have the time to fix the bugs. So that people don’t expect it to work.
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.
But I still don’t want to use anything different than UE4 
[]
So I experience a lot of bugs, but they don’t corrupt anything, they just make things not work.
[/]
Well, my maps seems to be fubar afterall…
See: https://answers.unrealengine.com/questions/231737/map-dissapeared-from-project.html
[]
But I still don’t want to use anything different than UE4
[/]
Thats the spirit!
Although I have the DMapEdit.exe around here somewhere 
This isn’t a topic for discussing current bugs or difficulties with the engine. Please take them to Answerhub to get support.
Considering some of the bugs I’ve seen reported and experienced myself, I suspect Epic needs to ramp up their automated unit tests. When a release comes out that outright fails to build for a platform that worked on the previous version, it’s obvious that isn’t being tested by their CI system.
Being a developer myself, what is Epic games doing with automatic testing? I think many of the bugs i experience daily could be tested automatically.This would at least ensure that new releases do not break existing functionality.
yes their internal quality control needs to be a little bit stricter.
ive done it myself on a smaller scale, code an entire feature from start to end and be pretty confident it will work, the code looks like it will work and the quick test i did worked. the instant someone else tries it they inadvertently find the bug(s).
one can get away with this kind of thing to an extent when its for a particular game mechanic for your own game, but ue4 has changed from being the unreal tournament engine set free (ue3/udk).
its time to get the core features (blueprints ect) absolutely solid. how they let through something like a bluescreen from pulling a wire out of a node is beyond comprehension.
not to mention how they (and unity to be fair) let the current physx through, even a 5 minute play would have shown the unacceptable state of it.
a general emphasis on quality and stability is whats called for.
Well, it sounds like this has been discussed to death already… But I get 8-10 crashes per work day on UE 4.7.6 right now, and I was lucky to get 1 every other day on 4.7.5. I would definitely be in favor of doing a major in-depth bug-fix release…
Maybe it would just help if Epic could make a lot more preview releases. For example, at the moment we are at 4.8 preview 3. During the 4.8 preview me alone found and reported 8 bugs (more exactly 9, but I don’t count one regarding destructibles because I know they are “backlogged”).
In preview 1 they said some stuff which should get in 4.8 is not in there, so also fixes which already exist are not in the preview 1, they get added in the later previews. So reporting bugs only really made sense since preview 2. One of the bugs I reported is fixed in the preview 3. I am reading through all the commits which get added to the master branch, and I think the other 7 bugs are not yet fixed.
Now in some days 4.8 will be released, we probably don’t get another preview. The 7 bugs I found during the 4.8 previews will most probably not be fixed in 4.8.0. there will be a lot of hotfixes which try to fix the remaining bugs. And some of the bugs will not fit in hotfixes, so they will get fixed in 4.9. But why not just make more previews, so that no hotfixes are needed and we don’t have to wait for the next major release to get a small bug fixed?
[]
Now in some days 4.8 will be released, we probably don’t get another preview.
[/]
I think it needs some preview iterations until a “stable” 4.8 is reached, unless Epic pulls off a massive fix in the nextone.
I would be perfectly comfortable with a few more, improving, previews and get to full 4.8 by end of june…
[=tegleg;297446]
yes their internal quality control needs to be a little bit stricter.
how they let through something like a bluescreen from pulling a wire out of a node is beyond comprehension.
[/]
“Let through”?
Really?
You think someone somewhere saw this happen and went ‘welp… good enough…’ and let it out?
I know you are frustrated but really?
Chances are what you are seeing is a graphics driver bug - the functionality in UE4 is clearly solid given the number of people who use it every day, so the more likely cause is that the driver is failing to handle something correctly (assuming its a graphics bug, the term ‘blue screen’ is too vague and something which, fyi, can not be caused directly by a mode program on any remotely recent version of windows and instead tends to be a lack of validation in a driver or other kernel mode section of the OS).
Does it suck?
Sure… but trying to argue that someone ‘let through’ something which was never seen isn’t great logic - and also strikes at the heart of the ‘zero bugs’ argument; Epic can’t test everything, clearly they aren’t doing things internally where people are seeing problems because people are seeing problems - so shutting themselves away for X months to try and produce a ‘zero bugs’ version of the editor isn’t workable; all that’ll happen is in X months a new version will come out, someone will do something Epic didn’t test and BAM! we are right back here again with people demanding a ‘stability fix’. (Although that’s ‘stability with no added features… apart from the features people want…’).
[]
Chances are what you are seeing is a graphics driver bug
[/]
Not really. I experimented a bit and it seems the chances of running into a bluescreen scale with the time the editor is open.
It feels like a subtle memory leak where some leftover pointers are floating around and its like Russian Roulette, sooner or later it happens.
Wen I close and reopen the editor every 30-45 minutes and also do the same before building lighting, I can avoid bluescreens pretty good.
Also the Graphics driver works flawlessly with countless other applications.
More imprtantly, it works with the older engine versions without bluescreening…
[=;296888]
That even gave me a bluescreen once . :rolleyes:
From my expierience, the BP system does not take too kindly on changing variable types etc.
If you are not following the exact ritual of:
-Unwiring all pins of that variable in use
-Change the type of the variable.
-Recompile the BP
-Refresh nodes where still neccessary
-Rewire again
If you follow that, it works, if not, you are playing Russian Roulette and each time another round gets added to the drum…
The same goes for:
-Create a struct
-Create a variable of that struct and fill it with values
-Change the type of one of the struct members
Sometimes the variable of the struct is just “blank” again, no values stored.
But again, it sometimes crashes the editor.
I havent made extensive tests, but this seems to happen only if the former type that was changed from was “pointer style” like a mesh or material reference.
If it was just a float or int, etc, its usually ok…
This makes iterations, especially for beginners who fiddle a lot, extremely “difficult”
[/]
It also defeats the very thing blueprint was designed to do. It’s not practical at all to try to unwire everything in all of your blueprints if you need to change a struct. I’d be totally happy with a crash 3 times an hour as long as things don’t corrupt 
Regarding issues with changing variable types or deleting variables… i have those too many times a day. I believe UE4 should literally check more on nullpointers (i.e. invalid data) instead of crashing all the time. In our project we first used blueprints a lot, but switched to mainly C++ to prevent these kind of issues.
[=;297624]
Also the Graphics driver works flawlessly with countless other applications.
More imprtantly, it works with the older engine versions without bluescreening…
[/]
Unfortunately this logic does not follow; graphics drivers are wildly complicated things with internal profiles and logic to deal with different games and applications - more to the point the UE4 editor might not hit the same code paths as other apps and maybe not in the same order, which can have an impact. If it was so simple as ‘works on other apps’ you wouldn’t need constant driver patches and updates for other games and applications.
If we were talking DX12 or as the renderer yes, I’d probably shift the blame towards Epic, but with DX11 the validation of data sits with the drivers and it is when they screw up that things bluescreen; there might well be a bug in UE4’s editor but that shouldn’t be causing a bluescreen.
(Also a ‘shut down every 30 to 40 mins’ will also spin down a lot of driver internals too so this would also cause any driver side problem to vanish.)
[=Bobvodka;297614]
“Let through”?
Really?
You think someone somewhere saw this happen and went ‘welp… good enough…’ and let it out?
I know you are frustrated but really?
[/]
thats exactly my point, they didnt test it enough to see there was a problem. quality control is too lax.
and you cant just say oh thats a graphics driver problem because its just 1 of the many many bugs people see every day throughout all aspects of the engine. they are not all driver related or these bugs would show themselves with other software too, and the fact is they dont.
edit:
incidentally ive never had a blue screen from ue4 but it does crash at any opportunity, thats ue4 crashes not my graphics drivers.
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.