BletchleyGeek

Wouldn't it be nice if we were older Then we wouldn't have to wait so long http://www.youtube.com/watch?v=ZVlVmv0K-pk I wonder whether Brian would like to review those lyrics

76mm has a point regarding the level of training of troops. Something which would work would be that changes in orders (such as removing the current order they're executing and issuing another one replacing it) took an amount of time to register that depended on the training of the troops. Pixeltruppen already carry some inertia with them (i.e. running soldiers might take some time to stop and change direction), but I wonder if such 'delays' are just a matter of the animation having to stop, or that time is actually dependent of how well drilled are those troops (target acquisition ability does indeed vary with training). And JonS remark regarding 'terrain FOW' is totally spot on. Assessing possible approaches to a target and defensive positions both take time - they're required in order to formulate a plan. Recon along possible approaches does take time, either in real-time and WEGO. You need to send someone along that route to see what lies along, and that will delay you in both formulating and executing your plan. One hard-to-get CM skill is that of reducing delays by minimizing the amount of time units are 'idle'. The thing is that in WEGO, the time for the latter, and identifying good hull-down/turret-down positions, isn't 'simulation time' but rather 'wall clock time' (i.e. the time the player spends zooming in and out or panning the camera to inspect the terrain). In real-time, such delay would depend on the level of familiarity with camera controls and clever hot-keys setup. CM is a game where the player is not only the commander, but also needs to do staff tasks. In WEGO mode, going over these doesn't consume any 'simulation cycles'. I think that MikeyD remark about 'self-restraint' referred to keeping in mind this.

This is a good point: I tend to think that the notion of 'acceleration' or 'how quickly a given force can change its mission' is already implicitly accounted for. Consider the following example: You command a force consisting of three infantry platoons: P1, P2 and P3. Each of these platoons has its own objective. As they progress towards it, say that at 30 minutes mark, P1 comes to grief in an ambush, and you assess that its combat power isn't any more enough to subdue enemy opposition. You replan and decide to change P2 mission so that the weakened platoon P1 and the fresh platoon P2 cooperate towards seizing P1's original objective. How much time are you going to need to 1) have P1 to fall back and regroup (so suppression levels and fatigue goes down) and 2) re-orient P2, ensuring security and redeploy any fire support assets? Will depend on the actual situation but it won't be an instantaneous change. That time is indeed 'command delay' (in this particular case it is the time you need to change from an 'Aufstragtaktik' approach or Recon Pull stance, into a 'Befehlstaktik' or Command Push stance). More to the point re: the Italian Army. Perhaps the most important usage of artillery is to suppress enemy positions so you can move with security. Italians have those little light mortars - which are quite an asset - but they usually require LOS to be used (unless you can find a conveniently located reverse slope position so you can use an HQ for spotting and have the mortars fire from a covered position). Italian units are usually either unable or very slow acquiring those fires, and the Brixia mortars will need to maneuver in order to get into position. How long does take for an Italian infantry unit to call for indirect fires or maneuver direct fire support units so to suppress an enemy and be able to start moving? The time you have your force taking cover and basically, sitting on their hands, is also 'command delay'.

This is great news. Not just the very close release of Bagration but also the news about 3.0 upgrades for both CMBN and CMFI being as well in the pipeline. I read that Bagration almost got released in 2013... too bad, and not too bad at the same time, as I wouldn't have had any time for it with all the family leaning on me [] Looking forward to the Bagration AARs, which will probably answering most of the questions I have (such as if it will be possible to split Soviet squads). In any case, kudos to everyone involved in the development of this great tactical wargame!

I DEMAND that Battlefront complies with the state-of-the-art in historical research about the Eastern Front, and provides us with painstakingly detailed tables of equipment for the upcoming Bagration title

Congratulations Vanir

And that's a fairly subjective assessment, Jason. If the null hypothesis is that "the probability of the shot trap happening is less than 0.025" I wouldn't reject it with a p-value over 0.01 (that's 99% certainty). Of course, the grounds on which p-value you select as the one rejecting or accepting the null hypothesis, depend on how certain you're of your claim. Given that we don't know much about the second step in the "panther shot trap" stochastic process, I'd be very very conservative and go for the 0.01 rather than the 0.07 you're happy with PS: It's nice to find someone to discuss statistics with, yet I'm surprised this happened in a forum about a WW2 war game.

I don't think that BFC is making an educated guess: Steve was pretty straightforward about this. He said, literally, that Charles was just letting the "physics" talk. I bothered enough to run the numbers, and calculate the probability of not getting to see one of those lower mantlet hits that enable the shot trap to happen. Even on JasonC scenario where one gets 5 to 10 hits on the Panther frontal aspect, the chances of not hitting the lower mantlet were as high as a 76%. It was also easy to see that in order to be guaranteed to see such a hit, one would need to have about 200 rounds on the Panther frontal armour. Because in order to the shot trap happening, you need 1) to hit the lower mantlet armour and 2) have the projectile ricochet in such a direction and kinetic energy that penetrates the Panther armour (which is what Ken is trying to say and seems to be ignored). Getting a simple probabilistic model of 1) is easy, we've done that in this thread. But 2) is matter of physics, which is probably modeled by a standard Physics equation that uses as parameters the incoming angle, incoming projectile velocity and the characteristics of the plate being hit. Getting a probabilistic model of 2) is not doable without making an 'educated guess' at what physics model Battlefront is using. But we can make a guess: that the probability of 2) being resolved in such a way as to cause a penetration are less than 1, which means that the shot trap is much more unlikely than what the probabilistic model of 1) alone suggests. My educated guess is that Vanir will eventually get to see it if he tries enough times.

