PhilM

Afraid I use a Mac version, not Windows, so I cannot help much. And as Jim said, I've never seen an error message like this (unsurprisingly, I guess, as this is windows based): but if H2HH won't start, then presumably you aren't even getting as far as being able to look in the log to try and trace the error? If it is any help, there is a new Windows version, 2.11.3, updated 10 days ago (?), that may address some Windows issues. Try that? Available here: http://bit.ly/h2h-helper

Makes sense ... thanks for the info. Hopefully GaJ is poised, waiting - couldn't manage without H2HH, nor bear to wait to play RT!

I can recommend The Few Good Men: http://www.thefewgoodmen.com/thefgmforum/

The latest Mac and PC versions are available here: http://bit.ly/h2h-helper

Will the current (v11.2) version of H2HH work "as is" with RT simply by "installing" RT as a new title? Or does H2HH need to be updated to recognise RT as a CMx2 title?

After pointing out that this post of mine isn't serious support for moeburn's point (indeed, I think moeburn doesn't seriously support his point, as I took it as 99.99% tongue in cheek ), I think your bit I've bolded was the basis of his point: i.e. it is exactly because the game tracks every round, and captures the 0.01% occurrences as well as the 99% occurrences, that there is no computer horsepower left for graphics ... ?? Anyway: my favourite bit of internal modelling - before this! - was inspecting an enemy bailed-out Panther, and seeing the internal faces of the vision blocks present inside the cupola, visible when the top hatch was opened but the TC was no longer there ...

Is this so? (my bold bit above) The OP does say "When the Jeep was the selected unit I could see some enemy units that it could "see"." I thought that, when the (empty?) Jeep is selected, if it has no spotting powers then ALL enemy units should (?) disappear from view, as it - the active unit - cannot by definition see any of them? Perhaps a unit (Spotter, HQ) has been dismounted from the Jeep, but there is still a driver: HE could be spotting the tank????

Steve, don't know if you are sure that it is / have already found a coding glitch to explain this? Just thought I'd chip in that I have been experiencing similar happenings for a while, and wondered what was going on - but finally realised that it is from my sloppy operation of a Magic Mouse with my Mac. I like the mouse generally, and especially the "mini-trackpad" on the centre top surface - very useful for Cmx2 view manipulations, in conjunction with other mouse controls. But I realised that, being careless, in moving from the pad and then trying to right click to deselect a unit, I was pressing too close to the centre of the mouse (there being no "button" per se to find) and getting a left click rather than a right click: in movement order mode, it adds an unintended waypoint. Then a slight movement and pressure to the right, which is what I was intending, gets a right click and the deselection. All went away when I was a bit more careful with my finger! Any similarities?

What? You mean some players think they can sleep when they have a PBEM turn to play??

Agree with this! Given that the LOS is being calculated, and the result shown, from the waypoint and not the current location, it seems almost harder (game engine wise) to show the line from where the LOS is NOT being calculated from (current location) than where it IS being calculated from (waypoint)? I don't know the history, but if LOS from waypoints was an addition to the game, then the LOS check - and the resultant line display - from the current location was the original basis of what we see, hence the line was drawn from the current location. But now waypoint calculations and results are being done, it doesn't seem too hard (??) to feed the waypoint location co-ordinates into the line drawing calculation, so that we see this result on screen? I tend towards the "intuitive" approach to playing the game generally, and to this LOS issue - i.e. not to want "too much" (in my opinion, of course ... ) in the way of LOS tools. But one argument FOR them is that in many cases what I WANT to do is not what we have to do now: - give an order to my guys to go precisely to point XY and look, say, east to see what they can see; - but rather to order them to go to the vicinity of point XY (say, within a specified grid of AS?) and then position themselves to get LOS to point AZ, if they can. So what I want (!) is some sort of "moderated LOS to" type command, rather than "LOS from". Based on absolutely no practical experience of mine at all, it just seems more like the kind of actual order you would give in practice? Where you look from is (very) important, to avoid both taking casualties yourself, if possible, and giving away your own position. But the most crucial factor of all is where you want LOS of, not where you want LOS from? LOS from is the means; LOS to is the end. I have no idea how that could work (or, more likely, not) in the game engine at the moment; but it seems to me to be a more realistic approach to the order, and in its absence a justification for some of the "unrealistic" LOS benefits we may have at the moment.

So that's why CM games are so inspired! I hope you are both still drin ... erm ... taking the liquid vitamin supplements ...

Erwin, you thinking about this, that I posted and we had a brief exchange of posts about? (In the CMFI thread on new ideas): 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? But I wasn't thinking only of "far off" waypoints, but any that seem to cross e.g. narrow gaps or doubtful terrain: just to make sure that the unit WILL follow the (perhaps) "shortcut" that you intend, and not set off on a long-winded, round about route to get to a nearby, as the crow flies, destination. I too would like to see the idea get more traction - if enough of us find it desirable ...

If you have to wait to see them before you complain about them, you're not really trying hard enough ....

I for one would be interested in seeing what you have put together, either posted here or, say, made available via dropbox? Thanks in advance.

The word "never", in the above example, was part of my problem in understanding this. Where I've now got to on trying to grasp this (Steve, if what follows is rubbish, by all means disillusion me, but please don't take away my gold star: that's too precious!) is ... Action squares are (in the context of the game) inanimate objects; they themselves do not / cannot "have" LOS to other AS, but rather offer the opportunity of LOS for units within them to other AS or units. So the LOS map will "never" allow LOS to certain other AS: it is always completely blocked to a specific other AS, regardless of which unit is where in either AS, because, say, of a large hill in the way. Similarly, some AS pairs will always be in LOS: say, two adjacent AS, on the same altitude and both level, just bare earth. Even the lowest, prone, unit viewpoint will always give LOS into that next AS. But in between those extremes, there are many AS where LOS is potentially available for a unit to another AS or to a unit in that other AS, dependent upon which unit, in which "stance", is in one or both AS. The examples that puzzle us come in this third category of AS. But only some of the factors that affect the outcome are illustrated in the graphics we see: e.g. an unbuttoned TC in a tall vehicle visibly gets a different view from the point of his AS where he is positioned than does a kneeling figure. But what about those many factors NOT portrayed nor explicitly represented in the calculation: how tall is the TC, or the kneeling figure? Does a squad member lean out of a window to look across a road? Etc, etc. To cope with all of these grey areas and fuzzy edges, they are abstracted into a LOS calculation that sometimes allows marginal LOS to occur - reciprocally - and sometimes doesn't. But, only in those calculations that fall into my third category of AS relationships: if the LOS map says (truly) "never" or "always", then the fuzzy edges are immaterial. This picture helps me to come to terms with what is going on, and for me makes it easier to accept the outcomes we get, but don't always like!

I read the explanations - thanks Steve - twice (!), still not sure I understand them ... But based on a quote from Steve that "CM understands that the two units already know where each other is and therefore the Action Spots are, for the sake of argument, ignored." ... is this (my bold bit above) because, when the unit in the building is, say, kneeling up at a window and firing out at your guys, it is a unit to unit spot and LOF ... but when they move away from the windows and, say, lie down in the room centre there is no longer a unit-unit LOS, and it becomes - or rather, fails to become - a unit-AS centre LOS, which doesn't exist? So, for as long as the guys in the building are face down away from a wall/window, they too don't have LOS and so cannot fire? Fire is only possible unit to unit, and not unit to AS? Make any sense at all??

Three! Count me in too! Though of course, you are right I can always choose not to use it ... Also, for me it depends WHAT is in the "encyclopedia". If it is a way of more easily accessing the specs of vehicles and units (remind me, what gun does that AFV have? How many rounds of ammo is it likely to have? etc) without having to go outside the game, either to the manual or to Wiki or whatever, then for me that is fine, and presumably relatively easily accomplished. But if - as seems sometimes to be the case - people want it to bring up e.g. hit and penetration probability %s for a specific, current, in game vehicle match up - then no thanks, I don't WANT even to look at it; and if I'm honest I guess I don't want my opponents to be able to either, but part of my objection is that I don't think it would - should! - do them much good anyway, because of all of the variables involved. In another post I'm fairly certain that Steve recommended playing the game intuitively, and I like that approach: we do need information to be able to do that (and also, in my case, as my results so amply demonstrate, better intuition ...), but some proposals for the encyclopedia are a step too far for me away from the way I like the game to work. And as always, it will likely come at a (perhaps modest) cost of something else being put back because of it.

Exactly! Such a pain - not least because it is so illogical! As the calculations are being done from the future waypoint - the hardest bit, one would assume? - how hard can it then be to draw the LOS/LOF line from that same point rather than from your current location? It is not so bad if you CAN "see" where you want to from the future point; but if you cannot, the "guessing" as to why not begins ...

Thanks, GaJ, for your continuing development and support of H2HH: couldn't do without it!

Steve, Great news! But can you confirm exactly what is being proposed / tested? Has "target briefly" gone, with both target and target light having the time increments included? Or have we "only" got a time-variable target briefly command, with the others left unchanged?

Go on then, clever clogs ... is it an Ausf H or J? Early or late?

Whilst I agree in principle with this (my bold bit above) - trying to determine the exact right number of seconds seems a vey fine distinction! - I also agree with the thrust of the OP: there is quite a difference between 15 seconds of firing (how many rounds go off?) and a minute, and a way to expand the choice seems reasonable to me. I too use the workaround the Regiment0 describes, but it always feels like you shouldn't have to! The existence of the variable setting for "Pause" makes it seem like it shouldn't be THAT hard (!) to apply the same countdown routine to a fire command? But that being so (?), do we need the "Target Briefly" command at all? Is it possible - preferable? - to do away with TB and make the target command of variable duration: default is permanent until rescinded as now, but whilst selected, optional variable timings from 10 seconds to 90 seconds (i.e. lasts longer than 1 turn, but you cannot forget to cancel it ... ) in 10 second steps can be applied?

Is it possible (meaning, I guess, viable, cost wise!) to make two slightly different versions: the same content of course, but with different install routines, one of which looks for and requires a previous version installed to work? Sell this latter one for a lower cost, and customers will be self selecting; only people with existing SF will buy this version, as only they could achieve a working install of it? Though I guess you may get some of us buying the wrong one ... As with others, I'd pay "full price" (especially with an existing user discount!) for this, and not expect it for $10 - $15.

I'm looking forward to them as well! But based on what has been said so far, I am inferring - hoping! - that they are something more than a "graphical flourish"? In that - whilst MikeyD may have had his tongue a little in cheek (?) - the decals WILL go in the appropriate places to reflect accurately where the hits took place? So, they won't affect ballistics, but they will reflect them. So, in this particular case, we will be able to see if a shot hits the chin projection on the late Panther mantlet, or hits the lower curved surface on an earlier mantlet without the chin, and then see where - if at all - it ricochets to afterwards? Including a hit decal on the hull top deck if the shell does ricochet into it?