Short answer: It was probably implemented with some specific unit in mind
to begin with, getting some of the details right more by coincidence than
correct design, and it has been subject to some bitrot.
On 18 April 2013 23:42, Emmet Hikory per...@shipstone.jp wrote:
Jacob Nevins wrote:
(Since I wasn't sure: this is referring to normal attack that the
comments
call bombardment, not the technical meaning of bombard that
UTYF_BOMBARDER
units do. That has its own hardcoded restrictions on terrain type, but
fixing
that should be the subject of a separate ticket.)
Regarding those: is there any documentation of the rationale for the
UTYF_BOMBARDER restrictions? I've looked at them a few times, but don't
have a clear idea of the intention behind the various restrictions. At
least in some places, the comments and code don't seem to match at all
(e.g. the error about being transported when testing is_ocean_tile() in
unithand.c:unit_move_handling()). The particular restriction that
confuses me the most is that one cannot bombard while in transport (from
unit.c:can_unit_bombard()), even if the tile is native, so that a player
could disembark the unit, bombard, and reembark the unit (thereby
increasing pointless micromanagement).
Over the years I've fixed similar checks from many places from the code.
At least in most cases it has been idiom for what now should be cannot act
while transported on non-native terrain - that was the same thing when sea
units were the only ones capable of transporting other units + they were
capable of carrying only land units.
One thought I had was to remove all hardcoded terrain and transport
restrictions, allow bombard if can_exist_at_tile() when the target has
UCF_CAN_FORTIFY and otherwise perform a normal attack, but I don't know
if there are uses of bombarders that would be broken with such a
solution, or if regardless of current uses, there is an interest in
making it even more general (e.g. using another vector to determine
targets or similar).
In general that sounds like a right direction to go. Just don't reuse
CanFortify for something unrelated (as far as I can see).
- ML
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
