TheVulture

Does that mean people who *didn't* pre-order it can go and download it now?

Done a little testing, and I can now make it happen or not fairly reliably in my test scenario. You *can* have back-to-back blast orders quite happily, so my first guess was wrong It depends on the spacing of the houses and position of the blast waypoints. The first rule of blast club is that they will go stationary at the start of the blast move, wherever it is, and try to blow up the nearest wall in the direction they want to move. (So you can have two houses, put a single blast move across the first house and into the second, and they will blow up the near wall of the first house and then run around the outside into the second - which is prefectly reasonable behaviour to my mind. I just mention it so that people know what to expect from a blast). The second rule of blast club is that if there isn't a wall in range (range is around 16 meters AFAICT) they will go prone, wait for the 10 seconds, and when no blast comes get up and do a 'quick' (it looks like) move to their destination. So one explanation is that the blast command path started too far from the house they were to enter, so they changed it to a quick after the wait. How close together were the houses, and where did they waypoints go?

As I understand what you've said: The first command was a single blast move to get into a building. That movement completed, leaving the guys at their final waypoint. You then plotted a multi-stage move involving two blasts (with or without a non-blast move of some sort between them?) Sounds to me like a fairly straightforward bug based on code being written with the implicit assumption that you wouldn't have a single blast move followed by another blast immediately. Can you work around it with blast, short move, blast, or is there not enough ground between the buildings? Or does that fail too? (I would test it, but my lunch-break isn't for another hour...). Either way it doesn't sound like a major problem to fix (caveat that I have no idea what the CM code looks like obviously, but all the ways I can immediately think of coding something like this would make it a pretty simple fix).

Ooh, that could be a nice feature. The swings of fortune as reinforcements arrive can add a fair amount of excitement to a game.

Just something for those who like to read AARs for fun and profit... a link to an AAR (well, a DAR - During Action Report) from a recent PBEM battle I had with BigDork. http://forums.mzocentral.net//index.php?showtopic=18644&st=0 Fairly picture heavy (and I think link-rot has already borked a few of the pics). No great claims to tactical virtuosity or anything, just hopefully some mild entertainment. (And a 2 minute vid at the end that is my first ever attempt at editing together footage from the game.) Enjoy. Or Not.

Most complaints over the last year or so have been about unbalanced forces. Now its fairly clear that the concept of balanced forces is waaay to situational to be tractable for a simple algorithm. So I'd suggest the simple fall back plan of an option to ensure that both sides have the same units. It's not ideal (part of the fun is in trying to figure out what your opponent might have hiding somewhere) but at least guarantees a pretty even match for those times that people are looking for just that. If you have time to kill, you could have a sliding scale of how matched the sides are forced to be, from exactly the same through to the current system (e.g. ranging from 'exact same tanks'; 'same tank unit with possibly different equipment quality, leadership etc.'; 'both have platoon from some kind of armoured formation' through to 'what do you mean you've got tanks? I've only got three guys with a sharpened stick'). Then people can fiddle around to find the level that gives them the mix of balance and unpredictability that they find most enjoyable.

AT the bottom of the forums page there is a "click here for full screen view" link which removes the frames around the page and gives you the forums full screen. The link Melnibone gives is the one you bookmark if you want to come straight to the full screen version (rather than going through the front page and getting the reduced size version).

and the third moving vehicle was a scimitar recon vehicle I believe. The warrior looks like the British army got hold of the new ERLB (explosive reactive lego blocks) and built a vehicle out of them...

Thanks for taking the time to write all that JasonC. Chalk me up as one of those who finds this kind of stuff fascinating (and very much worthwhile to read) but is aware that I don't know anywhere near enough to contribute to the discussion in any useful way.

In the demo scenario, back around 1.04 or so, I had an M1 covering the corner where the Syrian BMPs appear. One appeared just outside the cover arc of the M1, and they both sat there for the whole turn ignoring each other. I dare say it would have responded if fired upon though. Whether that was something that has been tweaked since then I don't know, but it seems to be a cse of sometimes they will stick to their arc, sometimes they will fire at things outside the arc that haven't shot at them, and the difference seems to be lurking deep in the murky depths of the game engine and appears rather impenetrable to the players.

Useful info I'd like to see at a glance would be Taking fire Taken casualties Suppressed Seen enemy unit Out of command range Destroyed (yeah, you miss a unit getting eliminated sometimes if you're not paying attention) The best way I can think of to show this is associated with the icon in some way. Changing the colour is the simplest way, but currently between red / blue, being shaded or normal, or flashing yellow the icon background is doing a fair bit of work already. My preference is for adding a coloured border around the edge of the icon which is colour coded in some way (and can be toggled on or off for those who find it intrusive. Personally I like to watch replays for the cinematic effect, and then again in more of a techinical, info gathering way). The main problem is that you have a number of independent things you want to show, which you can't reasonably do with a single colour. Blending colours gives you useless 'information'. Giving some states priority over others means you still get to miss some alerts that would interest you. Showing all of them separately can get cluttered, and would take much more practice before we could get the information we wanted at a glance (rather than pausing and going back to the last patch notes to decipher the message). One other possible approach is to have a (toggleable) box tucked away on the left or right somewhere where unit icons pop up when something of interest happens (along with a single word of explanation). And clicking on the icon takes you to that unit. (In an 'ideal' world you'd have both, with the box for units off screen, and icon changes for units on screen). But this is getting suspiciously close to an event-log-style affair.

