Broken

I didn't know the marking mines issue was a CMSF holdover. It seemed more effective in CMBN version 1.00, but I don't have enough data to prove that. *** Spoiler Alert*** Unfortunately, in School of Hard Knocks, the first AT mine field is right at at the entrance to the only bridge. You can't go around it. There is a strong motivation to get some tanks across that bridge in order to pound the reverse-slope German foxholes 600m distant. I did manage to get one tank through undamaged, which turned out to be enough. Even the immobilized tanks were still useful for suppressive fire, so they weren't a total write-off.

Thanks for the encouragement. I still have half my 105mm ammo left, if that matters, and my infantry losses are only about two squads. It's mainly my heavy weapons platoon that took a beating from the mortars. It sounds like you really know the decision tree for this campaign! I am currently on Bumper Cars. My hat's off to the beta testers. A very nice job.

You are quite right about the scenario. I did manage to get two tanks across, but one had severely damaged tracks and bogged/immobilized soon after. The remaining tank, plus two platoons of infantry and a little 105mm love were enough to force a German surrender. I am not wanking about the scenario itself at all. My complaint is that marking mines seems to be somewhat of an exercise in futility. If spotted AND marked mines still have a 50-50 chance of taking out tanks moving at slow speed, at the very least the game manual is incorrect.

I ran some tests on Version 1.01 with marked mines. As you can see below, the game manual is a bit off when it says "After a minefield is marked by an engineer unit, other units may safely (but slowly) move through it without the risk of setting off additional mines." I tested Regular unbuttoned Shermans in daytime, dry ground. The mines were in short grass and had turned White, indicating they had been "marked". There were three test groups of 49 tests apiece. Test 1: Tanks moved at Slow speed through the mines. 45% struck mines (22/49). Two that struck mines were still barely mobile (track condition one step above red X). Test 2: Tanks moved at Slow speed with 15 second pause in action spot just prior to mines. 51% struck mines (25/49). Two still barely mobile. Test 3: Tanks moved at Move speed through the mines. 67% struck mines (33/49). None still mobile. I also ran these three tests with unmarked but spotted mines. I only ran seven tests per test group, so the data set is questionable. Test 1, Slow: 71% struck mines. Test 2, Slow with Pause: 43% struck mines. Test 3, Move: 71% struck mines. In one test the mines being Marked turned Green, which means they are safe, I believe. The tank driving through struck a mine anyway. Am I doing something wrong here with my "mine passage" tactics, or is there something wrong with "marked mines"?

Are you sure the ground conditions were Dry and the road was paved? In Wet or Damp, I wouldn't move faster than Move, even on dirt roads. Use Slow for moving across hedges, walls, dirt, light forest etc. Muddy is a nightmare except on Paved roads.

I did some rough testing on passing through mines in version 1.00. It seemed at the time all you had to do to pass through marked mines was to move through at SLOW speed with a waypoint plotted in the action spot just before the action spot containing the mines. Like this: SSSSWMSSSSS where each letter is an action spot, W is a waypoint, M is the mines, S is the movement path at slow speed. In version 1.01, at least in School of Hard Knocks, it appears you need a Pause at the waypoint. I will try more detailed testing.

I never played "School of Hard Knocks" in 1.00, but in 1.01 there are a few issues. Good scenario by the way. The constant rush of incoming mortar rounds has scarred me for life. Bridge movement is still terrible: I know this is somewhat of a BFC tradition dating back to the earliest CM1, but there is definitely a zone of frustration surrounding bridges. It is very hard to select units near a bridge, and once selected, it is very hard to plot waypoints near a bridge. In a battalion-size battle like this little honey, one runs out of curse words trying move units across that single damn bridge. Have mercy on us. On map mortars firing smoke: My US 81mm mortars direct-firing smoke would sometimes fire only two rounds (out of ten) before ceasing fire. Even though they had eight rounds remaining, the "Target Smoke" option was greyed-out for the rest of the game. The mortars had taken no incoming fire, so what gives? Marking Mines: In this scenario, the aforementioned bridge has AT mines at both ends. One mine I discovered when it blew my engineer team to bits. I brought up another engineer team to mark the AT mines, which it accomplished in a few minutes (red mine flag turns white). So far, so good. I then moved a tank through these "marked" mines at SLOW speed. BOOM! This was a bit upsetting, so I loaded a save file from a few turns back and repeated this procedure several times. 3/4 times these "marked" mines blew up, disabling the tank. This result was no better than if I hadn't bothered to mark the mines in the first place. Is this a new feature of version 1.01 or am I confused about how to pass through marked mines? EDIT: For marked mines I tried the following: the tank is paused for 15 seconds in the action spot adjacent to the marked AT mines before proceeding at SLOW speed through the mines. This seems to work most of the time. In my version 1.0 experiments, it seemed that all that was necessary was to drive through at slow speed, but maybe I was just lucky(?).

