UE 4.9 Suggestion: Quality of Life Improvement release

General Feedback & Requests
67

[]
Also agree, but that brings up the point that now we’re talking about something like the Tick-Tock method, but for software builds. We’ve talked about it before internally, but were not sure how people would react to long intervals without a release or update. Any feedback would be appreciated and I can run it up the chain.
[/]

I like idea of Tick-Tock method for UE4 if you mean QoL Build-New Features Build. I think it would solve a lot of problems and people will like it. Maybe, it is time to sumarize all these questions and launch another Unreal Editor Survey, so you will have enough feedback to decide what people would like to see.

68

[= ;295086]
To better assess what long-standing bugs should be prioritized, we take into consideration community insterest; literally how many people talk about the issue.
[/]

thats a great idea in theory but the way it works in practice is:
someone reports a bug,
many people reply to the thread expressing concern,
an epic staff member says thanks we now know about this and here is a random number to prove it (UE-somenumber)

and here is where this system falls down:
because the bug has been officially acknowledged people quietly wait for a fix.
this means the perceived community interest dies to 0 and the bug fix gets pushed down in priority.

months later people ask about the bug again, vicious circle continues, nothing gets fixed.

69

[= ;295343]

  1. Also agree, but that brings up the point that now we’re talking about something like the Tick-Tock method, but for software builds. We’ve talked about it before internally, but were not sure how people would react to long intervals without a release or update. Any feedback would be appreciated and I can run it up the chain.

[/]

Could you elaborate on the statement :“how people would react to long intervals without a release or update”:

Why can’t you have bug squashing release every month (tick) and every forth (or third) month (tock) release with new features? What do you mean by long intervals and why? Surely you’re not suggesting that because intel is doing 12 to 18 months you have to do the same, because it is called tick tock?

It’s either I didn’t understand you and how tick tock works and what it’s all about, in that case I would really like if you explain to me why you’ve mentioned long intervals, or you didn’t understand how tick tock works and what’ it’s all about.

Thank you.

70

I really like the idea of a tick-tock release cycle :slight_smile:

72

[=;295634]
Could you elaborate on the statement :“how people would react to long intervals without a release or update”:

Why can’t you have bug squashing release every month (tick) and every forth (or third) month (tock) release with new features? What do you mean by long intervals and why? Surely you’re not suggesting that because intel is doing 12 to 18 months you have to do the same, because it is called tick tock?

It’s either I didn’t understand you and how tick tock works and what it’a all about, in that case I would really like if you explain to me why you’ve mentioned long intervals, or you didn’t understand how tick tock works and what’ it’s all about.

Thank you.
[/]

This is all just hypothetical right now. What I mean by long intervals is that by switch to a back-and-forth method would replace the workflow of releasing a major build, cracking down on bugs with hotfixes between builds. Hotfixes are easier to push out every couple of weeks as opposed to waiting a couple months for a big chunk of fixes. My question was more if people would prefer the fixes trickle in as they are made or waiting a while to get those same fixes all at once, but with a few more because there was focus on fixes for that period.

Yes, I understand completely that Intel can have year-long or more intervals between Tick and Tock, but what I said was “something like” it, not to do exactly what they do to the letter. If it would be easier, I can refer to it by something more like “flip-flop”. Intel is a chip manufacturer as well which explains their extra-long cycles (hardware+software takes longer to develop).

[=tegleg;295630]
thats a great idea in theory but the way it works in practice is:
someone reports a bug,
many people reply to the thread expressing concern,
an epic staff member says thanks we now know about this and here is a random number to prove it (UE-somenumber)

and here is where this system falls down:
because the bug has been officially acknowledged people quietly wait for a fix.
this means the perceived community interest dies to 0 and the bug fix gets pushed down in priority.

months later people ask about the bug again, vicious circle continues, nothing gets fixed.
[/]

This is something that we noticed was happening as well, but have put in a system to help prevent it. All of our reports that are being referenced in those answerhub posts get updated with a special section called “Community Interest”. As more people arrive and agree, that number is escalated and it shows up when deciding how to prioritize. We even have a new email that goes out to our various developers highlighting the bugs with the highest community interest.

This is all a bit new however (within the last few months), so I am sure that you are correct that a few have been missed or not given higher priority. If you have any posts that I can address specifically, I can look into them myself and make sure they are prioritized correctly. It’s important to me that these older issues get brought up to their respective developers, so please let me know.

73

