The Steppenwulf

Womble is drawing attention to the fact that the game engine isn't passing events in such a black and white way which you presuppose it is. The parameters for each flag would have to be established in order to then have a messaging system in the UI. Consequently, every other "event" could be a red herring and ends up looking messy and woolly. You know like stray bullets and inaccurate mortar rounds for example. I'm not saying the idea is without some validity or is impossible (running out of ammo is an event of particular note) but my gut feeling is that, generically speaking, this is not so easy to implement in a satisfactory way that can improve on the game and moreover justify the time spent coding it. With regard to the latter point, do you think there are many other things that could be improved upon that should take priority? I do, issues such as better damage modelling on buildings (as has just been mentioned in another thread) and basic vehicle damage is something I personally would like to see in v 3.00. The other point I would make is how such a feature could be implemented without it being a gamey addition that impacts negatively on the spirit of the current game. Who is resistant to change and how did you suddenly manage to jump to that conclusion about the "community"? This is neither fair in this limited context nor helpful to this particular thread discussion.

I recall reading something on this point in a thread previously somewhere. To be honest, I cannot be sure what the response/outcome on it actually was. However, in theory the Normandy v111.brz file will work fine but installing the 1.11 patch over 2.00 will probably write over the v 2.00 .exe so one would then have to re-run the v2.00 installer again and rewrite over the v1.11 .exe. It might be that the installer has been set up so as not to overwrite a later .exe version so v1.11 installer will install the .brz but not the .exe because it has detected that the current .exe is v2.00. However I doubt this. You can check this by noting the v2.00 .exe file size first, then install 1.11 and see if the .exe file has reduced in size. The v1.11 will be smaller, so if it does reduce in size you can then reinstall v2.00. One could of course just copy the v2.00 .exe before running the 1.11 patch then put the v2.00 file back in after. Note though, that in any case, there will certainly be no reason to do a completely fresh install. Perhaps someone else can confirm all this just to be sure (a second opinon is always superior to the one). Hope it was a clear enough explanation anyway.

Further to the answer above; the animations for these models are all in the 1.11 patch installation. If 2.0 should be installed without 1.11 the game reads no animation information and we get the generic pose only.

Erwin - observe the diff on the sleeve lacing (esp where it laces over), the foresight and what I presume is the foresight screw. The difference in bump effect really is stark - one looks dull, flat and far less interesting when compared so directly side by side.

Rambler - a hallmark example of what can be achieved with good normal mapping By the way, are you in the process of redoing your weapons with version 2? Is your previous work available in the repository? I'm guilty of having overlooked weapon modifications for my own install. Either that or I have just missed all such contributions as I have worked my way through the repository material.

There were no normal maps in version 1. BF left these out deliberately. The likely reason would be to test for inital optimisation and performance across the range of systems before adding them at a later point (version 2). Normal maps are not a hard and fast requirement for textualisation of a 3d model. It's just that they will make a 3d model look much better - particularly with light and shading features which will draw out the qualities of the map. If a normal map is not created by the modder the game will continue to read the stock map - just like any other modded/stock file. This is fine for certain changes (which I gave as examples in my previous post) and will make zero difference to the unsuspecting eye in game. If however, one were to change the suggestion of a fold in clothing which was not mapped on the normal then a good eye or the modder might be able to notice such a subtle oddity. This can go up in extremes, so for example, let's say, adding chainmail to a medieval knight but using a normal map created for a model wearing leather would be much more distinct. Therefore, this degree of significant change would certainly require a custom normal map. To do, or not to do depends on the changes made and the exactitude of the modder. Since making a new normal map isn't such a grand investment of time anyhow, it does no harm to go custom - except when merely modding the texture tones, which really would be a pointless exercise.

That's because the modified texture or diff file isn't fundamentally different from the stock version - an example would be if the modder merely intends ro desaturate the image or add decals dirt etc.. Adding belts or medals or anything that you might consider an object will prob need a new normal map depending on the effect and the level of expectation. However, not producing a fresh normal map will not prevent the texture from working. More fundamental changes to the look of the objects will likely require changes to the model itself. Then the model would need to be UV unwrapped and the texture reskinned; a fairly substantial undertaking. The .mdr files are the 3d model files. There is no script that can import the models presently into 3d modellling software. That noone has bothered to attempt producing one is reflective of the fact that there is little point - except perhaps to build new flavour objects - because of the accuracy of BF's own models. Normal maps can be produced in Photoshop (depending on the version?). I suggest you do a search online for how to do this but it is very straightforward. Otherwise there are some standalone nomal map free tools available, of which the best is perhaps "crazybump" - google it to find.

