From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14144 invoked by alias); 18 Aug 2004 12:52:53 -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 14134 invoked from network); 18 Aug 2004 12:52:50 -0000 Received: from unknown (HELO av11-1-sn4.m-sp.skanova.net) (81.228.10.106) by sourceware.org with SMTP; 18 Aug 2004 12:52:50 -0000 Received: by av11-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 7204537E46; Wed, 18 Aug 2004 14:52:50 +0200 (CEST) Received: from smtp4-1-sn4.m-sp.skanova.net (smtp4-1-sn4.m-sp.skanova.net [81.228.10.181]) by av11-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 60EA337E42 for ; Wed, 18 Aug 2004 14:52:50 +0200 (CEST) Received: from [212.181.162.155] (h155n1fls24o1048.bredband.comhem.se [212.181.162.155]) by smtp4-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id B706C37E42 for ; Wed, 18 Aug 2004 14:52:49 +0200 (CEST) X-Sender: u22611592@m1.226.comhem.se Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Aug 2004 15:14:00 -0000 To: xconq7@sources.redhat.com From: Hans Ronne Subject: The border between fiction and reality X-SW-Source: 2004/txt/msg00951.txt.bz2 In my hunt for unit pointers I ran into an interesting problem. Where exactly is the border between plans and actions in the case of the human player? Most of the discussion so far has focused on the AI, and I think there is a consensus that things happen only when an action is executed. Anything before that (plan execution, task execution) is planning code that should deal with unit views only. For the human player, the answer is easy when we are dealing with command functions that directly schedule actions. Until the command is given, it is all planning. The corresponding interface code should therefore use unit views only, which is what the human player sees. If a human command schedules a task for execution, things become a little more complicated. However, one can argue, as I have done, that as long as the task has not scheduled any actions, nothing has really happened that affects the state of the game. Hence, the task execution code would also be part of the (extended) planning code, just as for the AI. Unit pointers should be banned. 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. Unit views will not do. 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. 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. 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. The best that we can do in this case is to restrict the unit pointers to the common interface code by letting advance_into_cell look them up itself. And I will probably do that. Feeding it a unit pointer as an argument that it can look up itself doesn't make much sense, anyway. The conclusion would seem to be that advance_into_cell is really part of the action code (that part of the kernel where things do happen). But it is also, by definition, part of the interface. So perhaps the two are inseparable. One may ask, then, is there really a difference between advance_into_cell and the task execution code? Both of them recieve commands from the interface (human player) and both of them schedule actions. Perhaps we should permit unit pointers in the task execution code as well? 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. Hans