Actually, the reverse might be possible if you avoid reading the .gcfs: If the map is linking to a .vmt that you cannot find in the mod directory, it's either an error, missing, or in a .gcf. Either way, you can't pack it, so there's no need to figure out if you should or not. You'll need to read the .vmts anyway, since you want to pack the .vtfs as well, so there's no extra step here. Unfortunately, this only applies to Steamworks mods (e.g. Steampires) that have their 'official' files in .gcfs.
If you copy over a vanilla empires dl to a directory and have the plugin read only the what vmt's are in that directory, it would also work, but I think using a gcf reader that can pull out the names of the vmt's and comparing it to the other list would work best.
I'm not talking about using a list as a reference, I'm talking about using a lack of a list as a reference.
I think metal smith is correct, checking if a material is not present in the moddirectory does not allow us to distinguish between missing or official materials. The main idea I'm having now is: Build a reference list of all materials used by the current mod (maybe we can check the gameinfo.txt to see which GCF's are used). This list would only have to be done once per modupdate and it should be some sort of hashtable for easy and fast lookup. Once its stored somewhere it can be used multiple times. Java Collections and Serialization can do those jobs. Then build another hashtable from the contents of the PAK section of the BSP. Then build a hashtable from all used materials in the BSP. If a material is not present in either of the first 2 hashtables, it custom and should be in the RES file. I found a Java wrapper of HlLib which can open GCF files, couldn't find any documentation on how to use it though... **EDIT* If I'm going to support multiple mods it might be best to store a list for each GCF seperately to avoid duplicates.
Honestly I think the most useful tool would be something you can open, then manually select a bunch of files, and have it compile their pathnames into a res file, because I do keep making typos during the creation process. I don't think it's a good idea to try and entirely automate the process because res files aren't difficult to understand, and having an understanding of them lets you fix a lot of problems yourself. I highly doubt you will be able to actually make a program that does it flawlessly, and unless it does you're still going to have a lot of people (generally the same people as before as they are the ones who don't know what they're doing) being unable to make res files.
Well, the biggest thing is to have a way to tell what materials are used in the map, and then being able to compare that to a list of materials found in the default files. Making the res file for you is arbitrary to me. The list of path names for the materials that are custom is what I really want. Making the res file is easy with that.
First of all, mootant gave me a hard time over this, its materials not textures. I don't think I'll have the time or the stanima to build a program that works out every single dependancy of a map. This would involve looking in VMT files and checking the materials listed there are present too. What I think I'll do is create a hashmap of every official material (From Valve and Empires), which comes with the program. Then it will simply read a BSP, take out all the official materials and put the rest in a RES file. It will not look for files included in the BSP file nor will it check for secondary or even tertiary dependancies.
hmm, if you dont check the vmts you wont get the normal maps and masks and whatnot so your program gets useless for the more advanced mappers ...
The more advanced mappers should be naming their shit very similar to the original name, and should be able to see that flasche_dirt would need flasche_dirt_normal or something like that. This isn't to be lazy, but to help keep track of what all you have put into a map if you've gathered custom material files.
i beg to differ its not that you made 1 texture for a map that it wont be used again for a later map of yours naming it after the map only creates trouble later on
I didn't say It should be named after the map. I'm saying that if you have a normal map for a texture, then the normal map should be named the same thing as the texture it is for, except with _normal on the end or something like that. If that naming convention doesn't make sense....
Map naming is a little silly but naming it after your username is sensible, lets you know where each material comes from. Or if not naming it, putting it all in a folder with your name on it. The best way is probably to put it in a folder with your name, then put it in a subfolder with the map name, and if you use it in another map, copy the file over to that map folder, that way it's more 'these assets are used on this map' kind of thing. Also yes _normal _diffuse _detail _ssbump etc is so sensible I wouldn't have thought it'd need explaining, surely everyone does that already?
ok then what if you got a texture for a crate - well actually 3 textures, a redish one for nf, a blueish one for be and a neutral green one - the diffuse is the same basically, just a different tiniting, so quite obviously you dont need 3 normal maps ... ... where is your naming convention god now?
You mean you don't use the md5 hash of the file's first and last 16 bytes as the filename? Why would you ever think to do something else!?
You make the crate texture so that the diffuse map is greyscale, then use the vmt $color parameter to make the three different tints, meaning you only need one diffuse map, one normal map, and three vmts, not only does this alleviate the problem entirely, but it saves texture memory. Alternatively you could use the regular naming convention and name your things /materials/username/map/crate_01a/b/c.vtf and then your normal is crate_01_normal.vtf. That's kind of an easy question, given that it's answered by just looking at the stock source textures.
