[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
[Freeciv-Dev] (PR#39864) helicopter goto overly cautious
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39864 [book - Sat Jul 19 04:02:14 2008]: My opinion is that the current behaviour is excessively nannying and adds needless complications. The goto code should just make the unit go where you tell it to go, taking a safe route if one exists, and should not try to second guess your intentions and protect you from yourself. -- 皇帝陛下のために戦う神風が要るんだから。 Why is it that in previous versions of FreeCiv, I could send my aircraft anywhere in the world that I wanted to, but in this last version (2.1.5) it doesn't work like that? I also agree that having to move aircraft short distances at a time does not work very well. Personally, for me, it makes the game not worth the time to play. In fact, even with using waypoints, I still cannot move the aircraft very far at a time. ___ 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
[Freeciv-Dev] (PR#40213) No way to turn worker display from main map
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40213 [book - So 20. Jul 2008, 22:29:40]: [EMAIL PROTECTED] - So 20. Jul 2008, 18:15:03] Since there hasn't been done anything here for a month I assumed that this would be an ideal training ground for newbies. ;) It was very low on my list of things to do, despite the always-drawn output being quite an eyesore. Great that you saved me the trouble of having to implement this myself. Thank you book, I really appreciate your quick and helpfull responses. I'm glad if I helped you to save some time for doing other more important stuff with this. I tried to supply an option for the view menu in the same manner as all the other options have been coded before. However, I don't really understand the necessarity for the key_x_toggle() wrapper function, when you could just use directly the request_toggle_x() function in control.c. Yet I still used the same way arround for I may be too stupid to understand this. :D My guess is that one day keys will be configurable and the key_* functions correspond to bindable operations. Well that doesn't really sound convincing to me (not that it would matter to convince me ;) ). If you would make the key combos configureable for the user, wouldn't it be all the same if you'd call either key_*_toggle or request_toggle_* as both functions do the same and are prototyped in the same header file anyways? Also I used the key combo ctrl + t instead of only t, since all the other view options are also using the ctrl modifier. This patch only works for the GTK client, but should be addaptable for other clients. Not having found any problems with your patch, I'll commit it after the usual few day wait. Well take all the time you like, no need to hurry for me. ;) Greetings, Nico ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40334) save/load game to/from web
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40334 I don't know how this is best implemented... maybe by a single dedicated server (like del.icio.us http://del.icio.us ... obviously your games would be associated with your login), or maybe by letting individual players configure where their games will be stored. Maybe there's a free web storage service that could be used for the purpose. Checked out a few web storage possibilities. One that looks like a perfect fit is box.net http://enabled.box.net. They specifically give you an API, and give you a way to let users create an account easily. There are already a number of free programs that use it, such as a Firefox bookmark synchronizer. See http://enabled.box.net/docs Sounds like you ned to create a box.net project, for which you create an API key. Would be nice (according to the TOS) if this project could be more general-purpose than just for freeciv; e.g. if it could apply to saving/loading game files for multiple games. To do that, I suppose it would need to be external to freeciv; maybe just a separate folder-sync program (of which some already exist). In that case no modification of freeciv would be necessary. is already one sufficiently generic to handle this need, e.g. a general saved-game-storage project. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40337) Failing to load interstellar modpack maps
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40337 Should this savegame work? In reality, it doesn't if a client is started using my own 'starplio' tileset, but does if a client is started using amplio and then changed to starplio once the game has started. interstellar80x40.sav Description: Binary data ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#34276) clients default to the wrong port
URL: http://bugs.freeciv.org/Ticket/Display.html?id=34276 [EMAIL PROTECTED] - Mar. Sep. 04 12:00:48 2007]: On 04/09/07, Jordi Negrevernis i Font wrote: Marko Lindqvist wrote: What Freeciv version and which client are you using? Freeciv 2.1.0 Beta6 compiled from source Can you try what 'grep DEFAULT_SOCK_PORT client/clinet.h' says about default port? I grepped all our sources for '' and found no instance where it could still get it as default. I also greeped the sources and it appears that opensuse installs a default .rc with port . BTW, when i greeped the source for '' there were a lot of fuzzy translated strings with the string ''. Thanks, and sorry for the bug report. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40171) bug in gtk client - select CMA none
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40171 i noticed that PR#40097 is very similar to this report. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40171) bug in gtk client - select CMA none
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40171 i noticed that PR#40097 is very similar to this report. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
