PhilM

Touché ....

Which is what I was getting at in offering the vote of thanks to you, kensal, above. I too had seen and commented on Jim's recent post, and I didtn't mean to ignore that at all, but it was your testing and illustration of the issue that - I think - got it resolved so quickly with Steve.

Resurrecting the Panther shot trap conundrum????

Steve, thanks for looking in on this and picking it up: can I suggest that, along with the text change itself, the order of explanation is changed to read more left to right across this section, and - say - paras 8 and 9 have their numbers and order swapped, so that the C2 link explanation immediately follows the chain of command explanation (and as the interface shows them, next to one another). The split of the them was for me part of the problem in the current manual. Thanks Kensal for prompting this.

Another agreement with this from me. This aspect will - or should, anyway - become much more important in v3.x, with ground AA units now able to to fire back directly at the CAS aircraft. Repeated runs by one aircraft over a (relatively) small target area is an invitation to be shot down, and as such was avoided wherever possible.

I had always thought (partly because I believe what I read in the manual ... ) that the answer to this was "yes": so that, for example, to be able to call in higher level off map artillery that would not be part of the structure of the on-map units, there must be an off-the-map C2 link to assets that are controlled by the brigade / regiment?

Yeah, I'm one of those sad people whose first action is to read the manual Now, as to understanding it ...

I'm glad it's not just me ...

But that (my bold bit of your quote above) is not what the manual says ... as Jim said in his post, the manual says that the green light against 1st Platoon when the SQUAD is the selected unit means that the 1st Platoon (not the Squad) is in contact with ITS HQ: the contact status of the squad itself with 1st Platoon is indicated by the presence or absence of the contact method icons (eye, voice, etc) in the Squad's panel? Confuses me too, in that what seems to be happening (e.g. with keeping mortar teams in contact) does not always seem to follow what the manual says ...

AFAIK, I think the opposite is the case: the existing built in wing guns were removed, and the G carried only the 37mm's with 6 rounds of AP per gun. Like to see it in action though!

True: though the TO&E section of the Overview page does incorrectly describe the G - as well as the D - as a "dive bomber". Assuming that we are going to get the G modelled with its two 37mm underwing gun pods, then the description could probably usefully be amended to a more generic "ground attack" (as with the Fw 190) or perhaps even "tank destroyer", rather than "dive bomber", as that latter description was no longer its intended role?

I may be misreading what you say above (my bold bit), but H2HH has nothing to do with uploading the files. H2HH simply copies them from the game's location on your machine to the machine's local copy of your dropbox folder; it is dropbox itself that then maintains the sync between your machine's dropbox copy and the Cloud copy, that your oppo's can then see ... You could use H2HH without dropbox or vice versa. And - though no help to you I know, nor answer to your thread title question - in amongst the games I am playing there is at least one with 15mb + file sizes that upload and download with no problem ... AFAIK my oppo has no dropbox problems with the files either. I don't know if there is a file size threshold above which dropbox "doesn't like to play", to discourage users from large file sizes, but if there is I haven't hit it - yet! Perhaps some other factor of your internet setup? (Upload speeds are - usually - much much slower than download speeds.) Does your oppo have the same dropbox problems with those large files at his end?

So, six screenshots should be plenty then? Unless there are some whippersnappers out there ...

Yep, that's it exactly! Great minds clearly DO think alike ... however the rest of that saying goes

Oops! Sorry - definitely not a good thing for me to quibble with you if you are agreeing with me! Perhaps I misunderstood your post? I thought that the bit of yours that I bolded in my quote of it meant that you thought you didn't need the "path request" feature if you did (sufficient) micro management of waypoints to be "certain" where a unit will go? I was just trying to emphasise that, IMO, the path request feature is still beneficial even under this micro management regime, because even then, if you think you have plotted your way around all obstacles etc, you (or I, anyway!) can never be SURE that your chosen path will be followed (where some problematical aspect of the terrain is involved).

Well, so do I - try to. But the point is that, however precisely one places the waypoints (say either side of a gap, to make the AFV pass through it), you cannot tell until it begins to move - or sometimes even until it gets to the gap but won't go through it - that it won't go the way you want it to. Seeing this detail is my main gain from this. The - slightly different - gain of plotting a long distance waypoint and seeing how the unit would get there, left to its own devices, is useful but secondary to being able to see if units will or will not cross certain specific terrain.

