When opening projects, a special compatability issues logfile report should be created

General Feedback & Requests
1

I don’t know but this could be so in some fashion and maybe already part of the main logfile, which I’m not sure if it gets created unless a crash happens, I’ll do more looking but I just had to get this idea out anyway.

I think this special compatability logfile would be helpful when opening old projects that have a version mismatch and also even accessible from launcher if possible (so it doesn’t clutter or annoying in GUI), the logfile could also be feeded to a GUI dialog that would open up if any issues (broken things) were detected

Detecting issues shouldn’t really be hard at all, and I don’t think it need to be called detected, the engine parses, what it can’t do it just defaults to soemthing or whatever action it takes, this compatability report would simply report of all those cases in one logfile and be easily accessible either through GUI or manually, saved to the project root folder.

So essentially you would have a list of all the compatability issues, things that got broken when loading up the old project, all the broken links in blueprints for example, that would be extremely helpful to have an overview of how much is broken, and most importantly knowing everything what’s there to fix so none of it gets unnoticed, instead of discovering it much later down the line that some things aren’t working anymore, or not at all.

This system could be further expanded so these logfiles are versioned in such a way that issues that were detected in the initial opening of a mismatching project would be transferred to the recreated project with , incase a person couldn’t fix all the issues in one session, saves, closes down and continues next time. And when the project is opened again the next time, it would still check again and do report as if it was opened for the first time, and in this case it wouldn’t found anything but there it detected an existing compat-logfile (with metadata about original project version, resaved version, etc) and notify the user there’s some pending things from before that aren’t fixed yet, with a prompt to open the logfile or not.

This compat logfile should also come into play when saving, especially when resaving old projects in the new version initially, most of the time there’s no error when clicking press so the compat report simply wouldn’t be toucher, it’s just when something happens the verbose info of what and where the issue is would be reported as a line.

This whole worrying about the broken thing is the biggest thing, this feature would make it way more comfortable for me to just start a serious project and not keep delaying it until the next version, and the next, and the next. Maybe I’m too overworried but I just don’t see how this could hurt and it shouldn’t be that hard to do at all vs all the other things, and it would be very powerful psychologically and even if it doesn’t provide some big help, it adds to the sense of stability and that you can simply continue doing something and you know there’s a logfile with a list and you don’t have to keep a worry while not working … “oh no tomorrow I have to find all those tiny things that broke, god knows if I’m going to find them all” … that’s the biggest reason, even if I could have eventually found them manually, spending a day looking through all the blueprints, all the code, it’s really about that feeling that this feature creates that’s the most important thing.

2

Do you have any example of such issue?

Of course any improvement in area of automatic error detection would be awesome. Any automation tests are welcome.
But it could be impossible to do what you specifically request here for one reason.

Developer would need to know about an issue to write a piece of code in order to detect it.
And most of bugs/problems in the new release appears because developer/QA didn’t notice the issue.
If somebody noticed the issue, it is fixed then. Or programmer added a log message. Or the information was included in release notes. Or it’s at least reported somewhere on UE4 website.

Game engine is too complicated software to simply detect all the issues automagically.
And to analyze what’s causing new issue? You probably need a human for that :wink:

If you want to avoid ugly surprise and some extra stress, you could either:

  1. Wait like a week after release of the next major version and check what are the major issues. For instance in this release somebody reported issue with HISM component so I’m not upgrading one of projects to 4.17 until this issue is fixed.
  2. You could try upgrading a copy of project to preview version and detect problems in this way. That’s why we have those previews - to stabilize the upcoming version.

And you can’t never expect that you won’t discover some issues after a month. But methods above could save you a lot of time and stress :slight_smile:

3

Okay I’ll try to clarify. I’m not talking about the breaks that would happen in game logic or behavior because an underlying feature has changed to a different behavior, or affected normal engine bugs that are part of any software, the bugs that are when things don’t work as intended, or a rare condition isn’t being taken care of.

I’m talking about when the engine defaults to a setting where it can’t do what the project is asking it to do, however I assume this is all coded in as because if the editor tries to load up a blueprint component that doesn’t have the nodes that existed in the previous version so these ones would appear unconnected and also colored in RED afaik.

So that’s what I meant with no detection code required, because the engine would crash or just I guesss ignore the thing or or wouldn’t load the whole blueprint so my speculation is that it has to have some kind of ability already that it simply drops the links and references and everythign else works, even if this doesn’t require no functionality to be able to do this,
running some kind of basic general rule, it still probably knows when it happened, no, or maybe code would be needed, to check everything after loaded to see if it did, the ones that didn’t, output a message to a logfile, but this doesn’t have to be coded per case ofcourse.

