$color wont work if you want more then 1 color. and its exactly this crate_01a/b/c thing im talking about, chris - its where the "oh just take the filename and append stuff" thing wont work anymore. its unpredictable, youll need to read the vmts to do it correctly. this isnt needed at all, it would be handy, but it would only be handy if done correctly, if it fucks up at the slightest possible error this shouldnt be done at all. rather program a yet-another-calculator
Flasche, it's as chris said. The crate itself would get a name. Lets call it crate7 So, emp_flasche_crate7 would have crate7a for the redish, crate7b for the bluish, and crate7c for the greenish one. Each texture uses the same normal or diffuse? Then the diffuse would be called emp_flasche_crate7_diffuse, or emp_flasche_crate7_normal for the normal, etc. If the normal or diffuse or whatever is specific to a certain crate, you would add the a, b, and c. Point is that one model (crate7) can have 3 textures (a, b, and c, or nf, imp, and neut if you want to be more specific). All of this goes in the materials\flasche folder, with subfolders for each individual model if they are texture models, or descriptive subfolders for things like buildings, terrain, or otherwise. So, materials\flasche\Crate7 for all of crate 7's custom content. In other words, almost exactly like all of the materials already supplied by valve.
and what if i want to call it in more descriptive way like crate_red/green/blue? its all there in those vmt-files, they follow strict rules, they are text files, text is piss easy to read from, why not simply read them then? you are argueing for bloody hackjobs just to contradict something im saying ... ... pathetic edit: also blight, im sorry, i dont mean to insult you.
Er, why? Just make another vmt with another set of $color values. Voila, different colour. Yeah ABC is a bit nondescriptive, personally for colour variations I do go with _red _blue _green _darkgreen etc if only because I can't actually see colours properly, but it doesn't mess with the covention at all. I would still use ABC like valve does though, say you have door01 and door01a, door01a is usually like a resize or a slight modification of door01, the two are visibly related but you can't quite fit the distinction into a texture name, door01a is easier than door01withalittlethingyonthebottom. Say I have a crate, three colours, normal map, diffuse map. The normal and diffuse maps get called crate(because it's a crate)<number>(because that's how source handles varations on a theme, each new crate type adds one to the number)_diffuse and crate<number>_normal. The VMTs get called crate<number>_red and so on, but the convention is still fine, because crate01_normal and crate01_diffuse are part of the crate01_<whatever> texture. The VMT corresponds to the VTFs that go in it, and each VTF is named according to their place in the VMTs. It's perfectly logical and quite easy to interpret, I know what any given source texture does and what materials it's used in by the filename, at least for the most part. Similarly I can locate the textures for a material by looking at the filename of its vmt. That's what naming conventions are for.
What might be a solution is to format a list with checkboxes or something of used materials and let the user pick the ones he wants in the .res file.
right now it only finds whats in the bsp, Im planning on making every material a leaf in the tree, with all dependencies as subnodes
great job btw. im looking forward to use it. just found out how bad it is to do that all by hand, again ...
I'm working on a way to create a library with all official materials which can be referenced to figure out which materials are custom. Need to be able to read Valves GCF file though. Found a good site with information on the GCF file format: http://www.wunderboy.org/docs/gcfformat.php
Just had this idea, what if I just make a list of all the materials in the empires/materials folder and see which ones are also in the bsp?
