PhilM

Thanks for re-raising this: like the others who have posted, I agree entirely with your OP (this is one of - if not the - biggest barriers to the suspension of disbelief within the game), and the first point above that the effort does need to be put in to fix it. I can remember my first encounter with this, as I minutely manoeuvred the view down the barrel and out of the muzzle brake of a StuG to prove to myself that the weapon was indeed pointing right at the side of a building on which I wanted to area fire from a few hundred metres away (with no intervening obstructions etc of course), only to be told there was no LOS! But I'm curious: has BF ever said WHY this happens now? And as a consequence, what does actually need changing? I wonder if it is as "simple" as (my bold) your intersection of targeting line and terrain element planes point, above? Because, if I understand your point correctly, you can already happily target an empty terrain AS - e.g. on the opposite, facing slope across a valley - if you can see into it? So the targeting line does already interact with empty terrain tiles in which ground level is visible? But what you cannot do is (as I wanted to do with my StuG example!) is simply launch a shell off into the blue and see what it hits. My mind has wandered to the point of asking: does this mean that the targeting calculation needs not only a point of origin from the weapon but also a KNOWN point of impact (which may or may not be the intended target), on which the results calculation is then performed? So, if the target is a unit of some sort, this works. And also with empty terrain where ground level is visible. But if ground level (nor a unit) is not visible, then the targeting calculation does not / cannot work because there is no known impact point, and so you have "no LOS"? This would explain why you cannot do what I wanted to do with the StuG and issue a "FFS, JFTFG" order: the targeting, and hence firing, calculation cannot work without a "known at the point of firing" impact point. (Taking into account in-turn movement, and so including things that become in LOS as the turn progresses.) This may be rubbish! But if it is anything like right, then it is something more fundamental to the CMx2 game world that needs changing to e.g. allow you to area fire across a valley into wooded terrain when we can already happily target the empty terrain AS right next to it?

Vin, Thanks so much for making these available. Just downloaded both of them from CMMods, and had a quick go with them - SO much better than the defaults. Thank you.

You know you want to, really ...

Thanks for that: interesting, and helpful. I guess I would hope that the tac AI, having chosen LOS mode as its default, would switch to cover mode when hits are being taken, and dive for the bottom of the ditch! They don't seem to so far - but I am going by by a (very) small sample, so perhaps other behaviours will appear in other occurrences. Am I correct in inferring from what you say about the 1m and 2m difference that the troops have to position themselves on the bottom of the 2m ditch, and cannot "cling to the sides" at -1m, to get some LOS and some cover?

Anyone else finding these two quirks? I'm playing a MG scenario which has ditches that - I assume - have been created with ditchlock. But: - I can, courtesy of the new, improved speed (thanks BF!) - certainly for small maps - put all the settings at max and get a good frame rate etc: but even at those settings the new ditches disappear as a terrain feature much closer than anything else. Trees, hedges, buildings etc etc are all visible off into the distance, but the ditch appears to have an end slope and revert to normal level terrain quite close. (Should have measured how far away: but only just thought of that ...). Only by moving closer do you see that the ditch doesn't end, but continues ... This a deliberate design feature? - the tac AI seems almost not to be aware of the ditches. I am trying to use the ditches as a concealed route: but the troops are ignoring waypoints placed on the bottom of the ditches and ending turns perched on the normal ground at the ditch edge. This exposes them to fire, and they still seem to perch there ignoring the cover provided by the ditch just beside them? I wondered idly if the two things are in any way linked, in the sense of how the game both draws and uses in the game the new terrain feature?

Or, have you considered if it's a permissions issue? Installing the patches might somehow have affected the permissions to execute the files, and which user(s) may do so? If you right click on the app and choose "Get info", the bottom of that info box shows which users have permission to run the app: after the patch, is that still the same as before it?

Sorry, I know this a "Duh!" question, but are you sure (!) that you have applied the right patches to the right games in the right order? And, anything outside of the patched CM apps not working in the same way? Have you tried booting the machine in safe mode to see if that makes any difference?

I agree with the (my) bold bit above: easier both to work around and if necessary ignore oddities on e.g. LOS and penetration / kill outcomes if they are one small part of a bigger battle. Can be a turn off if you have only a few units and one of them gets screwed! Although only a relative newcomer to it myself, I would also recommend H2H play as opposed to v the AI. You get much more realistic reactions to and interactions with whatever you do yourself: much more compelling. Sure someone will take you through a PBEM game to start you off. (Me, if you like!)

If the guys on the help desk have been looking at this and cannot find anything then the rest of us don't stand much chance! When you say neither game will open or run after patching, how are you trying to start them? From Launchpad? Via an alias? Right or double left clicking directly on the app icon? And what actually does happen, if anything? Any error messages? And as Childress says, what, if any, anti-virus are you running?

That's really very helpful ... not. Please take your Mac issues to another forum: perhaps one where the average age is around 12?

The 2.11 Feature List includes "bridge navigation problems corrected". Having just installed 2.11 I was hoping to see the issue in my OP resolved. But a quick try shows that - for this bridge anyway - the vehicles still act as they did before??? Anyone else still see this?

Plus 1 to this: given that objects such as walls etc exist in the 3D battlefield world and e.g. stop rounds (or not), and can be destroyed to reveal LOS that they previously blocked, I don't understand why they cannot be targeted as objects in their own right? I've lost count of the number of times I've been in clear LOS to a building elevation and want to area fire on it "just in case", to have the game tell me that you don't have LOS to it (meaning, to the ground in the AS in which the building sits) when in "real world" terms you clearly do ...