Finally played the School of Hard Knocks. Even though I was forewarned about the deadly German arty in this game, I still took 110 casualties and had only one mobile tank left when the Germans finally surrendered (playing on Elite WEGO). The enemy arty didn't mess up my infantry too much, but it was merciless on my support weapons. I had 4 HMGs, 1 MMG, and 2 81mm mortars obliterated. Hopefully, that doesn't doom me for the rest of the campaign. I sent two platoons through the swamp on the right side of the bridge and then West along the South bank and then scampered up the West map edge, covered by smoke when necessary. I sent one platoon up the middle, which was a mistake. This platoon lost a squad and accomplished nothing except attract German fire. The Mark Mines command is a bit sketchy. I marked one AT mine (it turned White), but a tank which moved over it at Slow speed was still immobilized (Boom!). Another tank moved through an unidentified AT minefield with no ill effects. It seems very random. There are still bugs in the software when bridges are crossed: it is very difficult to place waypoints or even select units when they are near a bridge. The 1.01 patch foxholes actually protect their occupants from artillery! I spent all my 81mm rounds and a considerable amount of tank 75mm trying to dig out the German infantry, but I had to resort to 105mm to get some of them. And the remaining Germans still put up a fight against my two West flank infantry platoons! The US gets way too much infantry in this battle. I just left two whole companies hanging out in the backfield to avoid those nasty mortars. All-in-all a very well designed battle. All those German mortar rounds certainly put the fear of God into you.

Good to see this topic brought up again. The lack of convoy commands or convoy AI has been a bugaboo since CM1.

To paraphrase Bjorn Stroustrup: There are only two kinds of wargames: the ones people complain about and the ones nobody plays.

Yes, I have seen this as well. I had a German 81mm mortar spot an infantry squad at roughly 300m and start lobbing rounds at said squad. The mortar had no target orders and the squad was not firing at anything. The squad was near a TRP. The mortar was Crack with +2 command and within voice command radius of it's HQ. Not sure if this counts as a bug, but it is different from version 1.00

A major reason the 1, 2, 9, and 10 SS Panzer ended up in front of the Commonwealth forces was that the only good roads in Normandy at the time all led to Caen. This worked out reasonably well for the Allies, as the German armour was therefore within range of the Allied naval guns.

I was just in Normandy three weeks ago. In the towns without modern construction, most of the construction is stone and quite old. Small villages and hamlets are stone buildings usually connected by tall stone walls. The older bocage in Normandy today still looks like it would be impenetrable to tanks, but not as impenetrable to infantry as portrayed in the game. A lot of the bocage has been given a "haircut" leaving only the berm. Some of these berms appear to have formed over old stone walls. Sunken roads are quite common in the countryside.

You are exactly right. CMBB is 1st or 2nd on my list of all-time favorite games. The amount of work you guys put into that must have been enormous. I am sorry you got so little back for all that. No good deed goes unpunished.

In many Attack QB maps installed with the game, the attackers setup zone is very small compared to how many units are crammed into it. Small enough that a defender can gain a decisive advantage by barraging said setup zone and inflicting far more damage than the cost of the barrage. This is a rather boring way to win the game and pisses off your opponent to the point where they show up on this forum saying how "dissapointed" (sic) they are in the game. I don't think BFC has to do anything about this situation other than making people aware that it can happen and that fair opponents will agree before hand not to engage in pre-planned arty into attackers setup zone. Yes, there certainly were a number of cases where such tactics worked in real-life, but the defenders were taking a gamble and won. In real-life, the defender does not know exactly where the attackers jump-off line is located. There is no gamble when the attackers MUST setup in a very small zone known to the defender.

Yes, but hopefully all your platform-specific stuff is wrapped in an application layer? Shouldn't it be abstracted away by the time you get to the game logic? For multi-core processing, the critical difference (in my mind, anyway) between multi-thread and multi-process is how data is shared. In multi-thread, everything is shared unless you specifically put it in thread-local-storage (TLS) or on the thread's stack. In multi-process, nothing is shared, not even code, unless you specifically create shared memory between your processes. Although the multi-thread community claims the "share-everything" approach is a feature, some (including myself) see it as highly error-prone, unnecessarily complex, and inefficient for real-world applications. Multi-process is more object-oriented: each process(core) can be designed as an object with well defined interfaces to the other processes. Because data sharing is very controlled, there is much less need for critical sections, semaphores, and other synchronization overhead. In the neural network engine I described earlier, I used a shared block with an empty/full flag as the base primitive of each inter-process interface. Synchronization doesn't get much simpler than that. With any multi-core application, you sometimes need to pay attention to coordinating local cache with main memory. The Intel cache intrinsics are handy for this.