My sentiments exactly! On my bolded bits, above: - sadly I don't think one can "guesstimate" if there is enough room: I'm pretty certain, having spent many minutes/hours trying to do the same thing, that gaps that LOOK big enough on the map will still restrict passage to vehicles (mainly) that, on screen, would fit past. It seems to be impossible to be sure. Almost like the driver doesn't want to scrape the paint from the track guards ... and when you see the state - and places - AFVs actually got into, especially when someone is shooting at them or they have a chance for a shot at someone else, some of the collision avoidance decisions taken by the game end up looking a bit prissy - I would hope (guess) that it would take much less time than 30 seconds, even though I too would wait! Given that my not stellar spec'd Macbook Pro doesn't take that long to process whole turns on large maps, including all the spotting and firing resolutions, I'm assuming that processing one path resolution cannot take that long? But hence the reasoning that it would only be done "on demand", and not happen automatically for all waypoint plots.

I know this has been raised before (probably many times ...), but wanted to bump it back to a new post again: showing movement paths that will actually be used in the turn when the unit in question cannot actually follow the path prescribed by your waypoint(s). The recurrence of this as an issue for me in an ongoing H2H game made me wish for this again so much! But also, a possible implementation method that I don't think I've seen suggested before? (If I'm subconsciously stealing someone else's idea, apologies!) Given that we don't want processor cycles taken up with redundant work, and some people may not want or use this, and even someone like me who would, would only need it occasionally, how about: - if you double click on any waypoint, intermediate or final, the game calculates and sets the actual path that will be taken, with added intermediate waypoints as appropriate, from that unit's current location to the selected waypoint. Thus limited move lengths, for specific units, can be calculated and plotted: you only get the game to show you what might be the iffy bits, where you are not sure what will happen when the move starts. If you want to test lots or a little, the choice is yours. Once plotted after the double click, the waypoint(s) become just as if you had created them yourself - but in the knowledge that the unit WILL now take that route; the waypoints could then be moved and / or deleted (or the movement method changed) just as with user created waypoints. This would allow you to select a unit, set one waypoint where you want it to finish up, double click that waypoint and see how the engine will get you there: if you like it, it's done; if you don't like it, amend or scrap as you wish. Any takers?

Yeah, sorry I didn't clarify my thoughts before I wrote (not a good idea!), and hence conflated two aspects: - wishing to maintain my ignorance of the other side's position; - despite it being an AAR (i.e. after action), and so no "actual" spoiler for you Bill, advance presentation of some opposition aspects might compromise how developments which arose at the time are presented in the AAR. But anyway, I would just prefer the thread to stick to the view from one side, with any views from the other side being in a separate thread which I can catch up with afterwards. Though, as it's not my thread, I'll butt out now ...

I don't know how everyone else feels about this - and I don't want to sound rude - but I hope this is the last of posts "from the other side" in this thread. I know you did helpfully make a prominent "spoiler alert" warning, but I want to see how Bill copes (masterfully, I expect!) with the game's developments and surprises, if he gets any, as it goes along. Can we keep this thread for Bill's posts and our questions and comments on them, rather than adding stuff that neither Bill nor we (I) want to know just now?

How hard it is in absolute terms to spot the still visible portion of the hull down tank I guess would depend on factors like: is it silhouetted against the skyline (not good!); is it turned at an angle to the spotter, such that the "unnatural" aspect of the gun tube is exposed; etc. But if those sorts of factors are assumed to be the same for both the hull up and the hull down samples, isn't it reasonable to equate the changed spotting probability to the portion of the cross section on show that is that still visible versus that being masked? That is, if the hull down tank is front on, and the turret forms, say, 25% of that cross section, then the probability of being spotted when hull down is reduced by 75% of the original value, equating to the view of the hull that is being lost? And the point Steve made about the internal weights given to the different sets of eyeballs does seem to be a likely cause of any issue, if there is one. I don't know if they do now start off at equal shares / precedence? Probably not I assume, as the TC and gunner would have the larger share. But if the driver and W/Op - gunner currently have, say, 30% of the spotting weighting (depending on the view direction), then to lose that in a hull down position is a significant reduction. But if that should only ever have been 10% of the total to begin with, then hull down should leave the tank with 90% of its original spotting capability? Figures of this latter sort of order sound more plausible, on the basis of hull down positions being so favoured. Sure, it gets you cover: but if in the process you also significantly reduce your ability to spot targets in the terrain to which you are going hull down, and allow them to have the same - or more - chance of spotting you than you have of spotting them, then why would you bother? Perhaps you would even lose some rear view in this position? On the basis that the TC, knowing there is no driver / WOp forward view, will replace that by more forward (hull down direction) spotting of his own, at the expense of less all round/rear spotting, which only he has the capability for? Complicated, this ...

