Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2002:
[Freeciv-Dev] Re: (PR#2329) Portattacks 7
Home

[Freeciv-Dev] Re: (PR#2329) Portattacks 7

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: raahul_da_man@xxxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#2329) Portattacks 7
From: "Per I. Mathisen via RT" <rt@xxxxxxxxxxxxxx>
Date: Sat, 16 Nov 2002 07:02:08 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Sat, 16 Nov 2002, Raahul Kumar wrote:
> > Some of us discussed this on irc today. What we came up with is this idea
> > of units being in "layers" on the battlefield. Some units are up in the
> > air, some are on ground, others are in the sea. Killstack should only work
> > within one layer at a time. So if you kill a fighter, all air units
> > stacked with it die, but not a mech inf. get_defender() should prefer
> > units in the same layer as your own before trying to attack units in
> > another layer.
>
> I like this idea, but this is very hard to implement. Who exactly is going to
> implement killstack? I haven't even seen that code, and I doubt it worked
> before.

Killstack is what we have now. What I'm suggesting is that killstack only
works within one layer (air, ground, or sea) at a time.

> That will be a seperate patch to this in any case. Killstack can succeed and
> fall on its own merits. I refuse to add killstack to this current patch.

The so-called "killstack" patch has nothing to do with this. The patch
already contains killstack code changes. Those changes aren't really sane,
since it uses get_defender() to iteratively kill all eligible defenders.

> > The exception to this are airfields and cities. In cities, all units are
> > considered "grounded", and so best defender defends regardless of which
> > layer the unit would otherwise be at. Aircraft are "grounded" in
> > airfields, so that ground units will defend them, and killstack will
> > destroy them if a ground unit dies there.
>
> Status quo.

Yes.

> Per, I'm not clear on what happens to an air unit that attacks a normal stack
> of 3 mech inf. Are we retaining the current system that all 3 die, or do air
> units have to kill every single member of the stack one by one?

All units in the same layer die. So the mech infs are history.

> > As to the patch, I think the new abilities should be controlled a new
> > global game option in game.ruleset. The subs change should be a new unit
> > flag which says that for this unit, cities don't "ground" sea units in
> > cities, thus they will be in the "sea" layer when it attacks. This flag
> > can be used for normal ships too, which means they'll attack ships first,
> > then other units. F_PORTATTACK can be a name.
>
> I'm not sure if I understand this idea correctly. We're adding a new flag,
> PORTATTACK, and if that unit has it, get_defender will do exactly what we
> currently do for F_NO_LANDATTACK.

Not exactly. If given to a normal ship unit, the ship will first attack
any ship defenders in a city, before attacking any other units, even if
those other units are much better. This flag can even be generalised to
mean that you attack units in your own layer first _even in cities and
airfields_, so that it can be used for air and ground units too. Can call
it F_SNEAKATTACK, maybe, to indicate that it can ignore the "grounding"
(all units are considered in ground layer) effect of cities and airfields.

> Where exactly is the change here from the current situation? The only benefit
> from this change is Civ 2 Compatability. We get to keep the old model as is. I
> don't like the old model, and I think at some point we have to say no to
> compatability.

Not just compatibility... also more configurability.

> But if the maintainers insist, I will make the change.

Oh, I'm at least sure Davide will insist ;-)

> Raimar's idea seems far too hard for me. The idea of adding x,y,z co-ords is
> too difficult for me. And subs will be 4 dimensional, requiring yet another
> axis. So Sub and Air units will need at least two moreaxes. I don't think you
> have thought this through.

I haven't, and I think this part should wait. It can be added later.

  - Per




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