A little quirk i found.

[Chek]

Thanks for the replies to my thread, i am a newb around these parts and firstly i have to say that the game itself is by far the best of its kind i have played, clearly the devs have put a lot of effort into this polished gem and i am having a great time getting pwned by the AI nevermind a human opponent. I suppose small glitches like this appear in most games and it certainly does not curtail the enjoyment of playing if anything its quite amusing to see such odd events occurring.

thanks again.

Welcome aboard.

Mentioning AI behaviour round these here parts is akin to playing basketball with a wasps nest.

[TheVulture]

(The point of the cryptology comment was I believe an analogy that just because *you* can't see any pitfalls with potential AI solution you proposed, your opinion doesn't count for much unless you have a track record of programming game AI, or in other ways show a good awareness of the kinds of issues that AI algorithms have to deal with. ANyone can say "I can't see a problem". It doesn't mean there isn't a problem.)

We've had many discussions over the years on gun elevation limits. BFC have been involved and well aware of them. And have expressed agreement with people here who have suggested problems. Notably:

User interface: You put in gun elevation limits, and just watch the bug rreports come flooding in from people about how their tank can clearly see target X but won't fire at it. How do you provide interface feedback to the user on what the firing zone of the tank is? Bearing in mind that when the tank is yawing (tilet on the side of the hill), the firing 'band' won't be horizontal, meaning that in many places targets at ground level will be unabel to be targeted, and it won't be clear to the user why. Or which direction they should move the tank to be able to engage that target. Trying to find a firing position to engage a given target becomes rather non-intuitive. Particularly given that we are working with waypoints for vehicles, so it isn't entirely obvious to the user whether they will stop just short of that slight ridge and be in perfect firing position, or slightly on the ridge, tilting the front of the tank up 15 degree and making the tank utterly useless but perfectly vulnerable.

NB Anyone who wants to complain that the UI issue will rarely be a problem is implcitly saying that the lack of elevation limits is rately a problem - they occur at exactly the same points.

TacAI: A tank spots a target outside its elevation limits. CUrrently it just fires, end of story. With elevation limits, its first option it to sit there unable to do anything, and possibly be exposed to danger from that unit. That doesn't seem like a satisfactory (or realistic) solution. So it probably wants to engage the target. It has to first of all find a firing spot that enables it to fire at that target. Some kind of grid search starting at the current position and working outwards would seem to be in order. You'd probably have to limit it to action points, even though the sub-positioning within action points might be significant, but we can live with that. It has to calculate a route to that action point (since there may be a good firing position 10 feet away on the other side of a wall, but that would take a half mile detour through enemy lines to get to). Once it finds a route to an action point where the route distance is not much greater than the linear distance, then it has its firing position. So off it trundles. Shame it just reversed in to the line of fire of a panther. Or gets to where it is going, and hey presto, the target has moved. So maybe you'd want to check for known threats that have line of sight to the firing position (lets not worry about intermediate points along the route to that position), and consider the estimated time taken vs the rate of movement of the target. And we also have to decide vs stationary low-value target A that we can fire at vs moving high-value target B that we can't - we have to have some decision on whether to settle for hitting A or give up on A and try to hit B and possibly fail. These kinds of decisions are hard for AI.

Ther bottom line is that people generally want their tanks to stay where they are put, and not have them wandering off on their own in a vain quest to get firing positions against targets that suddenly crop up nearby. The first time you lose a tiger to a side shot from a stuart because it was too busy reversing to try and get a shot at an FO, there will be hell to pay. (Never mind the fun exploits you could manage by deliberately exposing tank hunter teams in odd positions to get all neraby tanks running around like headless chickens to try and get a shot off). The more decision making you offload to the tacAI, the more often it will get it wrong, and the more annoying it will be. Whatever algorithm you propose to deal with this, people will be able to find pathalogical situations where it will break down badly.

