Lucky_Strike

Yes I know what you mean. Problem with BN is it only has five tree types, so it limits what we can do to make a more diverse woodland experience. It's actually a bit odd, since all the games are supposed to be on the same engine which supports at least eight tree types. Some of the trees in SF2 even have individual parts, branches, twigs etc whilst some of it's 3D models use a very different approach for leaves. Maybe with the next engine upgrade (presumably for BN's release on Steam) we could get more tree types in BN, it would be nice, pretty please @Battlefront.com, heck, you can even have some of my tree textures if you want ...

Hahahahah, now I might just have to look into that, my bit of Blender knowledge might just stretch to at least getting a cardboard cutout of a certain royal up a tree. The latest tranche of liggers royals has a Charley that likes to play around with hedges, even has a special favourite coat for the occasion apparently.

Oh how easily he's distracted - my school reports often mentioned this trait. Partly window gazing, partly day dreaming, nevertheless curious. I am supposed to be working on my next big mod project but I got looking at some of last year's attempts in Blender to rework trees and such. Thinking I'd crack two proverbial nuts I decided to see what I could do now that I have a little more (dangerous) knowledge of Blender and the dark arts of 3D. I was going to look again at those beanpoles propping up the bocage when I came across a tree that I had started but could never figure out how to get in the game. I just couldn't export the damn thing from Blender to make anything more than floating broccoli in the distance. Anyway equipped with a bit more patience and a damp Sunday afternoon (though it's now very late into the small hours) I have finally squeezed something out of the Blender tube ... I give you a naturalistic oak ... ... or at least the start of one. The shape is working and I think I can alter it whilst still getting a result out of Blender; what I'm struggling with at the moment is getting the texture-mapping figured out. I have some working whilst other parts are somewhat bedazzled, but I think it's solvable. My question is do you folks want it? A whole forest of these old, leaning trees is a bit much but I guess they could be combined with a straight version of the same tree type for variety. Also a similar model for them apples might be quite nice, ancient orchards and all that. Thoughts people? In the meantime I'm back to the steppe to work on my latest, although I still need to look at the bocage beanpoles ...

Yes indeedy. Bocage and low bocage, and even hedges to a lesser extent, are incredibly flexible for creating interesting ground cover. They can be combined with so many different ground textures and other foliage such as trees, bushes and brush to create a variety of dense cover. I have similarly experimented with using gapped bocage as the basis for thickets in European woods and forests since this is something which is missing as a foliage type in all the games. The results are surprisingly convincing in game and provide both concealment and more or less cover, especially when viewed from ground level.

The files are: german_fueltank.bmp german_fueltank_normal map.bmp german_flamethrower-pack.mdr They are in: flammenwerfer 41 > weapons > normandy v310.brz

Sorry, that's just me thinking aloud - what I mean is why are the original game data files delivered in brz containers that don't get expanded when they are installed? The brzs don't save space, they are not compressed files. We have the tools to open them, so it's not a case of BF not wanting us to see what's inside of the brzs, so I presume it's just a convenient delivery mechanism that is platform-agnostic. One other point is that one big file is quicker to copy than lots of small files, this is especially noticeable on spinning HDD, whereas with modern SSDs and M.2 drives the time it takes to copy so much data is now measured in minutes not hours - I can drag copy a fresh install of ALL the data into my game folder in something like ten minutes per game across my network, enough time to go and watch some kitten videos on YouTube! Not a problem my friend. As I say I've already done most of the work, just a case of tidying up some of the odd files I found, then they're ready. No, I will never be interested in modern games, it's just the way it is ... Once I finish sorting the last bits and when I can find somewhere to store these online I'll let you know, might have to split them up, but will certainly only do one game at a time.

Yes, open. Yes, empty brz with original names just to stop the game from warning me I am missing some files, technically it'll run without these but will warn they are missing at every launch, nothing big. Yes, that's what I did, but then it occurred to me that most mods now are supplied in open folders, not brz files, so why not the stock Data brzs. I tried one any left it open, and the game ran flawlessly. What I haven't tried is using folders with the stock brz names, my aim was to bring all the textures, sounds, etc into one big folder with subfolders for example uniforms, sound fx, vehicles etc reflecting the folder hierarchy that BF use inside the brzs (though I use my own folder naming when I prefer and the game doesn't care so long as it finds the file it needs). What I suggest is keeping a clean untouched, unedited set of the original installed brzs somewhere and then messing about with your own open folders, without the need to re-brz them ever. Brz is just a delivery system so far as I can tell. Yes, once the brz are open they can stay that way. I sorted through the files by simply having two folders open next to each other on my screen, one the expanded original brz and the other my new data folder with subfolders in it for uniforms, vehicles etc. The subfolders can be whatever you want, with as many hierarchical levels as needed, whatever makes the most sense to you. I then started with the oldest brz, so for CMBN it's something like Combat Mission Normandy 1.00a , and just copied all the textures, sounds, 3D models over to their appropriate new subfolder. When that one is done I moved on to the next brz in chronological order, so for example Combat Mission Normandy 1.00b, and so on, copying the files over and, critically, allowing them to overwrite older versions that might exist in the new location. So if uniform-helmet.bmp already exists in the new subfolder and I find another, newer version in a later brz I allow that newer version to overwrite the older one. With files where the naming convention has changed, like the smod uniform naming which was introduced, one has to be more careful. I manually deleted to older uniforms and replaced them with the newer smod versions. If you're unsure it's easy enough to figure out which files are being used but applying the coloured circles on copies of the files. There are a few exceptions, as you have already seen, with things like the new versions of the US faces that don't get used, but if you miss something and it doesn't show in the game it's generally quite simple to get a copy from your original brzs. Be methodical and take your time, don't do it if you are falling asleep at your screen! Or ... Yes it's much easier if I just send you the folders, I only need to do a bit of tidying and they are ready. So long as you understand the process you can then go in and move stuff around to suit your needs. I've pretty much finished it for ALL the WW2 titles. I have no interest in modern games so that's as much as I'm doing. I hope you can understand my instructions, your text is perfectly fine! I don't know if this is something that most people would want and if it's even acceptable to BF. I do it for my own purposes and am happy to share the knowledge with the community, and to send the files to those that might want them to save a lot of work, but I'm wary of posting them for public consumption. Maybe the super mod folders would be okay, but they would contain a lot of other peoples works so again there are perhaps issues. It's all fascinating stuff, but ultimately useful only to a few of us.

These wouldn't be mod folders as such, but rather they'd contain just the stock textures that the game actually uses rather than ALL the years-worth of built-up crud. I will personally use this as the base for my own super mod which would be a data folder where I actually REPLACE stock textures with my favourite mods rather than using the z folder to substitute them, effectively the mods would become the stock textures. The z folder would then only be used for testing new stuff, development etc. Incidentally, I did a quasi-scientific experiment last night - as I was reinstalling a couple of the games (thanks Microsoft updates for somehow ruining the colour rendering of my system!), I ran a before and after loading times test using the virgin game installation as the before and my stripped out expanded data folders for the after. Loading the same game/scenario three times over produced no discernible difference in load times between the data sets. This tells me the brz files are just convenient delivery containers. So as you note, this is more about a cleaner, leaner installation rather than any improvement in performance, though as a caveat, I have no idea how the game accesses the textures during gameplay or if there may be some impact on performance depending also on memory usage and GPU capabilities. It's all a black art to me.

Not convinced by that article that anisotropic filtering will do anything for moiré; though am no expert at pixel level manipulation, happy to admit I could be completely wrong. I can see how mipmapping could be useful, but, so far as I know, the game engine doesn't use those. It has the LOD textures, but I don't think that's what we need to solve the issue. Randomising the texture a bit might help, less regular spacing of the ploughed lines, but I fear it won't be a solution because of the regularity with which the pattern is repeated.

Insurance, I can't afford to loose work in a house fire/flood/freak tornado for instance. Most of these renaming apps use search and replace as one method to rename ie search the selected files for this name pattern: german-wafenss-cammo-helmet; replace with this: smod_german_ss_helmet-soldier They can do whole or part name changes on selected files, so if one has a series of names which are mostly the same: german-wafenss-cammo-helmet.bmp, german-wafenss-cammo-helmet 2.bmp, german-wafenss-cammo-helmet 3.bmp - it can search for the german-wafenss-cammo-helmet part of the file names and replace it with whatever one wants eg smod_german_ss_helmet-soldier to give one: smod_german_ss_helmet-soldier.bmp, smod_german_ss_helmet-soldier 2.bmp, smod_german_ss_helmet-soldier 3.bmp etc - capice? The sounds have a different numbering convention After seeing so much of the insides of the brzs nothing surprises me, there are definitely some nonsensical conventions in there, even found a few raw textures with no colours or even form just odd wire frames, more like templates. I use the exact same technique to figure out what is used, indeed sometimes I found textures that were never used, even in the latest games like F&R Yes I also noticed that, the faces were made sometime ago but the old ones are still used ... I have removed a lot of the old textures and the game runs just fine, still have to do some more scientific tests to see if it speeds up loading, but that wasn't my priority. I do know that there are some textures I will have to check more carefully, some that might not be used but not obvious. Once I have "cleaned" out all the redundant stuff and double checked everything is working I am more than happy to let you have a copy of the "lean" data folders. Interestingly they don't have to be put back into brz format (which barely compresses them or saves any space by the way), the game happily runs from any collection of folders in it's master Data folder. It complains if it can't find all the original installed brz's but it will still happily run. And if a texture is missing the pixeltruppen just appear as black figures, like ninjas As I said previously, I have made an empty set of brzs with the names of the original installed ones to trick the game so it doesn't warn me they are missing. And of course I keep at least one virgin set of the original installed files just in case anything bad happens or in case updates don't like my data folders. Also always have the installers to hand if needs be. For sure, it's taken me longer to mod my games than to go through ALL the brzs for ALL the games I have and strip out all the old crud ... hohum

Yes, just buy everything and you'll effectively get at least one game for free compared to full retail price ...

sounds like a good solution, hopefully BF will fix the IVJ interior at some point.

Jace, not suggesting this isn't the case for vehicle interiors, but alpha channels can have grey values for some textures, plenty of the terrain objects allow for this. I don't know what determines whether grayscale or black & white is used for the alpha in game but quite happy to take a look at this one if you haven't fixed it already.

I do all my development on a Mac which has a facility in the Finder (Explorer) to batch rename files, so it's quite easy to select a bunch of files and add/replace prefixes etc. Still have to check the numbering by hand to a certain extent. I guess Windows has apps that can do the same type of thing. Yeah, I have plenty of extra external storage, but my games rig uses NVMe M.2 drives which are ultra fast and compact but ain't cheap to replace sadly. Also I have to balance my online backups, my work and important personal stuff takes priority then what's left can be filled up with CM stuff, but it's not a big space and none of it's free ... if only!

Yes, there's no bmp with a zero or "1" suffix, the first texture is always in the form mod.bmp* with any subsequent variations in the form mod 2.bmp, mod 3.bmp, etc - * but the caveat remains, there are a few exceptions that you need to watch for (odd spelling, odd spaces and, very rarely, apparent duplication of numbering), these are probably mistakes that BF deemed irrelevant for most people, so have not been corrected as they would doubtless require other code tinkering. The best way is to expand the brz files and check the naming schemata of their texture or sound files then follow their lead, but with the warning that you should only use the very latest* version of a texture as the specific naming example since the installed brz files have plenty of redundant files and revised names. So work backwards through the brz to find your examples, use search carefully to find exact names. * Another caveat being the odd occasion where new files are introduced in a patch, but they are not actually employed in the game - I saw this on a couple of occasions when I sifted through the installed brz files, particularly regarding uniforms; I suspect these cases are unintentional, often they are new files which obviously correct a game bug or somesuch, but for whatever reason they are not being used by the engine and the older version is still in use. One further point that just popped into my cluttered mind - many of the older uniforms and textures DID NOT have normal map files, in itself this is not a problem. But what will happen is that the renamed mod texture WILL employ the new stock normal maps, this CAN be noticeable on your models. To avoid it you would have to make new normal maps or somehow disable to stock normal maps. The good thing is that most of the files in the majority of the games have retained the same naming schemata since their release. CMBN is probably the game with the most changes to names. Since you're looking at renaming old mods to use the newer names it's quite trivial to rename a batch, bung them in your z folder, fire up the game and see what happens. Best case scenario is they work and you can take a pat on the back, worst is they don't work and you can pop them in the nearest trash can. Mostly it's been a learning experience and a way to reclaim quite a few gigs to save me getting a new boot drive. My gaming rig is quite limited for drive space, and my backups were getting out of hand to the point where my cloud capacity was reaching the tier limit and I had to consider extra subscriptions just to back up RT. As you know we have gigabytes of mods whilst developing new mods takes quite a bit of extra space as well. As I said I don't know if there's any performance gain, but there is a certain sanity gain from my point of view along with nice lean installs. It's certainly not for everyone.

As per Mr Kerner's comments, I'm pretty certain smod is used for all the uniform stuff, but YMMV, there may be some legacy bits and pieces, or errors, that contradict this. Couple of years ago I started tinkering with various mods for Panzer troops and SS uniforms, couldn't for the life of me figure why they didn't always show, then twigged the name change! I also discovered that not only did the naming change but in some cases the base models changed such that parts of the uniform were in different places of the bmp file, so they no longer worked even with a name change to the new smod scheme. This all coincided with the release of one of the games, and consequent engine update, but can't remember which. Lately, as an experiment, and partly inspired by what I'd noticed about legacy bmps and mdr files inside the base game brzs, I decided to see what would happen if I expanded ALL the brz files and removed ALL the legacy unused textures, models and sounds. I started with CMBN, as it's the oldest with the most crud inside the brzs. My thinking was that every time I boot the game it has to look through the compressed brzs until it finds the latest version of a texture to employ, surely this is adding work and if it only finds a single version maybe that'll speed up launching etc. Anyway turned into a marathon job - there's a a LOT of crud in the BN files. I organised the files using the BF folder hierarchy that's commonly used inside the brzs - terrain, uniforms, buildings, sounds etc plus subfolders as appropriate, along the way removing gigabytes of unused data from my boot drive. Keeping the pruned folders expanded, not making them into brzs again, AND inside the game's Data folder allows then to act as a kind of massive mod folder, the game still ran quite happily, but did flash a warning about missing brzs. This was easily overcome by making empty brzs with the original file names as installed by the game. Does the game run or launch any quicker? Maybe marginally, hard to say, I didn't do any scientific comparisons, it just felt a bit quicker at the get go. I have saved gigabytes on my boot drive after applying this to all the games. What about updates? I hear someone muttering in the back row. Should work just fine, the update just seems to install a new brz for each update, nothing getting written to the old already installed set. The fake brzs are there, and the game is happy with them, so I'm pretty confident the updates will be as well. And, in the meantime, I've archived the intact originals so I can quickly copy them back as necessary. My plan eventually is to replace original textures in the base set of folders with mods I find that I will always use, so keeping my overall game data footprint much lower, that is to say one file for each texture rather that six unused and one that didn't even come with the game but is what I prefer to use. Basically, so long as the game finds at least one correctly named texture file for a particular model it really doesn't seem to care where that file is in the Data folder, so long as it's there (or in the mod/z folder). Sorry, this is a distraction from your question ... Yes, don't know the why or wherefore of the naming of the textures, but there is no "1" suffix, perhaps it's reserved for something classified and developerish. If you are naming the files mod.bmp, mod 2.bmp, mod 3.bmp etc be on the lookout for spelling mistakes in the file names, BFs originals not your own, and strange spacing in names; I've see names like mod 3 .bmp and mod2 .bmp etc. Finally, if you make a mistake naming the files, say you have a lot of variations and you miss a numbered file like mod 5.bmp, then all the files after mod 5.bmp eg mod 6.bmp, mod 7.bmp will not load. It's not common to have this many variations in the base game, if at all, but some mods can have a lot.

I am no expert on 3D, but I do know a little about moiré in the traditional sense and consequentially why anisotropic filters don't do anything to alleviate it. A moiré pattern is usually caused when two screen patterns interfere with each other, in print this could happen when images that have already been printed, and so made into a pattern of dots, are then printed again so that the dot pattern that makes up the original printed image clashes with the dot pattern of the newly printed image, producing interference. The same effect used to be quite common on older CRT TVs when, for instance, someone wore a striped tie which would clash with the lines that made up the TV screen image. What we see in CM is similar to this, the lines of the ploughed field are clashing, or interfering, with the lines that make up the screen image. Anisotropic filtering is doing a couple of things, the primary objective is to tackle aliasing of surface textures, the jaggies along edges, noticeably in CM the shadows have quite jaggy edges. It also helps to sharpen some details. Ultimately it probably makes moirés worse because of the sharpening. To get rid of the moiré would require the reverse, that is some filter that blurs or softens, or even randomises, the offending linear textures, which we sadly don't have. There are some filters in ReShade that can effect softening and blurring, but I've not had a look to see if we could remove the moiré with them as I only tend to use those filters for screen shots at ground level where moiré is not an issue.

Sounds good

Hah! Bunch of old codgers some of us have a way to go yet. (Not really sure why these emojis come up when I search for old but since you're all old you can have them as well, maybe you have some insight as to what they mean?)

Thanks for info kevinkin.

Had a good look through the various files that make up the interface and text rendering. Sadly I think that the colours are coded into the engine somewhere us mortals cannot access. The 'fonts' bmps are certainly not coloured so I think some coding is adding the text colour. Could push it up to management and make a request @Battlefront.com, if not now then maybe customisable text colours for the next engine ... please.

Ta. I wonder how the scenario works without the mod, relying instead on BF stock F'u'R graphics?

This is a mod pack? Not the winter graphics that came with F'u'R? Indeed we do. Now you can post pics to your heart's content and know that it only cost your soul. Seriously, I've been using Imgur for that last 18 months and I haven't even had a single email from them let alone any increase in spam ... I don't get it but I'm not about to complain.

I went a took a look that same evening and, similarly, could not see any shoulders sticking out. It could be some weird shadow or it happens so quick we don't register it but you happened to capture it. As you say, odd ...