[Freeciv-Dev] [patch #1907] Vermont nation
Follow-up Comment #1, patch #1907 (project freeciv): Do you intend to use the modern-day US state flag, the 'Green Mountain Boys' flag, or one of the historical US state flag variants? ___ Reply to this item at: http://gna.org/patch/?1907 ___ 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 #1907] Vermont nation
Follow-up Comment #2, patch #1907 (project freeciv): The Grean Mountains Boys flag; that seems to be the one that was used by the Vermont Republic. ___ Reply to this item at: http://gna.org/patch/?1907 ___ 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 #1925] Numunu nation
Follow-up Comment #4, patch #1925 (project freeciv): Since Freeciv's source language is English, I suggest calling these nations whatever is the generally accepted term in English. That'll make it easier for translators, too. ___ Reply to this item at: http://gna.org/patch/?1925 ___ 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 #16642] Saving can be very long
URL: http://gna.org/bugs/?16642 Summary: Saving can be very long Project: Freeciv Submitted by: pepeto Submitted on: lundi 06.09.2010 à 07:01 Category: general Severity: 3 - Normal Priority: 5 - Normal Status: Ready For Test Assigned to: pepeto Originator Email: Open/Closed: Open Release: trunk Discussion Lock: Any Operating System: None Planned Release: 2.3.0 ___ Details: On games using lot of units or cities (like file #10091 for bug #16592), it takes many minutes to save the game because it checks for every new entry if there is no duplicate. Improvement attached. ___ File Attachments: --- Date: lundi 06.09.2010 à 07:01 Name: trunk_save_speed_up.diff Size: 577 o By: pepeto http://gna.org/bugs/download.php?file_id=10198 ___ Reply to this item at: http://gna.org/bugs/?16642 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16643] AI trireme stop moving?
URL: http://gna.org/bugs/?16643 Summary: AI trireme stop moving? Project: Freeciv Submitted by: pepeto Submitted on: lundi 06.09.2010 à 07:05 Category: ai Severity: 2 - Minor Priority: 3 - Low Status: None Assigned to: None Originator Email: Open/Closed: Open Release: trunk, S2_2 Discussion Lock: Any Operating System: None Planned Release: ___ Details: Loading file #7060 posted for bug #14275, it appears that the trireme ID 299 stops moving forever since turn 124. ___ Reply to this item at: http://gna.org/bugs/?16643 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16644] 1: Saved game contains incomplete map data
Update of bug #16644 (project freeciv): Priority: 1 - Later = 5 - Normal ___ Reply to this item at: http://gna.org/bugs/?16644 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16644] 1: Saved game contains incomplete map data
Follow-up Comment #1, bug #16644 (project freeciv): Bug added at revision 16822 (bug #14944). It removes the test _is not from a unit only fog of war save file_. Another thing looks strange, the test assuring game.fogofwar really exists has disappear... ___ Reply to this item at: http://gna.org/bugs/?16644 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16644] 1: Saved game contains incomplete map data
Update of bug #16644 (project freeciv): Status:None = Ready For Test ___ Follow-up Comment #2: Fix attached that reestablish the old behaviour and allow to load the file correctly. However, I never found a way to reproduce bug #14944. Could someone ensure it doesn't revert the fix for it? (file #10199) ___ Additional Item Attachment: File name: trunk_load_private_map.diffSize:1 KB ___ Reply to this item at: http://gna.org/bugs/?16644 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16644] 1: Saved game contains incomplete map data
Follow-up Comment #3, bug #16644 (project freeciv): Real patch, not including the patch for bug #16642 attached. (file #10200) ___ Additional Item Attachment: File name: trunk_load_private_map2.diff Size:1 KB ___ Reply to this item at: http://gna.org/bugs/?16644 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16613] Vision layer bug with editor
Follow-up Comment #6, bug #16613 (project freeciv): New fixes attached that fix a bug in map_claim_ownership_full(), and one in loading cities from savegames. Test status: * bug #16613: S2_2(OK), trunk(OK) * bug #16592: S2_2(OK), trunk (OK with bug #16642) * bug #14993: S2_2(cannot load), trunk(OK) * bug #14836: S2_2(OK), trunk(OK) * bug #14275: S2_2(OK with bug #16643), trunk(OK with bug #16643) * bug #14489: S2_2(OK), trunk(OK with bug #16644) (file #10202, file #10203) ___ Additional Item Attachment: File name: trunk_vision_cleanup3.diff Size:46 KB File name: S2_2_vision_cleanup2.diff Size:44 KB ___ Reply to this item at: http://gna.org/bugs/?16613 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1902] Apache nation
Additional Item Attachment, patch #1902 (project freeciv): File name: apache.ruleset Size:1 KB ___ Reply to this item at: http://gna.org/patch/?1902 ___ 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 #16648] Memory leak with ai_data_phase_init()/ai_data_phase_done()
URL: http://gna.org/bugs/?16648 Summary: Memory leak with ai_data_phase_init()/ai_data_phase_done() Project: Freeciv Submitted by: pepeto Submitted on: lundi 06.09.2010 à 15:58 Category: general Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: trunk Discussion Lock: Any Operating System: None Planned Release: 2.3.0 ___ Details: ai_data_phase_init() is sometimes used when ai_data_phase_done() has been called yet. It appears the problem occurs when living the server and when starting a savegame. ==5389== 384 bytes in 16 blocks are definitely lost in loss record 980 of 1,068 ==5389==at 0x4C284A8: malloc (vg_replace_malloc.c:236) ==5389==by 0x57C341: fc_real_malloc (mem.c:83) ==5389==by 0x57C434: fc_real_calloc (mem.c:128) ==5389==by 0x448E7A: ai_data_phase_init (advdata.c:345) ==5389==by 0x44A5DC: ai_data_get (advdata.c:725) ==5389==by 0x4A34E2: sg_load_players (savegame2.c:3124) ==5389==by 0x4A535F: savegame2_load (savegame2.c:607) ==5389==by 0x412519: load_command (stdinhand.c:3612) ==5389==by 0x40B1CD: srv_prepare (srv_main.c:2171) ==5389==by 0x40B293: srv_main (srv_main.c:2451) ==5389==by 0x4039AE: main (civserver.c:376) ==5389== ==5389== 384 bytes in 16 blocks are definitely lost in loss record 981 of 1,068 ==5389==at 0x4C284A8: malloc (vg_replace_malloc.c:236) ==5389==by 0x57C341: fc_real_malloc (mem.c:83) ==5389==by 0x57C434: fc_real_calloc (mem.c:128) ==5389==by 0x448FD6: ai_data_phase_init (advdata.c:478) ==5389==by 0x44A5DC: ai_data_get (advdata.c:725) ==5389==by 0x4A34E2: sg_load_players (savegame2.c:3124) ==5389==by 0x4A535F: savegame2_load (savegame2.c:607) ==5389==by 0x412519: load_command (stdinhand.c:3612) ==5389==by 0x40B1CD: srv_prepare (srv_main.c:2171) ==5389==by 0x40B293: srv_main (srv_main.c:2451) ==5389==by 0x4039AE: main (civserver.c:376) ==5389== ==5389== 384 bytes in 16 blocks are definitely lost in loss record 982 of 1,068 ==5389==at 0x4C284A8: malloc (vg_replace_malloc.c:236) ==5389==by 0x57C341: fc_real_malloc (mem.c:83) ==5389==by 0x57C434: fc_real_calloc (mem.c:128) ==5389==by 0x448E7A: ai_data_phase_init (advdata.c:345) ==5389==by 0x40B617: srv_main (srv_main.c:786) ==5389==by 0x4039AE: main (civserver.c:376) ==5389== ==5389== 384 bytes in 16 blocks are definitely lost in loss record 983 of 1,068 ==5389==at 0x4C284A8: malloc (vg_replace_malloc.c:236) ==5389==by 0x57C341: fc_real_malloc (mem.c:83) ==5389==by 0x57C434: fc_real_calloc (mem.c:128) ==5389==by 0x448FD6: ai_data_phase_init (advdata.c:478) ==5389==by 0x40B617: srv_main (srv_main.c:786) ==5389==by 0x4039AE: main (civserver.c:376) ==5389== ==5389== 816 bytes in 16 blocks are definitely lost in loss record 1,024 of 1,068 ==5389==at 0x4C284A8: malloc (vg_replace_malloc.c:236) ==5389==by 0x57C341: fc_real_malloc (mem.c:83) ==5389==by 0x57C434: fc_real_calloc (mem.c:128) ==5389==by 0x448E3C: ai_data_phase_init (advdata.c:342) ==5389==by 0x44A5DC: ai_data_get (advdata.c:725) ==5389==by 0x4A34E2: sg_load_players (savegame2.c:3124) ==5389==by 0x4A535F: savegame2_load (savegame2.c:607) ==5389==by 0x412519: load_command (stdinhand.c:3612) ==5389==by 0x40B1CD: srv_prepare (srv_main.c:2171) ==5389==by 0x40B293: srv_main (srv_main.c:2451) ==5389==by 0x4039AE: main (civserver.c:376) ==5389== ==5389== 816 bytes in 16 blocks are definitely lost in loss record 1,025 of 1,068 ==5389==at 0x4C284A8: malloc (vg_replace_malloc.c:236) ==5389==by 0x57C341: fc_real_malloc (mem.c:83) ==5389==by 0x57C434: fc_real_calloc (mem.c:128) ==5389==by 0x448FA9: ai_data_phase_init (advdata.c:477) ==5389==by 0x44A5DC: ai_data_get (advdata.c:725) ==5389==by 0x4A34E2: sg_load_players (savegame2.c:3124) ==5389==by 0x4A535F: savegame2_load (savegame2.c:607) ==5389==by 0x412519: load_command (stdinhand.c:3612) ==5389==by 0x40B1CD: srv_prepare (srv_main.c:2171) ==5389==by 0x40B293: srv_main (srv_main.c:2451) ==5389==by 0x4039AE: main (civserver.c:376) ==5389== ==5389== 816 bytes in 16 blocks are definitely lost in loss record 1,026 of 1,068 ==5389==at 0x4C284A8: malloc (vg_replace_malloc.c:236) ==5389==by 0x57C341: fc_real_malloc (mem.c:83) ==5389==by 0x57C434: fc_real_calloc (mem.c:128) ==5389==by 0x448E3C: ai_data_phase_init (advdata.c:342) ==5389==by 0x40B617: srv_main (srv_main.c:786) ==5389==by 0x4039AE: main (civserver.c:376) ==5389== ==5389== 816 bytes in 16 blocks are definitely lost in loss record 1,027 of 1,068 ==5389==at 0x4C284A8: malloc (vg_replace_malloc.c:236)
[Freeciv-Dev] [bug #16645] Server record many entries named savefile.options
Update of bug #16645 (project freeciv): Status:None = Ready For Test Assigned to:None = pepeto ___ Additional Item Attachment: File name: trunk_overwrite_savefile_options.diff Size:1 KB ___ Reply to this item at: http://gna.org/bugs/?16645 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16648] Memory leak with ai_data_phase_init()/ai_data_phase_done()
Update of bug #16648 (project freeciv): Release: trunk = trunk, S2_2 Planned Release: 2.3.0 = 2.3.0, 2.2.4 ___ Reply to this item at: http://gna.org/bugs/?16648 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16648] Memory leak with ai_data_phase_init()/ai_data_phase_done()
Update of bug #16648 (project freeciv): Planned Release: 2.3.0 = 2.3.0, 2.2.4 ___ Reply to this item at: http://gna.org/bugs/?16648 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16650] Fix S2_2 server memory issues reported valgrind
URL: http://gna.org/bugs/?16650 Summary: Fix S2_2 server memory issues reported valgrind Project: Freeciv Submitted by: pepeto Submitted on: lundi 06.09.2010 à 16:34 Category: general Severity: 3 - Normal Priority: 5 - Normal Status: Ready For Test Assigned to: pepeto Originator Email: Open/Closed: Open Release: S2_2 Discussion Lock: Any Operating System: None Planned Release: 2.2.4 ___ Details: ___ File Attachments: --- Date: lundi 06.09.2010 à 16:34 Name: S2_2_server_valgrind.diff Size: 2 ko By: pepeto http://gna.org/bugs/download.php?file_id=10208 ___ Reply to this item at: http://gna.org/bugs/?16650 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16625] save chat message for the sender
Follow-up Comment #10, bug #16625 (project freeciv):
There were still some oddities like if a player observer was sending a
message to a player, it was sending strange messages.
Changed the behaviour like:
* -{dest} message is sent to the sender connection.
* {sender} message is sent to the destination *connection*.
* {sender - dest} is sent to all observers of the sender (if a player) and
the destination. It is a big improvement since observers don't receive
ambiguous messages like if they were playing themselves.
* {sender - dest} is saved in the event cache. Unfortunately, there is no
way to determine if the connection is playing or observing when receiving the
cached event, so I avoided the usage of -{dest} message and {sender}
message here.
(file #10209)
___
Additional Item Attachment:
File name: trunk_chat_msg_to_player.diff Size:2 KB
___
Reply to this item at:
http://gna.org/bugs/?16625
___
Message posté via/par Gna!
http://gna.org/
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16410] Default ruleset loaded in server start even if user is going to switch to another ruleset
Update of bug #16410 (project freeciv): Status: Fixed = Wont Fix ___ Follow-up Comment #10: It's impossible for the moment to implement this. The default ruleset must be loaded at server start in any case. ___ Reply to this item at: http://gna.org/bugs/?16410 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16629] Autogame recipe in doc/HACKING doesn't work
Update of bug #16629 (project freeciv): Status: In Progress = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?16629 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16413] Gold upkeep and Military unhappiness
Follow-up Comment #7, bug #16413 (project freeciv): If you look into the directory where the patch was rejected, i'll find the file with the correct modifications and a .rejected and .orig files. The .orig is the original file before the patch process took over it, and the .rejected containts the parts of the patch that didn't got applied. In that file i'll find information of the code to apply and what did find the patch process. Thank you jnf. I have finally been able to apply and compile the patch over trunk revision 17877 (the day Matthias uploaded the patch). I'm still testing it, but I'm afraid it does not seem to work as expected. Units are killed even when the treasure is not under zero, and it happens even with gold upkeep style 1 that are supposedly unchanged... if I understood. I'll keep testing until I understand how exactly worked the old gold upkeep styles and how are currently working the new ones. ___ Reply to this item at: http://gna.org/bugs/?16413 ___ 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 #16385] Consider changing how base ownership works to avoid problems with buoys
Follow-up Comment #1, bug #16385 (project freeciv): I follow you in your brilliant analysis. However, I am not sure of what do you propose as rules changes. ___ Reply to this item at: http://gna.org/bugs/?16385 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16385] Consider changing how base ownership works to avoid problems with buoys
Follow-up Comment #2, bug #16385 (project freeciv): Related question: An empty bases (not protected by units) could be captured by enemy units? ___ Reply to this item at: http://gna.org/bugs/?16385 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1929] Gothic nation
Follow-up Comment #3, patch #1929 (project freeciv): Add Tervingian (or Visigothic) nationset. (file #10211) ___ Additional Item Attachment: File name: tervingian.ruleset Size:1 KB ___ Reply to this item at: http://gna.org/patch/?1929 ___ 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 #1929] Gothic nation
Additional Item Attachment, patch #1929 (project freeciv): File name: tervingian.ruleset Size:1 KB ___ Reply to this item at: http://gna.org/patch/?1929 ___ 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 #16385] Consider changing how base ownership works to avoid problems with buoys
Follow-up Comment #3, bug #16385 (project freeciv): another related question: should bases claim ownership of neighbouring tiles without a unit present? (see bug #14236) ___ Reply to this item at: http://gna.org/bugs/?16385 ___ 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 #16413] Gold upkeep and Military unhappiness
Follow-up Comment #8, bug #16413 (project freeciv): I'm still testing it, but I'm afraid it does not seem to work as expected. Thanks for testing; I can check it again at the end of this month ... Current Trunk revision 17939 gives me this error message when I start new game: Please report this message at https://gna.org/projects/freeciv/ in can_player_build_unit_direct() [unittype.c::631]: assertion '((void *)0) != punittype' failed. Does this happen with the included rulesets or only with your own ruleset? If it is your own ruleset, can you pin it down to one change (in units.ruleset?) ___ Reply to this item at: http://gna.org/bugs/?16413 ___ 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 #1936] limit the number of units a city can support
URL: http://gna.org/patch/?1936 Summary: limit the number of units a city can support Project: Freeciv Submitted by: syntron Submitted on: Montag 06.09.2010 um 23:08 Category: rulesets Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: see bug #16413 point 1): limit the number of units a city can support To balance gold upkeep David Fernandez proposed to limit the number of units a city can support to the size of the city. This could include a new ruleset option 'free_units_per_city'. If it set to -1 there is no limit at all. Else it gives the number of 'free' units. Example: free_units_per_city = 5 city size = 2 = 5 unit possible city size = 5 = 5 unit possible city size = 6 = 6 unit possible city size = 9 = 9 unit possible Some questions: Should this be limited to military units? What should happen if the city size is reduced? Kill random units till the maximum supported number is reached? ___ Reply to this item at: http://gna.org/patch/?1936 ___ 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 #16413] Gold upkeep and Military unhappiness
Follow-up Comment #9, bug #16413 (project freeciv): for point 1) see patch #1936 ___ Reply to this item at: http://gna.org/bugs/?16413 ___ 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 #1936] limit the number of units a city can support
Update of patch #1936 (project freeciv): Priority: 5 - Normal = 1 - Later ___ Reply to this item at: http://gna.org/patch/?1936 ___ 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 #1936] limit the number of units a city can support
Follow-up Comment #1, patch #1936 (project freeciv): Unit gold upkeep is already possible in the ruleset. I guess that some government effect already can give a certain number of free units? Am I wrong? ___ Reply to this item at: http://gna.org/patch/?1936 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16385] Consider changing how base ownership works to avoid problems with buoys
Follow-up Comment #4, bug #16385 (project freeciv): Here's where I've got to: First, after some work, I've more or less changed my mind about having a single owner field + borders flag in the tile; see below for reasoning. I'm now thinking about separate per-tile tile owner and base owner fields (both pointing to players). Add new base flags ownable and capturable. Make the existing border_sq, vision_main_sq, and vision_invis_sq properties require ownable to be set. An ownable base is one that (usually) has an owner. * The initial owner is that of the unit who created it. * Once created, by default, an ownable base doesn't change owner. (Such a base can end up un-owned if a player is killed/removed, but this is rare. It could also happen with scenario/editor.) * An ownable base doesn't necessarily act as a border source (only if border_sq is set). A capturable base is an ownable base that changes hands when occupied by a unit at war with the current owner. * Can't have a mixture of capturable and ownable-but-not-capturable bases on the same tile, so that's an automatic conflicts when loading rulesets. [Edited: I hadn't seen bug #14236. While we're in there, it probably wouldn't be hard to add another option that controls whether a base remains owned when it contains no units. Would need to think a bit about details e.g. allied stacks.] A fortress would thus be ownable, capturable, and have border_sq set -- this should result in no change from current behaviour. A buoy would be ownable but not capturable, and have the vision fields set, by default. Consequences: * It doesn't claim any borders (not even the tile it's on). This fixes most of the problems originally raised. * It can't be captured. The only way to stop the owner seeing with it is to pillage it (which is cheap and easy, if the owner isn't defending it). * In particular, my buoy can be inside someone else's borders and still provide vision to me. The last point is more or less why I changed my mind about having a single owner; when documenting ownable it seemed unnecessarily dirty to say this can't change owners (unless you build a city nearby). I don't think having two owners changes the design much, in fact. (Obviously border claiming bases must have the two owner fields the same...) It also makes the necessary changes to the editor much cleaner, I think. Something I've had in the back of my mind while designing this is a sort of capture-the-flag scenario -- this would use ownable capturable flag bases which have no particular effect (no border source, etc). One thing I haven't quite worked out is whether capture-by-unit and capture-by-borders should both be controlled by the capturable flag, or whether they need separate options. (I'm assuming the former, for now.) As far as client UI is concerned, I was thinking of an ownable base displaying a flag like a city does (when citybar is disabled), but having this be overridden by shields if there's a unit on the tile. This has the advantage of not requiring new graphics :) I've got a mess of code changes but nothing that compiles yet, and I've been getting a bit bogged down in the border code. I'll probably wait for bug #16613 and patch #1864 to land before taking this up again. Assuming everyone's happy, I'd like to get it in 2.3.0, which is why I'm working on it now (since it changes packet formats etc), but it probably shouldn't be a blocker. ___ Reply to this item at: http://gna.org/bugs/?16385 ___ 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 #16385] Consider changing how base ownership works to avoid problems with buoys
Follow-up Comment #5, bug #16385 (project freeciv): That's sound very great to me. For bug #16613, I will make new tests using autogames on custom rulesets (because I didn't have test bases enough), but it should be ready in about 1 week. For patch #1864, it's not ready, there are probably big problems because of the borders removals when creating and removing a base. I can wait you do your change, it would help for that. Also you could handle it if you wish. By the way, about the code, an important function for removing a base properly is missing in my opinion. ___ Reply to this item at: http://gna.org/bugs/?16385 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16385] Consider changing how base ownership works to avoid problems with buoys
Follow-up Comment #6, bug #16385 (project freeciv): By the way, about the code, an important function for removing a base properly is missing in my opinion. I already have a separate patch 95% complete for factoring that out. I should finish it. ___ Reply to this item at: http://gna.org/bugs/?16385 ___ 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 #16651] pseudo-fractal map generator can't be used with different startpos options (other than default=0)
URL: http://gna.org/bugs/?16651 Summary: pseudo-fractal map generator can't be used with different startpos options (other than default=0) Project: Freeciv Submitted by: tirolalira Submitted on: lunes 06/09/10 at 22:29 Category: None Severity: 2 - Minor Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: 2.2.2 Discussion Lock: Any Operating System: None Planned Release: ___ Details: Tested with v2.2.2 over windows and v2.2.99 over ubuntu. If you start a new game choosing the pseudo-fractal map generator (generator=2) and starting positions depending on continent size (startpos=4), then the game starts but the map is generated using the fully-random height (usually a lot of little islands) instead of the selected pseudo-fractal (usually big continents). I guess it must be a bug, because I can generate the map with generator=2 and startpos=0, then to save it, to convert it into a scenario removing the starting positions, and then to start a new game with generator=0 and startpos=4. This way it works, but you miss the fun of unknown terrain... ___ Reply to this item at: http://gna.org/bugs/?16651 ___ 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 #1936] limit the number of units a city can support
Follow-up Comment #2, patch #1936 (project freeciv): Your suggested free_units_per_city sounds perfect. I agree it should affect only to military units, and I agree units that can't be supported should be disbanded. If the option slowly kill unhomecitied units is enabled, units could be made unhomed instead of disbanded, but I guess it could enable some exploit depending on rate of recovering hp... I suppose it is not worth to complicate it, when it'd need a combo of optional rules. My doubt is how AI would handle such population limit. In my tests with gold upkeep, AI do not use to build more units than his total population, but they do build in some cities more units than the city size, while they do not build units in other cities. (I know it depends on many variables, but AI recruitment uses to behave similar with several different ruleset options I tested). I guess the rule would help the AI to spread the home of units, to take better advantage of free upkeep per city, to build more improvements (instead of units) in the cities with good production, and to avoid the chances of AI bankrupt due to huge armies that I see often with gold upkeep. Though it is hard to know until we can test it. In the other hand, human players use to handle pop growth much better than AI, and humans use to need less units to attack properly. Unit gold upkeep is already possible in the ruleset. I guess that some government effect already can give a certain number of free units? Am I wrong? True, but gold upkeep seems to need some additional rule to limit the number of units per city, else some aspects of game would not be balanced, mainly military unhappiness. ___ Reply to this item at: http://gna.org/patch/?1936 ___ 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 #16413] Gold upkeep and Military unhappiness
Follow-up Comment #10, bug #16413 (project freeciv): You are right about error message, I forgot I had a modded default ruleset in my /home/.freeciv folder... I did not planned to report a bug unless tested with default rulesets. I'm afraid my previous results about your patch are not valid for same reason, I was changing the gold_upkeep_style in a file that was not used. Sorry me, I'm novice here, I'll be more careful with future tests, and I'll try to limit the amount of my posts :) I have tested a bit more your patch with trunk revision 17877, I'm almost sure I tested it properly this time, I attach the savegames with the error: 1) I have played a game with unmodded experimental ruleset and gold_upkeep_style = 1, played until Corporation is researched, and it seems to work same than always. If, in the middle of that game, I switching to gold_upkeep_style = 2, when I press end turn the game stops with the error: Lost connection to server!. If I switch to gold_upkeep_style = 0 the game continues normally. - in /data/experimental/game.ruleset, change gold_upkeep_style to 2, then load savegame1 and press end turn. 2) I have started another game with experimental ruleset and gold_upkeep_style = 2. As soon as my treasure falls under zero when I press end turn, the server crashes. Even when there is no gold upkeep (The corporation still not researched). - load savegame2 and press end turn. Final comment: if the purpose of the change is to reduce army size when you can not support it, I suggest gold_upkeep_style = 2 to sell alternatively one unit and one building, as you did, but starting by units. Else, the money from the building will surely be enough to support the extra units this turn, and next time you run out of money, another building will be sold. If I'm right. (file #10213, file #10214) ___ Additional Item Attachment: File name: goldupkeep1.sav.gz Size:103 KB File name: goldupkeep2.sav.gz Size:34 KB ___ Reply to this item at: http://gna.org/bugs/?16413 ___ 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 #1898] Tanzanian nation
Update of patch #1898 (project freeciv): Status: In Progress = Ready For Test ___ Reply to this item at: http://gna.org/patch/?1898 ___ 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 #1899] Sicilian nation
Update of patch #1899 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?1899 ___ 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 #1900] Yucatecan nation
Update of patch #1900 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?1900 ___ 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 #15628] server crashed.
Follow-up Comment #2, bug #15628 (project freeciv): I'm browsing through the bugs while I wait for my git clone of the svn repository to finish up (I'm up to r17852). This bug should probably be closed. It has been over 5 months since the request for more information. I doubt any is forthcoming. ___ Reply to this item at: http://gna.org/bugs/?15628 ___ 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 #1936] limit the number of units a city can support
Follow-up Comment #3, patch #1936 (project freeciv): I don't know if this has been proposed or is currently done as I'm still new to both the game and the code. Instead of limiting the number of units a city can support under gold upkeep rules, perhaps limit what gold can be used for the unit upkeep. Units under shield upkeep are limited by the number of shields a city produces. The equivalent for gold upkeep could be the amount of trade a city has. ___ Reply to this item at: http://gna.org/patch/?1936 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
