Mud

If it's happening after you switch from 3D back to 2D (e.g. to show a briefing or AAR), switch out of the game, and back to it. That should help with a white-text-becomes-transparent-on-Win2K/nVidia issue. You might also want to get DeanCo's "clipboard" command-menu interface, which should help with command text readability. More drastically, you could switch to certain old Detonator drivers -- search the board for 'detonator', 'FSAA', and 'version' -- that should probably be enough search keys.

It still might let the FO communicate the exact intended target easier, right? And in theory, the velocities of the projectiles are probably known, so maybe they precalculated an approximate trajectory to use. Sounds somewhat plausible to me. Rocket spread is indeed huge. Set up a 500-pt QB, small map, w/ a German 300mm rocket FO. Target the enemy zone w/o LOS or TRP. Make everybody else sit tight, and watch rockets land basically all over a massive part of the map (and outside it, as well).

Or, check the color. With the default images, white => AP, yellow => AT (possibly daisy-chain; perhaps they use the same .BMP so you can't differentiate). (Oh, and on a road? If it's a paved road, they MUST be daisy-chain, IIRC; the engine won't let you bury mines in asphalt. Mining dirt roads is perfectly legal, 'tho.) Oh, and somebody once posted that you could get direct kills even with the very visible daisy-chains -- not just indirect ones by diverting attackers into a kill zone. Put them in a place where a zooming vehicle won't see until it's too late, such as the reverse slope of a hill road, or around a curve. Maybe more so if you have something to distract the vehicle with, like a sharpshooter taking out the TC.

You did check out the superstructure armor on that monster, right? If you haven't, take a look. Maybe the bugger was designed with Soviet heavies in mind, but it's massively overarmored (what, something like 250mm front superstructure?) and overgunned (128mm or so) for anything it's likely to face in CM:BO.

196m? Was that an from an explicit target order, or did the TacAI choose to make that (presumably VERY difficult) shot?

Alec Magua's "Normandy" terrain is a visual feast, if you can find it. You might also want to check www.combatmission.com, which has quite a few mods broken down by category. I'm using an awful lot of Fernando's and GEM's mods from that site. Oh, and there shouldn't be compatibility issues because they only affect the user interface: either visuals (.BMPs) or sound (.wav). You might want the high-resolution mods, 'tho, for higher-density projectiles and armor . [ 10-09-2001: Message edited by: Mud ]

Would there also be penalties or a lower baseline, or is having only bonuses preferred because AFVs are in general currently undermodeled?

Incidentally, here's a silly (but true) example of the difference between predicatibility and reproducibility. Suppose I select a book from my personal library without telling you. I then count letters, and every time the count becomes prime I list the letter. When the count hits 593, I reset it to 0. It's a strange sequence. It isn't easily predictable, by most humans anyway (a computational linguist or cryptographer with a database of human literature might do better...). And if I select a different book, the sequence will likely be rather different. But it's perfectly reproducible if I start counting at the same number, same algorithm, and the same position with the same book, if I'm an android who makes no counting errors and never loses his position. PRNGs are reproducible, and they try to be unpredictable.

Gyrene, ask yourself where the random numbers came from, and realize that CM does not require the existence of a dedicated "true" entropy source. Does it have physical dice to roll? Quantum states to check? No. Many computer programs instead rely on PRNGs. The term PRNG comes from pseudo-random number generator. Pseudo, because it's not truly random -- PRNGs just try to *look* random according to a variety of statistical tests. A typical example is the rand()/srand() combo in the C language. If you srand() with a given constant to initialize the PRNG state, and then you call rand() a few thousand times in a row, the series will look vaguely random, but it's actually not. If you srand() with the same seed (which defines initial state) and the same code (C library) on the same platform, and ask for the same number of random numbers from rand(), you'll get the exact same output every time. There are arguably superior PRNGs to most rand()/srand() implementations, but they are still fundamentally deterministic. If you know the PRNG rules, and you know the exact state, you can predict the numbers. There's been a lot of research into generating seemingly random numbers, especially in the cryptology community as they're keenly interested in attackers being unable to deduce a sequence. For instance, there's no point in a one-time-pad if your entropy source is weak to the point where your attacker can easily get enough message traffic to predict the rest of the key bits. Do a search for "pseudo random number generator" on Google. Or, say, read Random Numbers in C which is a a long thread on implementing PRNGs in C, complete with sample code. Note that they are all deterministic given a start state. The reason why I say that it may not be possible to save state and implement reproducibility is that there may be another source of entropy in CM, such as if it uses multiple threads or processes and the order of execution alters the actual results. Not all entropy is derived from traditional PRNGs; old versions of PGP didn't trust PRNGs, and computed bits from the user pounding keys for a while.

