vulture

They will under some circumstances. Area target against a building will usually fire off a javelin sometime within a minute normally, and infantry at long range (out of effective small arms range) will often get a javelin dropped on them. But you can't force the troops to use a javelin - it is at the discretion of the AI.

LOL. As it stands now, a T55 will stand toe to toe with an Abrams and duke it out. Syrians tankers seem to be missing that useful self-preservation gene. Or it could be sheer chutzpah. </font>

In my world of warcraft guild we have three generations of the same family playing - grandparents, parents, kids. The grandparents are probably online the most...

I've seen the inablity of infantry to spot tanks 10 feet away on the same road (with absolutely no obstacles in the way) as well. And in BigDork's AAR he posted here just after release, he sends a repulican guard tank hunter team to hunt a T-72 (red on red scenario) and when they come in to contact, the team doesn't spot the tank literally 10 feet away on the same stretch of road with no obstacles, while the tank soon picks them up and wipes them out. Either their spotting is in dire need of improvement in such situations, or there is some exciting bug - I'm speculating that maybe once a target unit is spotted by a friendly unit, other friendly units can only pick up the spot through the CC network, can can't spot it themselves (maybe once a friendly spots the tank, the time it takes to diffuse through the CC net is worked out, and the tank hunter teams will learn about it on turn X, but due to a bug it is flagged as unspotted by that unit until turn X, which overrules their ability to spot it themselves). No idea if this speculation is even plausible, since I don't know how all this is coded, obviously. And I can't be bothered to test it ATM

The 'show all moves and waypoints' option was patched in in the 1.03 version patch on Thursday. The 1.03 version of the demo isn't out yet though - only 1.02, so you'll have to wait a few days to get the demo with that option in probably.

Doesn't always work that simply with binary representations. 2 = 10 1.25 = 1.01 1.4 = 1.0110011001100....

They're arbitrary to some extent, in so far as you can internally represent them as whatever you want (suitable for machine performance). From a code management point of view though, sticking to a standard set of units (SI units) and having all distances in meters makes a lot of sense, rather than wanting 5m grid squares represented as size 8 - so each unit of distance if 0.625m. 'cos then you have to convert all other distances to those units, and it is so very easy to get some scale factors the wrong way around or stick something in in meters instead, and you have a very hard to find bug.

Even that is more complex than it sounds. DO you want the arc to go more or less through the waypoint? Or is it allowed to cut the corner> If you allow corner cutting then you have to decide the speed of the vehicle through the corner and from that determine how tight a turn is possible, and therefore how much you cut the corner by (assuming no blockages). Which isn't too hard - until you start putting waypoints close together and the first turn isn't complete (and the vehicle therefore isn't back on the plotted path) before you are expected to leave the path again to make another turn at a different speed (as an aside it might be instructive to see how much the behaviour in the first post depends on having 2 or more waypoints close together - is it still a problem if all points are widely spaced?) If you don't allow corner cutting and the vehicle has to follow a smooth curve that passes exactly through the waypoint then the problem is that you have to veer off the plotted path to hit the waypoint on the turn (look at the first left turn in the first post - to actually go across the waypoint on the turn, you have to start off to the right of the plotted track and swing back in - and to get to the right you have to turn off to the right at some point and then turn back left to line yourself up for the entry to the turn). And again, stick two waypoints close together and the whole thing can fall apart quite quickly as the algorithm tries to find a path that goes between the waypoints whilst tryig to follow the rules of the smooth turns it tries to make). The only way to guarantee hitting each line and point is basically to drive in a straight line and stop and pivot on the spot at each turn (not an option for strykers either).