It's not entirely clear to me exactly what they mean. "The projectile... ensures an anti-personnel fragmentation effect in an area of..." could be talking about the area in which a person is virtually guaranteed to be hit by a significant piece shrapnel and disabled or killed. Which is essentially a measure of how many potentially lethal fragments are produced by a shell. 12.9m is the range inside of which there is a guaranteed casualty. Of course, you can also read it to mean almost the exact opposite: outside the 520m^2 area (12.9m radius) there is no significant anti-personal effect at all. 12.9m is the range outside which you are completely safe. And by extenstion, you could take it to mean anything in between - 12.9 m is the range at which the probability of a casualty falls below some significant limit. Re the data Steve provided, the 144m distance from the 105mm shell sounds like it is talking about the range at which the density of fragments falls reaches some threshold below which (rather arbitrarily) chance of a casualty is negligible (it would presumably be a smooth function of distance with an arbitrary choice of when to stop caring about the risk). Plus presumably fragments slow over distance rendering them less lethal, although I have no idea what distance scales that would happen on for various sized pieces of shrapnel. Incidentally, I notice that, fudging for the differences between 105mm and 125mm shell effects, the radii 12.9m and 144m are in a close to 10:1 ratio, so a bit of hand waving suggests that if you are looking at a highly likely kill at 12.9 m (say typically 1 fragment per person-sized space (assuming a person prone taking cover I'd guess)) then you are talking basically a 1% chance of being hit at 144m, which is as good a threshold as any to chose to stop caring about the probability of being hit in a simulation.

There was a similar one - I was testing a scenario on a 2km by 2km map, and at one point an aircraft came in making a run on a tank... and when the bomb landed every single building on the map was destroyed. Quite impressive. No huge crater though

Did a ceasefire and had a look, and there is no vehicle there: The round appears to have skipped up off the ground, creating a nice fireball in the process.

It makes it a lot easier to see the shape of the terrain.

I figured an AP round would go straight through the BMP - it's the secondary explosion that is somewhat mystifying. Maybe there is a second vehicle hiding back there and winning the 'truly unfortunate bastard of the year' award as it gets whacked by accident.

A poor, unsuspecting BMP-2 with it's side facing an Abrams, survives for the expect few seconds. But notice the way the round has caused a big exposion in the BMP, caused a seconday explosion some ten or more meters behind it on a tree (I guess), and the round is still to be seen travelling further on into the distance. Is this some crazy property of APFSDS rounds (I checked that it was those the tank was firing), or some minor quirk of the game engine?

I'm in the early stages of this scenario (just wandered into my first minfield and killed my first RPG team). I've only seen two enemy units so far (RPG, BDRM-2 IIRC) and they've both been facing the wrong way - backs to the US force. The RPG guys refused to turn around even when I started shooting at them (failed to get a screenshot) and spent about two minutes with their backs to me before I got into their trench and killed them. I'm guessing this isn't the intended behaviour Is this one of those 'map has become corrupted in some way' things that other people have had that screws with unit facings? CMSF v 1.08 and Cry Havoc v02.

