From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3154 invoked by alias); 25 Nov 2003 16:30:25 -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 3146 invoked from network); 25 Nov 2003 16:30:24 -0000 Received: from unknown (HELO smtp14.fre.skanova.net) (195.67.227.31) by sources.redhat.com with SMTP; 25 Nov 2003 16:30:24 -0000 Received: from [212.181.162.155] (h155n1fls24o1048.bredband.comhem.se [212.181.162.155]) by smtp14.fre.skanova.net (8.12.10/8.12.10) with ESMTP id hAPGU4MT001656; Tue, 25 Nov 2003 17:30:05 +0100 (CET) X-Sender: u22611592@m1.226.comhem.se Message-Id: In-Reply-To: <20031125093515.GA551@leonardo> References: <20031123101615.GB10513@leonardo> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Nov 2003 17:05:00 -0000 To: Peter Garrone From: Hans Ronne Subject: Re: Major problem with the path code Cc: xconq7@sources.redhat.com, shebs@apple.com, mcdonald@phy.cmich.edu X-SW-Source: 2003/txt/msg00920.txt.bz2 >Hello Hans, also Eric, > This explains a lot and is quite stimulating. Unfortunately i am going > to have to write a bit of an epistle explaining my position. Anyway > your message is so good I am posting it to the list. > > The bad news first. I cant see how the current structure, particularly > with pathfinding, should be done the way it is. In fact I have lost > interest in it, so if in fact it is the "right" structure, you are > going to have to expend some energy bringing me back on track. [ ... ] > The pathfinding is now implemented as part of the action code, and that > is wrong, it should be part of the player code, because the path that > is found is only ever hypothetical. Also it ie expensive, so should not > be replicated on all computers in a networked game. So have pathfinding > called from task.c, but not move.c. > > This would require that move tasks be private to each player, and not > broadcast over the network. So the logical thing to do is to stop > broadcasting all tasks, only actions, and for each game loop to only > process local ai players. Also the shared state should not include > tasks or plans. Plans should be private, it should be irrelevant to the > referee code what the plan for each unit should be, only what its > actions are. I agree. I discussed this with Stan a long time ago. I remember that he had some good arguments why plans and tasks also should be broadcasted, but I am not sure to what extent they still apply today. They might have had to do with performance, which is not an issue any longer. I will have to do some email archeology to find out. Or maybe Stan can comment on this? > Unfortunately with the existing structure, the easiest way to "fix" the > current problem would be to stop the ai player calling the pathfinding > algorithm, but I feel that would be counter-productive, so I am going > to try implementing the converse, move the tasks and plans out of the > shared network state, and only invoke the pathfinding from task level > or higher. Then try to only broadcast actions. > > As a side note, if this separation does occur, then perhaps the AI code > would be ripe for OO implementation, leaving the bulk of the current > code, which is quite mature, in C. I think this is an excellent thing to do, but post-7.5. I am a little hesitant to reorganize the entire kernel just before a release. Are you sure it's not just possible to patch the current path code so that the synch error goes away? After all, it is only seen in some games (standard, bellum). I have never seen in in advances or flattops so far, despite extensive testing. And in the standard game, it is rarely triggered unless you turn on "world-seen". This suggests to me that we are dealing with a single function call that fails to broadcast properly in the ai part of the current path code. Hans