"Worldsettings_0 Duplicate level info" Error in 4.22.2

Hi Guys,

I am wondering if anyone has seen this error before, and knows how to resolve it.

Shows up as a “warning” every time i build the level. It is happen on two differnt levels, since 4.22.
I have a subclass that is parented to AWorldSettings, but i’ve been doing this for years and haven’t seen this warning before (so probably irrelevant…)

I have even created a new level, and imported a height map as a landscape, and get this on the new level as well.

Any ideas would be appreciated!

Thanks! <3

I just dug into this same problem in 4.23.0.
It may be because you may started that new level as “Default Level” like I did.

If so, here is what happened:

  1. ‘UWorld::RepairWorldSettings()’ will make a call to ‘ULevel::SetWorldSettings’
  2. ‘ULevel::SetWorldSettings’ makes a call to ‘WorldSettings->Destroy();’, which will be denied because ‘UWorld::DestroyActor will early out if (GetWorldSettings() == ThisActor)’
  3. I fixed this in code (ULevel::SetWorldSettings) by saving OldWorldSettings and then calling ‘pOldWorldSettings->Destroy();’ AFTER the call to ‘WorldSettings = NewWorldSettings;’

If you don’t have code access, you can work around this by choosing to make new levels as ‘Empty Level’ instead of ‘Default Level’

Can confirm this issue exists on 2.23 too. Level in question was saved with old world settings at some point which wont go away. Complains on baking light.

That’s correct sorry i never came back to update, also in 4.23…
With how many bugs i’ve found in 4.23 that’s the least of my worries, lol.

I’ll look more into that small code fix once we get a hotfix for 4.23 :slight_smile:

Thanks guys.

I’m aware that this thread is a few months, but since this was the only thread I found about the error about the “WorldSettings_0 Duplicate level info”, and that i didn’t want to create a new one, here it is:

UE 4.24.1
I get the same error as the original poster during Build.

If i understart the issue, it is due to a bug in he function that should take the data from the default WorldSettings and populate the custom WorldSettings and then delete the old “WorldSettings_0”?

If that the case, is there something I can do to manually fix it, the reason I ask is that I have just spent a day(After creating the custom WorldSettings) adding content to 40+ variables to my 44 maps I have in the project. i would prefer to not do that again.

Or should I just ignore the warning that pops up during builds, because from that I can see, i can access the new variables without issue.
myMapName = Cast<AAA2_WorldSettings>(GetWorld()->GetWorldSettings())->Title;

And hope it will solve itself in a future version of the engine?

Am having this very issue. I’m in 4.23.1. Sadly we are not alone, but at least, we are not alone. :wink:

In my case, when this error started popping up, an issue arose where my key bindings don’t work when a level is opened from my Start Menu. If I open levels without using the start menu, bindings work fine. Opened from my Start Menu, and pressing keys, mouse… nothing. I have escape binded to “quit level”, and curiously that does work in PIE. If launching in standalone, escape does not work along with the rest of the bindings. Hmm.

Having to send around packaged progress demos without the StartMenu enabled, with “game over” state returning the player directly into the first level again. Bummer. Anyone with a solution to this particular outcrop of this duplicate world setting issue? Assuming that is where it’s coming from? I’m guessing this is the case since the key binding issue cropped up the same time the dupey world error arrived.

After migrating to 4.24.2 and seeing that the error didn’t magically went away. So I checked for other possibilities.

Since the error become an issue when I created a new custom class extended from “WorldSettings”, I knew the issue should go away if I deleted the leftover object.

I verified that there is really 2 objects(File/Export All/T3d format), one of the origional class, and one of the new

Begin Actor Class=/Script/AA29.AA2_WorldSettings Name=AA2_WorldSettings Archetype=/Script/AA29.AA2_WorldSettings'/Script/AA29.Default__AA2_WorldSettings'
Begin Actor Class=/Script/Engine.WorldSettings Name=WorldSettings_0 Archetype=/Script/Engine.WorldSettings'/Script/Engine.Default__WorldSettings'

As I mentioned before, I’ve already added a ton of content into the new AA2_WorldSettings class for all the maps, so I could not start over(by copying map map content to the “Empty Map”, World Setting isn’t possible to copy in the GUI as far as I know.

So I created a new “Editor Utility Widget” whos only purpose is, if button is clicked, to delete the actor named “WorldSettings_0”, the name should be the one that was “leftover” when the engine tried to copy over all the attributes to the new class(and failed to delete) Here is the Event graph behind a simple button I added to the widget:

I assume it would be as easy to create a function in C++, but since I’m a bit more “fluent” in BP’s

This is a solution that worked for me. After deleting the leftover “WorldSettings_0” objects from a map I can rebuild without any errors.
I can’t recommend that you use this solution, but that is more that I don’t want to cause you any issues, and leaving the “WorldSettings_0” in the map might be the best way forward. A build error is something you might be able to live with.

But if you try it, make sure that you have full backup of the maps(You will have to run the BP on all maps in the project).

Here is a short video showing the usage of the Widget:


1 Like

@ELiZ_Swe Man thank you! I’ve been looking for this for ages!
Your code could be more simple and more dynamic. This thing happens if you implement your own world settings class, right? I made the same blueprint like you, only just make a check if there is actually more than one world setting, then delete everything what is not my overridden world class
Just make a cast to your worldsettings class, and if failed, destroy actor. Now I dont have to keep seeing the same warning all the time

Seems like Epic finally fixed this in their mainline: