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