TheVulture

Mostly because AI pathfinding is insanely hard to do well in a complex environment, and the brain-in-a-jar could easily spend two weeks doing nothing but to make some minimal improvement that would affect 1% of the cases where it goes wrong (exaggeration for effect). Not sure why they took the trouble to add in 3 monitor support - I guess one of the BF.C guys got said system and it was the work of a minute to code the extra stuff in to make it work properly. And +1 vote for adjustable waypoints (with the traditional mantra of "just like in CMx1")

Lovely to see it back again - although having just fired up a 1.08 scenario I didn't immediately notice that it was different - only when I read this did I notice that the lack of annoyance

I'm sure it is but that's assuming you are doing it from scratch. I contend that there must be loads of open source code out there by now that does passable water effects. It doesn't have to be bleeding edge, just passable. By the way, "Theatre of War" has water effects on a par with what I'd like to see for CMx2. Check out the video of the new editor: TOW Editor Perhaps Charles and 1C should put their heads together on this one, seeing as BFC already has a working relationship with them? </font>

I have a suspicion that that is a bug personally molotov_billy. I'm testing a scenario of my own design, and so far have seen about 20-30 strykers taken out by a combination of RPGs and ATGMs. Without exception, every single passenger has died. The two-man crew escapes a fair fraction of the time, although they usually die before getting too far. But I've not seen a single passenger surivive an RPG / ATGM hit.

