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):
- 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”