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 Freecivemail@example.com https://mail.gna.org/listinfo/freeciv-dev