There us a trade off between having to spend hours plotting simple movement orders (I exaggerate) to generate the exact effect you want vs having the AI interpret your orders to some extent (and inevitably getting it stupidly wrong sometimes). COnsider the most extreme example of the first kind - you work with the 'primitive' commands. You can plot move orders, but only straight ahead. You can plot turns (with various minimum turning circles depending on vehicle and intended speed) and you have to string them all together in the order in which they occur. Now you can either have the computer check in advance that the path is feasible (doesn't clip any walls or any impassable terrain) and only allow orders that are physically possible - which may involve delete and replotting a fair sequence of moves as you try and get the position, direction and turn point right to get a stryker round a corner in a narrow street. Ot you can allow the orders to stand and the vehicle simply stops if it is unable to continue the command sequence for any reason (corner too tight, another vehicle blocks the way, for example). This approach would probably be rather time consuming to plot all your vehicle movements (and possibly rather frustrating as you have to replot the entire movement sequence for a stryker 5 times to find a path that actually works). At the other extreme you have something closer to (intended) CM:SF functionality, where you simply plot the end point that you want to get to, and the tacAI works out how to get there. But you have very little control over what path it choses to get there, and given the limits of pathfinding algorithms in mixtures of passable and impassable terrain, even a 'perfect' algorithm will do some things that seem crazy to a human (you really have no idea how good our brains are at this sort of stuff...). This makes for a very easy to use system (just stick in the final waypoint and off you go), but with limited control. There are various grades in between of how much leeway the computer has to alter the path. The CMx1 system generally stuck very closely to the plotted path except where that path was impassable. And sharp turns would be converted to a series of smaller turns and smoothed out. But in general the more 'low level' you make the commands (giving the AI less room to interpret or react) the more complex the interface has to be, and the more fiddly (and time consuming) to work with. Maybe a compromise would be to distinguish between general "get there somehow, and don't bother me with the details" waypoints (like CM:SF currently) vs "drive along this exact line to this precise point" waypoints. Except that that would add even more options to the UI movement orders, and probably create more confusion (and annoyance when you mistakenly use the wrong kind of waypoint). And here endeth my random uninformed thoughts on the subject.

THat can be an issue for strykers (I imagine) that have a non-zero turning circle and can find themselves in the position of trying to hit a waypoint that is too close and off to the side. But according to the first post these tests were done with a Bradley. Correct me if I'm wrong but Bradleys are tracked vehicles that can pivot on the spot - so turning radius shouldn't be an issue (the extent to which they can turn while travelling at full speed might be a factor there though).

Enjoying it so far. Many positives. Still having a few issues with the UI, but as far as I am concerned that's my job to learn how to use it. The TacAI for my own units occasionally does surprising things, but it's also my job to learn how to issue the orders to the units to make them do what I want. I'm sure there will be issues with the AI and UI that need improving over time (or which they didn't have time to deal with in advance), but actually playing the game was fun, and entirely unlike what I'd expect if I'd just read these forums first (in fact, reading a selection of threads here almost makes me wonder if I wasn't actually playing a different game, or am failing to remember how awful it was or something, 'cos I enjoyed it...)

If your view it as grabbing the map and moving it around, then yes, that would be more intuitive. But if your mental image of what is going on is that you are controlling a camera, not a map, then the opposite is true. It's all a question of which mental picture you happen to default to.

Horse for courses. I find it intuitive, and would find your version rather confusing I imagine. Make it another configurable option (Can't imagine it's going to be *that* high on the to do list though). Some more observatios, based purely on the demo so far. I'd like to see the ability to show all moves, arcs and targets too. I always found that vital to get an idea of what my forces are doing overall, particularly in larger battles. I was expecting the M, C, A and S keys to pull up the relevant command tabs. It would be much easier if they did. The 'deploy' command produced some bizarre results for me. I got the MMG team out of a stryker, gave them a move order and a covered arc. The following turn while they were moving I added a deploy weapon order, thinking that this would happen at the end of the move This seemed to get the MMG setting up where they were, while the other two team members wandered off on the move order. The covered arc for the unit seemed to be based at the point where I gave it and not move with them (although in other cases it did move with squads and vehicles). Plenty more bizarre behaviour followed for this poor MMG crew (the 2 man crew eventually moved up to where the rest of the team were, but when I pressed deploy again (lost track of whether or not the weapon was actually deployed at this point) then started off back to where they had been before - they apparently set it up and left it there... ) These are just minor interface issues - the effects of putting a chain of orders together didn't work how I expected, but that's probably more to do with my not understanding the interface that well than anything else. On the suggestion front (for the distant future) for scenario desginers: how feasible is it to have a 'debug' playing mode to test the AI scripting. I'm thinking of something along the lines of being able to see all units all the time and being able to e.g randomly place 'human' units on the map to do things like test how the AI behave when spotting units or taking fire at various points, and to better be able to debug timings and paths and the like.

Point 1) You will get it at the time you were told you'd get it when you pre-ordered. Nothing has changed there that I can see. You didn't pay to get it then with a guarantee that no-one else would be allowed to see it before you. Point 2) No-one gets the full release version (1.01) before you do anyway. They get the 5 week old version that is effectively a beta release.

I suspect the answer of "the demo will be out when we finish getting it ready" is about the best you'll get. If they finish it tomorrow, maybe you get it tomorrow. If it takes until after the release date, then that's when it comes out.

Or for a more serious reply, it is designed to caused RPGs to detonate before they hit the main armour, thus stopping them penetrating.