A video of a Panther being killed by a T-34/85 because of the "shot trap" would be awesome, indeed

Okay, I miscounted the cells . Regarding to how often you'd see it, the math is easy. probability of the Panther shot trap happening = 0.025 probability of the Panther shot trap not happening = 0.975 probability of the Panther shot trap not happening after x shots = 0.975^x So, say you get 100 shots at the Panther in such conditions that enable the shot trap at all. The chances of not seeing it are an 8%. The number of trials you need to do in order to see this happening with a 99% are about 200 shots. In the situation you describe (the Panther takes 5 to 10 hits to the front) the chances of this not happening are an 88% and a 78% respectively. In order to be guaranteed to witness this, one should see 20 of those duels. I don't think I've played more than three or five scenarios featuring Panthers since 2011, and in many of those I usually kept them hull-down. So I'm not surprised to not have seen this. I am also the kind of person who thinks that OK Corral'ing Allied armour with Panthers isn't the right way to use them in the battlefield. So even in that situation seeing the shot trap to spring would be something rare, and that assuming that the conditions that enable the shot trap to happen remain unchanged for all rounds you put on the Panther. If somebody wants to verify this, he just needs to run a synthetic 1 minute long scenario more than 100 times in order to see this to happen. Or play Barkmann's corner ten times, as if Barkmann had Karl May's novels all over his head. It is a very rare event, so rare that Battlefront should give a prize to the first guy to come up with a Youtube video displaying it

Okay, I went ahead and counted the number of cells for the Panther lower mantlet, and I get 60. Since the whole area is about 56x69 (I think I miscounted), that yields a probability of about 1.5% (or about 99:1 odds). As Steve says, this Panther shot trap thing is very rare. So rare that I wouldn't even factor it in my decision making, I wouldn't ever bet any money against those odds, and I'm not surprised that I have never seen it in my games.

Well, Lock-On Modern Air Combat - the last flight sim I've really played - I think was being quite fair when modeling a hypothetical NATO-Russia conflict over Georgia. Too bad the game just crashed my machine more often than not due to overheating and stuff.

Thank you for your answer on the topic of automated testing, Steve. Regarding the PC vs. consoles: Sony and Microsoft platforms are just dumbed down PC's (very much like a Mac nowadays is just the same hardware, just with a better OS and a snazzy form factor). I don't think the PC is dead, anymore than it was back in 2003 or 2004 when major retailers in the US (like Walmart) decided to just say no to PC games, going overboard with the promises made by Sony and Microsoft of killing the PC as a gaming platform. Yet I do think you guys have quite a beachhead in that more 'mainstream' market, and it is CM Touch. How hard would it be to retool/repackage an experience like the one offered by CM Touch for the XBox One, for instance?

Okay, sburke I'm not coming here to pick up fights, and probably my Spanish upbringing might sound very impolite in settings where the exquisite Anglo-Saxon etiquette is the norm. So bear with me if I sound too harsh (or frank). That's totally understandable and I understand it. My observations regarding testing come from my background on stuff like developing and maintaining a speech recognition and synthesis systems (one that actually worked and was bought off by a big company which shall remain nameless), computer vision systems (reconstructing 3d figures from 2d pictures), and agent-based simulation and artificial intelligence systems. In all those works the team I worked in made good use of 1) actual people testing things and 2) automated testing over benchmarks along with simplistic yet effective programs using heuristics to detect when things go off. This thing of the bad plate / niggardly quality rating assignment is the kind of thing one spots better with automated testing than with human-driven testing. Why? Just imagine you're having a quite massive database of vehicles, each of them characterized by a substantial number of parameters. For instance, let's say you have a parameter that prescribes how probable is a vehicle to catch fire when its armour is penetrated. If that vehicle is a Sherman, indeed, if when assigning this 'ronson' parameter one was too generous (or did a typo when entering the data) it will be quickly spotted since 1) Shermans are all over the place in scenarios and 2) everybody knows Shermans catch fire easily. But what about the Sdkfz 253? Or the Panzer IIIN? Or an early Churchill model? How often does one of those appear in an scenario? How many people have a good sense about what to expect from those vehicles when penetrated? A quite easy heuristic to implement (if the engine allows it, it can take considerable work to retool the engine so it can be harnessed by benchmarks) is just to have a little script that runs a test program that loads the data and generates different penetration events for the vehicles in the database. Say you generate 100 penetration events and you get 0 brewing up results when you were expecting a 50%-50% chance. Then writing to a log "Vehicle X seems to be hard to catch fire, check Y", is quite easy and goes a long way to iron out the problems that complex simulations with many parameters entail.