Utlimately any simulation will be imperfect. There will be areas - types of things - it simulates well, and areas where the simulation tends to break down. The current implementation has the pathalogical situation of being able to fire at targets that it shouldn't. So the simulation diverges from reality when driving tanks through towns with high buildings for example. That is unfortunate. But also, not that common. (Or more to the point, since we are aware that this is an area where the simulation breaks down, try to avoid playing scenarios that involve that broken area of the simulation). Putting in elevation limits increases the fidelity in that area of the simulation, but at the expense of introducing broken areas elsewhere - notably tank behaviour close to the firing elevation limits. I'd argue that in those marginal cases, always being able to fire is actually an improvement in modelling fidelity, since it sweeps the business of not being able micromanage tank positions and respond immediately to problems under the rug (in much the same way, a hypothetical change to allow tanks to fire through tree trunks within 10 meters with no problems might improve overall behaviour, since in real life no-one is going to park a tank directly behind a tree trunk and then be unable to engage a target because of that trunk, and then sit there and do nothing about it; which is something I've had happen in the game occasionally. Such a change would clearly be physically impossible but arguably more realistic in terms out overall behaviour).

Throwing elevation limits in to the mix means that you will start to observe pathalogical behaviour at the margins of targetability (in areas that are strictly impossible but no-one would bother quibbling about in game). It would make the game noticably worse in the marginal cases for the benefit of the much rarer extreme elevation cases. I'm happy (and so, after extensive discussions of this sort of stuff in the past, are BFC) with having the pathology pushed off to the extreme elevation case and accepting that the game plays badly in those rare events, in preference to having it play badly in the considerably more common marginal cases. Watch in wonder as your tank drives over the crest of a hill, through the zone where a target tank is within elevation limits, and stop just past the point where it can hit that tank. And sit there for the rest of the turn while that tank slews its turret and gets the first shot off.

And don't forget the whole UI / user feedback issue. Not being able to target something you can clearly see because it is at 20 degree elevetion and your tank is on a downward slope will cause howls of protest and much frustration.

[Kat Johnston]

Did you go to the same design school as Diesel?

If you mean "do I have a clue what I'm saying when I talk about programming, because I suspect that you're not understanding the complexities involved behind the scenes", the answer is "yes, as it happens, I do."

What does 'free to', 'alter their position' and 'if they need to' mean, exactly, in this context?

'Free to' - is allowed to move. In much the same way that at present a vehicle is 'free to' move if it comes under fire.

'Alter their position' - move. In much the same way that at present a vehicle 'alters its position' if it comes under fire. It doesn't have to be complicated - the vehicle doesn't necessarily even have to "think" about where it is moving to - and it doesn't have to be far. Think "if you can't immediately hit this target because of elevation, move ten yards away from it and try again." It does not have to mean a straw-man "if you can't hit the lone infantryman in the building next door, abandoning all reason and in preference to doing anything else you must career wildly across the map getting shot at."

Though units often do exactly that when they come under fire - reversing wildly, flailing around seemingly in an attempt to present their weakest armour to as many possible enemies as possible. Reminds me of Carius's "and then after they were shot at the greenhorns turned their shiny new Jagdtiger around to run and were immediately destroyed" anecdote.

'If they need to' - comes down to aggression. Personally I'd set it very low, and have vehicles allowed to move to engage only if the infantry pose a threat - that is, only if the infantry are either within a very short distance or if they are armed with AT weapons. In other cases, it'd be the player's problem and job to move the vehicle, and the AI could continue bungling along as it always does.

What I'm suggesting is basically that in most cases, units would just find themselves unable to hit things they should not be able to hit, and when in clear danger ("does target have an AT weapon pointed at me") they should move away in an attempt to give themselves a shot. It's not a major reworking of code.

As far as enemy armour goes, implement elevation limits and leave it. If they can't hit, they can't hit and it's a rarer situation because armour, like daleks, can't climb stairs. Again, if a player-controlled vehicle ends up in some odd reverse-slope situation it's the player's problem, and the AI can continue bungling along.

How would this putative behaviour interact with succeding AI orders?

In exactly the same way that units moving after they have been shot at, or routed, or whatever interacts with succeeding AI orders. As you know, units aren't always in the exact place the AI designer expects (which is in any case an area rather than an exact location) and they aren't always in a condition to carry out the next move immediately if they're in a panic.

[JonS]

When I said, and emphasized, 'exactly', it was for a reason.

'Free to' - is allowed to move. In much the same way that at present a vehicle is 'free to' move if it comes under fire.

See the complexity you've just added? It's 'allowed' to, but it doesn't 'have' to. So now we need a decision making algorithm. As well as everything else that needs to be changed.

'Alter their position' - move.

Move how? How fast? Where? Which direction? Which route? What happens when it loses LOS to the target?

'If they need to' - comes down to aggression. Personally I'd set it ...

That's nice. Now the game is finely tuned to your preferences. Sucks to be everyone else though, huh?

If you mean "do I have a clue what I'm saying when I talk about programming, because I suspect that you're not understanding the complexities involved behind the scenes", the answer is "yes, as it happens, I do."

Facts not in evidence, your honour.

I'm going to stop at this point, except to say, See also: Vultures post, which covers off a whole other bunch of stuff (of which I think the UI could easily be the most important, and the most intractable). And yes, Vulture was exactly correct regarding the cryptography reference.

[sburke]

Welcome aboard.

Mentioning AI behaviour round these here parts is akin to playing basketball with a wasps nest.

Having been the victim of someone throwing a horseshoe at a wasp nest I can attest to the validity of this statement.

[dieseltaylor]

Thank you for the reasoning behind the decision. I would think it is in BF's interest to actually be up-front with some of their design decisions so that even if we disagree at least we know whats what.

The problem is that the armour behaviour in Version 1 stunk and it has been altered somewhat since then. We also have the altered reversing speed which again looks like a post V1 adjustment and to a generalisaed figure. And in terms of realism in movement there are still problems . You can understand why after a decade one begins to wonder what BF do with armour.

As for the decision on elevation. I comprehend the reasoning but still feel that when talking of buildings they are very large immobile structures in relation to most things on the battlefield so one might think special rules about proximity and height could exclude the most blatant shooting.

However perhaps simply doubling each vehicles elevation and depression would skirt most of the problem for the AI and players.

I see the gripe on "Free to move" for a tank controlled by the AI is surely reverse backwards directly OR if forward gets you out of the known danger more quickly then that. These decisions must already exist in game as tanks already carry out movement in the face of new information.

[Georgie]

In CMBN and the upcomming Battle of the Bulge game there was very little "city" fighting so the problem of a tank being able to shoot straight up has little effect on the game as a whole. The East Front game will be a different story and would be much more realistic if a tank weren't able to shoot straight up since there will be more "city" battles.

[YankeeDog]

In CMBN and the upcomming Battle of the Bulge game there was very little "city" fighting so the problem of a tank being able to shoot straight up has little effect on the game as a whole. The East Front game will be a different story and would be much more realistic if a tank weren't able to shoot straight up since there will be more "city" battles.

Depends on where they start with the East Front. Remember, they're not going to try to do the entire East Front all at once like they did with CMBB. Rumor has it, it's going to be Summer 1944/Bagration.

Relatively little urban fighting during Bagration. Also, not many tall buildings in the built-up areas where there was fighting during this operation.

Nevertheless, I do hope some sort of less abstracted treatment of elevation/depression limits gets added before we move to the East Front again. For one thing, the IS-2 in particular had pretty severe limitations on the depression/elevation limits of the gun, which limited its ability to take advantage of hull-down positions.

[A Canadian Cat]

Thank you for the reasoning behind the decision. I would think it is in BF's interest to actually be up-front with some of their design decisions so that even if we disagree at least we know whats what.

BF has discussed this many times. A little searching (https://www.google.com/search?q=site%3Abattlefront.com+battlefront+gun+elevation)

Yields these three specific examples:

http://www.battlefront.com/community/showthread.php?t=98488

http://www.battlefront.com/community/showthread.php?p=1194181&highlight=elevation+limits#post1194181

http://www.battlefront.com/community/showthread.php?t=90522

Plus this definitive answer from Steve:

http://www.battlefront.com/community/showpost.php?p=1194005&postcount=91

[A Canadian Cat]

The East Front game will be a different story and would be much more realistic if a tank weren't able to shoot straight up since there will be more "city" battles.

Plus we have the Market Garden module coming up soon which will involve lots of urban fighting. But given what Steve has already said on the matter I would recommend against holding your breath: because you might die:D

It would be nice if some tweak could be made to lessen some of the really silly occurrences that can happen. However; given the background on the way the AI works I, personally, cannot envision how such a tweak could be made.

[Kat Johnston]

When I said, and emphasized, 'exactly', it was for a reason.

I used to program (including wargames) for kicks, for a long time. I guess I understand your defensiveness, given the oddly large number of people who treat this forum as a platform for BF-bashing, but you may note I'm not one of them. CM:BN is an excellent game, but it does have problems. One of the more glaring ones - for a game simulating armoured vehicles fighting in urban areas - is the lack of elevation limits. It is right to raise the issue.

See the complexity you've just added? It's 'allowed' to, but it doesn't 'have' to. So now we need a decision making algorithm. As well as everything else that needs to be changed.

If I am trying to shoot something and I can't hit it because the elevation doesn't let me then I need to budge my ass.

Or if I have LOS to enemy infantry with an AT weapon pointed at me and I can't bring a gun to bear then I need to budge my ass.

Move how? How fast? Where? Which direction? Which route? What happens when it loses LOS to the target?

None of this matters much. Move twenty yards away from the enemy. If you can shoot it, good, if you can't, at least you may have made their job harder. The issue is NOT that we need to enable a vehicle to hunt down out-of-reach infantry in any and all circumstances, pursuing its job with guile and tenacity. The issue is that a vehicle shouldn't be able to shoot where it can't, and if it finds that it needs to, it should HAVE A GO at moving a bit to find a shot, in similar fashion to units adjusting their aim when their shot is blocked. If you lose LOS, you lose LOS, no problem. The AI is not clever enough by itself to pursue targets under normal circumstances (which would be difficult, and is a far more serious issue than elevation limits!) so there's no need to mandate that it should be able to in the special case of not having elevation to a target.

That's nice. Now the game is finely tuned to your preferences. Sucks to be everyone else though, huh?

Which is why I said my preference, and didn't say "this is how it must be!" Pretty much anything would be an improvement over guns firing at ninety degrees, so it doesn't matter. It's not about my preference - it's about the general preference people have for guns not to fire at ninety degrees to the barrel.

[dieseltaylor]

Thanks ian. I mean that for CMBN if the workarounds etc are explained and easily available in a thread here on the forum with BF giving the reasons or possibility.

This re-hashing of something that was discussed in CMSF 22 months ago does not really help the CMBN player.

Not having this information up-front leaves players re-inventing the wheel by bringing it up and getting bothered by it. Let BF just say:

elevation is out because ...

firing on fixed lines through smoke is out because .....

picking full ammo up is out because .....

reverse speeds are unrealistic because .......

broken troops carry their panzerschrek when running away because ..

Crocodile/FT's are not going to happen because ......

And for good measure they might say what is being looked at in a single BF thread or current staus on an apparent bug highlighted by a player on the forum such as TC attrition rate when unbuttoned. A simple comment like " In-testing" would do.

I am quite happy that if BF are up-front it will reduce a lot of angst as to what is a broken bit of coding and what is never meant to be. As it is many people must be equally bemused - other than those who are beta-testers and/or CMSF players.

[A Canadian Cat]

Not having this information up-front leaves players re-inventing the wheel by bringing it up and getting bothered by it.

Indeed, you have been around even longer than I have and, we both have probably seen many examples of people bringing up issues that were discussed multiple times in the previous year(s). I am not 100% sure how BFC could communicate those items better.

Thanks for taking my post for what it was - to bring in the previous discussions. After I re-reading it I thought - I sound a bit like I am saying "stop talking about this". Which is not my intent.

On the subject of searching: I knew I had read Steve's response to this issue previously but for the life of my I could not find it using the forum search tool. I have had this problem before. Finally I realized that the solution, to searching, is the same as it always is Google! Using "site:battlefront.com" worked like a charm - and I included the url for the google search so that other may benefit from using that feature of google to search this site.

[Guest]

@John Johnston: Moving backwards twenty yards would be insufficient in any but the most optimal circumstances. Your system is not generically effective. Just increasing the move distance won't fix it, either; the longer the move is, the more complex the underlying behaviors are going to be, so you might as well make something that provides accurate results most of the time.

So say we actually create a generically effective system that takes gun elevation into account, among other things - now you're trying to move, in some cases, 40-50 yards backwards in an urban environment whilst still maintaining LOS (otherwise how is that an optimal move for the AI? or is this a behavior that intentionally tries to break LOS?). And *then* the TacAI needs to be taught to use it. And *then* the scripted AI needs to be told that this might happen and given tools to deal with it. And all this for a fairly rare occurrence.

"See if it works" is fine as a thought problem, but actually *applying* new complex behaviors to an AI system takes a lot of work. You can't do it speculatively. And beyond that, after you've implemented said behaviors, they need to be tested extensively. Again, for a fairly rare occurrence. If you *have* done this before, you of all people should know.

The "why don't BFC just tell us exactly what they're working on" question has been asked and answered. It would be far, far more work than just answering the occasional question for a third or fourth time, and likely would not increase transparency all that much.

[dieseltaylor]

The "why don't BFC just tell us exactly what they're working on" question has been asked and answered. It would be far, far more work than just answering the occasional question for a third or fourth time, and likely would not increase transparency all that much.

I am not sure that this comment relates to the specific example I gave.

1] A list of behaviours/modelling that will not be included in the CMBN series because of practical problems. A one off entry.

2] Where a valid point is raised - like TC mortality rate - then to say it is testing is a fair enough clue. It does not require up-dating other than testing ends and result.

