Re: [Freeciv-Dev] (PR#40316) enemy cities not shown in fogged tiles
URL: 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 seen,
or new city has been founded to tile that previously had none.
Player knowledge should be available from player_tile. Cities are one
kind of vision_site, I think.
That means that the way the owner is communicated by the server on fogged
tiles is currently also wrong, as it uses the tile_owner function returning
also the real current situation and not what the client is supposed to know.
There's separate discussion about how to best handle owner
information of fogged tiles. I leave that part out until we know how
to really implement it. Modified version of your patch attached.
- ML
diff -Nurd -X.diff_ignore freeciv/server/maphand.c freeciv/server/maphand.c
--- freeciv/server/maphand.c2008-07-06 17:49:05.0 +0300
+++ freeciv/server/maphand.c2008-08-01 20:30:08.0 +0300
@@ -406,13 +406,16 @@
} else if (pplayer map_is_known(ptile, pplayer)
map_get_seen(ptile, pplayer, V_MAIN) == 0) {
struct player_tile *plrtile = map_get_player_tile(ptile, pplayer);
+ struct vision_site *psite = map_get_player_base(ptile, pplayer);
info.known = TILE_KNOWN_UNSEEN;
info.continent = tile_continent(ptile);
info.owner = (NULL != tile_owner(ptile))
? player_number(tile_owner(ptile))
: MAP_TILE_OWNER_NULL;
- info.worked = IDENTITY_NUMBER_ZERO;
+ info.worked = (NULL != psite)
+? psite-identity
+: IDENTITY_NUMBER_ZERO;
info.terrain = (NULL != plrtile-terrain)
? terrain_number(plrtile-terrain)
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40316) enemy cities not shown in fogged tiles
URL: 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 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40316) enemy cities not shown in fogged tiles
URL: 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 tile that previously had none. Player knowledge should be available from player_tile. Cities are one kind of vision_site, I think. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40316) enemy cities not shown in fogged tiles
URL: 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 tile that previously had none.
Player knowledge should be available from player_tile. Cities are one
kind of vision_site, I think.
That means that the way the owner is communicated by the server on fogged
tiles is currently also wrong, as it uses the tile_owner function returning
also the real current situation and not what the client is supposed to know.
I haven't realised up till now that the borders are also updated on fogged
tiles despite not having sent units to recon the new changes. I tried to
solve this right along when getting the cities working, however the owner
member of the vision_site struct seems not beeing set correctly at some other
place in the code, while the identity member seems to be working just like it
should be. So when applying this patch you would see the borders only on not
fogged tiles. I'm still trying for the right place in the code to set the
owner property, but as I don't have much of a clue I'm open for suggestions
as always. ;)
Greetings,
Nico
diff -Nur -X.diff_ignore trunk/server/maphand.c changed/server/maphand.c
--- trunk/server/maphand.c 2008-07-27 21:44:04.0 +0200
+++ changed/server/maphand.c 2008-07-27 23:32:28.0 +0200
@@ -406,13 +406,16 @@
} else if (pplayer map_is_known(ptile, pplayer)
map_get_seen(ptile, pplayer, V_MAIN) == 0) {
struct player_tile *plrtile = map_get_player_tile(ptile, pplayer);
+ struct vision_site *psite = map_get_player_base(ptile, pplayer);
info.known = TILE_KNOWN_UNSEEN;
info.continent = tile_continent(ptile);
- info.owner = (NULL != tile_owner(ptile))
- ? player_number(tile_owner(ptile))
+ info.owner = (NULL != psite NULL != psite- owner)
+ ? player_number(psite-owner)
: MAP_TILE_OWNER_NULL;
- info.worked = IDENTITY_NUMBER_ZERO;
+ info.worked = (NULL != psite)
+? psite-identity
+: IDENTITY_NUMBER_ZERO;
info.terrain = (NULL != plrtile-terrain)
? terrain_number(plrtile-terrain)
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40316) enemy cities not shown in fogged tiles
URL: 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 first place. For fogged tile, worked id should be id of the dumb city from player map (city player *believes* to be there). - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40316) enemy cities not shown in fogged tiles
URL: 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 client side can also be done in this function on the server, see the attached patch. diff -Nur -X.diff_ignore trunk/server/maphand.c changed/server/maphand.c --- trunk/server/maphand.c 2008-07-24 23:03:15.0 +0200 +++ changed/server/maphand.c 2008-07-25 23:50:56.0 +0200 @@ -412,7 +412,9 @@ info.owner = (NULL != tile_owner(ptile)) ? player_number(tile_owner(ptile)) : MAP_TILE_OWNER_NULL; - info.worked = IDENTITY_NUMBER_ZERO; + info.worked = (NULL != tile_city(ptile)) +? tile_worked(ptile)-id +: IDENTITY_NUMBER_ZERO; info.terrain = (NULL != plrtile-terrain) ? terrain_number(plrtile-terrain) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40316) enemy cities not shown in fogged tiles
URL: 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 client side can also be done in this function on the server, see the attached patch. Greetings, Nico diff -Nur -X.diff_ignore trunk/server/maphand.c changed/server/maphand.c --- trunk/server/maphand.c 2008-07-24 23:03:15.0 +0200 +++ changed/server/maphand.c 2008-07-25 23:50:56.0 +0200 @@ -412,7 +412,9 @@ info.owner = (NULL != tile_owner(ptile)) ? player_number(tile_owner(ptile)) : MAP_TILE_OWNER_NULL; - info.worked = IDENTITY_NUMBER_ZERO; + info.worked = (NULL != tile_city(ptile)) +? tile_worked(ptile)-id +: IDENTITY_NUMBER_ZERO; info.terrain = (NULL != plrtile-terrain) ? terrain_number(plrtile-terrain) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40316) enemy cities not shown in fogged tiles
URL: 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 suppose). That is what the tile_city function is all about (in S2_1 it didn't exist and the put_one_element function got just passed ptile-city), as it checks whether the tile that is worked on (if at all) is the center tile of the city itself or if not returns NULL (meaning it is just a tile in the vicinity of the given city and worked by it). 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. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40316) enemy cities not shown in fogged tiles
URL: 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 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. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40316) enemy cities not shown in fogged tiles
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 game. (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 Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40316) enemy cities not shown in fogged tiles
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40316 On Wed, Jul 23, 2008 at 6:13 PM, guest user Freeciv 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 city (in the city radius I suppose). That was a terrible idea. Though I suppose at first glance it must have seemed attractive enough. Question: if you disconnect and reconnect to the server, are the fogged cities shown then? I cannot recall testing this. Wow, that was a GREAT idea! I just tested it and noticed that the cities are updated correctly (meaning they are visible when fogged) after rejoining the game. I moved up to one visible fogged city with an explorer and left again et voila: once the city got fogged again it disappeared from the map. The problem seems to occur when the fogged city becomes visible again or is fogged again. So the problem with the updating must be happening somewhere when the TILE_KNOWN_UNSEEN flag is set for a formerly seen tile or vice versa when it is reset to the TILE_KNOWN_SEEN. I'll try to check through all the code blocks where these status flags are checked and/or changed and compare them with the former code of S2_1. Maybe I'll get lucky and find the needle in the haystack before the few weeks pass by. ;) 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 shouldn't be cleared if there's a city on the tile. It's also possible that the server is telling the client the tile is not worked. This would be a related error but in the server code. Though it could be fixed client-side I suppose. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40316) enemy cities not shown in fogged tiles
URL: 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 of a few weeks... ;) I can see books point, all of which quite sensible, and understand that the actual problem is quite somewhere else. It just isn't quite reassuring for me that an incredible complex and obscure code block I believe could be the source of the problem is commented on top of it with the words This was once very ugly In this tradition you could maybe use my current patch as temporarily solution if you want to branch S2_3 any time soon, as reverting back to the old S2_1 state would probably mean killing off a lot of good work related to the border algorithms (which seems to be the key change between versions that screwed all this fogged stuff up). Greetings, Nico the n00b ;) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40316) enemy cities not shown in fogged tiles
URL: 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 might be a good thing in general, but that's off topic). 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 suppose). That is what the tile_city function is all about (in S2_1 it didn't exist and the put_one_element function got just passed ptile-city), as it checks whether the tile that is worked on (if at all) is the center tile of the city itself or if not returns NULL (meaning it is just a tile in the vicinity of the given city and worked by it). This worked member is used quite extensively for calculating the owners of the tiles and their surrounding borders, so it seems to be working quite fine. Only problem is that somewhere on the client (or more likely on the server) this member isn't updated correctly, maybe because somebody thought that the client shouldn't be supposed to know about what tiles are worked by other players if they can't see it (hich sounds quite sensible at first glance). Question: if you disconnect and reconnect to the server, are the fogged cities shown then? I cannot recall testing this. Wow, that was a GREAT idea! I just tested it and noticed that the cities are updated correctly (meaning they are visible when fogged) after rejoining the game. I moved up to one visible fogged city with an explorer and left again et voila: once the city got fogged again it disappeared from the map. The problem seems to occur when the fogged city becomes visible again or is fogged again. So the problem with the updating must be happening somewhere when the TILE_KNOWN_UNSEEN flag is set for a formerly seen tile or vice versa when it is reset to the TILE_KNOWN_SEEN. I'll try to check through all the code blocks where these status flags are checked and/or changed and compare them with the former code of S2_1. Maybe I'll get lucky and find the needle in the haystack before the few weeks pass by. ;) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40316) enemy cities not shown in fogged tiles
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40316 On Tue, Jul 22, 2008 at 4:34 PM, guest user Freeciv 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 will have to give the client the chance to get an update on the city list by the server. E.g. with the GTK client and current editor available just press key combos: ctrl + e, ctrl + f and ctrl + e again. This bug is introduced since 2.1; I have no idea how or if it could have been intentional. One thing is for sure though: that it needs to be fixed and fixed carefully. Bugs with dumb cities have been around forever and any massive change here will likely introduce more instability. Better is to try to revert to the 2.1 design. I think. Unfortunately I don't have the resources to look at this problem within the next few weeks but I hope someone can give it the attention it deserves. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
