[Freeciv-Dev] Re: (PR#2581) Layers proposal redux

["Per I. Mathisen" <per@xxxxxxxxxxx>]

On Wed, 28 May 2003, Davide Pagnin wrote:
> Nope! I'm convinced that, if we need to go with simple Per idea, and
> there is space to save civ[12] compatibility, the best choice is to have
...
> a) global killstack (instead of layered killstack)
> b) global best defender (instead of layered best defender)
> (this two are related and not difficult to implement, we can code them
> as "battle effects are global in respect of layers" and unify them)
...
> c) Layer superiority rule, changed this way:
> "You cannot attack a tile if your own layer or any layer above yours
> contains one ore more units but you cannot attack any of them"
> NOTE the word "any layer above yours"
...
> global_battle_effects (vs. layered_battle_effects)
> strict_layer_superiority (vs. loose_layer_superiority)

Yes, this is a way to achieve 100% civ1/2 compatibility. I do not think it
is a good idea for reasons explained before.

> > I don't know how we can reasonably model the even more idiotic rule that
> > an attacking Fihgter might be forced to attack a Mech Inf rather than the
> > Bomber.
>
> Wait! If you consider that the original rule will let you destroy (by
> killstack) all units in the tile, THAN selecting the best defender (not
> the easy target) is not "idiotic" it is clearly the only wise option.

Greg means that sometimes you will select the mech inf instead of being
blocked by the air unit. Then clearly you do _not_ choose the "best
defender", since that would have been the air unit. So the rules are
inconsistent.

> > Note, that the pure layers redux proposal allowed full Civ12 compatibility
> > (including all idiotic features like bombers falling out of sky when the
> > Mech Inf under itis killed).All you had to do is to put everything into
> > one layer.
>
> Well, there are 2 options:
>
> 1. I have not understood at all Per's proposal
>
> 2. You're wrong
>
> So, supposed that the first statement is true, I will submit some
> example and you can explain me how they will work with Per Layer Redux
> idea:
>
> a) A tile containing a bomber and a mech. inf. is attacked by an armor.
> Civ[12] will stop you and say "Only fighter can attack air unit"

In the current rules, attacking a tile that contains a ground unit and an
air unit with a ground unit causes either failure to attack _or_ an attack
on the ground unit, depending on the defensive powers of the two
defenders. So Greg is correct in saying that a ground unit can destroy
a plane in an attack by killstack.

> b) A tile containing a bomber and a mech. inf is attacked by a fighter
> Civ[12] will allow you attacking but chose mech. inf. as best defender,
> in the event you win both mech. inf. and bomber are destroyed.
>
> How can those 2 examples be resolved (with 100% compatibility) with Per
> Layers Redux?

If you put all units in the same layer, in b) you will pick mech. inf. as
defender since it is the best defender, and in a) you will also pick mech.
inf. as defender, since it defends better than the bomber. In both cases,
if we win we will killstack both defenders.

This is, IIRC, exactly the same as default ruleset and civ2 ruleset
behaviour in Freeciv today. It may or may not be exactly like the real
civ2 did it, but then I don't really care much for exact emulation of
every little civ2 rule.

> (the worst problem, for your solution, is that I can't imagine how you
> instruct the computer to consider air units differents from sea units

Apart from can_unit_attack_unit_at_tile(), which will remain unchanged, we
don't. Where is the problem?

> If the layer proposal has the goal of eliminating any kind of special
> flags, than it will fail, at least IMHO.

Agreed.

On Wed, 28 May 2003, Davide Pagnin wrote:
> If you introduce layered stack and compatibility special rules AND AI
> will do well with layered stack and less well with compatibility rules
> enable, I'm fine. (Perhaps you're not...)

I'm not. In fact, I would be very unhappy about such a decision.

There are three factors here:
  - The AI's ability to function and remain challenging under different
rules and conditions
  - The time it takes to write code that supports all possible rules and
conditions that may or may not be changed from modpack to modpack
  - Our ability to test our code to be working against these rules and
conditions

The AI code works as a partial validator of the code by triggering asserts
or core dumps when it encounters errors. By supporting an option, it
validates it to a certain extent. Eventually, we should build up a test
suite of autogames to run that exercises various options and rules. I am
confident that this would uncover a lot of bugs that we have no doubt
introduced but that remain undetected since they only trigger with
non-standard options.

For these reasons, I am against any half-supported or unsupported options
or rules. Either we go all the way or we don't go there at, IMHO.

> > But my real reason to be against it is that it is too complicated for no
> > gain. Instead, the AEGIS ability should one day be generalised as a unit
> > effect.
>
> This may be a good point, but then I hardly imagine why there are so
> many configurable options in Freeciv that nobody change or uses...

That is no excuse for making the situation worse than it is.

  - Per