CRourke

Thought that was going to be Yet Another QB Belly Aching Post (or YAQBBAP for short). But I agree with all of your ideas. As much as I'd like to get back to the old, unrealistic, buying of forces with 'points', I'd be happy just to have some sort of vague selection (Gimme a mech company, with some sort of AT section, and medium artillery support)

Sounds like the result would be too complicated. Really, most of us just use it make our units advance in nice pretty formations, generally when they are already in close line of sight. Interesting thought though...

I've also noticed that both vehicles and infantry will occasionally give up trying to reach a destination, sometimes from obstructions, sometimes, 'just because'. They end up quite close to the waypoint, but they don't remove it. As a result, you can miss it, and sit there for a few minutes wondering why they won't follow the new string of waypoints you just issued.

I just remembered another question I have: Is 'rubble' abstracted as cover? It seems to me that it must be, because it would be impossible to model the intricacy of a pile of bricks, to say nothing of the biomechanics that go into tucking a soldier safely into it.

Count me as another one who misses those lines. It's hard to coordinate group movements without them. At the very least, it would be nice to display the movement paths for platoon mates. I think it would also cut down on pathfinding complaints as users wouldn't be as likely to plot intersecting movement orders.

Interesting discussion. I also would like to know what abstractions BF employed. And while a TacAI might be smart enough that you don't need to abstract cover, I don't see how you could program in 'concealment' without major abstractions. Also, people keep referring to the penetration of 'modern' bullets. Correct me if I'm wrong but penetration wise, 30.06 > 7.62mm > 5.56mm As a matter of fact, isn't that one of the arguments in favor of the M14 vs the M4? If those in the know say that mideast construction is light enough that most assault rifle rounds penetrate, I believe it, but I think its fair to say that grand dad's Browning M1919A4 would have also done a fine job. Ditto on the question of light buildings vs heavy. I'm not sure how to tell the difference yet, but I hope it's modeled.

It would be interesting to run some tests with CMSF vs CMAK... To be consistent, try a .50 cal vs squads in buildings.. see how long it takes to achieve 50% casualties.. I might give that a shot when I get off shift. Not sure if there is any other CMAK terrain with a close enough analogue in CMSF.

I wonder if this is a sign that the AI isn't disciplined enough when it comes to holding fire.... I'd think in the real world, enemy inf in hidden positions would wait until a) strykers came in easy rpg range, or infantry dismounted.

I was wondering if perhaps MMG's automatically get the deployed bonus in buildings, to account for using walls and windows in place of the tripod.

But you know, I never minded when CMx1 troops panicked and did something bizarre. I can always write that off as in the realm of possible under the stresses of combat. But show me a tank commander who thinks spinning in circles is a credible response to ambush by an AT team, and I'll show you the one tanker who survived my Arnhem campaign in CC2. I agree AI programming is beyond hard. But most of the problems we're seeing are specific to pathfinding. Pathfinding AI is hard as well, especially when you need to consider enemy fire, but I've also heard its very CPU intensive. So it still seems logical to me that the code might benefit from a little more CPU time.

I think a well designed scenario can indeed have a long opening phase where not very much happens (well, if you think 15 minutes is long). And I liked being able to skip through it in CMx1. But I don't think any changes away from the current system are practical at this point. I'll suck it up and hope that more important issues are addressed first.

I remember in pre CMBO days, the concept of calculating turn results, then displaying them, was intended to conserve CPU cycles. Made a lot of sense then. It seems to me that the decision to abandon that must have been motivated by the desire to move to continuous (real time) tactics. I don't think that the WePauseWheneverThenWeGO is fundamentally flawed, but obviously it must increase CPU load. I'm sure the code is currently written to give priority to the TacAI 1st, graphics second, but executing in real time does kind of tie your hands.. only so many CPU cycles to work with. That, combined with the incredible increase in complexity due to terrain upgrades and 1:1 representation, must make for some challenging coding. I suspect its also a motivated behind the focus on smaller battles. In any case, Itael's speculation was presented in a polite manner, I don't see any need for flippant replies.

I don't think the iraqis would still be fighting us if we'd just blown up more mosques. Nuke'm now, and they'll be making efficient reliable automobiles for us in just 30 short years.

Dang, I'm not seeing that one.. maybe i'm not even running the driver.. or maybe its the logitech keyboard driver that i need to toy with...

Anyone know what the task for the ms intellimouse is called? I'm not seeing anything obvious in processes...