From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30733 invoked by alias); 5 Jul 2004 21:25:07 -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 30724 invoked from network); 5 Jul 2004 21:25:06 -0000 Received: from unknown (HELO av11-2-sn4.m-sp.skanova.net) (81.228.10.105) by sourceware.org with SMTP; 5 Jul 2004 21:25:06 -0000 Received: by av11-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id EFD4D37E44; Mon, 5 Jul 2004 23:25:05 +0200 (CEST) Received: from smtp4-2-sn4.m-sp.skanova.net (smtp4-2-sn4.m-sp.skanova.net [81.228.10.180]) by av11-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id DF16037E42; Mon, 5 Jul 2004 23:25:05 +0200 (CEST) Received: from [212.181.162.155] (h155n1fls24o1048.bredband.comhem.se [212.181.162.155]) by smtp4-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 058E037E53; Mon, 5 Jul 2004 23:25:05 +0200 (CEST) X-Sender: u22611592@m1.226.comhem.se Message-Id: In-Reply-To: References: <17030786.1088898907645.JavaMail.root@skeeter.psp.pas.earthlink.net> <40E749CD.9000905@phy.cmich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 05 Jul 2004 22:12:00 -0000 To: Christopher Wood From: Hans Ronne Subject: Re: Question on combat procedures Cc: xconq7@sources.redhat.com X-SW-Source: 2004/txt/msg00663.txt.bz2 >1) Is the above lists in action.def the series of functions that get >called for a particular attack? Yes. The normal sequence is that the AI, interface or task code makes two calls: 1. check_some_action. Checks that the action is possible. 2. Either prep_some_action or net_prep_some_action. Schedules the action for execution. The net_ functions also broadcast the action, so that every computer in the game schedules it. For an explanation of the difference between the two and when to use broadcast functions, see my reply to Peter Garrone last year: http://sources.redhat.com/ml/xconq7/2003/msg00918.html Next time something happens is when the run_game code calls execute_action. It also makes two calls: 3. check_some_action (in case things changed and the action is no longer possible). 4. do_some_action, which finally does the job. BTW, the task code (next abstraction layer above the actions) is quite similar. See task.def. Hans