DAEParser.supportsData assumes ByteArrayData.position is 0

[chfoo]

I found that if I enabled the default parsers and include my own custom subclassed parsers, it will throw an EOF error:

Called from away3d.library.Asset3DLibrary::loadData line 123
Called from away3d.library.Asset3DLibraryBundle::loadData line 182
Called from away3d.library.Asset3DLibraryBundle::parseResource line 449
Called from away3d.loaders.AssetLoader::loadData line 135
Called from away3d.loaders.AssetLoader::retrieveDependency line 204
Called from away3d.loaders.misc.SingleFileLoader::parseData line 149
Called from away3d.loaders.misc.SingleFileLoader::parse line 273
Called from away3d.loaders.misc.SingleFileLoader::getParserFromData line 218
Called from a C function
Called from away3d.loaders.parsers.DAEParser::supportsData line 127
Called from openfl.utils.ByteArrayData::readUTFBytes line 565
Uncaught exception - End of file was encountered

The custom classes I used ParserUtil.toString(data) to convert it to a string similar to the existing parsers like OBJParser. However, DAEParser diverges from the Flash code and uses readUTFBytes() directly which makes an assumption that the byte array position is 0. Since the parsers ahead of it mutated the byte array, this becomes not true.

I guess the best fix is to use existing helper function ParserUtil.toString within supportsData() that sets the position before reading the byte array.

• OS: Ubuntu 17.04 64-bit
• Haxe: 3.4.2
• Haxelib: 3.3.0
• away3d: 5.0.2
• openfl: 5.1.3

[jgranick]

Thank you! I think the following commit may resolve the problem, but please test it and see if it does for you:

b89f3cb

If this is too simple of a solution, using the utility is probably fine. Let me know, thanks 😄

[chfoo]

Thank you, I tested it on Neko, C++, and HTML5 and I can confirm it works now.