[=;276827]
While I agreed at first, I actually don’t see the point. Why bother making a super-stable release for 4.9 which adds zero features, when in the next build all the new features will likely break stability again anyway.
[/]
because we want stable releases at every release. otherwise we just wait forever for a fix that will never come because it’s expected to get broken again
also it’s not only about stability, but also about usability.
so to add up, also because many of the existing features need sub-features that are non-existent. or the many cases where feature X works but not when combined with feature Y and Z.
[=tegleg;276897]
thats a nice sentiment but given epics track record it will probably not happen that way.
add features - add features - add features - abandon - shiny new ue5!
it would be a welcome change to have them focus on making sure everything works and works well every now and .
[/]
And what track record is that exactly? Epic supported UE3 through an entire console generation. It’s only UE2 that was short lived (2 years?).
If you’ve ever used UE3 (not UDK), you’ll see that Epic has a much better approach to both features & stability this time around. Previously, such efforts was centered around their internal projects and infrequent, whereas UE4 really is a flexible, deep & easy to use engine for that’s got its eye on the future.
[]
also it’s not only about stability, but also about usability
[/]
These are important, but hard to do when it comes to constantly evolving software. Epic seem to be on the right track with Preview Builds & Hotfixes, but need time to refine this process and find the right sweet spot between improving stability & adding new features.
If you need to take things cautiously with your own software development I would advise not upgrading to a newer version of the engine until that version is on at least it’s 4th or 5th hotfix.
I want stability too and performance improvements relative only for new features. That can be in 4.8 , not need release a 4.9 with only that, perhaps the only need its a bit more time with versions in “preview mode”, for when upgrade my project to 4.8 i upgrade to something very stable and with nice improvements in performance.
I like the new system of previews anyway, the only thing its that there are bugs still without solution and i prefer EPIC fix that bugs in the actual stable release than fix in the new versión with new features and new bugs.
I not upgrade my projects to preview never, i not like upgrade to a preview if there are any annoying bug in the current stable version for that fix, or wait for stable version. Not like that of “That bug its fixed in 4.8”. I want the fix in the 4.7 (current stable version) i not going to use a preview of 4.8 and need months for stable release and got that bug fixed . That’s my only criticism
Anyway at least for me its stable enought now with the current system.
[=knack;276907]
I want stability too and performance improvements relative only for new features. That can be in 4.8 , not need release a 4.9 with only that, perhaps the only need its a bit more time with versions in “preview mode”, for when upgrade my project to 4.8 i upgrade to something very stable and with nice improvements in performance.
I like the new system of previews anyway, the only thing its that there are bugs still without solution and i prefer EPIC fix that bugs in the actual stable release than fix in the new versión with new features and new bugs.
I not upgrade my projects to preview never, i not like upgrade to a preview if there are any annoying bug in the current stable version for that fix, or wait for stable version. Not like that of “That bug its fixed in 4.8”. I want the fix in the 4.7 (current stable version) i not going to use a preview of 4.8 and need months for stable release and got that bug fixed . That’s my only criticism
Anyway at least for me its stable enought now with the current system.
[/]
Yeah, there are two discourses at Epic which directly conflict with each other:
“Avoid upgrading if your projects to newer versions”.
“This bug will be fixed in the next version”.
That’s not to mention missing features that one might need, like Android support (hello 4.7!). This wouldn’t be a problem if there was a reliable way to grab the commits that contain the actual bug fixes from GitHub without having to beg on the AnswerHub.
Wow… a major update just for stability… I think that is a bit too much - I have never heard something like Windows 2000 which fixes all bugs from Window Me (and no new features).
I personally think the reason of so many minor revisions within 4.7 is because there are quite major architecture changes within the engine. So it affects features which used to work and there are lots of features in this engine… Probably 4.8 will be much better.
[]
While I agreed at first, I actually don’t see the point. Why bother making a super-stable release for 4.9 which adds zero features, when in the next build all the new features will likely break stability again anyway.
[/]
That would be based on the scenario that the introduction of new features would require changes to existing stable (fixed) code and inevitably break things again.
I guess the idea that the thread opener has is that if new features are introduced to an inherently stable version, new emerging bugs should only be related to those new features.
I guess the reality is a mix of both.
I would also prefer a rock-solid version 4.9. And here comes the catch: To prevent the scenario you described, the introduction of new features should be slower paced to make sure functionality is not broken.
Just as you said:
[]
but I’d rather see longer times between releases so that it’s only out when it’s 100% ready.
[/]
I wonder how the Epic workforce is distributed, like: How many programmers are working on Rendering , how many on engine core, on blueprint system, etc.
Maybe the “core programmers” dont bother to fix certain stuff, because the “features programmers” constantly trample over their work?
How are decissions avbout new features made?
A: I have an idea about a new feature but it will require core changes
B: Hey that may break things
C: break. schmeak. We need new features, who cares if it compiles…
B: Nah, we should be sensible here. Is the feature worth the effort? Do we need it at all? Better fix existing problems first.
A: But my new feature is so cool and bugfixing is so boring and lame.
Here the outcome depends on the job positions…
Unless we know more about Epics internal structure and culture its hard to tell where to improve the development workflow best…
[=;276827]
While I agreed at first, I actually don’t see the point. Why bother making a super-stable release for 4.9 which adds zero features, when in the next build all the new features will likely break stability again anyway.
I think it makes more sense in the long run, to add in all the new features they need as soon as possible, so that subsequent released polish the engine as a whole, rather than just in pieces which will only end up broken further down the line again anyway. It’s more efficient this way. That, and I honestly don’t think there’s anything SO broken in the engine that it desperately needs that kind of attention.
I think most people here don’t know how software development works… there are hundreds of people working on this. Having them all work on fixing bugs is silly. You will always have a small R&D team, individuals working on experimental features (see DFGI) and priority features / issues are probably escalated to the " muscle".
Besides, it’s been a while since I’ve experienced any major crash or bug that weren’t related to experimental features (EQS).
We’re all really interested in this feedback and we’d love to help out with stability. While we do have eyes on what is directly reported to us via the Answerhub’s Bug Reports (and to an extend, crash reports) and we try to fix those as they come in, that doesn’t always translate to greater overall stability.
What would help us to understand exactly where to concentrate our efforts would be more information about the specific features and areas that you all feel are unstable. Does the instability come in the form of “unexpected behavior”, crashes or corruptions? Some posts are very helpful with this already, but I’d like to get a better picture from more perspectives.
Any information about this will help us better concentrate our testing as well as give us an opportunity to discuss the progress that has been made internally.
[]
While we do have eyes on what is directly reported to us via the Answerhub’s Bug Reports (and to an extend, crash reports) and we try to fix those as they come in, that doesn’t always translate to greater overall stability.
[/]
Hi ,
Does this means when a bug is corrected, it can’t be corrected at 100% ? Or does the fix reveals some hidden bug ?
I would like a release based on bugs fixes mainly and baking improvments instead of new features.
[]
Does the instability come in the form of “unexpected behavior”, crashes or corruptions?
[/]
Ok. Here are a few examples:
1: I tried to import a CSV datasheet where I accidentially used the semicolon as delimiter. On import the editor crashed. Crash report was sent.
2: I created a struct and used it in a blueprint. I modified the struct. I draged a variable of that type in for a get node, bluescreen
3: I changed the output data type of a material function to put out a Vector4 instead a texture2d. The moment I click on the function in use somewhere (to correct the wiring), bluescreen
4: In the material editor, I tried to enter the word “mirror” in the palette search bar. I only came to “mir” the editor froze and 30 seconds later exited. Crash report was sent.
… and many more, but dont wanna spam here… :rolleyes:
So lately the most problems have occured for me in node editing )material graphs and blueprints). And in all I see more bluescreens than regular (reported) crashes.
Is there any usefull data to collect after a bluescreen that might help you guys?
Would be nice if the editor could log its activities and check on startup if it was shut down properly last time it ran. If not send a similar crash report.
Does this means when a bug is corrected, it can’t be corrected at 100% ? Or does the fix reveals some hidden bug ?
I would like a release based on bugs fixes mainly and baking improvments instead of new features.
[/]
It means some fixes only fix an edge case that affects a few users, so not will noticed the increased stability.
[=]
And in all I see more bluescreens than regular (reported) crashes.
Is there any usefull data to collect after a bluescreen that might help you guys?
[/]
What kind of bluescreen error was it? Memory dump?
In your project’s [Project Name]/Saved/ folder, there are files that document what happened leading up to a crash. If you make an answerhub post with those attached, it could help us a lot.
[=;277368]
Online SubSystem Achievements Even the Documentation is literally empty
[/]
Can you expand on how it’s unstable? Are you getting crashes or glitches?
I was able to locate a report for the doc pages for Achievements and it is scheduled for maintenance. Sorry about that, I’ll see what I can do about priority on that.
[]
I was able to locate a report for the doc pages for Achievements and it is scheduled for maintenance
[/]
I made a “quick” scan of the documentation on the server and found quite a list of broken links. Would that come in handy for you, or are you aware of it?
[=;277385]
I made a “quick” scan of the documentation on the server and found quite a list of broken links. Would that come in handy for you, or are you aware of it?
[/]
It couldn’t hurt if you already have the list. I can ask someone to check to make sure they are all know issues and being worked on.
[]
It couldn’t hurt if you already have the list.
[/]
I didnt save the list. It was a test result of the web crawler im working on Im Im still working on it, so I ll make more test runs. Next time I save out teh results and pass them to you.
Oh. By the way, I just rebootet again from a bluescreen. What I did was:
I edited a material graph and used three “add” nodes to add up 4 scalar values. created a “clamp” node and connected it to the last sum node. When I pulled a wire out of the clamp result pin, I came about 30 pixels far, bluescreen
And thats how it typically goes. They come literally out of the blue.
I hope that helps. When the editor crashes, its bad enough, but bluescreens also trash all my other applications running. So I lose far more work each time than with a “normal” engine crash.
A few folks here have mentioned that they would like to see the “Experimental” tools (Editor Preferences > Experimental) receive more attention and be brought out of ‘experimental’. I’m curious to know specifically which ones you find useful, and generally what types of issues you’ve been facing with them.
Even the Documentation is literally empty