Request: Add file extension to AssetManager's verbose traces

[Snky]

What do you think? I would personally like to know the file extension of the asset the verbose is telling me about. ( am.verbose = Capabilities.isDebugger ) ( AssetManager.as Line 576 )

Example: [AssetManager] Enqueuing 'sTiles' [AssetManager] Enqueuing 'sTiles' [AssetManager] Enqueuing 'sUtils' [AssetManager] Enqueuing 'sUtils' [AssetManager] Adding texture 'sUtils' [AssetManager] Adding texture 'sTiles' [AssetManager] Adding texture atlas 'sTiles' [AssetManager] Removing texture 'sTiles' [AssetManager] Adding texture atlas 'sUtils' [AssetManager] Removing texture 'sUtils'

I found this misleading, as I thought somewhere I'm loading the assets twice over, but it's one trace for the XML and one for the ATF/PNG/ETC.?

But even if I worked that out, I still would not understand by reading the verbose, what was being removed, but I'm going to assume it was the XMLs.

Also, I don't understand why sUtils for example had been added as a texture, and also as an atlas, but I'm not sure if my naming convention made the verbose traces appear vague. (sUtils.atf / sUtils.xml, sUtils is of type TextureAtlas, same applies for sTiles).

[kheftel-old]

I agree 100%. I'd like to be able to retrieve the extension of a loaded asset as well. Currently I have to prepend a type string to each file so I can load files by type, when type could be inferred with extension information (i.e. .tsx and .tmx and .pex are all XML and get lumped together).

As for texture atlases, the asset manager does special processing on them. Once the texture atlas is in the asset manager, it doesn't need the atlas texture as well, so it removes it, because all the subtextures are available through calling getTexture.

[PrimaryFeather]

You're right, it's misleading that the extension does not show up when enqueuing files. I just changed that — please try it out and let me know if that helps!

@kheftel, this doesn't allow retrieving the extension, I'm just logging it now. The reason why I don't use the extension in the "name" used to retrieve an asset is that I want it to be possible to change the file type during development (say, from PNG to ATF) and still be able to get the asset without changing all references. It's also useful if you create a game in an online version, where everything is embedded (→ no file extension), and use the same code for an app that loads the assets from disk.

Do you see what I mean? Or do you have another suggestion that might help you with this issue?

[Snky]

[AssetManager] Enqueuing 'sTiles.atf' [AssetManager] Enqueuing 'sTiles.xml' [AssetManager] Enqueuing 'sUtils.atf' [AssetManager] Enqueuing 'sUtils.xml' [AssetManager] Adding texture 'sUtils' [AssetManager] Adding texture 'sTiles' [AssetManager] Adding texture atlas 'sTiles' [AssetManager] Removing texture 'sTiles' [AssetManager] Adding texture atlas 'sUtils' [AssetManager] Removing texture 'sUtils'

It's better! :dango: I was hoping it would show up for all the lines, but I know you know best. Thank you.

[PrimaryFeather]

You're welcome!

The reason why it only shows up in the "enqueuing" phase is that later, when actually adding the texture, I don't know (care) any longer where the file originated. At that moment, it could be an embedded asset, a file, an URL, an object, etc.

But I hoped since the "adding" / "removing" texts inform about the type of the object instead (texture / sound / atlas / etc.), it's not as important in that phase any longer. :wink:

In any case, it's definitely an improvement, IMHO! So thanks again. :smile:

[kheftel-old]

Yeah, I get it. It does make sense. I can keep naming things "TSXFilename.tsx", "PEXFilename.xml", "TMXFilename.tmx", "SCRScript1.js", etc... I just wish there was an easier way to determine asset type, it just feels a bit clunky. I have several subtypes within XML and bytearray.

[PrimaryFeather]

Mhm, I know that some kind of grouping mechanism would be nice. I'll definitely think about it, Kawika!