Difficult to understand what this post is getting at but perhaps this might be worth considering: smod_american_m41_uniform 1.bmp From my experience, this file doesn't appear to be read by the game. All the other numbered variants are fine as is the unnumbered one. If I'm correct, any effort to see a change on this particular file will fail - perhaps leaving the modder confused on the cause. Perhaps mjkerner (or anyone else) would like to confirm that this is indeed the case - I could be mistaken - though I would then have to revisit why I was unable to get the texture on this file ref to work also.

Last time I looked I don't think this uniform texture was being read. smod_american_m41_uniform 1.bmp All the other numbers 2,3 etc do as does the unnumbered texture. Perhaps someone else can confirm this before BF waste time testing it for themselves.

^^ this ^^

For CW or just BN?

I thought about this before now also. However I suppose since black smoke actually fades rather than just stops, this might perhaps explain the reason. Providing a more realistic look requires an amended animation sequence to the current loop. I expect it will get addressed soon enough but it may also form part of the broader area of damage modelling such as burned out hulls, broken tracks, displaced side skirts etc...All part of the same box of tricks so my guess is they will all get worked on together at some point.

Some of these pics (not all) look like they have been put through an photo editor with a filter to give them that ww2 colour from b&w look. It works very well though, there's no disputing a somewhat authentic look about them. John Kettler:- I'm interested in how can you tell it's a Pz III Ausf J? It's my favourite tank of ww2 the Pz III, but I couldn't be sure to tell the difference from an Ausf G to an M? In fact I'm not 100% confident I could tell the difference between the 50mm L/42 and the L/60 gun less anything else. I think the L and M had thicker front armour but even that's hard to note without getting very close up and personal.

I've already looked at this also having thought about the possibilities of running a MP operational game - such a concept hinges entirely on being able to process input and output information in an open format such as XML. This would then allow a campaign manager to build a map from tiles on the fly (as you are thinking) but more importantly dovetail the position/progress of units in CM on an external OP map and visa versa. It doesn't take a CM wargamer to realise where the potential for this would be going.... I did actually manage to grapple with and change some of the encrypted bytes in the files which the game sucessfully read, but I melted my brain in the process of trying to crack the algorithm. Unfortunately the first 160 bytes are the only consistent ones in the files and they represent only the scenario/campaign overview data. As Mad Mike says the rest of the information is encypted and it is the same across all the file types. I suggest the reason is simply for compression for ease of transfer, to prevent cheating which could potentially ruin MP play, or possibly even because the BF devs are quite aware (from CMx1 days) that file access is the route to developing an OP campaign and they covered their base on this with the CM2 version.

Perhaps it's a matter of perspective. Having come to CM from other games with some pretty good graphics, slick UI's, award winning audio and having a decent machine that is capable of processing it all, its only natural that I'm interested in CM's community improvements of the stock game. Thus, I can see why, when new players coming to the game from that angle, might well under-appreciate the full beauty of CM particularly when underwhelmed by the graphics of the Demo and most of the youtube videos out there. Indeed, I've had one gaming associate and friend reject CM on this basis and I understand how he came to that rash judgement even if I think it's mistaken. So how many more potential players do the same without realising that community mods can enhance the game to meet such a higher level of expectation?!? I even suspect that many players will come to CM without being aware that it is moddable - perhaps even what a mod is. Personally, I think it's a major selling point of the game, and like the scenario editor, I wouldn't even be playing now if it weren't for these capabilities. Clearly some players don't share that perspective but I'll bet my bottom dollar that they are predominantly players who've been playing CM since CM1 days or hex based 2D games etc.. So yes, to mod or not to mod is a matter of taste for sure, but I hate to think that gamers, maybe coming mainly from playing mainstream games -like myself, might not be exposed to a modded graphical rep of the game that can win or keep their attention enough to see what the underlying game engine does. At which point you're either sold, or you never will be.

I heard of one adult player of a well known WW2 shooter who claimed to wear items of his personal Nazi memorabillia collection whilst playing. Furthermore, he steadfastly refused ever to play as the Soviets although apparently, he reluctantly tried playing as an American in another game once. I guess he just didn't find it as immersive.