SO BF has a forum all to itself like Scenarios or Modding where only it posts and a subject per entry to make it very easy to scan/search

Now I can understand that people on the inside might find this a strange concept but in my long experience in service industries keeping people in the dark tends to piss them off. I was very vociferous in BF's favour in CM*1 but it seems that BF really has a problem with seeing a clients view of itself.

I posted previously that bit from Vauxhall Motors that accompanied the first Churchill tanks explaining they had done the best they could in the time available with what they had - and things would be improved. A nice touch when an imperfect model is being provided. Customer relations.

[MarkEzra]

Sometimes I just read stuff and then need to look at my tatoo: "Rule 62" it helps a lot

[Guest]

I am not sure that this comment relates to the specific example I gave.

1] A list of behaviours/modelling that will not be included in the CMBN series because of practical problems. A one off entry.

Right. Because this "one off entry" will neither change nor cause any debate that will require heaps of explanation and spawn dozens of "why did they do this?" threads that will all require answers. And then in six months or after the next release, whichever came first, we'd have to do it again.

2] Where a valid point is raised - like TC mortality rate - then to say it is testing is a fair enough clue. It does not require up-dating other than testing ends and result.

I leave comments in threads that report bugs, if I'm alerted to them. When we've fixed a bug I say so. When we're looking into a bug, I say so. Steve and Moon do that too. So... what are you asking for?

