fails when an asset or material contain the string "light' or "sign"

in PrepareAssetsForCookingCommandlet.cpp -

lines 19 & 20 prevent assets with meshes that contain “light” or “sign” from getting packaged

lines 30 & 31 prevent assets with materials that contain “light” or “sign” from getting packaged

This should at least be documented. If not fixed.

I will update the documentation to reflect this restriction for the next release. In the meantime, assets and materials will not be imported if the name includes the string “light” or “sign”. This is because CARLA generates lights and signs based on the .xodr file and importing them from RoadRunner would result in duplication.

note - this also applies to props. e.g. if i have a rock with a material named lightgrey - it will be imported to unreal successfully and I can call it with PythonAPI when running in Unreal. However it won’t be included when packaged.

Maybe if it can’t be packaged, then it shouldn’t be imported?

Preventing the import of these assets would be great but we have little control over what can be imported with unreal, only what gets packaged.

@Axel - Thanks for the info. I’m a relatively new user of Unreal, and still learning my way around it.

I have been spending a lot of time importing/testing maps, props, etc. When working with a build from source, do people ever import/make packages manually inside of the unreal editor? It seems like it could save a lot of time when debugging and testing.

Is there any documentation on how to manually prepare maps to be packaged? (e.g. import assets manually in the editor and after they are verified, use

./Util/BuildTools/ --packages=MyPackage >

to build packages? thanks in advance

@dschambach, sorry for the delay in my reply. these tutorials show you how to import different types of assets:
And how to add them to a compiled version of CARLA:
These processes are a bit annoying but the assets need to be processed in order for CARLA features to work such as semantic segmentation and so on. I suggest using the make import make package commands and not the .sh directly.