[=;295824]
I doubt this will be considered, but let me just toss it out there. What about a monthly forums bug-bash, where the team that finds the most new bugs, gets something, I dunno, a shirt? You get triple points if you find a bug, and submit a complete fix for that bug. You could use the answer-hub to track points. Even if one team finds a bug, another team has a of fixing that bug and submitting the fix.

The bug-bash could be on a regular schedule, say from the 1st until the 7th of each month.

This would take the workload off Epic, and for a small cost (some prize), give incentive to the forums to find these bugs. In the long run, it’s a money saver, at least in theory.
[/]

I’m really starting to like the idea of doing a community event for bug hunts/bashes. Great “team-building” excersize for on the forums as well. This is something that I’d have to OK with and some of the leads, but I’m on board.

I’ll get back to you all on where the discussion goes.

74

[= ;295829]
This is all just hypothetical right now. What I mean by long intervals is that by switch to a back-and-forth method would replace the workflow of releasing a major build, cracking down on bugs with hotfixes between builds.
[/]

But this is not how tick-tock works. The idea behind it is that you have “alternating” major releases. Each tick is a bug squashing release, each tock is feature adding release. And you can have different patterns and lengths of them. Tick-Tick-Tock, where each tick is a month and tock where tock lasts 2 months.

So there would be no disruption in your workflow, because your workflow up until now was:
Tock-Tock-Tock-Tock-Tock-Tock-Tock-Tock-Tock-Tock-Tock, but no Tick.

Show us that you not only can tock the tock but also can do the tick.

And results we all see and experience.

75

A public facing “bug report” system with a voting process would be invaluable, and I don’t think it would be that hard. At a regular time interval, do a DB replication from the internal bug report system to the public facing one. All it really needs to have is something akin to the UE4 roadmap trello system:

Category, Subject, Projected Dev time, Progress Notes, Importance vote (1-5 star, each person can do 2 or 3 of each “star” system).

Or something to that effect. If there was a screenshot of the current internal report system, I could come up with something a bit more concrete or feasible on the replication.

As far as the community bug-hunting / bug-fixing teams seems cool, although I probably wouldn’t be able to do this (I’m but a peon in the midst of giants).

The tick-tock methodology, or something akin to it, for example: tick tick tick tick tock, where each tick is a feature release, the tock is a stability / enhancement release would be good. One perfect example for this that I can think of is Operating systems releases. End users usually go with each OS upgrade, while enterprises are usually 2-3 versions behind (OS more stable, better developed, etc…). This would allow people to forgo feature releases to favor a stability release.

Of course, to re-iterate, the stability release isn’t just about fixing bugs, but also overall enhancement to current tool-sets. The reverse also applies, a feature release wouldn’t only contain new features (and no bug fixes). However, each release would have the feature / stability theme on which to focus on.

If there is a major feature that Epic (and the community, via the roadmap trello) feels like needs to be pushed out, but the release is a stability build, go ahead and release it as an experimental release, so that it can be enabled or disabled depending on the needs of the developer / . One example would be, lets say some genius came up with a thing that made the engine use half the amount of resources for rendering… well, that’s kind of important, right? Release it as an experimental option in the stability release, to be further worked on and tuned for the “feature release” that follows.

76

The sissue is not finding the bugs, or presenting them in various ways.
Its simply that Epic does not have the resources to address all issues at once.
From what I can see on the Master branch activity, some parts of the engine are rewritten more or less from scratch. So bugfixes for the old implementation would be a waste of time.
Its just a bit unclear on how fast these new systems will be available. (Geometry 2.0 Mterial Editor 2.0, etc).
The same with the sound system. If the new hired sound guru creates a new shiny sound framework, why fixing bugs in the current one, unless they are real showstoppers…

77

[=;295859]
The sissue is not finding the bugs, or presenting them in various ways.
Its simply that Epic does not have the resources to address all issues at once.
From what I can see on the Master branch activity, some parts of the engine are rewritten more or less from scratch. So bugfixes for the old implementation would be a waste of time.
Its just a bit unclear on how fast these new systems will be available. (Geometry 2.0 Mterial Editor 2.0, etc).
The same with the sound system. If the new hired sound guru creates a new shiny sound framework, why fixing bugs in the current one, unless they are real showstoppers…
[/]

That is something that a public facing tracker would help with. A developer note that states, “Declining further work on this system, new system coming in such and such release / date”.

Think about this idea not as a “with each tock we’re going to squash all bugs in the software”… no, I feel that is impossible. Think of it more along the lines of a stability and enhancement release. See my above post.

78

[=SaviorNT;295854]
A public facing “bug report” system with a voting process would be invaluable, and I don’t think it would be that hard. At a regular time interval, do a DB replication from the internal bug report system to the public facing one. All it really needs to have is something akin to the UE4 roadmap trello system.
[/]

