http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
2008/7/28 Nicolas R. Wadhwani:
>
>> tile_city() returns real current situation. Instead server should
>> send to client what player knows. Player may think there is a city in
>> fogged tile, when in reality city has been destroyed since last
http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
> tile_city() returns real current situation. Instead server should
> send to client what player knows. Player may think there is a city in
> fogged tile, when in reality city has been destroyed since last seen,
> or new city has been founde
http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
tile_city() returns real current situation. Instead server should
send to client what player knows. Player may think there is a city in
fogged tile, when in reality city has been destroyed since last seen,
or new city has been founded to til
http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
Indeed Marko is right; this is a server problem after all. You should
be sending the city ID of the dumb city. This code has been rewritten
however and apparently I no longer have any clue how it works. See
maphand.h.
-jason
__
http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
> [EMAIL PROTECTED] - Fr 25. Jul 2008, 16:12:11]:
> It seems to me that problem has to be
> in server side sending such information in the first place. Something
> wrong with send_tile_info()?
Thanks for the hint. The same I did on the clie
http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
> [EMAIL PROTECTED] - Fr 25. Jul 2008, 16:12:11]:
> It seems to me that problem has to be
> in server side sending such information in the first place. Something
> wrong with send_tile_info()?
Thanks for the hint. The same I did on the clie
http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
2008/7/25 Marko Lindqvist:
> You seem to be avoiding
> setting ptile->worked to NULL when server requests it by sending
> worked == IDENTITY_NUMBER_ZERO. It seems to me that problem has to be
> in server side sending such information in the f
http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
2008/7/25 guest user:
>
> Great! Without even looking at the code you know exactly how to track
> down the bug. Just that the worked member isn't set to NULL directly but
> via a wrapper method I looked for in packhand.c and just the first ma
http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
> [EMAIL PROTECTED] - Do 24. Jul 2008, 00:49:34]:
> The problem must be that when the tile is fogged (in the tile packet),
> the ptile->worked flag is cleared. Looking for "->worked = NULL" in
> the code should find the offending code - it
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
http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
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
http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
2008/7/24 guest user:
>
> There is the catch: Between the versions the ptile->city member has been
> replaced by ptile->worked which points to the city working on the tile,
> so many tiles are pointing to the same city (in the city radius I
>
http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
[EMAIL PROTECTED]
Well I probably have the time for working on this but my experience
doesn't quite match yours with neither the C programming language nor
the freeciv source code, so I'm not all that confident that it would be
just a matter
http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
pcity->tile and ptile->city are both set to the correct values.
> In general ptile->city->tile == ptile and pcity->tile->city == pcity
> all the time (that would be a useful assertion to add somewhere - in
> fact client-side sanity checks mig
http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
As madeline points out, your patch is not right at all. But it does
make the problem clear: the "dumb city" information is being sent to the
client but ptile->city is not being set correctly there.
The error most likely resides in handle_ci
http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
On Wed, Jul 23, 2008 at 6:13 PM, guest user wrote:
> There is the catch: Between the versions the ptile->city member has been
> replaced by ptile->worked which points to the city working on the tile,
> so many tiles are pointing to the same
http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
On Wed, Jul 23, 2008 at 2:46 PM, guest user wrote:
>
> http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
>
> [EMAIL PROTECTED]
>
> Well I probably have the time for working on this but my experience
> doesn't quite match yours with neit
http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
On Tue, Jul 22, 2008 at 4:34 PM, guest user wrote:
> Attached patch will let the cities be visible in the fog after you
> viewed them with a unit or something else. Note that if you test it on a
> savegame affected by the current bug you wi
http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
> [guest - Tue Jul 22 22:34:42 2008]:
>
> [EMAIL PROTECTED]:
>
> Attached patch will let the cities be visible
> in the fog after you viewed them with a unit or
> something else. Note that if you test it on a
> savegame affected by the curr
http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
[EMAIL PROTECTED]:
Hi,
Attached patch will let the cities be visible in the fog after you
viewed them with a unit or something else. Note that if you test it on a
savegame affected by the current bug you will have to give the client
the cha
http://bugs.freeciv.org/Ticket/Display.html?id=40316 >
In trunk, any fogged tile won't show an enemy city. I can see the
borders but no city. Moving up to the city will reveal it, but it
disappears again when my unit moves away.
-jason
___
Freec
21 matches
Mail list logo
