L.Tankersley

One caveat here: I provided the 8500 picture, and I sent the raw shots (taken with Cmd-Shift-3) in PICT format to Tecumseh. He did the JPEG compression. If other people sent him images in JPEG format, they may have introduced more compression artifacts than Tecumseh did with my picture (and things like blurry track wheels is just where compression artificts would be most noticable).

It shouldn't affect display quality; it would probably affect framerate/responsiveness, and would definitely affect turn processing time.

::hits self on head::

That would be great, thanks mate.</font>

I can do a 64mb radeon 8500 shot; it'll have to wait until late tonight, though. I could throw in a Rage Orion also if you like.

I suspect BFC would say that mineroller tanks and other specialized equipment, as well as major minefield breaching operations in general, are out of scope of what CM:BB is trying to accomplish. They would probably also say that the minefields that can be purchased in the game engine are intended to represent hasty, point minefields, not the major mine belts that you refer to. If you want to model major minefield belts, you could I suppose buy LOTS and LOTS of small minefields and plunk them down, and use landmarks (or a border of daisy-chain mines) to mark the edge of the mined area.

It's sounding more and more like the (true) hit probability is equal for AI and human. This is what I expected; as Steve mentioned, the ballistics code should be the same for AI and human. Where I think there might be a discrepancy is in the time it takes to get a shot off (even if the human issues a targetting order). Unfortunately it's not easy to gather accurate data on just how long it takes to get a shot off because of the granularity of the CMBB movie clock. However, I think it would probably be feasible (for someone with altogether too much time on his hands, such as the estimable Treeburst) to set up an experiment to see which tank of a pair fires first. I would suggest a setup similar to Treebursts' but with each tank (AI and human) both having a single round of AP. By watching the turn movie from high overhead (view 8 or 9) with unit size at +4 you should be able to easily see the smoke plume when a shot is fired. (It might help to turn on fast, compatible smoke with shift-I.) There would be three possible outcomes for each trial (pair of vehicles): AI shoots first, human shoots first, or shot fired simultaneously (within the ability of the tester to judge, anyway). Identical vehicles should definitely be used, and the test should probably be run from both sides (human as Axis and as Allied). If a few hundred trials result in essentially equal chances, then I think we could probably put the issue to bed and write the various "curious" results we have seen off to confounding factors rather than fundamental differences in the code.

In the course of preparing an experiment (detailed in the "AI cheats!" topic) I noticed that Soviet and German (captured) T-35/85 M44 tanks have slightly different point values. I speculate that the reason may be to account for potential availability of "special" ammo (tungsten), or for poor AP shot quality of one side or the other. Seeing value change for the same vehicle at different times for the same nationality might be due to similar causes (changing availability of special ammunition, changes in crew quality exclusive of experience level, or general changes in ammunition quality).

Yeah, I agree. The consistent (but non-significant) bias is a bit troubling. Hopefully Treebursts's data collection extravaganza will help us figure out whether there is a real effect, or not.

