I have encountered a strange issue with one of my blueprints not saving settings, which has happened on occasion in previous versions (back to 4.5). I have a GameMode blueprint derived from my c++ base GameMode class. Somehow, the settings in that blueprint will not persist after closing the editor. Strangely, it’s actually not the default setting that it is set to when open, it a a different class.
I’ve made a copy of the blueprint uasset file (int Windows explorer), deleted the original, and the issue persists. I have made a duplicate of the blueprint (from the Content Browser in editor), renamed it, and the blueprint correctly saved and did persist as normal.
Has this happened to anyone else? I have seen this happen a couple times before - I had to duplicate the blueprint and manually reference the blueprint to fix the blueprint, but maybe there is more of an issue going on here?
I haven’t experienced this issue myself and I haven’t seen any other related reports. You said that you’ve experienced it multiple times all the way back to 4.5. Was it always in the same project or have you also seen it in different projects?
It has only been with the same project. I’ve not seen it on different projects - but I have seen it with different files. Let me know if there is anything further I can provide for you on this. One interesting thing is that the ‘fixed’ duplicate uasset file is a different size than the ‘broken’ one. Another thing, it’s only default properties that seem to be affected, not adding or removing nodes.
I still haven’t been able to reproduce this in-house, I believe it’s confined to your project. If you would like to post a copy of your project here or private message me a link to download it over the forums, we can investigate it further.
In the meantime, I will continue to look for other users that are having a similar issue.
OK - yes it’s pretty hard to cause to reproduce - posting a copy of the project is probably not practical, but I can post a copy of the file that will save and the one that won’t. It may be useful. In the meantime, I’m just using the ‘repaired’ copy of the file without issue (the one I duplicated from within the content browser.)
Hey - this has just happened again, with my replacement blueprint. It’s the GameMode blueprint specifically - it’s not happened with any other blueprint. but it is happening consistently and is reproducible in the sense that the blueprint isn’t saving settings. What is triggering that is unknown. Additionally, the settings for the GameMode are hard-coded in the source and the settings its populating aren’t default settings (from the source), which is strange.
I think I should be able to get you more info, I’ll see what’s going on during the save process and post it here.
No, they are setting to values other than my c++. Which is really the weirdest part. I don’t actually have specific steps to actually trigger the issue, I can only detect the issue once it has occurred. But once triggered, the blueprint is no good, I have to create a duplicate with a different name. What happened this last time was, I was working on a UMG widget. I middle-mouse clicked the tab to close the window as I was done with it. This caused the editor to crash with and error I don’t quite remember, but along the lines of invalid memory access. I re-started the editor from Visual . When I hit the PIE button, I noticed some ‘issues’ with my ability to interact, that is, I was unable to send any input to the game. I traced around and saw that my GameMode (which is a blueprint deriviative of my c++ GameMode) defaults (specifically, Default Pawn Class and Player Controller) are set to non-default values and even sport the yellow reset to default arrow. The Default Pawn Class is hard-coded to use a specific blueprint in the c++, and it is changed to ‘DefaultPawn’ from the hard-coded blueprint ‘PlayerCharacter’.
So what happens is when I set them back to the values they should be, they work fine for the session. If I save and close the GameMode blueprint, then restart the editor, the changes to these settings don’t persist. However, any changes to the event graph do persist.
Making a copy (and changing the name to create a new asset) of the file in Windows Explorer and the issue remains. But, if I duplicate the GameMode blueprint in the content browser use it as the default game mode for the level, it works fine. There is a file size difference between the duplicated .uasset and the bad one.
I haven’t been able to acertain if the issue is with writing the file to the disk or if the values are being changed when the editor loads.
Definitely willing to share, just that the project is too huge at this point to reasonably upload. I’ll see if the issue will carry over to a new project if I migrate the GameMode blueprint to an empty project with the associated classes.
It may still end up being too big for me to upload - I have limited bandwidth, but if I can pare it down in a new project, I can get that to you. I’ll post back here when I’ve got it prepped, if the issue carries over to the new project.
Unfortunately, I’m not able to get a reasonably sized project to upload for you at the moment. I have also realized that my maps are behaving in a similar way, just intermittently. With only settings. I’m not sure if the settings in blueprint instances are reset because of changes I’ve made to other blueprints or the blueprint itself (that is, not the instanced object settings in the map) may be causing these to be reset (they are resetting to default values where as the game mode blueprint itself is set to other than default values).
Maybe I can find the issue myself if I can get the time to spend a few more hours on it. Since I’m really only seeing this happen with the GameMode blueprint so far (though I believe I’ve seen it with the PlayerCharacter blueprint as well, but can’t truly remember and it’s not doing anything strange at the moment), I have a feeling that these settings are being read incorrectly from some other source, some kind of cache, maybe the DDC - not sure. I’ll try deleting that and see what happens.
Also, in the Project Settings under Maps and Modes - the default GameMode seems to be directly linked, read and write, with each other. I’m not sure that is correct? So if I’m in the Project Settings and I set those defaults, the selected GameMode blueprint immediately reflects those changes and vice versa. Should that be happening? If so, then OK, but if not, maybe that is the problem. that the Project Settings is being read in and for some reason, those are changing the GameMode blueprint settings. There is no ‘Save’ button for the Maps and Modes project settings - are they autowritten?
It looks like there is something wrong with the redirector file. I’d had the GameMode blueprint in a folder called Game. Some time ago, I moved the GameMode to a sub-directory called GameModes. What seems to be happening is on editor load, something is happening with the redirector which is overwriting the settings in the actual uasset file.
I was able to manage cleaning redirectors and shuffling files around and found that somehow, after moving the file back to the original (Geme) directory, then re-moving back to the new directory (GameModes) it was saving the settings and they weren’t getting overwritten.
Here’s the best part though - I can’t get it to fix again. I’d made a mistake (it was late at night when I was doing this), and accidentally overwrote the fix changes (I was working with a back up copy of the project), and now, I can’t seem to figure out how I got it to fix the first time. When I try to repeat the process, I get the ‘File exists in that location’ error. I tried a bit of manual Explorer moving of files, but the references get broken and so moving them back results in the issue re-appearing.
I’m wondering if you have any tips on cleaning up redirectors. When I try to clean them, I get some issue with blueprints still referencing the redirector. For example, that there are assets still referencing the redirector and either force the delete which results in irreparable damage to the referencing assets that can’t seem to be fixed up.
If I manually delete the redirector, the message log displays numerous errors, which then can’t be fixed.
No it doesn’t appear to fix the redirectors. When I attempt to fix up the redirectors, I get the messages that it is fixing them, etc., but at the very end of the process, I get the Pending Delete dialog, which says that there are several references to the redirector file and that there are no suitable substitutions and that I can force the delete.
I tried the force delete, and it broke a huge amount of assets, which I’m unable to fix. I tried to fix a couple of them, but they were still not ‘fixed’. It would literally take days to re-fix each asset, but even so, without knowing when the issue would again arise, would probably not be the best use of the time.
If there is anything you’d want me to try on my end, let me know - even an alternate process for cleaning the redirectors might help. I’m not even 100% sure that it is the redirector - is there some way I can tell what the asset is getting from the redirector?
Try migrating your content over to a new, blank project. This is not guaranteed to help but it might address some of the problems. The errors you are seeing are definitely due to folder management. We strongly encourage avoiding moving assets in the content browser at all costs, and only doing so if it is absolutely necessary. At that point the very last thing that should be done is an immediate “fix up redirectors” to prevent said redirectors from complicating the paths that are being utilized.
Wow - ok I seemed to have missed that tidbit. I’ve been moving all sorts of files about in the content browser - Are you suggesting that to re-arrange files, I should use Windows, then manually fix every reference to that asset?
In the meantime, i’ll try the migration and see where it gets me.
OK - I found the problem and resolved it. It had nothing to do with the redirector. It was me. It looks like I must be using ConstructorHelpers wrong. I’ve removed it from the code and just reference the class in the blueprint and its fixed. I’ll have to go back and see what I was doing wrong.