Possible bug with (seamless) servertravel

Hi guys,

I have encountered a problem where the game would get stuck on the loading screen trying to load a new map

I have a map called TestLevel_1 placed in a folder called “maps” in the root, no issues here.
A thumbnail texture named TestLevel_1 is also placed in a folder called “maps”, however; not in the root folder, it’s withing several sub-folders.

When the command “servertravel TestLevel_1” is run, it tries to load the texture as a map, at least that is what I think.
Here is the error I found in the error log, which lead me to this problem:
[2019.03.31-16.31.18:060][839]LogPackageName: Warning: Found ambiguous long package name for ‘TestLevel_1’. Returning ‘/Game/Effects/Textures/Placeholders/Thumbnails/Maps/TestLevel_1’, but could also be ‘/Game/Maps/TestLevel_1’.

After changing the name of the texture, seamless servertravel works fine.
I am putting this out there in case somebody else has this problem.

I wonder if using “TestLevel_1.umap” would work, have you tried that?

Just for future reference, this is one of many reasons to use standard naming conventions. Textures are prepended with T_, for example. In a perfect world you’d actually have more than that, but that’s a great start. Example, T_TestLevel_1_64x64. Then when you start throwing in splash images for loading screens, it’d be easy to delineate between the thumb and splash without lots of verbiage inside the name of the asset. When you have menu items that are 128x128 (or whatever dimensions), that’s easily discerned as well. So on, and so forth.

Thank you, I will try this. I assume you mean to put “.umap” in the command?

My project is small enough still to implement naming conventions, I have thought about this, I still think it is weird that the Servertravel command tries to travel to a texture.

Yeah exactly, I’m curious if explicitly adding the extension would clear it up if you had a map with the same name as a texture.

It definitely seems odd, but in a lot of circumstances where something seems unintentional there is a legitimate reason behind it. I’m not saying this is the case here, as frankly I don’t have the slightest clue. It does seem odd to me for sure.

In your servertravel command you can write /Game/Maps/TestLevel_1 instead of just TestLevel_1. I think that would probably solve the ambiguity too. Perhaps they don’t check the file type because in the future they might want to incorporate travel to a different file type - maybe an updated form of map. Just a thought. Nice of it to search through the whole folder structure for you though isn’t it?