1. We should be careful to clearly state just what it is we're measuring. Some people are measuring hit percentage, others kills, and still others who fires first. Personally, I don't believe that there is any difference between AI and human performance in the hit percentage and kill percentage areas. The area I think might (might) be skewed is in how long it takes to get a shot off. However, initial impressions are that a human using manual targetting gets similar performance to the OpAI (which presumably performs manual targetting as part of its orders generation). More data is needed to really do a valid test of this. 2. Random (or more properly "pseudo-random" numbers. The built-in random number generation functions that are provided in the standard C library (and presumably others) are (or at least were) notoriously non-random. It is also the case that many if not most pseudorandom number generation algorithms given in textbooks suffer from similar problems. (A good way to test a random number generator is to generate lots (and I mean lots, like a million or two) of random numbers and plot the results in a histogram. You should see a very even distribution. If there are any spikes in the histogram, you have a problem.) There was an article in the Communications of the ACM several years back that discussed common problems and presented a nice, easily-implementable algorithm to generate "good" random numbers using any seed. (One feature of problematic generators is that similar seeds generate similar strings of "random" numbers.) I used to have a copy of the article but don't think I do anymore; however, I do have an implementation of the algorithm that passed the tests nicely.

Hey, I forgot to mention something I noticed while building my second test scenario: the scenario editor modifies elevation data on its own sometimes. If you recall, my setup had all tiles set at elevation 12 except for a single elevation 0 tile near each end of each lane. When I opened the scenario again to edit it, the elevation 0 tiles were now at elevation 9. I replicated this a few times. This seems to happen when you load the scenario into the editor (because when I saved the scenario with elevation 0 and ran the test, the tiles were actually at 0, not 9) and not when you save the file. Not sure what's going on here. Has anybody else noticed odd changes in elevation (particularly around abrupt elevation changes)?

(Starting a new topic because I'm too lazy to drill down and find the original thread...) ATI just released a second October driver update. It doesn't help with the opaque smoke problem. However, I'm sticking with the Radeon 8500 Mac Edition because, other than the smoke issue, it's doing a pretty good job. Performance and texture quality are both fine. I now play with "fast, compatible smoke" and while it's not great, it's playable. If you're used to the fast, compatible smoke and want to improve your framerate and get the 64MB of texture memory the Radeon offers, this could be a good solution for you. And who knows, maybe someday ATI will actually fix the problem. YMMV.

I'm not expressing an opinion, as yet. I agree there aren't sufficient trials here to really state anything definitively. (I would definitely agree that if you don't issue a manual targetting order in the orders phase, while the computer player does, this gives the computer player an advantage. I don't see this as a problem.) Regardless, I don't believe the computer player is getting deliberate help. It might be that there is an unintented interaction, or "bug" that might be giving the computer player an edge in some situations. Or it all might be chance variation.

More data, generated while I wait for my meeting to start... I decided to do a quick test of the "who shoots first" question. I modified the Axis forces to use captured T-34/85 M44 tanks (same as the Russians were using). Sidebar: the point value for the captured T-34s is 169 (this is June of '44, south region). The point value for the Russian T-34s is 153. Clearly the point value calculation takes nationality into account in some way. Some of the Russian tanks did get a couple of Tungsten rounds; maybe that chance is factored into the value in some way. Anyway, things were set up the same as before. (I neglected to mention earlier that I set up the games with Fog of War OFF and with computer player set up restricted to scenario defaults.) Hit chance for both sides was 44% according to the LOS tool. I ran 4 trials, two with "human as Axis" and two with "human as allied." In the first trial of each pair, I let the TacAI handle targetting orders. In the second trial, I manually issued a targetting order for each human-controlled tank before hitting "go." Trial 1 (human as Axis, no manual orders) At T=0, all AI tanks were immediately targetting human tanks (red targetting lines). At T=2, 3 human tanks were targetting. At T=4, 7 human tanks were targetting. At T=5, 3 of the AI tanks had fired. At T=6, all ten AI tanks had fired, and only one human-controlled tank had fired (all were targetting). Trial 2 (human as Axis, manual orders) From the start, all tanks were targetting. At T=4, 4 of the human-controlled tanks had fired. At T=5, all ten human tanks had fired, as had 4 AI tanks. At T=6, all tanks had fired. Trial 3 (human as Allied, no manual orders) At T=2, 3 human tanks were targetting. At T=4, 9 human tanks were targetting, and 4 AI tanks had fired. At T=5, all ten AI tanks had fired. Human controlled tanks didn't begin firing until T=7, and some fired as late as T=10 (a few were knocked out before firing). Trial 4 (human as Allied, manual orders) At T=4, five AI tanks fired. At T=5, all ten AI tanks had fired, and 2 human tanks had fired. At T=7, all human tanks had fired. Analysis Hmmmm. It seems pretty clear that issuing manual targetting orders does help get shots off faster. How this compares to the computer player's performance is less obvious -- Trial 1 vs Trial 2 makes it appear that the computer player has the edge when you leave targetting to the TacAI, but that if you manually issue targetting orders, the advantage is neutralized or even shifts to the human player. But Trial 3 vs Trial 4 is less compelling. There may be an Axis vs Allied confound, an adjustment for use of captured equipment, or something else in the mix.

Ok, I had a few minutes to kill so I did my own test. I used StuG III G(late) vs T-34/85 1944 model. The map was essentially all tall pines at elevation 12, with lanes one tile wide running east-west. My test had 10 lanes. The lanes were separated by 100m of tall pines. I also put a tile of tall pines at the edge of each lane to keep vehicles from escaping off the map, and put a single elevation 0 tile one tile into each lane from each end to keep the vehicles from advancing. This limited each vehicle to a single 20m x 20m tile. No vehicle could see any other vehicle not in its lane. For the curious, range between each pair was 757 meters; the stated hit chance for the StuG (to hit the T-34) was 43%, and the hit chance for the T-34 was 38%. I ran the test scenario 10 times, 5 "playing" as Axis, and 5 as Allied. I did _not_ issue any targetting orders; I let the AI do that. Each test consisted of a single CM turn. After the test, I counted "kills" as a tank that was either knocked out/abandoned, in the process of bailing out, or otherwise soon to be knocked out (e.g., vehicle morale broken or gun damaged, with the opposing vehicle still manned and able to fire). Results: (Human as Axis) Trial StuGs killed T-34s killed 1 5 5 2 6 4 3 6 5 4 2 9 5 4 8 Total 23 31 (Human as Allied) Trial StuGs killed T-34s killed 6 3 7 7 3 7 8 6 6 9 4 6 10 3 8 Total 19 34 My hasty calculations give a probability of 0.389. That is, there is not a significant deviation from chance (of the side the human plays affecting the outcome). One very interesting observation: I did not gather statistics on this (yet), but my strong impression is that the AI side fired first in virtually all engagements. That is, in the "human as allied" trials, the StuGs got the first shot, and in the "human as axis" trials, the T-34s got the first shot. Given the relatively high hit probability and lethality at the test ranges, a discrepancy here could very well have a significant effect. I suggest that to gather data on this, you view the firing range from above using view 9 and watch the smoke plumes. Again, my impression is that most or all of the AI tanks fired before any "human" tanks fired, regardless of nationality.

Found this link on Slashdot today: http://www.tech-report.com/reviews/2002q4/lcds/index.x?pg=1 It compares several LCD screens, you might find it useful.

I just sort of assume that CM FO teams are composed of the kind of people that get carsick when they try to read in a moving vehicle, and that's what prevents them from calling in fire while embarked.

I just noticed something: in an operation, I had an HQ tank immobilized. In the next battle of the operation, the HQ tank was abandoned, and the tanks that had been in its platoon now draw their command lines to the nearest infantry HQ in range (platoon or company HQ). Is this by design?

The new drivers don't appear to help the opaque smoke problem.

The new drivers don't appear to provide any improvement vis-a-vis the opaque smoke problem. Edit: I said it twice because I'm so bummed. Yeah, that's the ticket. [ October 16, 2002, 09:04 PM: Message edited by: L.Tankersley ]

The new drivers don't appear to provide any improvement vis-a-vis the opaque smoke problem.

Update: ATI today released new drivers for the Radeon 8500 Mac edition. I will download them tonight and give them a spin. (Thanks jeffsmith for the heads-up.)

Update: today, October 16, ATI has released new drivers for the ATI Radeon 8500 Mac Edition (thanks to jeffsmith for the heads-up). I will download and try it out tonight to see if it helps.

The CMBB manual suggests that the backside cache can cause system lockups under MacOS9 on G3 and G4 machines. I was seeing occasional lockups on my G4 tower running 9.2. I disabled the cache and haven't seen it happen since, but the problem is sufficiently intermittent that I'm not convinced the problem is solved yet. See page 246 of the manual for a link to where you can download a utility to disable the cache.

ATI cards on the PC side don't support fog in CM. On the mac side they do, but there are ... other issues.