I suspect that building to building stuff is complicated by the fact that both buildings have a wall in the same place, if the default setup. It seems to me that scenario designers can work around it by removing the 'internal' wall of one building in the appropriate place, leaving a single wall between buildings. I definitely read something like this on the subject of simulating interior doors - one building wall gets the door, the other building wall gets removed, and the door is usuable (was this in Rune's scenario editor guide?)

I'm creating a scenario (the usual blue attack type thing), and am hoping to get the US force choice at least vaguely believable, so would like some input from someone who knows more than me about this (i.e. anyone who knows more than a month-old cabbage). The US force is selected from a heavy infantry, combined arms battalion - the battalion has 2 infantry companies (bradley mounted) and 2 tank companies, plut mortars, recon elements, JTAC (don't actually know what that is to be honest) and other support stuff. Terrain is rural- hilly farmland and a small village (long thin map). The scenario concept is probably unrealistic, so comments on this will be welcome too. I'm thinking of an exploitation force that is one of the first units through a breach in the Syrian lines, and is tasked with finding the Syrian operational reserve and fixing it in place until more substantial forces can be brought to bear. Two of the bradley inf platoons from C company are sent to do recon (recon in force? yeah, I've heard the phrase, don't know how it applies) along different routes, with the 3rd platoon in close reserve. The scenario follows one of these platoons. Since I don't want a whole battalion on map (my computer probably can't handle that), I'm thinking that both recon platoons meet resistance at different times, and that the battalion resources are allocated piecemeal as the estimates of the resistance on each axis are adjusted as things develop. So 3rd platoon ends up coming in to the scenario as they meet resistance first, but D company (the 2nd infantry company) get allocated to the other advance. The scenario also ends up with a tank company arriving, one platoon about 5-10 minutes ahead of the rest of the company. Is any of this even remotely realistic? Completely contrary to the way the army works? How would the organic 120 mm mortars be used? (I don't even know what sort of range they have). Would they be set up close to the line of departure of the recon platoons to support both? Or would they stay further back with the reserve companies and move up and deploy when the reserves were committed? The other problem is that I have no idea how to set up an effective defence as the Syrians. I'm thinking in terms of no trenches - hasty defensive positions only (the reserve units are positioning to attack the US advance, and have had little warning of the approach of the battalion to this area, so have only had an hour or so to prepare). I'm just not that used to CMSF yet (as opposed to CMx1 games) and I just can't convince myself that there is enough good cover around for the infantry defence, or enough concealment. Pretty much anywhere I put defenders I look at it and think "they'll be spotted and killed from miles away before they can do anything". Any tips on what terrain provides decent concealment for infantry?

Useful little guide Huntarr - cheers.

The text saying they've arrived shows up without the units. They actually turn up some turns later - I forget when exactly but 2nd platoon did arrive when I played the scenario. Never saw 3rd platoon, but the Syrians surrendered with about 20 minutes left, so I don't know if they would have turned up at some point.

Since we're on the subject, it would be nice to have the icons of eliminated units on the final map too. I've had battles where I have rubbled most of the buldings with 152mm howitzers, and trying to findout whether it was worthwhile can be painful as you try and find bodies in the wreckage. Just stick the unit icons back in for all units, maybe marking completely eliminated units in a different colour. And while I'm making wishes, show the complete complement of infantry in each unit, colour coded by status (okay, minor wounds, major wound/dead, surrendered, routed). It just helps those of us who are completely useless at the game to improve by getting a better idea of what worked and what didn't.

It's understandable - to me at least. There seem to be two attitudes to command issues. Some people go with the principle of "find out what the command does in practice, and then figure out how to structure commands to achieve what you want". Others have the idea of "I know what I expect to happen with the command I gave (namely: what the manual says), and any deviation from that is a problem". The second group tend to have (unrealistically?)high expectations of how well the tacAI can interpret orders and react to situations, and complain when the tacAI deviates from what they think a rational human ought to do. The first group are possibly too willing to live with bugs, because they expect the AI to do dumb things, so their attitude is to find out what dumb things the AI does and find out how to work with that. The second group tend to find the bugs, but also tend to complain about things that aren't bugs rather than trying to find out what actually does happen. (With apologies for the crass generalizations). (Random example: move to contact in CMx1. Does what it says on the tin: move until you spot an enemy unit or take fire, and the stop where you are and twiddle your thumbs or fire back. You can either argue about the sanity of the behaviour of the squad when they take fire, or do things like use advance over open ground with short move to contact sections in cover, with the result that when they take fire they continue to advance to the nearest cover and then stop there to return fire). What seems to cause issues for some people in CM:SF is that the waypoints seem to operate both as low and high level commands. Low level waypoint: follow this exact line to the next waypoint, rinse and repeat. If something bad happens (you spend the turn walking into a wall), that's the players problem for giving stupid orders. High level waypoint: I want you to get to this point, not too fussed how you do it. CM:SF mixes the two up: a single waypoint can work as a high level command. You just give a destination to a unit, and it figures out how to get there and does so, by whatever route it finds convenient. But if you want more control over the path, add in more waypoints - with the expectation of them being low level waypoints (go here, then here, then finally here). Except that the same pathfinding AI works in each case, so each one is really a high-level waypoint, but hopefully the routes between them are simple enough that they act like low level waypoints (the major exception being when there are obstacles unnoticed by the player). I think WeGo works better with low level commands: you have time to work out the likely results of your various complex commands. In real time though, it is quite easy to imagine that there will come times when you need to give quite a lot of orders in a short time, and being able to give a unit a single 'go here somehow' order would be necessary. (As a personal preference, I like low level commands, and being in direct control - as much as is possible - of what my units are attempting to do. I think predictability of how your units respond to your commands is absolutely essential in this sort of game).

Would they be able to shoot sonic rays out of their mouths too? Or lasers from their eyes? Or whatever it was Godzilla used to do...

Actually, just for kicks I am trying to write a random map generator for CM:SF (and I assume it is theoretically possible to make it stick the output in the same format as scenario files, just as soon as someone deconstructs those to know how to represent the maps and AI plans in a file). But I'm doing it for fun, whilst holding down a full time job, looking after small children, and whatnot (and looking for a new job...) so there is no guarantee I'm going to get it working any time before 2015. Oddly enough the approach I'm taking is essentially to divide the map into small 'tiles' of specific types (row of houses, compound, street, forest, park etc.) There are several layers of tiles - for example an 800m x 800m map may be divided into 4 tiles (not necessarily square ones) that could be 'forest', 'open' and 2x'city (low density)'. Then each tile is divided into further sub-tiles, the possibilities for each depending on what its parent tile type is. Rinse and repeat until you are at a small enough level that writing a map-building algorithm for the lowets level tiles is possible (tile is 40m x 40m, has road connections to other tiles here and here, and is high density housing, for example. Or maybe mosque complex. Or small park in the city). Or maybe just use hand-designed tiles for some of the more complex urban tiles, like is being discussed above in the thread. Now as to how well it will work, and whether I can design some very basic algorithms to chose setup zones (preferably out of LoS of each other) and something resembling an AI plan that works....

There are two differences there. A) It looks like there is enough room to get around the humvee on the road, and whatever detour it plans to get around the humvee, it can follow the road for some time, whereas the following tank starts off pretry much at the point where it has to take its detour. When the takns get to their respective 'detour' points, one has a clear road and the other a blocked one. So it's not necessarily anything to do with anticipation. Yeah - when it comes to AI progamming issues I tend to look for the problems with an idea straight away, which leads me to see problems that might not be there. The CMx1 system worked pretty well: ignore friendly vehicles as blockages until you run into them. Well, pretty well aside from it's ability to simulate traffic jams when trying to move a column... So maybe try 'ignore friendly vehicles until you hit them (more or less), then wait time T (say 10 secs) to give them a chance to move before planning another route'. It will probably cause some odd behaviour, but will be more directly under the player's control, whilst being slightly more tolerant than CMx1. (Odd behaviour, like Cmx1 traffic jams, are much less of a problem if the behaviour is reliably predictable, because at least the player can know what effects his commands will have and use them accordingly). Might have some issues with losing vehicles to enemy action starting the 'death clock' ticking, while the following vehicle sits there (in the firing line) waiting to see if the dead vehicle is going to move. But hopefully the threat avoidance AI ought to kick in at that point and override the commands anyway.

Nice job of showing up a problem clearly. They more or less have to do that though - base your route finding on the current map. An AI that attempts to plan its route based on what routes will be available at the time it is driving down them would be an nightmare. One simple fix that might improve things would be to distinguish between permanent and temporary blocks (temporary being a vehicle that is still able to move). When faced with a temporary block, allow say 10 or 20 seconds for it to move, and if it hasn't go around. But actually that wouldn't work that well either - it seems to me that the only reasonable approach would be to drive to where the temporary blockage is and wait there (or not, if it has already moved), but I'm pretty sure that could generate some pathalogical behaviours too (of the 'failing to anticipate the obvious' variety). No idea how well that would work in practice. It ought to work well in this particular case, but you never know what unanticipated side-effects will crop up. Was the following tank given a pause command? And would that make any difference? If the path is calculated on the fly as the vehicle starts to move, the a long enough pause to allow the front vehicle to reach open space (wide enough for the following tank to get around) ought to produce 'expected' behaviour (wouldn't help with trying to get a convoy of vehicles down a narrow road though - they'd be all over the shop). If the path is calculated in advance (and only altered due to changing situations blocking the pre-chosen path) then the pause might not help at all.

Agree with Melnibone. The only one that is specifically an issue designed into the new WeGo system is the first one (and also the 4th one, which is the same thing...). The rest are bugs, tacAI issues and UI issues, which can all be resolved (in theory).

Well yes, True 1:1 representation for anything much above platoon level would seem (to my mind) to be somewhat beyond the abilities of current processors. I'd agree that the level of abstraction of terrain and units in CMx1 meshed well together (20m tiles work fine when you are abstracting a squad of 10 people covering something more than a 10m x 10m area in reality, as a single point). BUT (and this is an important one), BFC are insisting that there simply wasn't a market for further games (of the type they were interested in doing) based around that level of abstraction. And as Steve may have mentioned in passing, they are the ones with the sales and marketing data to back that up. So if they were going to do something that was a) commercially viable (hopefully) and still resembled the CMx1 concept to some extent (rather than writing say a FPS based on squirrels raiding a badgers den with a variety of squirrel-sized weapons ... CM:Squirrel Force...) then moving towards 1:1 representation was one of the few innovations they could do (at least, no others spring to mind right now for me). I don't think we need to wait for CM3. But it might take a few patches and ongoing feedback from the players to get to the right mix of abstraction and general tweaking before the game 'feels' right to most people (caveat: it probably feels good enough to some people now... I expect that number to grow with every patch as the tacAI improves, bugs are resolved, game 'balance' issues are sorted (infantry vulnerability for example), and the UI is tweaked in response to what most people find they need).

