I have run into this asphalt problem, as well. It was easy for me to fix with images2tga, because I am very experienced in this by now. Somewhere along the way, texture.txt files became mandatory and obviously a lot of content was not updated to reflect this. This to me is a serious quality control issue for N3V. If you are going to change the way things work, then you better make sure the assets you are selling meet your own criteria. Otherwise you are, in effect, selling faulty merchandise and no advice on how to fix it changes that. Why does N3V not just go in there and create those texture.txt files for the asset on the DLS? I don't understand why they let their paying customers get confused and frustrated. It is NOT going to help sales!
Added Note, I went through the list above. I do not have the M120's but I do see them on the DLS, so will get those. I did see Bae Dawe had Faulty Dependecies and it was a streetlight that I had to fix with the same method above, no texture.txt file, so the customer may have an issue with that as well...
When an asset is exported from a 3d modeling program such as Blender, the textures are changed to the internal file.texture format. We can't see the contents because these are binary format when the asset is submitted in Content Manager. When the asset is decompressed when opened for editing, we get the two parts, the texture its self, usually a Targa (.tga) file plus it's texture definitions file, or the file.texture.txt.
This works fine for user-created assets, however, when assets are further compacted as in built-in and old payware stuff Pre-TS12 HF4 that we can export, Content Manager doesn't fully decompress the assets and leaves only the .texture files instead and causes an error because these files can't be read natively outside of the program, and are only read by the graphics engine. Images2TGA is the only tool we have available to us that can read the .texture files and extract the graphics file and the .texture file from that package.
With that said, N3V isn't responsible for this since technically we shouldn't be importing old built-ins and payware, but we do because we need the dependency. I know what will be said, but that's what we've been told and they are technically right here.
What is an issue, however, is the change in suitable formats, or rather the enforcement of suitable formats for graphics. This has caused some angst among the users where the program looks for a .texture file instead of the texture.tga. For this the user needs to create a .texture.txt file with the graphics file in it and TILE=ST or something like it. (I can't remember off hand). This .texture is referenced in the config.txt file, and the asset submitted. (Or committed in TS12 terminology).
But... this was thrown at us as a curve ball because what worked before is not working now, because the rule was enforced without mention. I have a problem with this as well because these changes should be noted in release notes along with the bug fixes instead of leaving stuff for us to find the hard way. Sure it may be documented somewhere and noted that the rules will change, but let us know when they've changed and refer to the documentation if there is any.