SO BF has a forum all to itself like Scenarios or Modding where only it posts and a subject per entry to make it very easy to scan/search

And who maintains this? One of the people who knows precisely which bugs have been fixed? That would be me, Steve, Charles, or Moon. And how do we map our internal bugs to external bugs when the two bear nearly no resemblance to each other? With a lot of painstaking work.

Are you saying that we'll somehow create time to do this? It would take a lot of time, as I suggested in my comment. Again, you're positing a solution without even *considering* addressing any practical aspects.

Now I can understand that people on the inside might find this a strange concept but in my long experience in service industries keeping people in the dark tends to piss them off. I was very vociferous in BF's favour in CM*1 but it seems that BF really has a problem with seeing a clients view of itself.

I posted previously that bit from Vauxhall Motors that accompanied the first Churchill tanks explaining they had done the best they could in the time available with what they had - and things would be improved. A nice touch when an imperfect model is being provided. Customer relations.

What I see is that this particular client's view - yours - bears no consideration for the practical aspects of the demands being made. We make games, do our best to provide support for our customers, and moderate a forum for you to discuss it. On top of that, you want us to come out consistently and debate our design decisions and even CODE with you, as if somehow this will change the realities of our resources and design constraints. How is that helping our customers?

Your suggestion would mean LESS time for our primary jobs, let alone extra customer service. To top it all off, there would be so much information that it very likely would be useless except to a very few people.

