Json import naming issue

[anaanook]

I have content is named "test.json" and the texture is "test.tex.png" Content.Load<TextureAtlas>("test"); Throws an overflow exception. If I change the name of the texture to "test_tex.png", it loads fine. Seems to not like the period demarcation. If this is an issue with monogame itself, please feel free to close, and I will submit it there.

[craftworkgames]

Thanks for letting us know. I suspect it'll be a path parsing issue, probably splitting on the dot or something like that.

[lithiumtoast]

Using Content.Load<T>("path") will attempt to load a .xnb only. If you need to load images from disk directly you can do so by like the following:

Texture2D texture;
using (var fileStream = new FileStream("Content/Sprites/sprite.png", FileMode.Open))
{
    texture = Texture2D.FromStream(graphicsDevice, fileStream);
}

[anaanook]

Ah. Yeah... so, I think this may have been interpreted wrong. My file IS an xnb, and is being built as part of the content pipeline. I wrote it here as .png because that was the source file, before being built through the pipeline. The issue is with parsing a filename that has an extra "." separator in it. Give it a try with a file named "abcd.efg.xnb", In my example ".tex" wasnt an extension, it was using a period as a separator. I know that the content loader doesn't want the files extension.

If you don't want to re-open it fine, but this wasnt a case of user error.

[lithiumtoast]

How XNA/MonoGame works is when you call ContentManager.Load<T> the following is how the file path is intended:

var assetPath = Path.Combine(RootDirectory, assetName) + ".xnb";

I don't see anything at a glance about how an extra . in the path would be problematic. However, this would be a MonoGame issue, not a MonoGame.Extended issue.

[anaanook]

Okay, if you had read the original bug report you'd know its not coming in from a standard image Import, but the image file referenced in a .json texture atlas. I'm pretty sure it was something going on with the textures asset path getting passed around behind the scenes and having the second period removed by getrelativeassetpath being performed on it multiple times.

[lithiumtoast]

if you had read the original bug report

I read what you wrote. You did not include a stack trace, so I don't know if the issue is from MonoGame itself or MonoGame.Extended. I looked at the code or MonoGame, and I did not see anything there, which is immediately evident that the extra . is removed or otherwise problematic.

That being said, it's now apparent that the problem is here. Calling Content.Load<T> does not need the String sanitation as MonoGame can handle it instead.

The code says that the file path has any extension deleted for runtime readers of the Content Pipeline in MonoGame.Extended. Note that this includes bitmap fonts as well as texture atlases. Your use case of an extra . in the file name was not considered or intentionally added for some reason. Anyways, it does indeed appear to be a bug since I don't see why an extra . can't be used in principle.

For the time being, you can simply change the . to another character such as - and things should work.

[anaanook]

Thank you for looking into it, I will try to be more clear with the bug info next time. The 'user error' in this case was me not being thorough enough in my report.