<URL: http://bugs.freeciv.org/Ticket/Display.html?id=40316 >

> [per - Thu Jul 24 12:14:28 2008]:
> On Thu, Jul 24, 2008 at 1:01 PM, Marko Lindqvist <[EMAIL PROTECTED]>
> wrote:
> > This also brings the concept of client sied "invisible cities".
> > These are cities client knows to exist, because it has seen some
> > tile it uses, but doesn't know where city center is or anything
> > about city internals. I fixed crash related to city->tile->city
> > == NULL not so long ago. Maybe this (legally) invisible city code
> > is not working correctly, but makes also fogged cities invisible.
> Just make it a rule that if you see a city worked tile, you also see
> the city working it and surrounding tiles? It makes a great deal of
> sense from an in-game perspective, and should simplify the code logic.

I disagree with this game rule, it is not good for gameplay.
The reason being is that it would make sneaking up on cities
easier. An example would be a trireme that only has to see a
worked ocean tile to find where the city is located, in essence
giving it a larger vision radius near a city. This is also the
reason why almost all 2.0 multiplayer games disable borders;
it gives too much information to attackers and unbalances the

(I do know that triremes cannot enter deep ocean now, which is
nice I suppose, but really it applies to any unit.)

(Also, I would like borders to be fogged like units and cities
too, but that is an issue for another ticket...)

As for the case of the seen worked tile but unknown city,
perhaps it would work to have the ptile->worked field be a city
id (and to restore ptile->city to its original purpose). Then
ptile->worked==0 would indicate an unworked tile, whereas a
positive value would indicate that the tile is being worked
by the city with that id. It would be an "invisible" city if
the client does not know about that city id (i.e. has never
seen the tile on which the city is located).


Freeciv-dev mailing list

Reply via email to