[ChrisND]

Now I can understand that people on the inside might find this a strange concept but in my long experience in service industries keeping people in the dark tends to piss them off.

No one is being kept in the dark to any reasonable definition of the phrase. The things that pass for important around here usually aren't in the larger scheme of things, and spending large amounts of time constantly updating the couple dozen people who would actually care on the minutia of relatively trivial problems would be a gigantic waste of development time.

I don't go into WoW's forum angry at the Dev team because I haven't been told in detail what is planned to address the misplaced texture mapping on the Warlock boots or whether they think the damage coefficient of the Curse of Doom spell is off by 10%. I trust that they'll address the issue when there is something substantial to say. Which is usually in the patch notes for the next patch.

[Kat Johnston]

@John Johnston: Moving backwards twenty yards would be insufficient in any but the most optimal circumstances. Your system is not generically effective. Just increasing the move distance won't fix it, either; the longer the move is, the more complex the underlying behaviors are going to be, so you might as well make something that provides accurate results most of the time.

So say we actually create a generically effective system that takes gun elevation into account, among other things - now you're trying to move, in some cases, 40-50 yards backwards in an urban environment whilst still maintaining LOS (otherwise how is that an optimal move for the AI? or is this a behavior that intentionally tries to break LOS?). And *then* the TacAI needs to be taught to use it. And *then* the scripted AI needs to be told that this might happen and given tools to deal with it. And all this for a fairly rare occurrence.

