Follow-up Comment #9, bug #16383 (project freeciv):

I'll look at splitting out the cities bit from the rest -- shouldn't be too
hard, and it'll hopefully allow the (fully working) movement part to be
committed. That is the most important part, which allows RiverNative units to
be trivially abused in many cases; if we have a few remaining oddities that
require lucky/careful city placement, that's not so bad.

> Current philosophy is to limit building of the units in cities 
> without access to native tiles, _[...]_
I agree that criteria for building and hosting units are in principle
different, the former being in can_city_build_unit_{direct,later}() and the
latter in can_exist_at_tile().
However, I think the only current practical difference at the moment is that
a city in the inland part of a "city channel" can't build sea units.
(Aside: I assumed this was an oversight and considered fixing it, but became
alarmed the expense of is_city_channel_tile().)

> _[...]_ but any unit can be stored to 
> any city (if you have units that are capable of transporting 
> ship to inland city, then your technology certainly allows 
> also keeping ship in that inland city). 
I don't think that's embodied in the current code. In can_exist_at_tile(), a
unit type is considered to be able to exist in a city only if there's some
adjacent native terrain (unless it's a BuildAnywhere unit). There's also a
recently-added special case here to handle city channels.

Actually, now I come to test this, there are bugs:
* (by inventing a trireme transporter) my transporter+trireme *in* a
landlocked city cannot unload the trireme (which I think is correct), but put
them *next* to the city and the boat can move *into* the city; the game then
generates several assertion failures on every new turn.
* If I landlock a city by transforming terrain, a sea unit caught in the city
stays there, with the same result (assertion failures). Here
update_unit_activity() only checks units on the tile, not in adjacent cities.
(These should be separate tickets, of course.)

Anyway, I think it's not such a stretch from this to adding additional
restrictions.

> I think we should retain consistency here, so if such a thing 
> is used for RiverNative units, rules for other non-native 
> units should be similarly changed. 
Strictly applied, this would make it impossible to build boats at all in the
default ruleset!
I wouldn't advocate changing the behaviour for all non-native units.

It's true that I've introduced a hardcoded exception here to solve a
particular problem, and I accept that the fact that there are already various
hardcoded special cases for rivers isn't a strong argument for adding one
more.
(BTW, are you considering folding rivers into the gen roads stuff?)

Would you be OK with some way of specifying in the ruleset whether a given
kind of non-native unit requires present or merely adjacent native terrain to
a city? (I haven't even begun to think about what that might look like, but it
should be possible.)

> Of course, *building* RiverNative units in all/only correct 
> places part should be fixed (if it really is broken). 
It's not broken, it's just that it allows something that's arguably an
exploit, so I wanted to change the behaviour.

> Actually, could you tell me how it works before this patch?
Similar to sea units: you can currently build a RiverNative unit in cities on
or adjacent to a river tile (even if not cardinally adjacent).

    _______________________________________________________

Reply to this item at:

  <http://gna.org/bugs/?16383>

_______________________________________________
  Message sent via/by Gna!
  http://gna.org/


_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Reply via email to