Complete.Org: Mailing Lists: Archives: freeciv-dev: May 2003:
[Freeciv-Dev] Re: (PR#4196) Enemies in allied transport assert.
Home

[Freeciv-Dev] Re: (PR#4196) Enemies in allied transport assert.

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients:;
Subject: [Freeciv-Dev] Re: (PR#4196) Enemies in allied transport assert.
From: "Gregory Berkolaiko" <Gregory.Berkolaiko@xxxxxxxxxxxx>
Date: Thu, 8 May 2003 14:02:27 -0700
Reply-to: rt@xxxxxxxxxxxxxx

On Thu, 8 May 2003, Per I. Mathisen wrote:

> > The function will now return the best defender available on the tile
> > against given unit. It might be an enemy, might be an ally, might even
> > be one of the attacker's relatives. I decided that get_defender is no
> > place to make such checks.
> 
> Err... but...
> 
> You're changing the rules. Maybe this would be a good thing, but at least
> then we have to aware of what is changing.
> 
> Previously, if we attack a tile containing units with multiple owners, you
> were guaranteed to be picking one of those units that were at war with you
> as defender. Units not at war with you would survive the attack.

No kidding!  I wasn't aware of this rule...
But ...testing... such rule exists.

Well, that's just ridiculous!

> Now you get the situation where you may attack a tile containing such
> units, and get a friendly unit as defender, which will be protecting (as
> human shield) the enemy units on the tile. Whether or not this human
> shield thing works, will be rather arbitrary, which is itself bad.
> 
> Of course, we may rule that you can't attack such stacks at all.

That's what we should do!  That's what I thought is the present situation.
Because you cannot kill units under another unit neutral to you, but you 
can under a unit allied to you.  It makes no sense.

And because of this stupid rule the bug that prompted this discussion 
happens.

> Anyway, there you have a fine way to confuse the AI - cooperate with
> someone not at war with it to render your units totally immune to attack.
> 
> The correct solution is to go the other way, the way that the layers patch
> went: Returning NULL is not an indication that the tile is empty. It is
> just an indication that you cannot attack anything there. You got to lose
> the assumption that just because you can't attack a tile, you can move
> there.

This is also a good idea.  But we need to simplify the rules first.

Axiom: all units on the tile of defeated defender die (unlessthere is a 
fortress/city/airport there)
Corollary 1: You cannot attack a non-city tile with a unit not at war with 
you.
Corollary 2: To make rules consistent you cannot attack _any_ tile with a 
unit not at war with you.

> > The step after that is a thorough cleaning of handle_unit_move_request, to
> > ensure that it issues right warnings.
> 
> Well, that is necessary in any case. The function is a mess. I started
> cleaning it up a while ago, moving more stuff to the client, but left it
> unfinished, the patch is in RT.
> 
> > Also it would be helpful if you can tell me what happens when something
> > (not Fighter) attacks a tile with a Bomber and fortified tank.
> 
> It is not allowed. The check to can_unit_attack_unit_on_tile() fails.

The check is only on the chief defender.  But what if the tank is selected 
as the defender?

G.




[Prev in Thread] Current Thread [Next in Thread]