From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22408 invoked by alias); 20 Aug 2004 01:42:37 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 22385 invoked from network); 20 Aug 2004 01:42:35 -0000 Received: from unknown (HELO rwcrmhc13.comcast.net) (204.127.198.39) by sourceware.org with SMTP; 20 Aug 2004 01:42:35 -0000 Received: from [192.168.181.128] (c-67-172-156-222.client.comcast.net[67.172.156.222]) by comcast.net (rwcrmhc13) with ESMTP id <2004082001423401500923m6e>; Fri, 20 Aug 2004 01:42:35 +0000 Message-ID: <412556EF.80401@phy.cmich.edu> Date: Fri, 20 Aug 2004 03:29:00 -0000 From: Eric McDonald User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) MIME-Version: 1.0 To: Hans Ronne CC: xconq7@sources.redhat.com Subject: Clearing the Air (long) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg00968.txt.bz2 Debugging email is a tiresome business and I think both of our efforts could better be spent doing other things. However, I do feel compelled to reply to this, and attempt to set things to right. We have worked together on this project for over a year now, and I doubt it would be good for the project if our collaboration were to end. So, I'll make another attempt to clarify and rectify. Hans Ronne wrote: > by changing the > subject to fire-at in the middle of our discussion. I don't know how this could be construed as changing the subject. In practically every case where I mention 'fire-at', there is a corresponding mention of 'fire-into' lying near at hand. Comparison and contrast are legitimate tools to use in a debate. >But perhaps this was a > misunderstanding? Let's recapitulate: Yes, let's: > 1. You proposed a scheme for how to model hits against stacked unit in > fire-into (not fire-at). Correct. >I am referring to the section of your email 2 days > ago that started "Let me clarify and expand upon what I think should happen > wrt 'fire-into'". The scheme you proposed for distributing hits in > fire-into is based on unit sizes and the total terrain area. If, by unit sizes, you mean the unit target area coverages, then that is essentially correct. > 2. I pointed out a problem with this scheme, namely that it introduces the > sizes of other units into the hit-chance calculations for a given unit. I am still quite confused by what this supposed problem is. I asked you earlier to give me an example of where my probabilities are screwed up, and you have, thus far, not done so. But, since we're all about clarification these days, allow me to clarify: (1) Suppose I have one unit in a cell, and its target coverage area (subarea size, subregion size, or whatever) against the backdrop of the cell is 2%, and its hit probability is 50%. The coverage area of the stack is therefore 2%. This means that there is a 98% chance of missing the stack. Now suppose that the stack is hit. What does this really mean? It means that we randomly chose an unit, mutliplied its target coverage area by its hit probability and determined a hit. In this case, we only have one unit, and so it is "randomly" chosen, and then its target coverage area (2%) is multipled by its hit probability (50%), thus giving it a 1% probability of being randomly hit. (2) Suppose I have two units in a cell, and each has a target coverage area against the backdrop of the cell of 2%, and that their hit probabilities are both 50%. The coverage area of the stack is therefore 4%. This means that there is a 96% chance of missing the stack. Now randomly choose one of the two units in the stack, apply its target coverage area multiplied by its hit probability. We get 1% (as in the previous case of an identical solo unit occupying the cell). Now suppose we miss the first unit occupying the cell, so we calculate the probability of hitting the second unit after it is "randomly" chosen. Guess what? The probability of hitting the second unit is also 1%. Therefore, it is not dependent on other units in the stack. Quod erat demonstrandum (QED). > I suggested that a better way > to model random hits against a stack of units is to treat them as > statistically independent objects and roll a dice for each one of them. You mean you suggested what I suggested? > I did not at that time discuss how to strike a proper balance between hit > chances in fire-at (targeted shots) and fire-into (random shots) That is unfortunate, because your "hit-chance" comment certainly fooled me into thinking you had made a significant oversight. (Your "hit-chance" comment is mentioned below.) > 3. After pondering my comments, you claim that this way of modeling hits in > fire-into is flawed because the basal hit-chance against a unit would be > the same as in fire-at (your example with u1 and u2). You make a big deal > of this, Well, yeah, it was the fatal flaw in your scheme, as I understood it. (Again, see the mention of your "hit-chance" comment below.) >and the inference is that your scheme would not suffer from > similar problems. That is correct. It would not suffer from similar problems. > This argument is incorrect for several reasons. First, I did not state that > the basal hit-chances in fire-into and fire-at (or against invisible and > visible units) should always be the same. That's your assumption, not mine. Actually, to quote you in http://sources.redhat.com/ml/xconq7/2004/msg00944.html: "Now, as I see it, all these factors (including the unit's size) are already weighed into the hit-chance table and its various modifier tables such as uu_protection etc. I certainly assign a larger hit chance against units that are big targets when I design a game. So if the hit-chance for artillery against infantry is 20% it means that an infantry unit which sits in a standard terrain cell (no terrain modifiers) has a 20% chance of being hit each time a piece of artillery fires into that cell." You clearly and unequivocally state that you are considering the 'hit-chance' table (which _is used_ by 'fire-at'), and, yes, we were most definitely discussing 'fire-into'. The subject had not been changed and 'fire-into' was very much the topic at hand. So, my "assumption" is based on something you wrote in the context of the discussion. Not too shabby of an "assumption", I would say. > Second, these matters are irrelevant to the discussion we had, which was > about how to model random hits against a stack of units. You're saying that your own mention of 'hit-chance' was irrelevant to the discussion we had? >Third, as far as I > understand, your area-subdivision scheme does not address these problems > either, unless modified by further assumptions not described in your > original proposal. The unit area coverage scheme was made out of the necessity to differentiate between 'fire-at' and 'fire-into' by better modelling 'fire-into', and it appears to do exactly that. Your above claim that it does not address "these problems" is, quite frankly, bizarre and contradictory. > I stand by my criticism of your scheme, but please do not take it > personally. I don't take it personally. I do think it shows that you still misunderstand the unit target area coverage scheme. What I am taking personally, as you likely would too if the situation was reversed, is what appears to be the way you have distorted my arguments. If you didn't understand them, you could have asked for further clarification instead of making them out to be something they are not. I even gave you an opportunity recently to demonstrate your understanding of them by asking you to show their supposed statistical flaw, but you did not take me up on the offer. >And I do think we had that in this > case, right until we got side-tracked into fire-at. As I mention above, there was no sidetracking or changing of subject. If anything, it was your mention of 'hit-chance' that sidetracked things. > We have always been able discuss technical matters on this list without > getting emotional. Let's keep it that way. I wish we could. And perhaps calm can return again if you can convincingly show me that you were not abusing my arguments in the way I perceived. >And perhaps move on to a > different subject. I would like to, but I am not sure that the 'fire-into' stuff is completely thought through yet. Although this is not presently as critical to me as some of the earlier topics in the thread, I am still concerned about and keen on helping make sure that we do the right/best thing wrt it. However, if we want to take a breather from the discussion, I think it would probably be welcome by all those who have been watching the flames and shards of ice fly. Eric