Illiterate. In case you didn't notice, I'm asking why the solo reviews aren't replayable -- not why PBEM games are. The situation now is that you CAN "save scum" in single-player, and that you CANNOT reasonably analyze results post-game from previous turns because the results may very well be quite different, especially where significant discrete outcomes (shot KOs, shot ricochets) may differ. Does this non-repeatibility strike you as good for some reason? I have seen references here to PBEM files being large, suggesting that entire movies are being sent. Theoretically, if the PRNG state is saved (as does NOT seem to be done), "save-scumming" is prevented, not enabled (as it is now in solo). In addition, you'd be able to go back to previous saved games and review them just they way they happened before, which would be good when you're analyzing the game, AND you would save file transmission time because you wouldn't necessary need to send the movie. Here's why. A turn resolution must be based on rules + state + some entropy source. Because computers follow instructions literally, if a standard PRNG such as the common C library random() / srandom() functions are used, it is possible to save sufficient state that application of the rules and repeating the exact PRNG sequence must yield 100% identical results each time. The primary exception that I would see would be if CM uses multiple threads in a way that affects combat resolution as a consequence of the operating system scheduler; in this case, repeatability cannot be guaranteed without saving the entire movie because there is too much state beyond your control. Frankly, I would like to see reproducibility even for solo play, and it strikes me as what should theoretically be simple to implement even as a toggle -- depending on the nature of the entropy source. Remember that programming instructions are basically math which must return a given output for a given input and a current state. State which is clearly being saved includes the state and orders of the map, of all units, and so forth. If the PRNG state is the sole source of randomness AND is explicitly saved -- which may mean that CM would need to use its own routines -- and the algorithms are constant (which they would be, given that they'd be in the code) then the start state and rules are fully specified. Since this is NOT the case -- you CANNOT replay a solo saved game to study what happened, because it changes -- logic would suggest the state of the entropy source is not being preserved. Simply initialize the PRNG during game setup phase, and track state subsequently; with most, you're not supposed to reinitialize again, anyway. The potential downsides for saving the entropy source might be - It's impossible, because it depends on things beyond CM's control such as OS scheduling. Fine. It'd be nice to know about this, 'tho, just out of curiousity. - You can't test the "Was I just lucky" hypothesis. Fine. If people really want that, Battlefront could leave a toggle switch to not save state, and do whatever it is they do now (initialize based on the timer, or whatever).

And if you play Herr Uberpanzer (10 KTs?!) again, in another city map, consider American Airborne. They get some SMGs (useful for the close-in fighting), loads of rifle grenades / gammon bombs (useful for ambushing tanks), and still have available MG and zook teams for support. The major alternative might be British for the smokeless PIAT, but be warned that it can jam just when you had the perfect shot lined up.

Oh yes. In "All or None", after that [CENSORED] [CENSORED] [CENSORED] was removed so my armored columns could safely advance, I took my revenge with the Crocodile and ravaged the town. Oh, and I meanwhile methodically shelled with various AFVs parked on the bridge. But the Croc was useful for demolishing the remaining strongpoints.

Plink and run, plink and run. KTs have slow turret rotation, so it'll be better if you can stay mobile, engage from VERY close range from behind. Hopefully, you've got FTs, zooks, gammon bombs, rifle grenades, or *something* left. Maybe the worst thing you can do is have a squad stay put in the top floor of a building futilely chucking grenades at a buttoned-up KT for a minute, basically asking for the tank to smash the building while you're in it.

Speaking of replays, was it ever mentioned why solo-play replays aren't repeatable (i.e. save, hit 'GO', reload, hit 'GO' yields different results)? Seems to me that if they saved the state of whatever random number generator -- for a simple arithmetic PRNG, this normally wouldn't be many bytes -- then one could save before each 'GO' and at least watch turns unfold identically in whatever order is desired while, say, writing up an AAR or otherwise doing a post-mortem. Unless, of course, it's deliberate -- to, say, permit reload-'GO' just as a check to see whether you got rather lucky / unlucky. Hmmm.

And large-caliber VT arty wreaks absolute havoc on infantry in the open :eek:. But even 81mm often deserves credit for an assist -- if it causes already suppressed troops to break, run, and get mowed down, it helped. It's also OK for tormenting guns, if gun owner doesn't move it ASAP.

It's been suggested that CM:BB provide more detailed AAR kill counts, right? So maybe it'll tell you both confirmed kills, and actual kills for more accurate post-game analysis.