Complete.Org: Mailing Lists: Archives: freeciv-dev: May 2003:
[Freeciv-Dev] Re: (PR#2581) Layers Patch

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#2581) Layers Patch
From: Juhani Heino <juhani.heino@xxxxxxxxxx>
Date: Thu, 22 May 2003 15:35:20 +0300

Sorry if this mail seems odd - I hadn't subscribed to
freeciv-dev  yet so I took it from the archives. So
probably the threading won't work.

> I didn't understand the need for the layer weights.
> The layers discussed earlier gave sharp distinctions between the 
> different layers. I like this since it makes the game rules 
> predictable. First you attack your own layer, then you attack
> the other layer. Only two layers are needed at this point:
> 'ground' and 'air'. Sea units are 'ground'.

They were not weights, but priorities given - only the units
at the highest priority are compared otherwise. So this is meant
to be totally predictable (if you know what units there are).

And Sea units can't be 'ground' because ground units can't
attack them. layer_priority() was made to be as general
as possible.

One afterthought - I commented that you can remove the
strafing possibility by changing the fighter value to 15.
But that would mean we should add a function is_cargo()
to see if defending aircraft is in air or on carrier.
Actually the function would be more general and apply
to ground units too.

Besides, I like the idea of strafing   8-)

> The reason why I and Greg got renewed interest in layers was
> because we found problems in the code that were hard to solve
> otherwise. I cannot for the life of me remember what it was
> we found (exam reading takes its toll on the mind) but I hope
> Greg can fill that in. Anyway, the conclusion we came to was
> that layers should replace the current code - it should not be
> optional. It is just too hard to keep two separete code paths
> in this area bug free over a longer period of time.

While I was at it, I thought that some if not all
functionality of can_unit_attack_unit_at_tile() could
be moved to layer_priority(). If you think this would be
good, I'll make another patch after this is committed.
And I can take a look if I can cleanup elsewhere too.
I got the same warm feeling about layers - thanks, Raahul.

>> can_unit_attack_unit_at_tile() contradicts its comment 4:
>> marines can't attack a sea tile. If the comment is valid
>It is.

OK. So I'll make the changes at these.

>> I moved *_carrier_capacity  functions to more logical place
>> in unit.c
>Please don't. If you must, supply a _separate_ patch that does nothing
>but move it. Try very hard to avoid "patch noise".

OK, sorry. I'll remember that in future, and in the new
version I'll separate them.

>I saw no 'stranded' feature above, but... yes, I think so. Doesn't this
>happen already? If not, I remember adding this feature to my new stack
>resolve code patch (not posted yet).



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