Yes, you have the issue of a huge investment in legacy code. It is rare when that is not the case. Sounds good. I will contact you on what I've learned about multi-core engines after the new patch comes out. You guys are probably memory-mapping data files already, since you are so performance focused. If not, I can send you my crude but reasonably documented Win32 memory-mapping wrapper classes for file memory mapping and inter-process memory sharing. You can find something similar in the boost interprocess library, but the boost interface offers a limited exposure of the API. http://www.boost.org/doc/libs/1_35_0/doc/html/boost/interprocess/shared_memory_object.html

Thanks for being as polite as you have been. This type of discussion can get heated in a hurry. But now you have me interested in the challenges of multi-core game engines....

I agree with you here: it is usually far easier to build parallelism in from the start than to modify a large program to be parallel. But you guys have parallelism already: your engine runs on a CPU plus a GPU. Adding parallelism isn't just about adding threads. I am speaking of multi-process, not multi-thread. Run a separate process on each core. Each process can be single-threaded if you like. The processes share data structures through OS-provided memory-mapping. The interaction is quite similar to CPU-GPU multiprocessing, which I am sure your game engine must employ. It is much easier to migrate most single-core designs to multi-core via multi-processing instead of multi-threading, at least for me. Yes, that is my experience with multi-threading as well. It sucks, although some astro-physics friends have had good luck with openMP on their application. OpenMP does not appeal to a control freak like myself. Multi-processing, however, has worked well for me on a neural network engine I built. This is an app that scales to 5 cores with 80% efficiency, so I get 4 times the throughput of a single core. At 6 GBytes memory footprint, it is not a tiny application. You guys don't script at all!? Python and Ruby have gotten 2X-3X faster in recent years. One of the physicists I know has his postdocs do heavy number crunching in Python which has been pre-compiled into C. I prefer C/C++ with Intel intrinsics for number crunching, but that's because I'm obstinate. Even your GUI is in native C++? That IS old school. Actually, I think your code gets simpler in with multiple processes because you don't need to optimize nearly as much. Optimizing code for speed is a huge complexity driver. I think you guys got frustrated with parallelism because multi-threading is pretty sucky. Look into multi-process instead. It is way easier to design and get big performance boosts.

Interesting. Because to me, it seems there is a lot of parallelism in your application. Line-of-sight, Line-of-fire(?) are not light-weight calculations but are mainly read-only to the database and therefore easy to make parallel. Likewise, path-finding and other AI which can be done independently on a unit by unit basis is a natural for parallel code. I can believe the engine is enormous. My point is that an initial investment in multi-core pays big dividends down the road in product performance and programmer productivity. Single-core optimization becomes less critical, so you don't waste resources on it. One nice advantage is you can run one core process in C/C++ for performance and another in python,lua,ruby, or c# for productivity.

Why aren't you guys multi-core? It doesn't make sense to beat one-core optimization to death when you can easily access four cores on your typical customer's setup. I can understand the reluctance to thread on multiple cores, but why not at least run multiple processes with memory-mapped communication? Even I, not exactly a high powered programmer, have written that functionality in a few man-weeks. Every new PC has at least two, sometimes eight+, cores. I have 12.

Even worse, panicked troops will get up from their prone hide positions and run to more "protective" terrain, even if that terrain is the target of the mortars. I am speaking of on map mortars. I haven't tested if this AI behavior happens when the mortars are off map. I have been using the following gamey tactic against squads on the edge of covering terrain such as dense forest: aim the mortars slightly into the covering terrain. Units on the edge of the impact zone will panic and RUN into the impact zone like they were being sucked down a blackhole. The AI could be improved by treating both on map and off map mortars as indirect fire and have troops hug the dirt whether they are panicked or not. Either that or have them run away from the impact zone, even if that is where the best cover is.

I think your balance is pretty close for human vs human. If you bumped the number of Panthers, you would probably have to bump the number of Shermans 76's, and/or bump to Veteran. The Panthers can't dominate this map like they could a more open map, but dealing with even four of them is still a handful if you are playing against a human opponent (just a guess).

Even the more accurate bazooka, M9A1, is best used under 80 meters for a high hit probability from a Regular un-rattled crew. Hitting at 200 meters is probably <5%. Hitting at 250m is winning the lotto.

A 230 meter kill is amazing. My best was a 160m first-shot kill of a Panther with a M9A1 bazooka. The Panther had just nailed a Sherman through smoke 20 seconds earlier.