Hi, I’ve found that whenever you compile a blueprint, if that blueprint is instantiated in the level you’re working in, then UE flags the level as modified (ie. places an asterisk next to the level showing it requires a save).
Does this mean the level should be checked out and saved? Is this a bug? I did not really change any actual level data so I am surprised UE wants me to save it. This happens even if you didn’t change anything, or made some trivial change in the BP event graph like moving a node; stuff that shouldn’t actually affect any level references or change the level at all.
This isn’t great if lots of peope are working on the same level file, designers will get confused about when they need to save a level, and cause a source control chokepoint on the map file
If you modify anything the level “references”, then you’ll need to resave the level. You may even have to run a build on the level in some instances.
The level updates itself as you modify BP actors etc that are placed in the level. For example if you change a mesh in a placed BP it will automatically update in the level.
change a sm component to from dynamic to static, or modify shadow settings … level will need to be saved and a light build run.
You have re-stated the current behaviour, but my question is more about whether that behaviour is correct or not.
Blueprints are just a recipe to spawn an actor, i assume the .umap file simply knows to spawn an actor at a given transform (at least that’s how it is in other engines, I’m still quite new to UE). If I change that recipe, nothing should change on the umap side, so it should not need saving?
Of course, if I change some data on the instance of this blueprint (in the details panel below the world outliner), of course the level should need saving. But if we’re changing class defaults or event graph logic, I don’t see why the level should need saving.
One can test this by making some changes to some BP class defaults, compile and save the BP, close the level and do NOT save it when prompted. Re-load the level and of course the changes you just made will be loaded fine. Thus the save was not necessary and this seems like a bug to me?
I don’t see any reason for this behaviour either. In our team, we constantly need to discard changes to the map, since there are no actual changes. Everything works just as well even though we discard changes to the map. This also helps save some git storage space, as the map is a binary file, so it would need to be saved completely to git.
One other erratic thing about this is that if the actor whose blueprint is saved is in multiple levels, then only the one that is currently open records a change.
Also, not every blueprint seems to trigger this. My widget actor does not trigger this, but pawn does.
I am having this same issue. Any solutions. In my case, I have eliminated connections between files in these reference viewer, but still get * added to a widget when compiling the controller. In the reference viewer, shows no connection, and I’ve even switched over to BPIs (Blueprint Interfaces) to support this change from hard to soft references. I’ve even replaced specific variable types, like W_WidgetObjectRef, with ObjectRef and then assign the widget to that variable somewhere else. Again, reference viewer shows no connections between controller and widget now, but when I compile either of them, they both want to mark the other as changed/modified.