When pathnames to an xmesh file are longer than 255 characters, and the path is set via maxscript, xmesh can’t find the file.
The workaround of putting “\?” or “\?\UNC” in front of the pathname also fails.
Thank you for your report! I have reproduced this problem, and I will add it to our issue tracker.
It seems like I can’t even set the renderSequence to a path starting with \?\ – the first \ gets removed.
You mentioned maxscript, but I assume you are not able to set a long path in any way, right?
Is this important for you?
If i use the manual load option through the command panel, the windows explorer feeds shortened names “\bla~bla~blabla” into the xmesh node, and that works. But all our handling code is automated, so maxscript would need some sort of support too :\
Its kinda important, we run into this every now and again, and most of our scripts we have fixed by adding support by prepending \?UNC\ into the pathnames. But this particular asset has to be rendered in a day or so, so we will rename the objects and redo the export that way. So in other words, would be nice to get this fixed in a future build, but no need to light the emergency fires 
Does the new-world path style work in most places? I’ve been meaning to play around with that but keep forgetting to. I’m just wondering if telling people to throw “C:” into path mapping to become “\?\C:” would be worth playing around with.