PhysicsSettingsDetails exports PhysicalSurfaces incorrectly

(might be fixed still on 4.2)
I exported my newly made list of physical surfaces to an outside ini file using the in editor details settings panel. The result for physical surfaces was:

when it should be:


Can you provide some more details. I’m not able to locate where you’re seeing this information?

Also, are you experiencing any problems with your physical surfaces not importing back properly because of this?

With detailed repro to export and where to check I can test with this with our Live build of 4.3 and our internal build.

Thank you!


I use the export button to export my engine physics settings to an Ini file that I expect to be formatted correctly. It is not.
Each additional entry in the PhysicalSurfaces array requires a + prefix.

When I made the original post and this last post it was not exporting correctly. If it is now than this has been fixed.

Is there an issue with it not reimporting correctly? Everything on my end exports and reimports correctly.

Is this just a suggestion for what it should be? I want to make sure I’m not missing anything here.

Thank you!

Hi Tim,
Has the format of this information in the ini file changed? To get any options to show up in the game, my DefaultEngine.ini needs it to be formatted similar to the above screenshot:


However the Physical Material User Guide says it should be like this:


(The project I’m currently on is using version 4.5.1, I’m not sure what version that documentation applies to).

In addition, none of those settings show up in the Engine->Physics->Physical Surface section of the Project Settings in the editor, it’s just blank (but they do show up in the physics material assets, and blueprint etc). That might be due to some of our changes, but I just want to check if that’s a known issue from that version of the engine?

Things have changed since 4.5.1. The information in that doc is actually from 4.0 and earlier. That document is in need of some love to get it back up to where we are now and we do have a ticket in for this (UEDOC-1011). It’s backlogged at the moment, but for the most part the guide is still fairly accurate from my quick glance. The surface types that go to the DefaultEngine.ini no longer need to have the tag added or restart the engine to get them to show up though.

This is the basics of what it should say now (I’ve just edited out doc file to easily demonstrate):

I hope this helps.