It's hardly a design error - more of a design necessity. Performing LoS checks between every individual soldier and vehicle is too computationally intensive (and the time required increases as the square of the number of units involved, so it would very quickly become the bottleneck in the system, which pretty much always determines the maximum size of engagements. (And going from squads in CMx1 to individuals in CMx2 means 5-10 times as many units roughly, and 25-100 times longer calculations - possibly more given the finer terrain mesh and more detailed terrain, which means each single point to point LoS check takes longer). The trick to get around that is to use pre-computed LoS maps, which get generated at the start of the battle (and modified as terrain changes). And that, incidentally, varies with the fourth power of the linear map size (unless there is some clever workaround I can't spot). There is a maximum size grid of points you can cope with before you run out of memory (which doesn't vary much from machine to machine - going from 1 gig of memory dedicated to this to 4 gig would only increase the linear size by 40%). As an aside, if you want to cover a bigger battlefield with a fixed number of grid points, you need a wider grid spacing. People are already complaining that a) the grid spacing it too wide and at the same time that the map size limits are too small. But you can't improve one without making the other worse (for a given size of memory available for the maps). So we have too many individuals for individual one to one spotting (and besides, that would terminally screw up the ability of the game engine to scale up to larger battles), and memory constraints mean you have to trade off between grid spacing and overall map size. And don't get me started on the memory and CPU tme requirements for pathfinding algorithms...

Is it possible to give positive points for keeping buildings intact, balanced out by a fixed sum of points for the other side (as per CMx1) which would have much the same effect. You'd have to tweak the values of other objectives to get the right behaviour no doubt, but it seems like it ought to be possible.

And also if a unit is eliminated during the turn (so it's little marker disappears) the marker doesn't reappear when you rewind back to the start.

As I understand it there are now more or less 3 levels of AI. The highest level - the Strat AI - is scripted by the scenario designer and is attatched to the map (and for quick battles you still need some kind of AI plan suitable for the battle type with the map - a map that only has a defensive plan will have the units doing nothing in an ME or an attack AIUI). The lowest level is the Tac AI, which is the one the player has to live with too. It is what determines how the units follow their orders - picking targets out of covered arcs, deciding when and what to fire, chosing the precise path to reach a waypoint, deciding when to abandon the plan under incoming fire and seek cover. That sort of stuff. There logically has to be an intermediate level AI as well, which has the job of turning the stratAI plan into a series of movement and target orders (as per what the player does), that are then interpretd by the tacAI. But this sounds fairly minimal, since the stratAI is fairly detailed. The stratAI might say that group A has to move quickly (on the assumption of no enemy ocntact) to point X, then advance in bounded overwatch to point Y (starting at time t) and hold position there, shooting at any targets. The mid level AI just has to chose waypoints, delays and movement commands that achieve those conditions. By the sounds of it, it doesn't try and adapt the plans in any way (if contact is made earlier than expected for example), so for really good scenarios a great deal of testing is require to get the stratAI plans just right.

Here's a theory of what happened there: The Syrian tank has LoF to some part of the Bradley, so the target as flagged as 'targetable'. The gun therefore rotates to point at the center of the target unit (rather than at the center of the visible area) which is a) not visible and behind the corner. And the result is what you see. If you instead make the aim point the center of the visible area, then no problem occurs (assuming LoF is measured from the rotational center of the turret) - the gun will never point at a target beind the wall / corner and won't therefore stick through the wall. Alternatively it may just be that the calculations show that LoF exists through the breached wall and the window. In which case I'd suggest that for vehicles windows block LoF but not LoS. I don't imagine too many complaints from people about their tanks *not* being able to fire in one window and out of another. Either way, the problem looks to be one of determining that LoS or LoF exists, and then orienting the gun accordingly despite the fact that it is physically impossible to get the gun in to that position. But that's more or less unavoidable (I mean, you could put in some code to check whether the gun can traverse from its current position to its intended position, but I suspect that would lead to even more bizarre problems and people wondering why their tank rotates the turret *away* from its target, taking an AT round to the back of the turret whilst doing so).

The point being made is that the old CMx1 system did the TacAI and turn resolution in one run, taking as much time as it needed, and then did the graphics at a seperate time when it needed to do no other calculations. The CM:SF system has the CPU doing the tacAI, turn resolution and graphics processing all at the same time. Since a certain amount of processor time is required for graphics, there is a fixed number of CPU cycles to spend on tacAI and turn resolution. (Where before it took as long as it took). Presumably BF wouldn't have gone down this route if they felt that it was going to cramp the AI too much with not having enough CPU time: rather I suspect they figured there was more than enough CPU time to do the tacAI and turn resolution in real time, and leftover processing would be put to use on the graphics. Or some such thing. I assume the thinking of Cid250 is that if we went back to precomputed turns we could gain the ability to do much more computationally intensive indepth AI planning which would take considerably more than 1 minute to crunch. Whether this is true or not I have no idea - it isn't always the case that throwing more CPU cycles at a problem gives you better results - it may just given you somewhat different pathalogical behaviour...

Just to make it very clear: the Syrian research threads in the build up to this game indicated that a large fraction of T-55s are built into static positions (about 1,200 T-55s out of 4,600 or so total tanks IIRC) and are entirely unable to move. Whether they should be represented as T-55's parked on the ground and not moving rather than mostly buried in concrete or whatever is another question.

Someone let Seanachai out of the peng thread? Who left the gate open?