Please make UE4 more "refactorable"

General Feedback & Requests
1

Please make UE4 more “refactorable”, Epic.

I don’t know exactly what must be done. I only know that refactoring on UE4 is painful and it always leaves weird stuff behind.

For example: I have a blueprint called BP_PlasmaWeapon, and a parent blueprint called BP_Weapon.

BP_Weapon is too much complex and I think I must refactor it to a C++ class called AWeapon. And then set the BP_PlasmaWeapon’s parent class to AWeapon without loose any data. I mean, every property that BP_PlasmaWeapon changed, or accessed, or any function it called, must now aim to the AWeapon automatically.

And, of course, if I have a BP_PlasmaWeapon placed on my levels, and my placed actor have some custom values setted on it’s properties, these data must not be lost.

Today, data, properties, functions and classes are too much tangled. Make it ease. For example, when load a level or a blueprint, make things fit by the names.

After some efforts (which usually refers to rename the old variables to some temporary name and some restarts without save some blueprints or levels), I can make it work partially: properties and functions now aims to the C++ class. But the components don’t. If I open a level where I changed some properties on the components of placed actors, these changes never passes to the C++ component (aparently, UE4 try to find a component SPECIFICALLY made with blueprints… but why?).

I don’t know if I was clear enough (english is not my primary language and talk about complex stuff like that can be difficult), but I’m sure that many people must have the same issues.

2

What you’re asking for is to make the reflection system less type-dependent and more “loose.”
This is totally a possible design philosophy, but it comes with two draw-backs:

  1. If you “do the best you can with the data you see” then your code won’t be able to tell 100% correct data from somehow-incorrect data, and you might go a long time without noticing that your data is wrong. This is how game-killing bugs happen! (Well, one of the ways.)
  2. The runtime performance of looking things up by name is a lot slower than the performance of just reading things in a format you “know” in the code.

Perhaps a better way of doing this would be to have some kind of “export to XML” and “import from XML” (or JSON, or YAML, or another text format) that did what you want, but that you can apply manually when you need it, rather than having to pay the cost every time you do anything in the editor.
Also, because uassets are binary, they don’t diff very well, so the ability to export a game to a line-format text file (XML with line breaks, JSON with line breaks, YAML) and then re-import that format might be useful for certain source control scenarios.

3
  1. This kind of issue already happen. If you try to make the things I explain on my example, this can happen and I might go a long time without noticing that the data is wrong. This is my main issue with UE4: it requires the data to be 100% perfect all the time, but there are many ways to make them don’t. Data created on UE4 is not unbreakable like UE4 thinks it is.

And UE4 already “does the best it can with the data it sees” sometimes… it’s a little tricky, but it works and shows that, sometimes, UE4 finds the data only by it’s name (like removing the property from the blueprint and adding the same property in the C++ parent class, without loose any data. But, like I said, it is not the usual way, I have to restart the engine, without save some assets etc.).

I completely understand this draw-back, but I think UE4 makes more mistakes when trying to prevent the developer to make one.

And, of course, it makes the refactoring process very dificult - the main subject of this thread. I really think this is a very important thing. UE4 only helpes when refactoring simple things, like renaming some blueprint variable or function. But refactorings can be much more complex.

  1. If this is a problem, this kind of optimization can be done on “compile time”. Actually, I really think maps and blueprints should be text files - and then maybe conververted to binary formats when compiled or packed.
4

I agree the binary nature of engine files, is a huge mistake; but I also understand why they have made it that way.
Software such as Maya has both binary and ASCII file formats for these obvious reasons, hope someday we may see ASCII assets in Unreal as well.

5

I think that in the end this would be a waste of development time. The kind of situation you ran into is a classic “dealing-with-a-huge-system-for-the-first-time” mistake. Once you go through the same thing twice or thrice you’ll learn to anticipate these kinds of things and plan accordingly.

6

I’m definetely not “dealing-with-a-huge-system-for-the-first-time”. Refactoring is a very common practice and helps to improve code quality and adapt to new features.

Suggest that refactoring should be antecipated by “plan accordingly” is, at least, nonsense.

7

True, but in a gigantic project there is no such thing as a “clean refactor”. What I mean is more along the lines of “plan what goes into C++ vs. what goes into Blueprint”.