I got github 5.6 repository to compile last night. This time with 3 failed builds. I still have to study the errors. I was getting 5 failed builds. But I think that was because I may have been using dev-5.6 from a few weeks ago, and there were actual unfixed bugs in the code. Apparently 5.6 solved at least 2 of those build errors.
I am still confused about the difference between the 5.6 repository and the release repository.
Google AI says: “Numbered branches (e.g., 5.6): Represent the source code for past and upcoming official releases. The branch reflecting the current release (like 5.6 for the current official release) is thoroughly tested by the QA team for stability and reliability.”
Apparently that is not the whole story.
The problem I am trying to solve at present is LiveLinkHub is not populating the Video Format field for the several new webcams that I have. Yet those webcams work in other software and also in my own video frame analysis software. The recommended fixes that I have seen sound like guessing. And I know from programming similar that capturing and processing the video feed is not about hacking a work-around.
I think, at this point, I am going to have to dig in to the LiveLinkHub video camera code to find the answer. My guess is that LiveLinkHub is anticipating a particularly video format (eg. 640x480, 24 bit) and the webcams don’t support the required resolution. And therefore LiveLinkHub simply does not list a format, and does not explain why it did not list any of the video formats that are working in other software.
Digging in at the developer level looks like it may be a requirement to find the answer and to do the things I want to accomplish.
The Epic Launcher binary install seems to work well enough if you limit your goals to environment and character mesh construction and stand alone builds. But, as the environment gets larger and as I try to do more complex stuff, it seems changing over to the source build becomes necessary to figure out why some things don’t work as it seems they should. And in other cases appears to be required, for example: client server multi-player builds.
It was disappointing to find out that UE has a core layer that abstracts the structs and classes away from standard C++. Epic calls it the reflection system. Apparently the reflection system is so that the UE Editor has a generic way of revealing the struct and class members to the Editor user interface.
UE seems to have many problems that are unusually difficult to solve. And I don’t think it is because of code size. I now think it is a result of decisions like abstracting away from standard C++ structs and classes.