PhilM

It is with some trepidation that I offer a view contrary to that of the Oracle, but ... Provided that the original download file was correct and working (sort of like the proviso that the original disc arrived in the mail undamaged and correct ...), then - given hard and optical drive speeds - if you need to reinstall I think it is quicker to do so from the copy of the download file that you keep (along with at least one backup copy ...) on your machine's hard drive, than from a disc??? You need download it only once ...

If - like me - you are a download only person (in my case because of local taxes levied on physical packages) then you cannot pre-order, if BF stick to their usual rules ... Not sure why, as - given that a pre-order system exists - BF could take our orders like everybody else but then just NOT send us the package ... I would happily improve their cash flow by pre-ordering a download-only.

Sadly not! One of the things that continues to bug me ... mostly on the basis that, given that the calculations ARE being done from the relevant waypoint and not from the unit location (as evidenced by, inter alia, the range value, as pointed out above), I cannot get my head around how it would not be easier to draw the line from the point at which the calculations are being made (the waypoint) rather from where they are NOT being made (the unit). Can the line drawing routine not just have the waypoint / calculation origin used as its start point? I guess not, otherwise it would have been done by now! Unless it is deliberate, to avoid giving away too precise information from a yet to be reached location????

You can certainly have two installs ... just to elaborate on the first reply though: Before you upgrade, make a full copy of v 2.12, in a different location to the default install. Continue to use the COPY as v 2.12; let the upgrade install work on the default location, original install of v 2.12, and turn that into "v3.0" (actually, v 2.2 ... don't ask!). Remember to take any mod files out of the original install, that is going to be upgraded, before you upgrade; re-apply afterwards. Also delete any old version saved games from the copy to be upgraded, as you'll need to play them out in the "old" copy. That works for me.

I'm hooked! I want to read the whole story ... novella, or war and peace?

Exactly!! And, it may just be the way my mind works, but - even sticking to the present methodology of seeming to have more than one engine, though there isn't really - a simple nomenclature change for the "public face" of the game, rather than the code build version, would help get around this. It would have been confusing to have "CMRT: v 3.0" be the first iteration of RT. But what if it was called "CM2 v3.0: RT" ... i.e., it's not v3 of RT we are seeing, but v3 of CM2, which is first implemented in RT. Then later we get CM2 v3.0: BN and CM2 v 3.0: FI; etc, etc.

Spare track links: either / or (sometimes both) carried on hangers on the turret sides, to be used as replacements for damaged ones (mine damage, etc), or welded on to "exposed" surfaces as additional armour protection.

I agree, I think you're right: all the calculations occur now after you hit the red button. But I am assuming (!) that the first stage after you hit the red button is to calculate a planned path to the waypoint(s) ... this is where the route can first diverge from what you think will happen (re not using "gaps", etc). After movement starts and contact occurs, "reaction" movement may occur, and all bets are off (quite correctly) in terms of not knowing beforehand what will then happen. It was being able to bring forward, on demand, the first stage which I meant: to see, barring any subsequent contact, etc, what the initial path plotting will be, just to see the route it will attempt to take the unit to get to the waypoint location you have specified ... In most cases it is not an issue, but if some of the terrain is "iffy", this would be a way to confirm how the AI path plotting routine will initially interpret and implement your route planning.

I have been pondering this for a long while: Poesel71's post over on Erwin's minefield thread brought it to mind again and made me think it may be worth posting ... It concerns having the ability to choose (up to a point) the "stance" - to some extent physical, but mainly mental - of your units. How it would work is ... The GUI would be modified to "squidge apart" (technical term) the Team Info panel and the Command panel, to provide space for 5 (?) "radio" buttons (i.e. only one selectable at any one time), that would put the unit in question into different "stances", from the lowest level of activity/alertness/aggressiveness at the bottom, to the highest level at the top. The choice would be subject to: - the game "taking over" and putting the unit into a different mode (the extremes, I guess), based on suppression, morale, C2 (etc); indicated perhaps by a red button, that you cannot move until it goes green; - some options (again, the extremes I think) being "greyed out" and not available for certain units, based on e.g. their experience levels. The command panel would still operate as now: but what would be available, and the actions that would result, would now depend on / interact with the current "stance" of the unit. Lots of options present themselves, but to list a few: - "ambush" type setups could be planned more precisely, sacrificing some cover for the increased likelihood of spotting and making the ambush work by choosing which stance you give the ambushing unit ... - hunting on max alert means going looking for trouble: fire at anything you see. Hunting on next to lowest level (not allowed on the very lowest level?) would mean proceed with caution and stop on contact; etc - target orders on max level means don't worry about saving ammo, fire everything you've got because if you don't use it now ...; target orders on a lower level mean extended suppression fire, conserving ammo; - crawling on max level means an assault-course-type "fast crawl" over a short distance to stay below cover, as opposed to the present "take your own sweet time" kind of thing. There are hopefully lots more ideas / combinations that would present themselves across the range of commands. What do you guys think? Workable? Worthwhile, or a sledgehammer to crack a nut?

What I'd like to see - because the irritating consequences of it not being available have just happened to me again! - is the availability of a "manual" call-up for route plotting preview for a specific unit that will occur in the coming action phase. I had plotted for a tank to go through a nice, tank-sized, gap between two lots of impassable terrain that the mapmaker had kindly left for me to use ... I thought! But although it LOOKED tank-sized, the tank driver decided that it wasn't, actually, and proceeded to drive out of concealment to take a loooong roundabout route to get to its first waypoint and NOT using the gap ... Given that the movement plotting routines already exist, surely it cannot be TOO hard (he said optimistically) to allow us to "call" that, for one unit from its current position to a selected waypoint on its movement path? If you don't find the need, you can ignore it; and done for one unit (at a time), it shouldn't be too lengthy a task? If you want to keep the plotted path (even if wasn't what you first expected / adds intermediate points), just click to accept it. If it shows that what will happen is unacceptable, escape out of it and think again ...

Very impressively reasoned and explained - I understand! Whilst I'd like to give the impression that I'm far too polite to vote "yes" in your poll, I would nevertheless say that, in my - sadly, mostly chastening - experience of CM, this is .... erm ... WAY ott!! Given the vagaries of spotting first (or, often, not first, or at all), missing with the first few shots, and the reaction of taking cover / cowering in response to return fire, I count myself lucky if my guys hit anything at all in a likely target zone, let alone wondering where they may be able to hit something that is six feet high as opposed to something that is four feet high ...:eek:

I agree with your PITA comment! It isn't always easy - and IS always more work than it should / need be - to work out what is blocking LOS when the line originates from the "wrong" place ... But what I don't get is whether BF's apparent low prioritising of this is because it really is a big development time hog, or they just don't think it is a big issue even though it wouldn't actually take that much resource to fix? I'm no programmer, which immediately invalidates what I'm going to say next (but yes, I'll still say it ... ): but given that the calculation IS already being done from the new waypoint location, it seems almost MORE work for the engine to then draw the line from a point of origin (i.e. current location) that is NOT the origin of the LOS result currently being calculated??? (For example, how are the LOS / no LOS portions of the line drawn from the "wrong" place currently calculated in this circumstance, when they cannot (?) result from the LOS calculation currently being performed?) How hard can it be to substitute the waypoint location that is the origin of the current calculation into the routine that draws the line, and so use it as the origin for that also, and thus then to display accurately the results that have already been calculated? Unless (trying to answer my own question ...) it could be related to some aspects of the LOS map and the detailed specifics (e.g. height of observer) of the LOS calculation being available in full only from the current location and unit in question, and that information is not (?) available in full for the future waypoint calculation? (So, in essence, we are getting a different / "lesser" LOS calculation from anything other than the current location?)

Have you "only" tried to find them in the game? (Not unreasonably, as they should be there!!!) Or have you used Finder to search the directory structure, to see if the files are there, but just not showing up "in game"? If you try the latter and the files ARE there in the installed package, but just not showing up in the game, it *may* be a permissions issue: sometimes, some files (e.g. QB maps, or scenarios) are given different user permissions from the main app file itself, and so the game does not have permission to use them and they do not show up ... You can change the faulty permissions, and hey presto ...! Just a thought.

???? I thought that's what I did; now I wish I hadn't ...

You seem to want to have the last word about my pics and my battle: let's just say I've been put in my place, and leave it at that.

No ... thank you! Brilliant!

Well ... given that at the very least he knows it was hit a very high RoF 37mm AP-capable weapon system, it could only (?) otherwise have been an Sd Kfz 7/2? In survivability terms for me (particularly to equal calibre weapons and up), I'm not sure that there's a lot of difference between the two of them, nor therefore too much that I gave away ... Anyway, I thought the pics worth posting to show off Juju's great UI mod, Aris's lovely T-70 mod (along with all the others, of course) and BF's great hit decals showing the cluster of penetrating hits ... that's all!

Womble, your post followed mine - but I'm not sure if yours (esp my bold bit above) was in response to it? Anyway, FWIW, my "resource conflict" concerns were over the dev time required to bring to fruition and implement a realistic, changing weather, routine, rather than in-game processor time resource to run it once built ...

I agree! But: Presumably the former is somewhat less resource intensive than the latter? Rain (etc) doesn't just start and stop immediately, nor stay still; so presumably we need transition conditions and changing weather moving across the battlefield? I'd sooner see the dev resources go to improving (say, as raised in another thread recently) the positioning of and use of cover by troops within and across AS. So, yes please: but not top of the list for me.

Well, my opponent had already seen it kill his T-70; and, erm ... it isn't any longer where it was when I took the pic ...

It's not rifle fire I'm worried about at the moment! My opponent has lots of T-34s as well as the T-70s ... if I cannot keep the Mobelwagen hidden, it will soon be toast ...

Apologies, I'm not certain what you meant? Putting down the transport shields to fire? Anyway, a very cool vehicle to use ... though sadly I expect to find out in the not too distant future how vulnerable they are to return fire ... :eek:

Mobelwagen ambushing an unwary T-70 ... Result!

Erm ... I'm no mathematician (and probably about to reveal that to the world ...), but each of the three new AS (compared with the one larger old AS) need to have their potential LOS - provided that the initial LOS map doesn't permanently rule it out - checked with the three new AS in every other location ... so isn't it some sort of ? x ? x ? calculation for the additional LOS calculations, rather than just four times more? My point - aside from pedantry - being that it is even more of a computer horsepower issue than that makes it seem??? (Or not, if I'm wrong!)

Having tried to understand, and taken a brief part in, some of the other threads referred to in which Steve has explained this issue, this is a pretty darn good explanation and summary of what I understand the position to be. It also gets my vote for the most useful post of 2014; heck, probably of the decade so far!!