From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22994 invoked by alias); 19 Aug 2004 11:25:52 -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 22953 invoked from network); 19 Aug 2004 11:25:51 -0000 Received: from unknown (HELO av15-2-sn4.m-sp.skanova.net) (81.228.10.101) by sourceware.org with SMTP; 19 Aug 2004 11:25:51 -0000 Received: by av15-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id C896937E45; Thu, 19 Aug 2004 13:25:50 +0200 (CEST) Received: from smtp4-1-sn4.m-sp.skanova.net (smtp4-1-sn4.m-sp.skanova.net [81.228.10.181]) by av15-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id B7B0837E42; Thu, 19 Aug 2004 13:25: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 214C137E43; Thu, 19 Aug 2004 13:25:50 +0200 (CEST) X-Sender: u22611592@m1.226.comhem.se Message-Id: In-Reply-To: <200408190637.i7J6bZc03815@panix5.panix.com> References: (message from Hans Ronne on Wed, 18 Aug 2004 14:53:15 +0200) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Aug 2004 11:57:00 -0000 To: Jim Kingdon From: Hans Ronne Subject: Re: The border between fiction and reality Cc: xconq7@sources.redhat.com X-SW-Source: 2004/txt/msg00956.txt.bz2 >> 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. > >Well, to me that means there should be an advance action, so that the >decision between overrun and move (and the other choices, like >capture) are in the action, rather than outside it. That makes sense. I'll look into it. >But perhaps there is a simpler solution, or the status quo is >technically wrong but doesn't lead to any exploits/leaks/etc. Or even >that advance_into_cell is tied into the user interfaces in ways which >aren't immediately obvious to me, and thus would be hard to put into >an action. In fact, there is one more rather interesting complication, considering our previous discussion about selective actions and one action defaulting into another one. When you click in the target cell, as opposed to a do_dir command, the interfaces actually look up the unit under the cursor. This is something that the common interface code cannot do, since the pixel coordinates differ between different interfaces. It is the main reason why unit pointers are present in the tcltk/mac/x11 code. So what is this selected unit doing in a basically non-selective action? Well, it turns out that if the overrun fails because you don't have enough ammo to hit all units in the stack, the action is converted into a selective attack against the unit under the cursor. Here is the relevant code from advance_into_cell: rslt = check_overrun_action(unit, unit, x, y, z, 100); if (valid(rslt)) { net_prep_overrun_action(unit, unit, x, y, z, 100); return TRUE; } if (reason && rslt == A_ANY_NO_AMMO) *reason = (HistEventType)rslt; rslt = check_attack_action(unit, unit, other, 100); if (valid(rslt)) { net_prep_attack_action(unit, unit, other, 100); return TRUE; } I don't think this happens very often in real games. At least, I was not aware of the potential selectivity of clicking on a unit. It makes me wonder if this selectivity could be used also in a successful overrun action. For example, one could perhaps make the unit that was clicked on the first one to be attacked, instead of using the normal stack order. Or make this unit more likely than others to be hit. Hans