That's interesting: so CMx2 is actually modelling not only thickness but also manufacturing quality? That kind of confirms that CMx2 succeeds at being featuring very high-fidelity models and hiding those details from the average player.

And here comes sburke, which doesn't read the posts and thinks everyone but himself is an a**hole. Let me quote myself and highlight something I wrote and I think it's quite relevant to: See what AlexUK says, and I don't think I need to further embarrass you pointing out to the thread where one guy probably detected a problem with bad plate data on the JagdPanzer lower hull. Just to mention one example.

I don't think the open beta model would work well with BFC's current DRM system - things could get messy with activations and deactivations (say, you install a beta patch and you want to revert to a 'official' patch, just the first thing that comes to my mind). To be honest, not even Matrix release procedures are agile enough: Steam does and it is indeed leading the way in delivery, completion and sensible DRM policies. I'd suggest BFC to consider getting their products on Steam as a secondary shopfront. Yes, you'll have to pay a fee for that to Valve, but on the other hand, you can give away as many Steam keys as you want (somebody who buys from you can redeem an Steam key) for free. @warrenpeace et al. Anybody promising you that a software product is bug-free is selling you smoke (or smoky snake oil, if you want). There are always bugs, some of them are noticed, some of them aren't. And the regular Joe, in his forties, from Winnetka, Illinois, with a keen interest in history and wargaming, probably hasn't been trained in Q&A: which means learning how to collect data, analyze it and make sense out of it. Most (99%) of the beta-testers you'll find around the wargaming world are well-meaning individuals that probably devote a substantial part of their spare time to check that installers work, games don't crash, models look good, spotting gross ubermodelling problems, etc. There are other things that require much more time in order to be properly identified and possibly require extensive analysis of test runs over benchmarks, and contrasting those results on readily available sources on arcane topics such as as battle psychology or ballistics. The great thing of open betas is that individuals with great deals of time in their hands devote that time to do the kind of painstakingly patient and devoted work that I describe above. Which a great majority of the population find to be a royal pain in the a**. This pool of 'well-educated individuals with lots of time in their hands willing to do hard work for free' is going to become a major asset, if it's not already.

The observation regarding staff work and middle-level officers is very interesting.

I tend to agree, to some extent. Nonetheless, is also true that everyone will at least have one sloppy scenario under their belts as everyone has to learn some new skills. I do also think that some people apply the same ruler to measure the quality of official scenarios and that of third-party scenarios, which I think is also a very unfair and unhelpful attitude. And tools can always be refined so to be more friendly and to allow to reuse more work (like OOB's, although I discovered recently that the Import Campaign OOB feature can be used to great effect for that). I'm pretty sure that JonS, Paper Tiger and the rest of your crew have already generated a substantially long list of feature requests for the Scenario Editor. I can also understand that having the editor being part of the game - and using in-game UI capabilities to a great extent is a big limiting factor in what you guys can do. Having the scenario editor carved out of the game, and deployed a stand-alone application that integrated with the desktop environment (opening the possibility of copying & pasting, for instance) and spawning in a window having the pre-view and deployment, would be a very good thing. But probably you've already thought about this as well

Couldn't help looking at the other pictures you have on your photobucket profile. That Moroccan/Algerian infantry looks very nice

To be honest, if I were the one having to make this decision, I think I'd have done the same, especially taking into account the Real-Time gameplay, which needs the frame rate to be as high as possible (the game is as responsive as possible). Are the load times sensitive to the level of detail? Anyways, good job guys!

In my machine load time has gone up - perhaps a 50%, haven't measured with a stopwatch or anything - but my FPS shot through the roof (and I would say the the shadows and the lighting is considerably better).

If we get Bagration in the next six months, maybe you'll get into the advanced course, right on the road to a PhD ;-) Nice bibliography, indeed.

If all those divorce lawyers gave a just contribution of a 20% of their fees to Battlefront, we would probably get almost everything you ask for

Here I'm assuming a lot, and Phil will probably correct me, but my guess is that BFC engine is implementing some variation of the technique called Cascading Shadow Mapping, which is entirely executed and implemented as little routines (shaders) which are loaded on the GPU very much like one loads geometry and textures, and implemented in the OpenGL 'shader' language. Note that 'shaders' do much more than just 'shadows', they basically allow to control procedurally (i.e. to control programatically) how your hardware rasterizes a 3D scene (i.e. translates geometry, textures and lighting into pixels in your screen). You can also understand them as 'procedural textures'. Before that, i.e. before 2005 or so, soft shadows used to be precomputed as textures (i.e. into image files that one loaded from the filesystem) and a substantial amount of perspiration was required in order to get the good old Texture & Lightning pipeline to do what one wanted with them. The CPU was involved when transferring the textures from your hard disk (or main memory) to the video memory. And even before that, and here I'm talking 20th century, shadow rendering was something only professional rendering environments (such as RenderMan, or 3D Studio) could do, and not in real-time. Entirely in your CPU. EDIT: For a wargame like CMx2, I tend to consider shadows to be a luxury. But man, I do love the immersion they provide.