I'd be fully in support of adding that as a difficulty option. In the situation Steve describes above, it will be the PLAYER's responsibility to ensure team A doesn't get between team B and the tank. If they do they might get clobbered. It will create a very different, but much more realistic playing style. </font>

Just to ask the stupid question... did it definitely survive? All I can tell from the screenshots you posted is that it kept moving - but a tank moving at high speed that is killed will coast for some distance before stopping. If it did slu88's explanation may cover it - it appears to have hit the sloped front of the turret where some of the ERA tiles are, so it is certainly possible.

I suspect that the actual calculating the effects of friendly fire is pretty trivial - a slight increase in the amount of CPU time required to do the extra hit calculations and that is all. But that's not all there is to it. You have to have units' AI responses make allowances for friendly fire, and deciding when to cancel a fire order when a friendly unit moves in to the danger zone (which can vary from weapon to weapon). And there is a very big difference between calculating the trajectory of a single shot and what it hits, versus calculating the danger area of the firing 'cone' (all the possible trajectories a shot might take from a given shooter aiming at a given target - before we even consider moving targets, travel times, area fire orders, spatially dispersed shooters and targets). The danger area of a firing cone projected on to the ground, potentially with different parts of the cone occluded by different objects at different distances, is something I really doubt can be done quickly enough to be useful in CM:SF, which means fudging it, which means errors - possibly glaring ones. And even if you are prepared to have your own forces shoot each other and chalk it up to your own stupid fault 9which is fair enough), an AI player would have to be aware of this stuff to give sensible fire orders or movement orders. Throw in the very important fact that in practice you often have to anticipate where a unit will want to fire and avoid blocking that LoS with movement of friendly forces, and it really is a black hole. Any AI algorithm that is going to look at an AT gun on a map, decide where it might want to fire in the near future (based on where enemy armour assets have been seen recently, and where they were heading) and plot movement orders for its own infantry and vehicles to try and minimize the interruption to the function of the AT gun 9as opposed to parking a half-track in front of it since it is a good firing position), is an algorithm that a) simply isn't going to work, and has no guarantee (after you've spent a month or so developing it) that it is actually going to improve game play as opposed to simply making some horribly exploitable AI behaviour (worst case scenario). There is a very useful rule in software development: don't think "how do I do this right", think "in how many ways can this go wrong". You have to start out looking at the complications that might arise, or what you end up with is code that works fine in the 'textbook' case in your head, but falls over in the real world where 98% of situations are uniquely different from your textbook case in some vital way. So finding a solution to the few examples of how friendly fire should work in your head is trivial. Finding a general solution that is going to be robust in all circumstances, and do so without crippling the AI player, is a whole different story. It really is a black hole, because there are so many potential complications to doing it well. No doubt some of them won't turn out to be problems at all, but you don't solve programming issues by writing something and hoping that the problems aren't too bad - that is a great way to go out of business.

Withdrawing wasn't exactly easy in CM1 either. One of the most useful bits of advice I heard (probably one of JasonC's nuggets) was along the lines of "if you wait until it looks like time to withdraw, you've left it too late". Which I found out when playtesting a scenario of an overwhelming Soviet attack on a German-held village - if I left on turn X, it felt too early. If I thought "I can probably take one more turn before leaving", then almost without fail the squads would be pinned by too much fire to get out of there the following turn, and only a rather mangled squad would make it out out of a whole platoon. If you think "I should probably withdraw now" you've left it too late, and will be lucky to get anyone out of there. Of course there may well be specific issues with movement / LoF in trenches as well.

From that angle, my guess would be 'bugger all'.

CM: Bocage

I may be wrong, but I was under the impression that 'unintentional' friendly small arms fire couldn't cause casualties (unit wanders into area fire target or line of fire of friendly unit targetting hostile). But 'intentional' friendly fire from small arms could cause casualties (when the unit mis-identifies a friendly unit as hostile and deliberately targets it). As I said, I may be wrong, and haven't exactly tested it myself.