What I would add to all the great points made above is don't be put off by the apparent lack of polish in the demo and the stock game. The sheer number of community mods and scenarios out there really lift the game onto a higher plane. There's so much that can be enhanced, discovered and created in the game that the demo provides a mere snap shot of the basic game. I now run more collective mod material than the size of the original game, taking me over a year to assemble. And that's not including the maps and scenarios of which I've probably played around a half of what is actually available.

Just a suggestion: Have you been on the CoH forums and ask if someone can make a mod that's more realistic like Combat Mission but keep in the resource gathering and base building. You'll find more like-minds...

Combining the two tools that Japanzer wrote facilitates the process of taking a QB set up and putting it into the scenario. Unfortunately, whilst it appears to automate this quite well I have never actually performed it myself. It's just one of those things one downloads and never gets round to playing with. Consequently I cannot endorse the method from personal experience (especially because CM v 2.00 may have changed some things that are incompatible with the tool) - I can only go on what I have seen in his videos: Both tools can be downloaded from the repository. VSL's quite right though; competitive balance is a vague construct at best and means even less in scenario battles. If you want competitive fairness - where no player can go down feeling cheated - it's best just to stick with QB play. In other words just create the map, leave out the units and upload it for others for play as a QB map only. In my view well-thought out scenario OOB's predominantly are ones that are appropriate both for the size of the map and its terrain and the tactical nuances that characterize those map features. This is what produces tactically interesting and varied gameplay. You cannot condense this judgement nor the qualities of the final product down to some magic formula of purchase points scoring.

The FOW symbols provide no differentiations of the kind you are claiming. Infantry - the FOW symbol is a generic infantry symbol. The only differentiation in infantry types is an MG team (poss mortars too). That doesn't seem unreasonable when one considers that an infantry squad carrying, deploying or firing a MG or mortar could quite likely be distinguished from a standard rifle squad. There are no other infantry differentiations that can be gleaned from FOW. Only the fully ID acquired icon can yield the specific role type and possible size. Tanks - FOW will only notify the spotter of the category of tank; light or heavy. The player cannot deduce from FOW the specific make or model, less what the "specific calibre" of the weapon is. Again, I find this within perfectly reasonable expectations since the sound of a vehicle or the obscured sight of one in trees is enough only to tell its size and probable role; light support, or heavy or SP, tank hunter etc.. In summary there are only 6 FOW types: 1) Generic Infantry 2) MG (poss mortars) 3) Generic Gun 4) Light Tank 5) Heavy tank 6) Truck Contrast that with version 1.0, there was only the single FOW type which was a contact. Now this is merely a matter of opinon, but in my view version 2.0's FOW is both more realistic and more tactically engaging.

SlowMotion: - What fow features for CM2 do you suggest WOULD make the game more realistic!!

Returning to read up on this thread I feel like it was best summed up by the comments of ASL Veteran's - they extrapolated the issues masterfully. If you didn't read it before, go back and be sure you do!! The only thing I felt more broadly important is that map size and scenario asset choices aren't just restricted to artillery inclusions. As was hinted in the point re Panthers, it does also apply to the number and types of other assets. I mean a battery of flak 88's on a 400m x 400m battlefield with limited los not only ends up feeling like an unsatisfying scenario, it's also counter-intuitive to tactical realities and feels a bit dumb-ass. But then perhaps that's why it feels unsatisfying to me; If by "style" we mean "expectation" which is founded on "discernment". Discernement leads nicely into my main point:- I'm kinda digging this!! However, in my view, this (the thread's substantive issue) has nothing to do with competitive balance. This is about design balance; an instinct for what makes the game interesting. Competitive 'balance' is an expression bandied around by devs and fan-bois of dedicated server RTS arcade 'wargames' as if it's the paradigm for perfect wargame design. I completely concur in this respect though that some of the best war games I've ever played were those that happened to be competitively unbalanced. Unfortunately, such games don't suit players who want to just play that scenario once - from my personal experience it's only when such games are in repeat mode that both players can both experience and then appreciate the distinct challenges presented to each side. Moreover, such games are no less measurable than finely tuned, competitively balanced games, it's just that the evaluation and interpretation of the results are far more nuanced, which is why they often end up commanding more respect by serious players over the long term. Besides this, QB's cater very specifically for the gamey experience, in which case we know where to go to get those particular needs fulfilled. Thus, I think there is some scope for a greater conceptual distinction between scenario and QB's to be drawn and greater room for the community and designers for recognition of such differences. With repect to this I felt that the idea of providing data on results and feedback (as linked earlier by JonS) is a highly commendable one. If scenario designers and players were ever to embrace the beauty of competitively unbalanced scenarios, this is the kind of 'linked in data' that is a neccessity for developing wider participation in 'against the odds' type scenarios.