So all I’m saying is to put all these links breaking occurences into a list of messages in a separate compatability log , all the things that can’t be applied from the project settings, configs, BPs, code references, all the editor has to do is to compare it to the ones that couldn’t be loaded, and this would save time trying to go manually to check all BPs for the broken links.

It could also be more advanced as I suggested, to not only work as a basic log file, but even as a status file, keeping things dynamic, logging metadata as well:

Example (with comments):

    • session start
    • opened project with version X with editor version Y / for the first time (no previous compat logfile data found for this case "project version X with editor version Y)
    • compat config issue: users setting f8d7d8s could not be applied; editor action: left blank
    • compat config issue: user setting 8d7d7d could not be applied; editor action: set to default value
    • compat blueprint issue: node in blueprint component 23daed8 could not be found in blueprint “filename” ; editor action: link broken
    • compat material issue: texture 4d939 could not be found; editor action : reference to texture “name” in material “filename” removed N times ( or set to default if applicable/makes sense in a certain case, there could be more references, could be even “dropdown” (in gui) to display a list of all the locations of where those individual references are)

This whole compat thing can be wrapped under the special “open project under compatability mode” with would also be the default automatic action when the editor detects the project version mismatch, if something like this doesn’t hiddenly exist already.

But it doesn’t have to be a button it self, that you would have to click, it would just be a mode the editor launches with and nothing special really, it would just display an additional alert message box:

This compat mode would show the GUI message and an constant alert icon in one of the corners incase you close down the message box (slowly flashing maybe)) only in this compat mode the editor would perform these additional checks and report to the special separate compat logfile, (it wouldn’t run on normal circumstances) , ofcourse create it if it doesn’t exist, and once you fix some of the issues, it would be able to detect that you did and flag those things as fixed, however ofcourse any change would flag it as fixed, even tho you might make later changes to it, but the first time you get to the BP and click on the note that is broken, unlinked due to compat issue, and hook it up to something else, that’s the change that’s when the compat system has to flag the issue as fixed because you saw it you came to it, you found it where it is, that’s all it has to do, if you unhook it again that’s your problem from it’s point of view it’s fixed, and if you know for 100% you want to leave it unhooked as you changed your mind, you could right click on it an because this is compat mode, an option will be available to click “mark compat issue as fixed” to remove it from the list

Once all the issues get fixed from the compat logfile point of view, then the trigger to activate compat mode the next time editor runs this project, is disabled.

However as I said before, a user might not be able to fix all the compat issues in one session, and when he resaves the project, the project is converted to the new version, running it again will not trigger the compat mode again, however this is where compat logfile comes in again, the editor would always scan for a bit present in a compat status/logfile that the compat status/logfile will keep saved as well. That bit if switched on would trigger the editor to forcefully run the project in compat mode again even if the versions aren’t mismatched, once the user fixes all problems the the override bit will switch to off you’ll be running the project without any compat issue messages.

And for those who for some reason would hate this idea, there could be an option to simply press “ignore forever” button in the initial message box when you open an old mismatching version project for the first time (but please make the ignore forever button a non-recommended option and with an “are you sure… bla bla why is this helpful bla” confirmation dialog as well as limited to this version mismatch case so when another engine switch happens and a mismatch is detected in future it would still reactivate the compat mode for that case and ofcourse give this option again, ignore forever only for this case.

And I just call it a logfile as well because it would keep the info of the compat issues and fixes from previous sessions, you could look back a year and see how many versions did the project switch and stuff, there could be option to limit the size, but it shouldn’t be enabled by default, a large project can have a lot of breaks if more than 5 versions are switched for example, on large projects that would be more comoon as they probably wouldn’t be jumping to newer engine every 3 months.

A different message could be displayed in the GUI message for the compat issues if the previous session logfile triggered it, to make things more clear to people why it’s showing up again after they resaved the project in the new editor.

And the reason why this whouldn’t be that complicated to do is because I’m merely seeking to report status, not to fix anything automatically, it’s impossible anyway, the editor can’t possibly know what you might choose even if it was some super duper AI that would make the BPs for you, you could have changed your mind, so I understood that.

However, setting things to default is actually some sort of a fix that doesn’t need any advanced scripting/detection/ai code to do it, it’s just an action after a trigger, it’s really not a big deal, this behavior of what action is taken is best decided by developers who would go more in depth and figure out where it does make sense to set something to default or just leave it blank or even provide a separate dialog box for the user to select the action “set to default” “set to none/blank” “mark as fixed/ignore” “fix later manually”