This is something we’ve been working on, but do not have an ETA for at this time.

[=;295848]
But this is not how tick-tock works. The idea behind it is that you have “alternating” major releases. Each tick is a bug squashing release, each tock is feature adding release. And you can have different patterns and lengths of them. Tick-Tick-Tock, where each tick is a month and tock where tock lasts 2 months.

So there would be no disruption in your workflow, because your workflow up until now was:
Tock-Tock-Tock-Tock-Tock-Tock-Tock-Tock-Tock-Tock-Tock, but no Tick.

[/]

I think we’re having a misunderstanding, because that’s exactly what I’m saying as well. We are both saying that the new method would be to have, for example, 4.8 be a “tick” build with only fixes and 4.9 be a “tock” build with new features and to continue with that pattern.

[]
What I mean by long intervals is that by switch to a back-and-forth method, [we] would replace the [current] workflow of releasing a major build, cracking down on bugs with hotfixes between [major] builds.
[/]

I tried to clarify that a little better, but I was saying is that the current method we use is to release a major build(4.7), a series of minor builds (4.7.1, 4.7.2, etc) for fixes. In a way this is “Tock, tick, tick, tick”, but with a big Tock and a series of small ticks. This allows us to get the fixes out faster than 1 month or 2 months was my original point and why I asked the question. I am just asking if the wait of a month or two before seeing any updates at all would make people feel impatient or that their bugs were not being addressed fast enough.

EDIT: Let’s not get caught up on specific methods or details at this time. I’m just trying to gauge if doing alternating “fix heavy” and “feature heavy” releases would be the community’s preferred method or not. I can’t even make any promises.

80

Part of the problem too is how new features can fix certain issues and break other things at the same time, so if we spend too long stabilizing each release, those efforts can be thwarted by a new feature in the next “tock.”

Truth be told, UE4 is FAR more stable than UDK ever was. I had animation students complaining about how frequently Maya crashed on them, and in response I would tell them my own horror stories of losing hours of work because of a lightmass crash, I would rebuild the scene only to have the same crash happen again. Or I would tell them about the many times my file just literally got corrupted because of BSP, landscapes, or Prefabs (remember those?), and I was even able to demonstrate how easy and unpredictable these types of corruptions were in a matter of 60 seconds at a time. Nowadays, we don’t have that massive scale of a problem…

But the problems we have now are small, isolated things going out here and there. Anything that can be done to minimize this, I’m sure the community would agree on. But I feel uncomfortable dictating how Epic should do their job. It would be nice if the programmers who work with blueprints and bug fixes could come in here and talk about what they thinks would be the best way to ensure a stable release, that would be much better than any suggestions the community can come up with on their own. We love the engine, and we’re quick to point out its numerous flaws, but we don’t really have a bird’s-eye view over why certain bugs happen the way they do.

82

[= ;295875]
I’m just trying to gauge if doing alternating “fix heavy” and “feature heavy” releases would be the community’s preferred method or not. I can’t even make any promises.
[/]

Hi, thank you for taking the time and replying/clarifying.

I personally think that most people would prefer that ^^^ and agree that this would help the engine. Which by the way, I’m so looking forward to love.

Thanks for your time .

83

[=;296176]
But I feel uncomfortable dictating how Epic should do their job.
[/]

Nobody is doing that. People simply want stable software. Nobody is telling Epic how they should achieve that.

[=;296176]

Truth be told, UE4 is FAR more stable than UDK ever was
[/]

I know few people who would strongly object to it. And I also object to that too. I was/am working with UDK for last two years now. I’ve updated to each new release. One time only I needed to change one line of code after update.
You see, stability is far more than simply about crashes. API stability is very important too. etc, etc.
I’m not saying that UDK is perfect - far from it, but where stability is concerned UDK is far, far more stable than UE4.

And just let me mention something, because I’m getting vibe from people who don’t see how unstable UE4 is. That vibe tells me that all they do is, pretty renders (which UE4 is fantastic at it), and some animations.
May I remind you that UE4 is a game engine, which means that it is supposed to make games, not pretty renders and animations. On top of that, pretty renders and animations are just a drop in an ocean of making a game. Let’s not forget that.

EDIT:
If that is not a prove of UE4 disastrous instability I really don’t know what to say:

That example ^^^ is actually so upsetting and horrible that at this moment in time I would never start my project with UE4.
I’m sorry, something like that should never happen with a software of a caliber UE4 is claiming to be.
Toy, not a tool. And really at this stage, scary to work with.
Heads should roll at Epic.