Not quite: 2.11 will patch bugs in MG 2.1, as well as updating 2.01 to 2.11 for those that don't have MG - I think!

With apologies to the original poster for hijacking his question a little, is it only me that would like a way out of these different version numbers? My first choice, for more reasons than this, would be to separate the game engine - and have just one current version - for use with any and all the data modules for maps and OOBs. But that ship has already sailed (to the wrong port IMHO ... ). So as a second choice - though I suspect it is not a usual software development nomenclature - could we not have the version numbers made to match across the modules? For example, after CMBN is patched to 2.11 (to patch 2.1 and upgrade 2.01 to the same state), when this state is then also applied to CMFI could it not be labelled as CMFI v2.11 also, not v1.xx (?), so that it is visible from a glance at their version numbers that the games are, or are not, at the same point development-wise, and include (or not) the same game features? The confusion is only going to get worse as Bulge, East Front, etc are published and more sequences of version numbers are created?

Thanks for the update.

OK, thanks for the intel.

Not too much of an issue - so far! I am continuing with the PBEM, and my v AI tries were just re-running the first few minutes several times to make sure that the issue did recur. It is possible to proceed because of both where the problem bridge is (way in my backfield, and so not offering a sideways-on or backwards-on target from the errant pathing), and "when" it is (right at the battle start, and so there seems to be time to wait for the traffic to work through). My concern is that it will be the same for other bridges later in the battle where I expect to be under fire, and could then do without the pirouetting about ...

Just from memory, both the Ferdinand/Elefant and the Tiger II only ever had all-steel wheels for their respectively very different wheel and suspension arrangements, so no rubber tyres for either. Early versions of the Tiger did have rubber-tyred wheels, and these are represented in the game in CMFI. Late versions of the Tiger (as with the Panther) moved to all-steel wheels, as a result of rubber shortages. So a late version Tiger may correctly have all-steel wheels, and IIRC they are also represented in the game in that condition, possibly late in CMFI and / or in CMBN.

Just tried another option: setting a path for a Panther that leads from the road before the bridge, straight across the Beek (=Beck? I didn't know that! Isn't CM educational ...) and back to the road on the far side of the bridge. The Panther will not (cannot?) cross the mud of the Beek, and so does correctly find and use the bridge to cross, but even then when it is doing it under its own steam rather than directed by me, it still does the left-right-left thing: which does look to me like it is following AS edges as it crosses the bridge ...

Ken, in setup I had grouped my guys into mini battle groups (equal strength as near as you can) in which I plan to employ them: a Zug of Panzergrenadiers on foot accompanying a Zug of Panthers and a Drilling 251/21, with a Mobelwagen tucked in a couple of the groups. It is the first such group I am trying to get across, with a Panther leading at normal speed. As the first vehicle on its own, and with a clear bridge in front of it, the first Panther exhibits the "route hunting" behaviour. In later tries the other vehicle types do the same thing. The Panzergrenadiers on foot don't seem to suffer the same problems, running straight down the middle of the bridge ...

Last point first: yep I did try to leave enough of a gap with pauses, and grouped the vehicles into formations I want them to fight in and began to move them by formation, but because of the slow progress the gaps were too short and a minor jam ensued. But I'm reasonably happy that the jam was a result of the difficulties, not the cause of them. Also take the point that there is time, on this occasion: but if it is a point of principal with bridge(s) that may crop up on other occasions when there may not be lots of time ... And yes, it is the bridge just out of the setup zone, over the Hooidonksche Beek. As I experienced the issue in a PBEM game, I have just tried a few turns in a separate v AI game to repeat it if I can. (You are so far away from enemy contact that I've learned nothing new about the opposition in this, honest! Still not seen them at all, in either game ...) I'm playing on a MacBook Pro with integrated HD graphics: not the wizziest performer, but I don't think it is the ATI thing. My AFVs veer left on entering the bridge, then turn sharp right to the right parapet half way across, and then sharp left again to get stuck trying to exit the bridge over the left parapet, and slowly work their way off from there ... This happens with long or short waypoints beyond the bridge, and with the AFV sitting squarely in the middle of the road in front of the bridge before they set off. Even though the path indicator seems to take them right over the centre line of the bridge, they don't follow its line ...

Potential spoiler alert if you don't want to know anything about the Scenario ... I have just begun a PBEM of this, as Axis. There are significant AFV forces which have immediately to cross a bridge to begin to move to contact. Despite many different tries at waypoints at various distances from either end of the bridge, the AFVs do not like crossing it, going through lots of pirouettes at both ends of the bridge and making VERY slow progress. The bridge seems to go diagonally across the action squares themselves, and the line of the ditch it crosses zig zags itself to make an overall opposite diagonal to the bridge across the action squares. The vehicles seem to want to follow a path at right angles to the action squares, not the diagonal line of the bridge, and do not find a straight line from one end of the short bridge to the other. As it is only a ditch the AFVs could probably be directed to cross the ditch without using the bridge at all, but it seems a bit odd to have this bridge right at the start of the scenario and not be able to use it properly? Also, the scenario has a much more significant bridge later on, and I don't want to find the same problem with that one after hours and hours of play! I have seen other references to bridge issues after MG for pre-existing bridges from 2.0: any comments on this one built new in MG?

Steve, thanks for the definitive clarification!

I haven't had a chance to look at the examples you mention, but could it be that these are late variants with all steel wheels, and hence no rubber tyres?

Thanks for the pictorial evidence!