From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10538 invoked by alias); 18 Aug 2004 15:28:01 -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 10531 invoked from network); 18 Aug 2004 15:28:00 -0000 Received: from unknown (HELO ob2.cmich.edu) (141.209.20.21) by sourceware.org with SMTP; 18 Aug 2004 15:28:00 -0000 Received: from egate1.central.cmich.local ([141.209.15.85]) by ob2.cmich.edu (8.12.10/8.12.10) with ESMTP id i7IFMYPO004301; Wed, 18 Aug 2004 11:22:52 -0400 Received: from leon.phy.cmich.edu ([141.209.165.20]) by egate1.central.cmich.local with Microsoft SMTPSVC(5.0.2195.6713); Wed, 18 Aug 2004 11:25:14 -0400 Received: from localhost (localhost [127.0.0.1]) by leon.phy.cmich.edu (Postfix) with ESMTP id 8F4AF70045; Wed, 18 Aug 2004 11:27:53 -0400 (EDT) Date: Wed, 18 Aug 2004 21:10:00 -0000 From: Eric McDonald To: Hans Ronne Cc: xconq7@sources.redhat.com Subject: Re: The border between fiction and reality In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 18 Aug 2004 15:25:14.0698 (UTC) FILETIME=[8F4B2AA0:01C48537] X-CanItPRO-Stream: default X-Spam-Score: -0.9 () X-Bayes-Prob: 0.0001 X-Scanned-By: CanIt (www . canit . ca) X-SW-Source: 2004/txt/msg00953.txt.bz2 On Wed, 18 Aug 2004, Hans Ronne wrote: > However, a different situation arises with move-unit commands, all of which > eventually end up in advance_into_cell. At this point we are committed to > moving, and we have to know what real units are present in the destination > cell. Do we? > Consider the case of a single invisible enemy > unit in the target cell. Because of its presence, advance_into_cell will > schedule an overrun action. In its absence, it schedules a move action. > Whether we see the unit or not is irrelevant. Right. Are you saying this is a problem? If we are advancing into a cell as a result of a movement task, then a flag should be passed to the 'advance_into_cell' code to indicate that an overrun should not be attempted in the case of a seen enemy unit. If the enemy unit is unseen, the an overrun should, in fact, be attempted, because this case is no different than if the human player had been clicking along cell by cell and had accidentally run into the unseen enemy. > Every call to advance_into_cell in the interfaces is therefore preceeded by > a unit_at which gets a pointer to the first real unit in the stack. Yuck. > According to the principle that the interfaces should deal only with unit > views, I started to convert these calls to unit_view_at instead, but soon > realized that this was a mistake. I am talking without having seen the code recently, so perhaps I am missing something, but I would not consider that to be a mistake. > In fact, the task code which does the same thing as advance_into_cell > (do_move_to_task and do_approach_subtask) also checks for real units in the > destination cell. However, the main reason for this seems to be that these > tasks once could schedule attack actions against enemy units, just like > advance_into_cell does. That code was later commented out, so I'm not sure > to what extent we really need these unit pointers in the task execution > code. Like I stated earlier, if the human wouldn't know the enemy was there and the enemy is on the path being taken, then the human would have likely clicked on the cell containing the enemy if he/she had been moving cell by cell with keys or clicks. The automatic movement should not use special knowledge to avoid combat when, in fact, the human player could not have such knowledge. Eric