Some advice from a retired, seasoned programmer of non-stop, 7/24/52/10+ programs

I’m running Unreal now from 5.0 up to 5.5, and in every update, I ran into unforeseen, unpublished incompatibility issues and plain bugs, that caused some projects to be severely delayed, postponed, put on hold or simply dropped, because I could not get on due to these issues.
Returning back to the version before it isn’t possible unless you download the sources from the repository and build it yourself.

Browsing the forums, I see that a large number of bugs still exist, even as old as introduced in 4.27, as I’m told. As well as huge numbers of issues that are still ‘unresolved’.

I know there are time and resource limitations, and when you have the knowledge and ability, as a user you could do some checking yourself - especially large studios. But I think the vast majority of users are either small studios or individuals without the requirements. I may have enough programming experience but in a very different arena.

Another problem I often face when trying to find a way in creating something, or finding a solution of an incompatibility, is the fact that the documentation is either outdated (which is not a problem if functionality not interface has changed but often is doesn’t match the current version), Incomplete or, often, completely missing. Not just on the nodes in blueprint, material definition, PCG… If I get a message on screen, or in the message box, and I want to look it up (the [Docs] link) it is not available, or just the message with no explanation or something on how to solve or get around it. “Google it” : That is NOT the answer. Is SHOULD BE UP-TO-DATE

I think I can speak for a lot of users, with these suggestions:

1: SOLVE BUGS ASAP. I know it’s not the fanciest and fun job for most programmers. But being a professional programmer, it is simply one of your tasks to tackle bugs, whether you like it or not. If you don’t like it, IMHO you shouldn’t be in a professional team. Period.
2: RESOLVE INCOMPTABILITIES. At least, between subversions. What works in one subversion, should work in the next subversion too. If unavoidable (which can happen), publish it clearly and give the solution how to overcome it, so as a user, we loose less time in finding out what happened and how to solve it.
3: KEEP OLDER VERSIONS ONLINE ACCESSABLE: If an update is done that causes severe problems, it is not possible to quickly revert to the previous subversion. As described, the only way is rebuild the engine from the repository, which only (larger) studios are capable of - but it takes time and resources, and game development production is interrupted. Either be a roll back of an update, or a re-install the previous version as if it was downloaded before.
4: KEEP DOCUMENTATION UP-TO-DATE. Again - not the most fancy or fun job but it is part of YOUR job. Of course, the community could / should help, but the videos on YouTube are NO substitute of official documentation!

Of course, I could go for another program but I have gone so far with Unreal and I’m too pleased with the facilities it offers me to exploit my creativity. Of course, I can stay in a subversion, but when I run into an issue that is solved in the next subversion, I use that one - and running into issues there that did not happen before…Or even an update of a version, which can cause problems too. These are mere frustrations that ca so easily be avoided. Making a great program is not just adding more and more fancy features (no doubt one more complex than the other), in the long run it is even more important to keep your users - note: YOUR CUSTOMERS - in focus, and release them from these frustrations.

One question for my fellow Unreal users - single individuals like me, small / indie/big studios: What is more important to you - as a creator of games, environments, buildings, cars, you name it: a stable, predictable and well documented environment to work in, or are you fine with less stability, some incompatibility sometimes, lacking documentation, even if that means you will loose production time solving what you encounter?

As another seasoned coder, I’m just used to exactly this kind of thing - the only really well documented hardware I’ve used was back in the C64 and Amiga days where we had ROM kernel reference manuals and hardware reference manuals etc - of course, that was only possible because the ROM was ROM and the hardware was propriety.

Things are too dynamic, Epic could stop development and focus on catching all the bugs introduced from coders working on the engine (some Epic, mainly focused on UEFN and some devoted devs submitting PRs) and spend the months and months of documenting it well (the reference pages are just generated by comments in the code by the looks of it) - but then the engine gets left behind from hardware and algorithm evolution - which is going through a growth spurt rn.

I think if this is becoming an issue for you, maybe build from source and modify the code yourself to fix anything that’s not working, don’t get tempted to install the latest version, or just use it as reference. Most studios stick to a version and modify that anyway.

The Unreal Source discord channel can be very useful, there’s a lot of very talented, intelligent and experienced people there that are happy to help - I’d actually go as far as saying that’s more useful than detailed documentation.

1 Like

I didn’t mean that Epic should stop develop new functionality, or enhance existing; I am well aware that it is a requirement to stay ahead - or keep up with the competition. My point is that I have encountered - several times - that a feature, broken in one version, is solved in the next, but that one introduces another issue, completely unrelated, which is repaired in the version following. Not just between subversions, even releases within a subversion can break things. and if you update your version (say 5.5 to 5.5.1; 5.5.1 to 5.5.2 and so on) and something breaks, you have NO possibility to revert that update. I have asked for this before - I don’t mind how it’s done, a .zip file containing the changed executables would do, or a function to revert the update - it’s all fine.
Building and debugging it from the repository - of course it’s an option, but I’m on my own, no C++ or Python knowledge (I can read and understand the code but lack programming experience in these languages) and don’t have oversight of the 3D / gaming domain.

In my development days, the OS I worked on is propriety but the whole system is very well documented, and up-to-date. It still is - after over 40 years of development and maintenance. I know some of the engineers - and documenting is part of their job.