[Freeciv-Dev] [bug #16300] doesn't compile with --enable-debug
Follow-up Comment #1, bug #16300 (project freeciv): what system do you use? The warnings are for variables of type 'size_t' printed using '%lu'. What is the type of size_t on your system? As a solution casts could be added to all lines with warning ... I do compile using '--enable-debug=checks' and get no errors (opensuse 11.1). ___ Reply to this item at: http://gna.org/bugs/?16300 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16300] doesn't compile with --enable-debug
Update of bug #16300 (project freeciv): Status:None = Ready For Test Assigned to:None = syntron Planned Release: = 2.3.0 ___ Follow-up Comment #2: Here is a patch adding the needed casts. (file #9564) ___ Additional Item Attachment: File name: 20100725-04-trunk-cast-size_t-as-unsigned-long.patch Size:3 KB ___ Reply to this item at: http://gna.org/bugs/?16300 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16300] doesn't compile with --enable-debug
Follow-up Comment #3, bug #16300 (project freeciv): I use Ubuntu Karmic 32 bit. Is there a possibility that these casts can go wrong on 32 bit or 64 bit? Compilation of savegame2.c works OK with this patch, but I can't test if saving/loading the game is correct because of another warning in gtkitemfactory.h (that's not freeciv's problem, but it prevents me from compiling the whole source). Maybe there is a way to compile freeciv with debugging support without warnings being treated as errors? ___ Reply to this item at: http://gna.org/bugs/?16300 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16300] doesn't compile with --enable-debug
Follow-up Comment #4, bug #16300 (project freeciv): I use Ubuntu Karmic 32 bit. Is there a possibility that these casts can go wrong on 32 bit or 64 bit? This could be the case for size_t ... (32 bit on 32 and 64 bit on 64?) Compilation of savegame2.c works OK with this patch, but I can't test if saving/loading the game is correct because of another warning in gtkitemfactory.h (that's not freeciv's problem, but it prevents me from compiling the whole source). It's due to an error in gtk and you using '--enable-debug=checks'. If you use only '--enable-debug=yes' it should work. See patch #1493 and ./doc/HACKING) Maybe there is a way to compile freeciv with debugging support without warnings being treated as errors? Yes, use '--enable-debug=yes' or (if it's your system and you can do it) change one line in gtkitemfactory.h (see the link in ./doc/HACKING). ___ Reply to this item at: http://gna.org/bugs/?16300 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16301] update queue not working with player pointers
URL: http://gna.org/bugs/?16301 Summary: update queue not working with player pointers Project: Freeciv Submitted by: syntron Submitted on: Montag 26.07.2010 um 12:34 Category: None Severity: 3 - Normal Priority: 1 - Later Status: None Assigned to: None Originator Email: Open/Closed: Open Release: trunk (patched) Discussion Lock: Any Operating System: None Planned Release: 2.3.0 ___ Details: if the patch #1739 is applied, the update queue is not working anymore. I had to bypass the queue to leave the game ___ File Attachments: --- Date: Montag 26.07.2010 um 12:34 Name: 20100726-02-trunk-fix-set_client_page.patch Size: 812B By: syntron http://gna.org/bugs/download.php?file_id=9565 ___ Reply to this item at: http://gna.org/bugs/?16301 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1739] [players] use pointers for players
Follow-up Comment #9, patch #1739 (project freeciv): new version; the editor was not working do to a missing call to player_slots_init() patch comments: * replace the static array game.players by 'const struct player **pslot' * add new accessor functions * define an extra 'placeholder' player in ./client/packhand.c * game_reset() does player_slots_free() AND player_slots_init() for clients * send player information to the client in send_conn_info_arg() as the player information are reset if one switches into edit mode leaving a game is not working - I need to bypass the update queue for page changes; see gna bug #16301 (file #9566) ___ Additional Item Attachment: File name: 20100726-01-trunk-use-pointers-for-players.patch Size:100 KB ___ Reply to this item at: http://gna.org/patch/?1739 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1732] [Metaticket] increase number of players
Update of patch #1732 (project freeciv): Depends on: = bugs #16301 ___ Reply to this item at: http://gna.org/patch/?1732 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1741] [players] use player_slot_count
Follow-up Comment #2, patch #1741 (project freeciv): updated version (file #9567) ___ Additional Item Attachment: File name: 20100726-03-trunk-use-player_slot_count.patch Size:9 KB ___ Reply to this item at: http://gna.org/patch/?1741 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1742] [players] cleanup game_init()
Update of patch #1742 (project freeciv): Summary: [players] cleanup game_(init|free|reset) = [players] cleanup game_init() ___ Follow-up Comment #1: updated version (file #9568) ___ Additional Item Attachment: File name: 20100726-04-trunk-split-game_init-into-game_init-and-game_default.patch Size:1 KB ___ Reply to this item at: http://gna.org/patch/?1742 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1743] [players] dynamically allocate player-diplstates
Follow-up Comment #2, patch #1743 (project freeciv): updated version (file #9569) ___ Additional Item Attachment: File name: 20100726-05-trunk-dynamically-allocate-player-diplstates.patch Size:71 KB ___ Reply to this item at: http://gna.org/patch/?1743 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1745] [players] dynamically allocate ai_data
Follow-up Comment #2, patch #1745 (project freeciv): updated version (file #9570) ___ Additional Item Attachment: File name: 20100726-07-trunk-dynamically-allocate-ai_data.patch Size:49 KB ___ Reply to this item at: http://gna.org/patch/?1745 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1759] [players] fix debugging tool in score.c
URL: http://gna.org/patch/?1759 Summary: [players] fix debugging tool in score.c Project: Freeciv Submitted by: syntron Submitted on: Montag 26.07.2010 um 12:45 Category: general Priority: 3 - Low Status: In Progress Privacy: Public Assigned to: syntron Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: trunk ___ Details: ___ File Attachments: --- Date: Montag 26.07.2010 um 12:45 Name: 20100726-08-trunk-fix-debugging-tool-in-score.c.patch Size: 808B By: syntron http://gna.org/patch/download.php?file_id=9571 ___ Reply to this item at: http://gna.org/patch/?1759 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1760] [players] define MAX_NUM_PLAYER_SLOTS
URL: http://gna.org/patch/?1760 Summary: [players] define MAX_NUM_PLAYER_SLOTS Project: Freeciv Submitted by: syntron Submitted on: Montag 26.07.2010 um 12:46 Category: general Priority: 3 - Low Status: In Progress Privacy: Public Assigned to: syntron Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: trunk ___ Details: ___ File Attachments: --- Date: Montag 26.07.2010 um 12:46 Name: 20100726-09-trunk-define-MAX_NUM_PLAYER_SLOTS.patch Size: 7kB By: syntron http://gna.org/patch/download.php?file_id=9572 ___ Reply to this item at: http://gna.org/patch/?1760 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1761] [players] add team pointer
URL: http://gna.org/patch/?1761 Summary: [players] add team pointer Project: Freeciv Submitted by: syntron Submitted on: Montag 26.07.2010 um 12:47 Category: general Priority: 3 - Low Status: In Progress Privacy: Public Assigned to: syntron Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: trunk ___ Details: * rewrite of ./common/team.(c|h) * create the maximal amount of teams (= MAX_NUM_TEAM_SLOTS = MAX_NUM_PLAYER_SLOTS) * changes to the network protocol ___ File Attachments: --- Date: Montag 26.07.2010 um 12:47 Name: 20100726-12-trunk-add-team-pointer.patch Size: 33kB By: syntron http://gna.org/patch/download.php?file_id=9573 ___ Reply to this item at: http://gna.org/patch/?1761 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1762] [players] dynamically allocate the team names
URL: http://gna.org/patch/?1762 Summary: [players] dynamically allocate the team names Project: Freeciv Submitted by: syntron Submitted on: Montag 26.07.2010 um 12:48 Category: general Priority: 3 - Low Status: In Progress Privacy: Public Assigned to: syntron Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: trunk ___ Details: * new network package ___ File Attachments: --- Date: Montag 26.07.2010 um 12:48 Name: 20100726-13-trunk-dynamically-allocate-the-team-names.patch Size: 15kB By: syntron http://gna.org/patch/download.php?file_id=9574 ___ Reply to this item at: http://gna.org/patch/?1762 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1732] [Metaticket] increase number of players
Update of patch #1732 (project freeciv): Depends on: = patch #1746 ___ Reply to this item at: http://gna.org/patch/?1732 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1763] [players] rename player-ai_common.control to player-ai_controlled
URL: http://gna.org/patch/?1763 Summary: [players] rename player-ai_common.control to player-ai_controlled Project: Freeciv Submitted by: syntron Submitted on: Montag 26.07.2010 um 13:10 Category: general Priority: 3 - Low Status: In Progress Privacy: Public Assigned to: syntron Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.3 ___ Details: * similar to unit-ai_contolled * changes to lua; I think the api is not touched but please check ___ Reply to this item at: http://gna.org/patch/?1763 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1763] [players] rename player-ai_common.control to player-ai_controlled
Update of patch #1763 (project freeciv): Planned Release: 2.3 = 2.3.0 ___ Follow-up Comment #1: add file ... (file #9575) ___ Additional Item Attachment: File name: 20100726-14-trunk-rename-player-ai_common.control-to-player-ai_contr.patch Size:66 KB ___ Reply to this item at: http://gna.org/patch/?1763 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1764] [players] fix unit-server.ai-hunted
URL: http://gna.org/patch/?1764 Summary: [players] fix unit-server.ai-hunted Project: Freeciv Submitted by: syntron Submitted on: Montag 26.07.2010 um 13:11 Category: general Priority: 3 - Low Status: In Progress Privacy: Public Assigned to: syntron Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.3.0 ___ Details: * a bv_player bitvector is needed for 32 players * move the definition into fc_types.h ___ File Attachments: --- Date: Montag 26.07.2010 um 13:11 Name: 20100726-15-trunk-fix-unit-server.ai-hunted.patch Size: 7kB By: syntron http://gna.org/patch/download.php?file_id=9576 ___ Reply to this item at: http://gna.org/patch/?1764 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1765] cleanup bitvectors
URL: http://gna.org/patch/?1765 Summary: cleanup bitvectors Project: Freeciv Submitted by: syntron Submitted on: Montag 26.07.2010 um 13:12 Category: general Priority: 3 - Low Status: Ready For Test Privacy: Public Assigned to: syntron Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.3.0 ___ Details: bv_flags = bv_unit_flags bv_roles = bv_unit_roles (new) bv_impr_flags (new) bv_tech_flags changes to the network protocol ___ File Attachments: --- Date: Montag 26.07.2010 um 13:12 Name: 20100726-16-trunk-cleanup-bitvectors.patch Size: 8kB By: syntron http://gna.org/patch/download.php?file_id=9577 ___ Reply to this item at: http://gna.org/patch/?1765 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1766] remove TEST_BIT from server/score.c
URL: http://gna.org/patch/?1766 Summary: remove TEST_BIT from server/score.c Project: Freeciv Submitted by: syntron Submitted on: Montag 26.07.2010 um 13:12 Category: general Priority: 3 - Low Status: Ready For Test Privacy: Public Assigned to: syntron Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.3.0 ___ Details: ___ File Attachments: --- Date: Montag 26.07.2010 um 13:12 Name: 20100726-17-trunk-remove-TEST_BIT-from-server-score.c.patch Size: 1kB By: syntron http://gna.org/patch/download.php?file_id=9578 ___ Reply to this item at: http://gna.org/patch/?1766 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1767] [players] fix bv_player in sdl client
URL: http://gna.org/patch/?1767 Summary: [players] fix bv_player in sdl client Project: Freeciv Submitted by: syntron Submitted on: Montag 26.07.2010 um 13:13 Category: client-sdl Priority: 3 - Low Status: In Progress Privacy: Public Assigned to: syntron Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.3.0 ___ Details: an int was used for all_players in ./clinet/gui-sdl/gotodlg.c ___ File Attachments: --- Date: Montag 26.07.2010 um 13:13 Name: 20100726-18-trunk-fix-bv_player-in-sdl-client.patch Size: 3kB By: syntron http://gna.org/patch/download.php?file_id=9579 ___ Reply to this item at: http://gna.org/patch/?1767 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16300] doesn't compile with --enable-debug
Follow-up Comment #5, bug #16300 (project freeciv): Thanks, it worked out. Saving/loading games works OK, as far as I have tested. ___ Reply to this item at: http://gna.org/bugs/?16300 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1765] cleanup bitvectors
Follow-up Comment #1, patch #1765 (project freeciv): bv_flags = bv_unit_flags This is unit type specific flags that unit has, right? When you are changing it, you should also make it clear that unit class specific flags are not here. ___ Reply to this item at: http://gna.org/patch/?1765 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1765] cleanup bitvectors
Follow-up Comment #3, patch #1765 (project freeciv): it should be: bv_flags = bv_unit_type_flags bv_roles = bv_unit_type_roles ___ Reply to this item at: http://gna.org/patch/?1765 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16305] Incorrect sabotage handling for diplomats
URL: http://gna.org/bugs/?16305 Summary: Incorrect sabotage handling for diplomats Project: Freeciv Submitted by: None Submitted on: Monday 07/26/2010 at 19:31 CEST Category: None Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: 2.2.1 Discussion Lock: Any Operating System: None Planned Release: ___ Details: The base sabotage chance for a diplomat is half that of the spy, yet could be the same by changing the client. This is either a bug (when the base sabotage chance should be the same for both) or a security flaw (when it should not be possible to upgrade the sabotage chance on the client). Since I don't know the intended behavior, I cannot asses this. In server/diplomats.c:835, function diplomat_sabotage(), the base success probability is chosen depending on whether a specific target is chosen, or random: int success_prob = (improvement = B_LAST ? game.info.diplchance : game.info.diplchance / 2); A few lines further down (line 848) the improvement is set to B_LAST if the unit is not a spy: if (!unit_has_type_flag(pdiplomat, F_SPY)) improvement = B_LAST; So on line 835, the 'improvement' comes straight from the client unmodified, and based on that, the base success chance is chosen. This value is set in the gui, for example in client/gui-gtk-2.0/diplomat_dialog.c:120, function diplomat_sabotage_callback() request_diplomat_action(DIPLOMAT_SABOTAGE, diplomat_id, diplomat_target_id, -1); The last parameter (-1) is the improvement which will be the parameter 'improvement' in diplomat_sabotage() in server/diplomats.c:835. Since -1 B_LAST, this means that a diplomat will sabotage with half the base success chance. This can be changed on the client by simply sending B_LAST as the last parameter on request_diplomat_action() ___ Reply to this item at: http://gna.org/bugs/?16305 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16305] Incorrect sabotage handling for diplomats
Follow-up Comment #1, bug #16305 (project freeciv): Since I see nowhere in the rules/help that diplomats have half the success chance of spies, I figure this is a bug. Then again, it's kind of an obvious bug when you notice that sabotaging by diplomats fail very often, so maybe it's the security flaw after all. If it's a bug, then either the gui's must be fixed to send B_LAST as the last parameter, or better: put line 848 in server/diplomats.c before line 835. If it's a security flaw, then I would still suggest putting line 848 first, and adding an extra check, halving the chance for diplomats. E.g.: int success_prob = (improvement = B_LAST unit_has_type_flag(pdiplomat, F_SPY) ? game.info.diplchance : game.info.diplchance / 2); ___ Reply to this item at: http://gna.org/bugs/?16305 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1773] [dbv] remove tile:tile_seen
URL: http://gna.org/patch/?1773 Summary: [dbv] remove tile:tile_seen Project: Freeciv Submitted by: syntron Submitted on: Montag 26.07.2010 um 22:24 Category: general Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: syntron Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.3.0 ___ Details: server: use player:private_map:seen_count client: use dynamic bitvector ___ File Attachments: --- Date: Montag 26.07.2010 um 22:24 Name: 0007-remove-tile-tile_seen.patch Size: 18kB By: syntron http://gna.org/patch/download.php?file_id=9587 ___ Reply to this item at: http://gna.org/patch/?1773 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1774] [dbv] remove tile:tile_known
URL: http://gna.org/patch/?1774 Summary: [dbv] remove tile:tile_known Project: Freeciv Submitted by: syntron Submitted on: Montag 26.07.2010 um 22:24 Category: general Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: syntron Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.3.0 ___ Details: replace it by an dynamic bitvector ___ File Attachments: --- Date: Montag 26.07.2010 um 22:24 Name: 0008-remove-tile-tile_known.patch Size: 10kB By: syntron http://gna.org/patch/download.php?file_id=9588 ___ Reply to this item at: http://gna.org/patch/?1774 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1775] [Metaticket] dynamic bitvector
URL: http://gna.org/patch/?1775 Summary: [Metaticket] dynamic bitvector Project: Freeciv Submitted by: syntron Submitted on: Montag 26.07.2010 um 22:27 Category: general Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: syntron Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.3.0 ___ Details: with the increased number of players and the increased (possible) map size some memory is unused in the bv_player bitvectors defined for each tile. In this patch series they are replaced by bitvectors in the player struct. Its length is given by the number of tiles. Furthermore, tile:tile_seen and tile:seen_count are merged. ___ Reply to this item at: http://gna.org/patch/?1775 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1775] [Metaticket] dynamic bitvector
Update of patch #1775 (project freeciv): Depends on: = patch #1768 ___ Reply to this item at: http://gna.org/patch/?1775 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1775] [Metaticket] dynamic bitvector
Update of patch #1775 (project freeciv): Depends on: = patch #1732 ___ Reply to this item at: http://gna.org/patch/?1775 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1732] [Metaticket] increase number of players
Follow-up Comment #3, patch #1732 (project freeciv): additional data for the dynamic bitvector patch (it's for mapsize 30): 1 player 30 player 126 player S2_2 34864K 77008K - svn17555 37336K 78640K - svn17568 41644K 83424K221056K (pointers)38180K 79788K222036K (dbv) 36488K 78676K221784K For one player (dbv) uses less memory that trunk before the increase of the player and map number. ___ Reply to this item at: http://gna.org/patch/?1732 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16300] doesn't compile with --enable-debug
Follow-up Comment #6, bug #16300 (project freeciv): This seems to be a FAQ on comp.lang.c... the consensus there seems to be that casting to (unsigned long), as file #9564 does, is OK for C90 implementations, since size_t is guaranteed to fit in that. That's not true for C99, but there you can use the %zu format specifier (which is specifically for size_t). However, relying on %zu puts us at the mercy of the system's printf. Looking at this instance I don't think the risk of a cast to unsigned long losing information is worth worrying about (it's just an unlikely diagnostic message), so the cast seems like the best (most portable) solution. ___ Reply to this item at: http://gna.org/bugs/?16300 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16305] Incorrect sabotage handling for diplomats
Follow-up Comment #2, bug #16305 (project freeciv): Well spotted. I suspect the difference in success probability between Diplomats and Spies is unintentional. I think it's been there at least since this area was last substantially modified in r9000, RT#11058 http://bugs.freeciv.org/Ticket/Display.html?id=11058, in 2004. There's no indication in that ticket that it was an intentional change. Also, the help for the server option diplchance says Base chance for diplomats and spies to succeed. And all the other actions using diplchance don't (obviously) favour the Spy. On the other hand, the current help for the Spy does say She can perform all the functions of the Diplomat, but with a higher rate of success. This text came in in r13997, RT#39541 http://bugs.freeciv.org/Ticket/Display.html?id=39541. No indication in RT of where that notion came from. (Daniel, if you're listening, do you happen to remember?) If this is fixed, I don't think the statement in the help will really be true any more -- the only way spies have a higher rate of success is that they're relatively stronger when in contention with other diplomatic units, I think. Fixing this will make diplomats more effective at sabotaging improvements, which could affect the balance of the early game. However, we don't seem to have shrunk from rectifying similar unintentional but long-standing gameplay issues in the past -- see for instance bug #14181 and bug #16080. So, on balance, I think we should restore equality for diplomats and spies. I don't think we should fix S2_2 clients to send B_LAST, as that'll give new clients on old servers an unfair advantage. We could do so on trunk (but in general sending foo_LAST over the network is a bit unpleasant -- see for example bug #15743). ___ Reply to this item at: http://gna.org/bugs/?16305 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1732] [Metaticket] increase number of players
Follow-up Comment #4, patch #1732 (project freeciv): Nice work, Matthias. The dynamic bitvector patch has pretty impressive memory usage now. ___ Reply to this item at: http://gna.org/patch/?1732 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16305] Incorrect sabotage handling for diplomats
Follow-up Comment #3, bug #16305 (project freeciv): I cannot remember a specific decision regarding diplomat vs spy success rates. Tried to look around a bit but couldn't find any reference. It is a tricky business though, balancing diplomats/spies. There was a time a few years ago when they were so powerful that they essentially replaced military units as the main tool for warfare. Let's come up for a few testcase scenarios to make sure the proposed changes are somewhat balanced. :) ___ Reply to this item at: http://gna.org/bugs/?16305 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16308] Great Wall protects wrong units
URL:
http://gna.org/bugs/?16308
Summary: Great Wall protects wrong units
Project: Freeciv
Submitted by: kernigh
Submitted on: Tuesday 07/27/2010 at 01:10
Category: rulesets
Severity: 3 - Normal
Priority: 5 - Normal
Status: None
Assigned to: None
Originator Email:
Open/Closed: Open
Release: 2.2.1+ r17591
Discussion Lock: Any
Operating System: *BSD
Planned Release:
___
Details:
Let player C have the Great Wall. Help text says, Works as a City Wall in
all your cities. I would expect the Great Wall to protect all units in
cities, where the _cities_ belong to player C. The bug is that the Great Wall
protects all units in cities, where the _units_ belong to player C. (I have
r17591 of S2_2, which has the fix from bug #16080 that actually requires
units to be in cities.)
If player C has alliance with player K, then Great Wall protects whom? Units
of K in cities of C, or units of C in cities of K? I attach
x-great-wall-test.sav.bz2 which shows exactly this problem. (I made this game
with the editing-mode.)
Load x-great-wall-test.sav.bz2 and take player S (Scottish), who is attacking
player C (Chinese) and player K (Korean). Cities marked [C] have three Chinese
defenders; cities marked [K] have three Korean defenders. All units are green
Archers.
* Guangzhou [C] and Shanghai [K] are Chinese cities.
* Wanggomsong [C] and Jolbon [K] are Korean cities with no walls.
* Ungjin [C] and Wandu [K] are Korean cities with City Walls.
Kill all defenders, but never conquer cities. (They might be homecities of
other defenders.) Shanghai [K] and Jolbon[K] are easy to kill; the four other
cities are difficult to kill.
* Guangzhou [C] is a Chinese city with Chinese defenders. Difficult to kill.
Chinese Great Wall protects defenders. No bug.
* Shanghai [K] is a Chinese city with Korean defenders. Easy to kill! Chinese
Great Wall fails to protect Korean defenders in a Chinese city! This is bug.
* Wanggomsong [C] is a Korean city with Chinese defenders. Difficult to kill!
Chinese Great Wall protects Chinese units in a Korean city! This is bug.
* Jolbon [K] is a Korean city with Korean defenders. Easy to kill. No bug.
* Ungjin [C] and Wandu [K] have City Walls. Difficult to kill. No bug.
Chinese Great Wall prevents loss of population in Shanghai [K], but not in
Wanggomsong [C]. This is correct.
I thought that Chinese Great Wall and Korean City Walls might combine to add
protection to Ungjin [C], but this seems not to happen.
These are the current rules in effects.c:
[effect_great_wall]
name= Defend_Bonus
value = 200
reqs=
{ type, name, range
Building, Great Wall, Player
UnitClass, Land, Local
CityTile, Center, Local
}
[effect_great_wall_0]
name= Defend_Bonus
value = 200
reqs=
{ type, name, range
Building, Great Wall, Player
UnitClass, Helicopter, Local
CityTile, Center, Local
}
This says to protect all Chinese units in any city (if the attacker is land
or helicopter unit). I would change this to say to protect any unit in all
Chinese cities, if I knew a way.
___
File Attachments:
---
Date: Tuesday 07/27/2010 at 01:10 Name: x-great-wall-test.sav.bz2 Size:
10kB By: kernigh
play as Scottish; attack Chinese and Korean cities
http://gna.org/bugs/download.php?file_id=9590
___
Reply to this item at:
http://gna.org/bugs/?16308
___
Message sent via/by Gna!
http://gna.org/
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