Just a hint: you can take this further, and issue more than one fire order per one minute turn ... Assuming you have several targets that you want to suppress, and they are all in LOS/LOF from a few adjacent action spots, then you can: - give the tank a target briefly order (key J) from its current location (gets you 15 seconds of firing), and also a 15 second pause order (key P, pressed three times); - plot a nearby waypoint, target briefly from there again and another 15 second pause order for that waypoint; - plot a third waypoint, and target briefly from there too. Bingo! Three targets hit (hopefully!) in one turn. You do have to be wary, though, of where / how far away you put the fire waypoints. Having given the tank specific fire targets, it will tend to follow those orders possibly to the exclusion of other targets that arise as it moves, and so expose itself to unreturned fire. Best to keep the fire waypoints to an area in which you are pretty sure that the tank will not reveal itself to new enemies it isn't yet aware of ... (ask me how I know that bit ...!)

Most logical explanation so far - go to the top of the class! (For now ...) I'm relieved that a few other people seem to be as sad as I am, and also find this interesting (as well as frustrating ...)

Yep, I get that (my bold bit above); I don't think otherwise, and didn't think what I'd written implied that I did. But if I was unclear, apologies. I'm running out of ways to frame the question; the simplest way I can think of to rephrase it is: why can we not fire (and have the resulting ballistic and physics calculations applied to) a shot that is aimed into an AS that we do not have ground level LOS into, because of a LOS obstruction, but could otherwise hit, as in the firing into woods example? Why does there have to be a target - be it a unit, or a ground level view AS, - available before a round can be fired? Any clearer? If it is simply a BF decision that this would be such an infrequent occurrence that they decided not to allow it, then fine: that's why it cannot happen in game. But this seems unlikely, for one thing because such a choice could presumably be reversed relatively easily coding-wise, and so not require a lot of work to do as has been mentioned? But if the engine's ballistics and physics cannot cope with doing it, why not? This is what I don't understand ... and why I proposed the "known impact point" idea above. In saying that the calculations MAY require a known impact point at the time of firing, I was not implying that the results are worked out by tables, etc. Ballistics and physics apply as the shot is fired and its effects calculated. But the ballistics and physics are being applied only to a - large, admittedly - proportion of the total POSSIBLE firing options, with some options (no "target") excluded? It is this close-ending of the calculations that I am struggling to get to grips with ...

Mmm, sorry that my question must have been a bit too obtuse! I knew this bit (above) already (though thanks anyway for responding): but my question "why" still applies to this. You have to have a target to target (self evidently); but why do we have to have a target - of either a unit or the centre of an AS - to fire at all is what I meant. BF have said (I think!) in threads like the Panther shot trap still not trapping, and half track gunners, that once a round is fired the outcome is purely down to "ballistics". But if you want to "just in case" area fire into, say, woods across a valley on the slope facing you where you cannot see ground level because of the woods themselves, not because of the relative AS elevation itself, why does the engine not permit area fire at all? You may be wasting time and ammo on an empty AS; or you may hit and kill a team, say, without ever knowing it unless and until you get LOS to the AS in question and find the bodies. But if the engine is tracking and computing results for every round fired, wherever it goes, why can't we just fire and see - or not see! - what happens? That was the thought process that led me to wonder if it is because the computations require a known impact point at the moment of firing (though that might not be the point aimed at, as rounds do miss, as I know to my cost ...). So, a round cannot just be fired off into the distance because there is currently no computation of what might happen to it: the round's impact point - and effect - is worked out at the moment it is fired, and that effect can be known only in an AS with LOS? As I said first time, that may be a surmise or two too far; but it seemed to me to provide one answer as to why this works the way it does now.