84

Hey ,

Just wanted to offer my own input on this idea. I like the idea of a stability/usability/polish release and doing a tick-tock approach would be really great from my point of view.

Bit of context: I’ve been teaching classes using UE4 for the last year now, with maybe 200-ish? students using it in various areas (programming, design, art). There seems to be patterns of instability that come in waves with the releases over the last year. Particular builds were really unpopular with the students because they crashed so often. 4.6 seemed to be very popular because it was more stable. So I think the takeaway there is that for new users, having stability is at least as important as particular features.

From my viewpoint, I’ve noticed a few areas that I think are pretty critical to perceived stability, or have been causing a lot of frustration to my students.

  1. When using the editor, it really shouldn’t crash on the normal editing tasks. So dragging nodes around or wires in blueprint shouldn’t crash, similarly editing values in property fields shouldn’t crash. Those crash bugs are perhaps the most debilitating with regards to just workflow.

  2. Cooking builds recently almost all crashed or failed in some other way to function. I suspect this is because PIE and Cooked are handled so differently. In terms of WYSIWYG this is a complete disaster. This one has me a bit worried I must admit. My students were asked to produce cooked builds for externals and almost all of them had issues in either functionality or the cooking process failing. Many of them had issues that would be impossible to reproduce, such as certain objects not spawning, or functionality working once breaking in random ways.

  3. Corruptions. Especially blueprints. These occur a lot. But also even simple levels can often become corrupted beyond recovery.

Which brings me to one of my insights and this is pure speculation but I’ve been doing this a long time now :wink:

I think there’s a bug somewhere in the serialization system. Almost all of the bugs I see (i.e. ones that aren’t related to a specific experimental feature) almost always involve some kind of serialization of properties on an object. Think about the bugs in general, editing properties, saving files, editing blueprints etc. Most of that is likely to use serialization. At the very least, i think there’s a serious bug somewhere in the serialization of blueprints, but I suspect its more a bug somewhere in the code UObject system.

Honestly its the kind of thing my programmer wants to go in and debug and find for myself, but I’ve got waaay too much other stuff to do.

As I was reading through this thread (+1 to 4.9 bugfix focus btw), it struck me that maybe we could turn this idea on its head. How about we submit a feature request for a set of tools that allow for finding and fixing bugs? What I mean is that we request a feature for doing things like coverage testing. Building a set of Unit tests and functional tests. It strikes me that right now there’s a few support guys trawling answerhub and trying to do repro cases to escalate to devs, but what happens about regression? Wouldn’t it be great if there was a tool those guys could use to create a repro case to pass to the devs, but which also tracked regressions if those cases were affected by subsequent releases? I know there was some automated testing stuff in there already when I first looked? Is that actually functional?

Also, on that tack, what about a feature request for a tool that allows users to setup test cases to submit as crash repro cases. These crash repro cases would go into a public bank of regression tests.

I guess what I’m saying is lets start treating the engine as a proper open source kind of development, where stability-increasing features and tools are given as much values as “wow factor” new features. A bit more like enterprise development in a way, less like seat of your pants just-in-time game development :slight_smile: After all, many people here on the forums are basing their businesses on the engine now.

85

What UE4 needs the most right now is a consolidated GI. This should be the focus of most of their resources if they want to compete with Cryengine and other advanced engines.

Once they do that there would be no question which engine is better. Right now, no matter what features UE4 has, one can always say, yes but not GI. I’ve read countless posts about people using Cryengine and not UE4 because of GI.

86

[=bzinventor;296400]
What UE4 needs the most right now is a consolidated GI. This should be the focus of most of their resources if they want to compete with Cryengine and other advanced engines.

Once they do that there would be no question which engine is better. Right now, no matter what features UE4 has, one can always say, yes but not GI. I’ve read countless posts about people using Cryengine and not UE4 because of GI.
[/]

You really think that having marginally better shadowing is a bigger issue than having an editor toolset that crashes? :slight_smile: seriously, I respectfully disagree.

87

@

I absolutely agree on your points 1 and 3.

[]
Also, on that tack, what about a feature request for a tool that allows users to setup test cases to submit as crash repro cases. These crash repro cases would go into a public bank of regression tests.
[/]

That would be great. i have some problem-projects here on the posion-shelf… :slight_smile:

88

[]
What UE4 needs the most right now is a consolidated GI.
[/]

GI Gi GI :slight_smile:
As if the engine doesnt have other problems :rolleyes:

89

Your logic is akin to saying, “I’m not going to the doctor for my major illness because I’m hungry and I need to eat instead”