I'm pleasantly surprised by this information. I think this now warrants a closer look for myself at the campaign script. However, I'm not going to get carried away at all at this stage with any ideas. If I think I have something I will report back. I really need to know now if a H2H (2 player) campaign as mentioned in the previous posts (& as I have quoted from) is substantive fact or just wishful thinking. I must say I'm a little sceptical, but to me it read (& from two separate postees) that it was established in practice. EDIT: This is from the v2.00 manual p100:- The pulse runs a little faster...

Thanks for your response. I'm aware of Mad Mike's .CAM extractor. Yes I know. However, there may be a way to facilitate this that I could provide the practical means. Unfortunately, I have no experience of BF's campaign script. I haven't even ever bothered to look at it so I know not how flexible/inflexible it might be. The burning question in this regard is; is it possible to extract the script to an external document from a CAM file with Mad Mike's extraction tool? And; Is the campaign script only editable/ accessable via the game editor?

and.. How?? - Specifics please!! I assume the flag is a hexadecimal byte change. Do you have the file reference for this flag?? See as far as I'm aware the .btt files. and the .ema files are encrypted archives. This makes it impossible to change just about anything in the files - this is the biggest stumbling block to playing out a multiplayer campaign on an higher operational level. Yes the .CAM files have some accessibility but I was unaware of aforementioned 'flag'. I find this interesting because I've spent some time thinking about this. There is already a piece of software that could take care of many aspects of the operational game. There are many other ways to do it outside a computer - as per Broadswords own "St Lo Campaign and CM maps" and Noobs Campaign ideas. Unfortunately there are massive compromises (as they would testify) many of which you have touched upon in your post. The biggest problem, the way I see it, is that without being able to edit the .ema files (because they are encrypted -understandably so, to prevent H2H cheating), a Campaign Administrator cannot account for dynamic reinforcements as they would apply to an ongoing engagement. For example, assume that George, playing A company, is engaged in a battle on map A with German forces played by Hans and is also engaged in a battle on the right flank on map B with B Company. Assume that, after an hour of battle, A company defeats it's adversaries and C company, which was held in reserve, moves through A company, stealing a flank on the german forces facing B company to assault their flank on map A - which is still being played out. Clearly this is not possible and therefore rules out the application of realistic operational maneouvres above the capacities of a single scenario. Moreover, this is highly unlikely to change because of the very sound reasons (as given above) for protecting the file data - hence the reason why BF have produced no higher operational game layer other than the SP Campaign - which is not the same thing in any case. There are however some pretty interesting ideas that could emerge from campaign design, as JonS indicates, which could be very worthwhile pursuing. Japanzer (I think) wrote an application that uses a screen reader program and records battle results from scenarios. His unit buyer app can then take an OOB from an external document and then put forces into a new scenario. For me this seemed like the only way to take care of this messy business. I was of the understanding that campaigns could carry damaged forces forward?? Would this work for our theoretical H2H campaign - assuming that the byte 'flag' has been identified? Nothwithstanding these questions which are indeed of great interest in themselves, I find it pertinent to highlight that in reality any units that find themselves in battle are unlikely to advance to engage outside battle objectives as provided by orders without suitable recuperation, resupply and receipt of a fresh set of orders. Unsurprisingly, that takes time and explains why fresh battalions, and then brigades, move through their own forces to keep up the pressure on the retreating enemy lines and maintain momentum of attack. Therefore, I question whether there is a need to have units that carry over from one map to the next. Units that engage in battle normally do one of two things; either they fallback through their own lines, and their rear units, and then reorganise before receiving fresh orders, or they advance sucessfully to their objectives where they also reorganise awaiting new orders whilst rear units move through them to exploit. The number of casualties inflicted, tiredness accrued, supplies expended and morale sapped, amongst other factors, all affect the time taken for reorganisation. With the kind of intense firefights the average scenario puts its pixeltruppen through, one wonders if in real life that unit would be on the march again at all but certainly not for a substantial period of time - perhaps 24 hours or more!! In summary, a cleverly written campaign could write this idea into each battle, ideally with the player pre-planning and deciding how to structure his own forces to meet each set of objectives?!??! :confused: Apologies for the long post...