[=;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.