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

["Davide Pagnin" <nightmare@xxxxxxxxxx>]

On Wed, 2003-05-28 at 18:31, Per I. Mathisen wrote:
> 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.

You're talking of actual freeciv, right?
I was not aware that actual freeciv was not compliant with civ[12] rules
(in the sense that it behaves oddly)

> 
> > > 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.

So, definitely this means you're talking of freeciv...
(I was talking of Civ[12]...)

> 
> > 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.

IT IS NOT CIV1 NOR CIV2 RULES. (Please believe me)

And I understand that you don't care... but I do care.

> 
> > (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?

Ok, the whole misunderstanding was caused by me talking of civ[12] and
Greg (and you) talking about Freeciv.

> 
> > 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

At the moment AI isn't challenging at all if you change some parameter
(most important of them are those regarding unhappyness).
So you are defending something that is already not existent.

>   - 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

This is agreeable, but in this particular respect, if your killstack set
of rules is, say, complex valuable to 20/100, than adding my two
parameter will lead it to 25/100, that you can consider a lot (by
incremental percentage) or not (by absolute increment).

>   - Our ability to test our code to be working against these rules and
> conditions

This is trivial, both with your rules and with my addition.
(Is not so, perhaps, if Raimar idea is applied, but this is another
matter...)

> 
> 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.

I have wrote of "AI less good with civ 2 compatibility options enabled"
not of wrong AI. This means, in my mind, that with standard rules AI
will do the best thing (If it is possible...) and with civ2 rules AI
will do something considered good (but perhaps not the best thing).
Anyway, let me say that I hardly believe that you're AI will do well
with your Layer Redux set of rules and will be completely screwed up by
my two special rules.  
I can be wrong, but there is no proof at the moment, that you're right.

> 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.

What about starting to modify AI so that it support the already included
options?

> 
> > > 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.

>From my standpoint, with your proposal and my two variables, you'll get
solved the problems you pointed out and, moreover, you'll get back
civ[12] compatibility (that is not assured at the moment, if I have got
right your talking). The effort to introduce Per+civ12 Layers rules will
be just a little bit more than simple Per Layers rules AND the AI will
do only a little bit worse with civ12 rules (and perhaps this is not the
case and it is the contrary, how can you demonstrate this?)

>   - Per

        Davide