First, lemme say this - troops at high elevations are generally rare across the whole range of situations in the game - but in a large town, it's common and important.

My thought was that as there are several things that push a unit out of the position it has been moved to by the player or the AI plan, a (relatively) small backwards move to try for a better shot and/or break LOS with unhittable AT weapons would be just one more among many, not unusual. For trying to hit something (as opposed to avoiding fire, in which case just move back), I guess you could quickly poll a series of points in a direct line away from the target unit for LOS to the target, and if one was available within a certain distance, plot a move to it, and if not, do nothing?

Ach. Sorry. I know what you mean, I'll shut up. Though right now I'd love to see how the TacAI is written!

[dieseltaylor]

Phil,

I have a problem here in I am suggesting a very minimalist approach which somehow seems to grow into some monstrous time overhead.

The point about elevation, which appears to be discussed in several places could be No.1 on its not happening and here is why - copying and pasting from any existing place it has been discussed.

This is on a forum where only the three of you post - or a loyal helper : ). You need never post again - unless BF ever alters its stance. Ditto fire breathers. Firing through smoke?

The second part which if you like could be optional is the trials area. I am well aware that BF comments get put on interesting bug threads. However all I am suggesting is an easy place for your customers to check what the result is after testing.

For all the protestation on work load I think this is actually easier for punters rather than trying to recall what name the CW TC casualty rate was discussed. SO what would happen. Its agreed there is testing required it gets entered on the BF section for bugs as a testing item - and can be a pasted copy of the answer in the original thread. Two months down the line perhaps a result is entered.

Extra labour -

Features never happening - one topic entry

Bug topic - One pasted comment saying testing required. Result pasted.

For players a one stop shop for what is a design constraint, and what is currently being up for evaluation. Clients not being allowed to post should make it a simple forum to read and pass on.

Just in case you wonder what my angle is - high level and detailed process engineering in the service industry is what we have great experience in. Good customer outcome is actually a high priority in our world be it for external or internal clients.

[dieseltaylor]

No one is being kept in the dark to any reasonable definition of the phrase. The things that pass for important around here usually aren't in the larger scheme of things, and spending large amounts of time constantly updating the couple dozen people who would actually care on the minutia of relatively trivial problems would be a gigantic waste of development time.

