TheVulture

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.

This, for me, is where I have issues with infantry sometimes. Even knowing how the commands work reasonably well, it is often impossible to know exactly what the results of a command will be. I've had squads take a beating becaise a waypoint that is several meters short of a corner puts a few men around the corner and draws fire and HE badness on the whole squad. I've had infantry squads be taken out of a fight for five minutes (in WeGo) because I keep trying to position them near a sharp slope (or the lip of the top of a berm) but they insist on taking up positions that are just far enough back that the lip of the slope blocks their line of fire to the targets. Eventually I figured that there was no way to get them to do that - they were either too far back so the lip intruded, or over the lip and fully exposed. So I had to find a completely new position for them. (Scenario designers: beware of trying to position units on cliff tops). And one minor bug/gruntle: when giving movement commands to infantry, the cursor doesn't change to 'forbidden' when over marsh, unlike for vehicles. So I managed to get a get a squad killed by giving them a movement order over marsh without realising it, and instead they went around it into the firing line... but that's a pretty minor problem once you know about it. Conversely, changing to the right pointer icon over marsh for infantry is probably a pretty minor bug fix. It's not that there is anything wrong with the way that infantry position themselves around an action point. It is that the player doesn't know where the troops are going to end up. It would have been easy for me to give a waypoint another 3 meters shorter of the corner in my first example if I had known that one fire team was going to wander into trouble. I would dearly love to see something that indicated roughly where your men will take up positions at their final waypoint (adjusted for the face command naturally). For my money, that is the single biggest improvement that could be made right now. If players can predict exactly what results their orders will have (barring unforseen events) then problems of 'realism' become much less important - people are ingenious at finding ways to use well-defined commands to achieve what they want (witness some of the mixtures of fast / move to contact in CMx1 to get troops crossing open ground to rush into cover and stop there to return fire if they are fired at). Make it so that the results of a move command are entirely predictable, and half the complaints about 'stupid infantry behaviour' will go away. Because 'stupid behaviour' usually means 'something I didn't expect'. The 'crawl of death' ones will never go away of course...

Or to paraphrase into a way that is more intuitive to me, it is less important to have lot of different vehicles etc. in the simulation than it is to make sure that what is in is done to a very high standard. And as long as you have enough in the game to give enough variety for a rich experience. Commercially, these days, it is very important to have a very high visual standard with attention to details. Hence trees and grass moving in the wind, vehicle suspension etc. SO that the trees and vehicles that are in the game as as good as they can be. It is a different design strategy to "simulate a wider range of things to a low(er) standard". Some people may not like the design strategy, but I am also pretty confident that having chosen that approach they should stick to it - everyone would like the results of changing the basic design philosophy mid-stread far less I suspect.