How much does video ram matter in the specs? My laptop is up to recommended specs on processor and memory, by has a crappy nVidia Geforce Go 5200 with a whopping 64Mb VRAM - and isn't upgradeable, so I can't get a new card; I'd have to buy a whole new machine. So is it a case of the processor coping with the number crunching of turn processing, but the crap video card giving me 1 frame per second animations, or what?

juan, I think what Jason is getting at is that humans are quite capable of producing results from individual CMBB battles that defy expectations to a huge degree. And in a program of any complexity (and this is pretty complex), it is pretty much inevitable that this can be used to break the system in some way - in a way that simply wouldn't be apparent in playtesting using auto-resolution of most or all battles. You can work on interface and data issues that way, but not game balance / mechanics issues. To take one possible example that has been discussed previously, consider a battalion attacking a platoon. The platoon hides very effectively, and the battalion is unable to find it before the end of the battle. The result at the operational level is that the defending platoon continues to hold the tile, and the battalion is unable to move past it. Rinse and repeat. (Auto-resolving the battle would lead to the death of the platoon for little or not loss to the battalion in all probability). It is of course relatively simple to work around on specific issue such as this. But as I said before, this is a complex game. It is virtually inevitable that there will be a number of unforseen game breaking issues like this that crop up. Some will crop up and be solved when using the auto-resolution. But some will only crop up when highly competitive nerds^HGrogs try every extreme idea in the book to gain an advantage - there will be ways of manipulating the CMBB battle result to exploit loopholes in the rules at the operational level. The auto-resolver will never do this - it will always give you resasonable results (and if it didn't, it would be cursed to high heaven and back again). So to beta-test reliably, you need to have the testers trying their utmost to break the system, which means playing every battle (arguably, it means playing every battle in a campaign several times - keep the first one as the 'result', and then try every wierd and wonderful approach that occurs to you in the replays). All of which boils down to the necessity of seeing the first release as a beta product. Without having the entire CMBB community beta-testing the game for months on end, things will be missed. Game breaking exploits will be found. Patches will be released to stop some. Others will be found to be too deeply rooted in the program design, or would break too many other things in the process of fixing this one. This is the way things are with all software of any complexity.

I agree with LeeW re the ricochet kill - whatever killed that tank wasn't the ricochet. Point one - that t-34 takes the hit and starts bailing out before the ricochet message comes up - the shell hasn't actually reached the panther yet (the 'hit' sparks appear onthe t-34 before the panther too). Point two - the t-34 that dies, a few seconds earlier is buttoned by coming under MG or small arms fire, which doesn't come from the Panther. It is being targetted by a second unit. Point three - you can watch where the ricochet shell goes. It heads off over the river. In the last second, a second Panther appears on the far side of the river. Lock on to that unit, turn to look towards the fight, and watch from view '4'. You quite clearly see the shell head off to your right. That t-34 was taken out by an un-spotted tank or AT gun (or TD, take your pick), not by the ricochet. [ May 01, 2005, 04:49 AM: Message edited by: vulture ]

But what fraction of shots hit the sloped upper hull vas the vertical turrent front? With Bigduke's Russian ricochets vs German penetrations on the first salvo, does he have the hit distribution recorded? If Russian rounds are bouncing off the turret front while German ones are pentrating the same face, then there is a large discrepancy in practice between the penetrations at close to zero degrees despite what the numbers say.

Bigduke: twilight zone? The numbers are quite clearly different in the vast majority of cases (the exceptions being 0 degrees at 100m and 500m, and 30 degrees at 100m). The differences are particularly severe at high angles. Check the 60 degree lines.

Glider: the armour quality is also differemnt between the two models. Russian is 90%, while captured German is 85% (reflecting that captured t-34s may have been damaged whilst being captured?). Which makes the difference in penetration slightly more severe - the Russians are getting worse results against slightly inferior armour.

Wheeled vehicles can also cross shallow fords (and so can HTs, obviously).

Having just seen a Korean War documentary featuring tanks parked up on sloped earth ramps and firing as artillery, I'm wondering when someone is going to complain that HQs can't spot for indirect tank fire. BTW does anyone know how widespread the practice of setting tanks up in an artillery-like role was? Was it used in WWII as well?

Incidentally, another argument against requiring reviews before downloading more scenarios: Consider someone off for a few weeks with their laptop and no internet access guaranteed. They might just want to download a reasonable groups of scenarios (say 5 in one go), with the intention of playing (and reviewing) them all over the next few weeks.