Normal Dude

Funnily enough if I invest time in playing a battle in a realistic fashion and then find out all my cleverly placed infantry on higher floors in a narrow street are not safe from tank fire from below I think I am entitled to feel mislead as to the realism of the game.

Now I have not read the rules manual since last year so my memory may play me false but I do not recall this being mentioned as feature of the game that would need finessing.

[Ranger33]

Phil, just curious if you guys would consider a very limited version of his idea. Something just to avoid the silly looking things like having a tank fire through itself:

I'm thinking, instead of using the exact realistic angles, just limit it to less than say 80 degrees (or whatever) where the tank only needs to back away from high priority targets in the same manner as they already back away from AT threats, or even a shorter distance. They could just ignore regular infantry, since they wouldn't be able to see them at that angle anyway (in most cases). Just enough to get the tank fire at a non-ridiculous looking angle. It would be enough to make narrow streets dangerous for tanks and safe-ish for infantry.

Just spitballing here. This issue is fairly rare in my experience, BUT when it does happen it is totally immersion breaking, not to mention gameplay breaking.

[Guest]

@diesel: I said "the amount of work to maintain the list would be enormous" and you replied, several times, with variations on "well, it doesn't need to be presented in a complicated way." I'm not saying anything about the complication of presenting the list to customers. I'm *assuming* we would present it in an uncomplicated way. (The forum idea, by the way, would require quite a bit of extra work and would be easily overwhelmed by volume. Are you assuming that your personal list of issues is the only one extant?)

I'm saying the amount of work to maintain the list - including turning "our" internally-tracked bugs into "forum" bugs, keeping the list of things up to date, going back and updating things - would be enormous. The amount of work behind the scenes, regardless of presentation, would be decidedly non-trivial, and would *certainly* impact our ability to work on the game itself.

Then Normal Dude says "spending large amounts of time constantly updating the couple dozen people who would actually care on the minutia of relatively trivial problems would be a gigantic waste of development time" and you say "I feel misled about the realism of the game".

Honestly, it doesn't seem as though you're reading our posts. You're not addressing the points we're making. Instead you keep banging on about what is clearly an axe that you're grinding. Now, I expect people to have issues that are near and dear to them, and to complain about them. But ignoring our answers, and insisting we don't care about the game, is a great way to ensure that I, at least, stop trying to discuss this with you.

[Guest]

Phil, just curious if you guys would consider a very limited version of his idea. Something just to avoid the silly looking things like having a tank fire through itself:

I'm thinking, instead of using the exact realistic angles, just limit it to less than say 80 degrees (or whatever) where the tank only needs to back away from high priority targets in the same manner as they already back away from AT threats, or even a shorter distance. They could just ignore regular infantry, since they wouldn't be able to see them at that angle anyway (in most cases). Just enough to get the tank fire at a non-ridiculous looking angle. It would be enough to make narrow streets dangerous for tanks and safe-ish for infantry.

Just spitballing here. This issue is fairly rare in my experience, BUT when it does happen it is totally immersion breaking, not to mention gameplay breaking.

The process - needing to teach the TacAI and scripted AI to handle the concept, then test extensively - is the same regardless of the simplicity of the solution.

As Steve said in the post that ian (I believe?) linked to on a previous page, this is something we'd love to solve, but the combination of fairly rare and pretty darned difficult makes it unlikely we'll do so anytime soon.

[Tarquelne]

A fudge-factor that has a tank delay it's first shot - time based on how far out-of-elevation the target is - might be nice. As a visual clue for what's going on the tank could boogie-around in place, as if it's trying to find a firing angle.

As with all problems involving combat, dance really is the best solution.

But what we really need is for the forumites to vote on the worst realism bug (or lack-of-feature), with the agreement that the item with the most votes will be deemed by those participating to be the most important problem.

Then we could present a united front and all complain about the same thing while waiting for BFC to work their way down their own list. It wouldn't really change anything, but we *would* avoid duplicate efforts at impotently whining.

We may be grognards, but we don't have to be disorganized about our grumbling.