[Freeciv-Dev] [bug #14035] pf_fuel_map finishes on infinite loop
URL: http://gna.org/bugs/?14035 Summary: pf_fuel_map finishes on infinite loop Project: Freeciv Submitted by: pepeto Submitted on: Thursday 07/30/2009 at 09:26 Category: general Severity: 4 - Important Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: Similar to bug #13742. If a fueled unit is in the middle of anywhere, a client goto causes an infinite recursion of the function update_last_part() before crashing. ___ File Attachments: --- Date: Thursday 07/30/2009 at 09:26 Name: trunk_client_pf_fuel_map_loop.diff Size: 2kB By: pepeto http://gna.org/bugs/download.php?file_id=6306 --- Date: Thursday 07/30/2009 at 09:26 Name: S2_1_client_pf_fuel_map_loop.diff Size: 2kB By: pepeto http://gna.org/bugs/download.php?file_id=6307 ___ Reply to this item at: http://gna.org/bugs/?14035 ___ 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 #14036] Game gets into infinite loop after last city taken by enemy
URL: http://gna.org/bugs/?14036 Summary: Game gets into infinite loop after last city taken by enemy Project: Freeciv Submitted by: hamaryns Submitted on: Donnerstag 30.07.2009 um 11:35 Category: None Severity: 4 - Important Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: If an enemy takes your last city (normally you’d break off before that, right, since you see it is hopeless), the last turn never comes to an end and the game becomes unresponsive. You see the other AI players going on (the year stays the same, but they evolve quite fast beyond it, funnily), but you cannot do anything. ___ Reply to this item at: http://gna.org/bugs/?14036 ___ 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 #14037] unit_change_homecity_handling() teleports units
URL: http://gna.org/bugs/?14037 Summary: unit_change_homecity_handling() teleports units Project: Freeciv Submitted by: pepeto Submitted on: Thursday 07/30/2009 at 13:08 Category: general Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: When I was reading the bug #14017 report, I noticed with surprise that units changing homecity were teleported to this location. This behaviour has been added at revision 10398 for PR#12950 in a patch by Per. This change is not documented or explained and it seems that Per doesn't remember why he did that. After checking, the function unit_change_homecity_handling() is called by 2 ways: * handle_unit_change_homecity(): so the unit needs to be at homecity tile. * transfer_unit(): in this case, the unit doesn't need to be at the homecity tile. But also, transfer doesn't mean teleport, the function header only says: Change home city of a unit with verbose output. This bug is also the cause of the PR#34672. ___ Reply to this item at: http://gna.org/bugs/?14037 ___ 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 #1210] Prevents client goto infinite recursions
URL: http://gna.org/patch/?1210 Summary: Prevents client goto infinite recursions Project: Freeciv Submitted by: pepeto Submitted on: Thursday 07/30/2009 at 09:59 Category: client Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any ___ Details: To prevent the client to have infinite recursions of update_last_part (see bug #13742 and #14035), the attached patch stops the recursion and warn with a log message an error occured. It makes only 1 warning per goto, else, you get very fast 300 similar error messages. Patch for S2_1 and trunk. ___ File Attachments: --- Date: Thursday 07/30/2009 at 09:59 Name: warn_instead_of_crash.diff Size: 2kB By: pepeto http://gna.org/patch/download.php?file_id=6308 ___ Reply to this item at: http://gna.org/patch/?1210 ___ 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 #1207] pft_fill_utype_*_parameter functions
Follow-up Comment #1, patch #1207 (project freeciv): Fixed compiler warning (file #6309) ___ Additional Item Attachment: File name: PftFillUtype_1207.diff Size:16 KB ___ Reply to this item at: http://gna.org/patch/?1207 ___ 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 #13958] View traderoutes always shows 0/4 for cities of other players
Follow-up Comment #1, bug #13958 (project freeciv): You should probably use client_is_global_observer() instead of checking if client.conn.playing == NULL. ___ Reply to this item at: http://gna.org/bugs/?13958 ___ 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 #14035] pf_fuel_map finishes on infinite loop
Follow-up Comment #1, bug #14035 (project freeciv): How can I reproduce this bug? ___ Reply to this item at: http://gna.org/bugs/?14035 ___ 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 #14035] pf_fuel_map finishes on infinite loop
Follow-up Comment #2, bug #14035 (project freeciv): Test with this stealth fighter. (file #6310) ___ Additional Item Attachment: File name: civgame-T000-Y4000BCm.sav.bz2 Size:10 KB ___ Reply to this item at: http://gna.org/bugs/?14035 ___ 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 #1188] proposed menu and command key revamp
Follow-up Comment #11, patch #1188 (project freeciv): OK, I'll get patches together and put each one in a separate ticket, so that they can be reviewed independently. - Civilization has general settings affecting your whole civilization, yet it is next to last menu. I would move it second after Game. I agree that might seem a little odd at first, but its commands affect game controls, rather than elements of the game itself (views, lists, etc - the exception is revolution, but tough to say where else to put it at the moment). This has worked well for e.g. Photoshop, Illustrator, Flash (development), which offer palettes and other controls in a similar spot. I've used those apps regularly, and think it works well overall. But I admit that my same experience that led me to bring this arrangement in Freeciv may have clouded my judgment. :-) - Edit is not usually needed at all - I would move it after all the menus used in normal play, just before Help. I tried to follow the generally accepted order of menus (File, Edit, View, Select, Window = Civilization, Help). But this Edit menu is also more vestigial than useful. Once the menus are converted to GtkUIManager, it'll be possible to change top-level items. Then edit mode can gain more menu items, better/more shortcuts (no conflicts with game menus). That would allow the edit mode commands to disappear from Edit, and it would make sense to move the others out and remove Edit completely. I see this revamp as the start of an iterative process, focusing on unit management this round. I didn't clean up the other menus as much, because the final arrangement isn't yet clear in my head and I wanted to avoid too much moving around during future steps. That said, I'm more than happy to make your two changes to the patches if you still see fit. I just wanted to explain my thoughts a bit, in case that showed a bit more method to my madness... :-) ___ Reply to this item at: http://gna.org/patch/?1188 ___ 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 #1201] Setting to control distance of traderoutes.
Update of patch #1201 (project freeciv): Status:None = Done Open/Closed:Open = Closed ___ Follow-up Comment #8: Committed with capability string bump. If you don't want to include capability string changes to patches (it would quite often cause patch not to apply cleanly), at least mention need for bump in the ticket to ensure that committer remembers to do one. ___ Reply to this item at: http://gna.org/patch/?1201 ___ 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 #13763] gtk assertion VALID_ITER failed when detaching
Update of bug #13763 (project freeciv): Status:None = Fixed Assigned to: mbook = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13763 ___ 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 #1205] Named user unit type flags
Update of patch #1205 (project freeciv): Status:None = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?1205 ___ 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 #14040] AI should use scientists when there is no research
URL: http://gna.org/bugs/?14040 Summary: AI should use scientists when there is no research Project: Freeciv Submitted by: None Submitted on: Friday 07/31/2009 at 04:09 CEST Category: ai Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: mt.kine...@gmail.com Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: The AI does not utilize scientists instead of workers, even when they are producing 0 bulbs, and will continue producing no research throughout the game. This is particularly a problem with the scenario maps, as I find it particularly hard to generate trade on them (as does the AI too) otherwise. Even if one city had to take a hit to growth, the game doesn't go anywhere with no research... I attached a saved game to show this. This is using the trunk version. Hard, Experimental, and Cheating AI levels are used in this savegame (UN is cheating, us and china are experimental, and almost everyone else is hard) ___ File Attachments: --- Date: Friday 07/31/2009 at 04:09 CEST Name: civgame-T059-Y975BCm.sav.bz2 Size: 117kB By: None http://gna.org/bugs/download.php?file_id=6312 ___ Reply to this item at: http://gna.org/bugs/?14040 ___ 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 #14041] Lojbanistani city names all lowercase
URL: http://gna.org/bugs/?14041 Summary: Lojbanistani city names all lowercase Project: Freeciv Submitted by: None Submitted on: Friday 07/31/2009 at 05:08 CEST Category: None Severity: 2 - Minor Priority: 5 - Normal Status: None Assigned to: None Originator Email: mt.kine...@gmail.com Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: Currently all of Lojbanistan's (fictional nation) cities start with a lower case letter, unlike the rest of Freeciv's cities. I don't know if this was intended, but it stands out against the rest of Freeciv (plus it was an easy fix, which I've attached). Since it is a made-up language, I capitalized all the separate words, but I didn't make it up so I don't know if its right, but it just didn't seem right lowercase. I left the leader's names lowercase because they seem to be people's usernames (??) ___ File Attachments: --- Date: Friday 07/31/2009 at 05:08 CEST Name: lojbanistani.ruleset.diff Size: 1kB By: None http://gna.org/bugs/download.php?file_id=6313 ___ Reply to this item at: http://gna.org/bugs/?14041 ___ 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 #14037] unit_change_homecity_handling() teleports units
Follow-up Comment #1, bug #14037 (project freeciv): So this is not the wanted behaviour? I thought it strange, that the boot in gna #14017 was teleported to an (inland) city. What would be possible action which result in a change of the homecity of a unit? 1. unit is in a city and it should be the new homecity = unit stays in this city 2. unit is bribed; homecity should be changed to the nearest city of the new owner? = unit stays there it is 3. a city is disbanded due to building a settler unit = change homecity of the units supported by this city to the nearest city (or kill all units?) = units stay there they are (or the next possible tile _within_ city radius there it can survive) this is important for allied units! = to far away units (from the old or new homecity?) are killed 4. a city is disbanded due to migration = like 3. 5. a city is bribed = that happens to the units? [never done this] = units supported by this city and at the city tile are also bribed (at the cost to the bride cost?) = units supported by this city change homecity to the nearest city = units allied to the old owner are scattered within the city radius (like partisans) Is this list correct? Are there actions missing? ___ Reply to this item at: http://gna.org/bugs/?14037 ___ 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 #14037] unit_change_homecity_handling() teleports units
Follow-up Comment #2, bug #14037 (project freeciv): 6. city is taken by combat. = there is no more units in the city tile. = supported units change homecity to the nearest city (but are not teleported to there). However, for the the buf #14017, it would be very strange a boot could be supported by an inland city. ___ Reply to this item at: http://gna.org/bugs/?14037 ___ 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 #14037] unit_change_homecity_handling() teleports units
Follow-up Comment #3, bug #14037 (project freeciv): Thanks for action 6! Do you know other possible action, where units are rehomed / teleported? However, for the the buf #14017, it would be very strange a boot could be supported by an inland city. This is the reason for the allert in gna #14017. The patch I send would kill such a unit. Marko asked that to do with gameloss units in this case as it would end the game for this player. I did never use such a unit and don't know that should be done. Should the gameless unit only be killed by an attack? Does the gameloss unit has a homecity? If not, the problem would be solved as this unit would only be influenced by action 5. - is would be scattered within the city radius. I think, if there is no place there the unit can survive the gameloss unit is destroyed and the game is lost for this player. ___ Reply to this item at: http://gna.org/bugs/?14037 ___ 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 #1210] Prevents client goto infinite recursions
Follow-up Comment #1, patch #1210 (project freeciv): Version 2, works with any goto part. (file #6316) ___ Additional Item Attachment: File name: warn_instead_of_crash2.diffSize:1 KB ___ Reply to this item at: http://gna.org/patch/?1210 ___ 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 #14037] unit_change_homecity_handling() teleports units
Follow-up Comment #4, bug #14037 (project freeciv): Actually, what I think is that units would change homecity not to the nearest city, but at the nearest city every of this units can be rehomed (then if the nearest city is inland, boats will be attached to the next coastal city). If a unit cannot be attached to any city of the player, then it would get killed, including the gameloss unit. And yes, a gameloss unit can have homecity. ___ Reply to this item at: http://gna.org/bugs/?14037 ___ 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 #13889] Attempt to move unit with 0 move rate crashes client
Follow-up Comment #1, bug #13889 (project freeciv): The attached patch does: * Checks before dividing by zero. * pf_map_iterate() (or pf_next() in S2_1) always returns FALSE when the unit doesn't have move_rate. (file #6317, file #6318) ___ Additional Item Attachment: File name: trunk_pf_null_move_rate.diff Size:4 KB File name: S2_1_pf_null_move_rate.diffSize:4 KB ___ Reply to this item at: http://gna.org/bugs/?13889 ___ 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 #13889] Attempt to move unit with 0 move rate crashes client
Update of bug #13889 (project freeciv): Assigned to:None = cazfi ___ Reply to this item at: http://gna.org/bugs/?13889 ___ 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 #14037] unit_change_homecity_handling() teleports units
Follow-up Comment #5, bug #14037 (project freeciv):
so the rehoming of units would look like the following (return code says if
the unit survives):
foreach unit of the city {
if the city is disbanded (case 3. and 4.) {
if unit can not survive at the old city tile {
check in dist 1 for a field there the unit can survive (no enemy units;
ocean for boots)
if such a tile is found {
move unit there
} else {
disband unit
return FALSE
}
}
}
search own city nearest (max dist?) to the unit! there the unit can survive
(i.e. coastal cities for boots)
if a city is found {
rehome unit
return TRUE
} else {
disband unit
return FALSE
}
}
the gameless unit wouldn't be a special case. I think both cases there this
unit would be disbanded are valid reasons to lose the game:
* no tile in radius 1 around the disbanded city there the gameloss unit can
survive
* no city (in max dist) there the gameloss unit can survive
the maximal distance could be a game / ruleset option
special case 5. has to be checked in the code for bribing a city
___
Reply to this item at:
http://gna.org/bugs/?14037
___
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 #14015] add illness information to gui-win32
Update of bug #14015 (project freeciv): Status:None = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?14015 ___ 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 #14004] Client should show plague risk as 0 when illness disabled
Update of bug #14004 (project freeciv): Status:None = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?14004 ___ 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 #1208] City warmap alternative
Update of patch #1208 (project freeciv): Status:None = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?1208 ___ 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 #14031] Multiple units unload all crash
Update of bug #14031 (project freeciv): Status:None = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?14031 ___ 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 #14045] autoconf 2.64 AC_REQUIRE 'AC_PATH_XTRA' warning
URL: http://gna.org/bugs/?14045 Summary: autoconf 2.64 AC_REQUIRE 'AC_PATH_XTRA' warning Project: Freeciv Submitted by: cazfi Submitted on: Saturday 08/01/2009 at 01:59 Category: None Severity: 3 - Normal Priority: 1 - Later Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: When using autoconf 2.64 I get warning: configure.ac:548: warning: AC_REQUIRE: `AC_PATH_XTRA' was expanded before it was required ___ Reply to this item at: http://gna.org/bugs/?14045 ___ 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 #1210] Prevents client goto infinite recursions
Update of patch #1210 (project freeciv): Assigned to:None = cazfi ___ Reply to this item at: http://gna.org/patch/?1210 ___ 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 #1211] command key revamp (see also patch #1188)
URL: http://gna.org/patch/?1211 Summary: command key revamp (see also patch #1188) Project: Freeciv Submitted by: jkeller Submitted on: Saturday 08/01/2009 at 15:19 Category: client-sdl Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any ___ Details: Patch to ensure that SDL client uses same command keys as GTK client and the information in the global helpdata.txt. (GTK changes in patch #1188) * new command keys * consistent text with key and across clients * patch for helpdata.txt in patch #1188 Please note: This patch contains changes to translatable strings, so update-po should be run after the patch is applied. ___ File Attachments: --- Date: Saturday 08/01/2009 at 15:19 Name: keys_sdl_r15860_v01.diff Size: 21kB By: jkeller http://gna.org/patch/download.php?file_id=6319 ___ Reply to this item at: http://gna.org/patch/?1211 ___ 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 #1188] proposed menu and command key revamp
Follow-up Comment #12, patch #1188 (project freeciv): I just submitted patches for the other clients: * patch #1211: SDL * patch #1212: Windows native * patch #1213: XAW These three bring the same changes to other clients as the files in this patch: * file #6194: (apply first) menu.c.01_reorg.diff * file #6197: menu.c.02_accels_revised.diff * file #6195: helpdata.txt.diff After all patches are applied, update-po should be run to catch the changes to translatable strings. ___ Reply to this item at: http://gna.org/patch/?1188 ___ 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 #1212] command key revamp (see also patch #1188)
URL: http://gna.org/patch/?1212 Summary: command key revamp (see also patch #1188) Project: Freeciv Submitted by: jkeller Submitted on: Saturday 08/01/2009 at 15:19 Category: client-win32 Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any ___ Details: Patch to ensure that Windows native client uses same command keys as GTK client and the information in the global helpdata.txt. (GTK changes in patch #1188) * new command keys * consistent text with key and across clients * patch for helpdata.txt in patch #1188 Please note: This patch contains changes to translatable strings, so update-po should be run after the patch is applied. ___ File Attachments: --- Date: Saturday 08/01/2009 at 15:19 Name: keys_win32_r15860_v01.diff Size: 6kB By: jkeller http://gna.org/patch/download.php?file_id=6320 ___ Reply to this item at: http://gna.org/patch/?1212 ___ 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 #1213] command key revamp (see also patch #1188)
URL: http://gna.org/patch/?1213 Summary: command key revamp (see also patch #1188) Project: Freeciv Submitted by: jkeller Submitted on: Saturday 08/01/2009 at 15:19 Category: client-xaw Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any ___ Details: Patch to ensure that XAW client uses same command keys as GTK client and the information in the global helpdata.txt. (GTK changes in patch #1188) * new command keys * consistent text with key and across clients * patch for helpdata.txt in patch #1188 Please note: This patch contains changes to translatable strings, so update-po should be run after the patch is applied. ___ File Attachments: --- Date: Saturday 08/01/2009 at 15:19 Name: keys_xaw_r15860_v01.diff Size: 8kB By: jkeller http://gna.org/patch/download.php?file_id=6321 ___ Reply to this item at: http://gna.org/patch/?1213 ___ 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 #1212] command key revamp (see also patch #1188)
Update of patch #1212 (project freeciv): Assigned to:None = cazfi ___ Reply to this item at: http://gna.org/patch/?1212 ___ 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 #1213] command key revamp (see also patch #1188)
Update of patch #1213 (project freeciv): Assigned to:None = cazfi ___ Reply to this item at: http://gna.org/patch/?1213 ___ 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 #1211] command key revamp (see also patch #1188)
Update of patch #1211 (project freeciv): Assigned to:None = cazfi ___ Reply to this item at: http://gna.org/patch/?1211 ___ 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 #14045] autoconf 2.64 AC_REQUIRE 'AC_PATH_XTRA' warning
Update of bug #14045 (project freeciv): Category:None = bootstrap Status:None = Ready For Test ___ Follow-up Comment #1: Fix (file #6324) ___ Additional Item Attachment: File name: CheckACPATHXTRAForXawClient_14045.diff Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?14045 ___ 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 #13861] [Patch] Ruins
Update of bug #13861 (project freeciv): Status:None = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13861 ___ 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 #14050] Bases with vision capability lose vision when game saved loaded
URL: http://gna.org/bugs/?14050 Summary: Bases with vision capability lose vision when game saved loaded Project: Freeciv Submitted by: cazfi Submitted on: Sunday 08/02/2009 at 01:09 Category: general Severity: 3 - Normal Priority: 1 - Later Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: $subject ___ Reply to this item at: http://gna.org/bugs/?14050 ___ 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 #14050] Bases with vision capability lose vision when game saved loaded
Update of bug #14050 (project freeciv): Status:None = Ready For Test ___ Follow-up Comment #1: Fix (file #6328) ___ Additional Item Attachment: File name: VisionBaseLoadFix_14050.diff Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?14050 ___ 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 #14051] Game loading tries to use is_new_game before it is loaded
URL: http://gna.org/bugs/?14051 Summary: Game loading tries to use is_new_game before it is loaded Project: Freeciv Submitted by: cazfi Submitted on: Sunday 08/02/2009 at 01:39 Category: general Severity: 3 - Normal Priority: 1 - Later Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: When loading saved game, game.info.is_new_game is being used before it is determined. Fix attached. ___ File Attachments: --- Date: Sunday 08/02/2009 at 01:39 Name: NplayersLoadFix.diff Size: 799B By: cazfi http://gna.org/bugs/download.php?file_id=6327 ___ Reply to this item at: http://gna.org/bugs/?14051 ___ 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 #1215] Base can see partially invisible units
URL: http://gna.org/patch/?1215 Summary: Base can see partially invisible units Project: Freeciv Submitted by: cazfi Submitted on: Sunday 08/02/2009 at 01:01 Category: general Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any ___ Details: This patch adds support for bases to have vision in invisible layer too. ___ File Attachments: --- Date: Sunday 08/02/2009 at 01:01 Name: BaseInvisVision.diff Size: 12kB By: cazfi http://gna.org/patch/download.php?file_id=6326 ___ Reply to this item at: http://gna.org/patch/?1215 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Mailing List
Am Sunday 05 July 2009 03:05:04 schrieb Matthias Pfafferodt: Am Saturday 04 July 2009 18:10:58 schrieb Matthias Pfafferodt: Hello, does the list has hickups? I'm missing some emails about comments to patches on gna since Thursday. The newest mail in the email archive is also from Thursday (https://mail.gna.org/public/freeciv-dev/2009-07/threads.html). I hope this Email will find its way. Matthias OK, I now got around 40 mails for Freeciv-Dev ... seems to be a problem at gna.org? This is a test mail ... Does this problem repeats itself at each start of a new month? Again no mails since Friday? -- Matthias Pfafferodt - http://www.mapfa.de Matthias.Pfafferodt at mapfa.de ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #14053] CRASH:gdk_x11_atom_to_xatom_for_display: assertion `atom != GDK_NONE' failed
URL: http://gna.org/bugs/?14053 Summary: CRASH:gdk_x11_atom_to_xatom_for_display: assertion `atom != GDK_NONE' failed Project: Freeciv Submitted by: None Submitted on: Sunday 08/02/2009 at 12:28 CEST Category: None Severity: 4 - Important Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: System: Linux 2.6.29.6-213.fc11.i686.PAE #1 SMP Tue Jul 7 20:59:29 EDT 2009 i686 X Vendor: The X.Org Foundation X Vendor Release: 10601901 Selinux: Enforcing Accessibility: Disabled GTK+ Theme: Nodoka Icon Theme: Fedora GTK+ Modules: canberra-gtk-module, pk-gtk-module, gnomebreakpad Memory status: size: 180559872 vsize: 180559872 resident: 151093248 share: 11657216 rss: 151093248 rss_rlim: 18446744073709551615 CPU usage: start_time: 1249189991 rtime: 10772 utime: 9859 stime: 913 cutime:0 cstime: 1 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/home/fc/client/freeciv-gtk2' [?1034h[Thread debugging using libthread_db enabled] 0x00bb2424 in __kernel_vsyscall () #0 0x00bb2424 in __kernel_vsyscall () #1 0x007abd43 in __waitpid_nocancel () from /lib/libc.so.6 #2 0x0097d8ff in g_spawn_sync () from /lib/libglib-2.0.so.0 #3 0x0097dc0c in g_spawn_command_line_sync () from /lib/libglib-2.0.so.0 #4 0x002483cc in ?? () from /usr/lib/gtk-2.0/modules/libgnomebreakpad.so #5 0x00248dc2 in ?? () from /usr/lib/gtk-2.0/modules/libgnomebreakpad.so #6 signal handler called #7 0x00bb2424 in __kernel_vsyscall () #8 0x007397c1 in raise () from /lib/libc.so.6 #9 0x0073b092 in abort () from /lib/libc.so.6 #10 0x007328ee in __assert_fail () from /lib/libc.so.6 #11 0x0814fd26 in real_die (file=0x8173cdc nation.c, line=262, format=0x8173d60 bad nation) at shared.c:758 #12 0x080f14ed in nation_of_player (pplayer=0x8235198) at nation.c:262 #13 0x080a8175 in objbind_get_value_from_object (ob=value optimized out, op=0xc5bf268) at editprop.c:1538 #14 0x080a8596 in property_page_set_store_value (pp=0xc5be4a0, op=0x6, ob=0x51b4, iter=0xbfcb97e0) at editprop.c:4503 #15 0x080b0417 in property_page_object_changed (pp=0xc5be4a0, object_id=value optimized out, removed=value optimized out) at editprop.c:5066 #16 0x08098ced in editgui_notify_object_changed (objtype=3, object_id=1, remove=false) at editgui.c:1857 #17 0x0807b70b in handle_player_info (pinfo=0x0) at packhand.c:1977 #18 0x0807e562 in client_handle_packet (type=PACKET_PROCESSING_STARTED, packet=0x6) at packhand_gen.c:128 #19 0x0805b169 in client_packet_input (packet=0xf816390, type=39) at client_main.c:491 #20 0x0805f743 in input_from_server (fd=5) at clinet.c:391 #21 0x04e9de7c in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #22 0x0097b77b in ?? () from /lib/libglib-2.0.so.0 #23 0x00944cf8 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #24 0x00948370 in ?? () from /lib/libglib-2.0.so.0 #25 0x009487df in g_main_loop_run () from /lib/libglib-2.0.so.0 #26 0x0761e029 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #27 0x08058079 in ui_main (argc=1, argv=0xbfcb9ed4) at gui_main.c:1796 #28 0x0805b679 in client_main (argc=1, argv=0xbfcb9ed4) at client_main.c:446 #29 0x0805731b in main (argc=1, argv=0xbfcb9ed4) at gui_main.c:1626 Thread 1 (Thread 0xb7f9b9a0 (LWP 20916)): #0 0x00bb2424 in __kernel_vsyscall () No symbol table info available. #1 0x007abd43 in __waitpid_nocancel () from /lib/libc.so.6 No symbol table info available. #2 0x0097d8ff in g_spawn_sync () from /lib/libglib-2.0.so.0 No symbol table info available. #3 0x0097dc0c in g_spawn_command_line_sync () from /lib/libglib-2.0.so.0 No symbol table info available. #4 0x002483cc in ?? () from /usr/lib/gtk-2.0/modules/libgnomebreakpad.so No symbol table info available. #5 0x00248dc2 in ?? () from /usr/lib/gtk-2.0/modules/libgnomebreakpad.so No symbol table info available. #6 signal handler called No symbol table info available. #7 0x00bb2424 in __kernel_vsyscall () No symbol table info available. #8 0x007397c1 in raise () from /lib/libc.so.6 No symbol table info available. #9 0x0073b092 in abort () from /lib/libc.so.6 No symbol table info available. #10 0x007328ee in __assert_fail () from /lib/libc.so.6 No symbol table info available. #11 0x0814fd26 in real_die (file=0x8173cdc nation.c, line=262, format=0x8173d60 bad nation) at shared.c:758 __PRETTY_FUNCTION__ = real_die #12 0x080f14ed in nation_of_player (pplayer=0x8235198) at nation.c:262 __PRETTY_FUNCTION__ = nation_of_player #13 0x080a8175 in objbind_get_value_from_object (ob=value optimized out, op=0xc5bf268) at editprop.c:1538 pplayer = value optimized out objtype = value optimized out propid = 35
[Freeciv-Dev] [bug #14037] unit_change_homecity_handling() teleports units
Follow-up Comment #6, bug #14037 (project freeciv):
There are 2 functions to don't confuse: transfer_unit() and
unit_change_homecity_hanling(). In unit_change_homecity_hanling(), only a
homecity change would be performed. So only the moving code would be
removed. The other stuff is a part of the bug #14017.
But, to answer you, I don't think in any case an unit have to be moved. For
me the transfer_unit() would take only the unit argument and look like:
if find a new possible homecity {
change_homecity();
return TRUE;
} else {
wipe_up();
return FALSE;
}
___
Reply to this item at:
http://gna.org/bugs/?14037
___
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 #14054] Autosettler behaviour makes engineers move far too far and take too long
URL: http://gna.org/bugs/?14054 Summary: Autosettler behaviour makes engineers move far too far and take too long Project: Freeciv Submitted by: None Submitted on: Sunday 02/08/09 at 18:10 CEST Category: None Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: Here's an example: suppose I've got two large continents and I've managed to connect them by a land bridge. The whole lot is connected by railway and I have a large number of engineer units. During the autosettler movement phase we see lots of engineeers moving from continent A to continent B, and also lots of engineers moving from continent B to continent A! It looks like each engineer selects the global best location to go to, in order. It would be much better if the best global locations were considered simultaniously and then the nearest engineer sent to each one. This would result in far less movement and thus far far less time spent during the autosettler phase watching engineers shuttle back and forth. As it is, it can end up taking several minutes for the engineers to make their moves. So the suggestion is to change the algorithm so that autosettler moves are considered simultaniously rather than in turn. Engineers that are in connected segments of railway should be treated as a block. If there are N engineers in a segment of railway then select the N best locations for them to move to. Select which engineers to send to each such location so as to (approximately) minimise the total distance moved. The point is we do not change which locations we move engineers to, we just change how we pick which engineers to go where. ___ Reply to this item at: http://gna.org/bugs/?14054 ___ 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 #14055] autosettler does not irrigate city square
URL: http://gna.org/bugs/?14055 Summary: autosettler does not irrigate city square Project: Freeciv Submitted by: None Submitted on: Sunday 02/08/09 at 18:18 CEST Category: None Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: The autosettler behaviour does not improve the city square itself with irrigation or farmland. Even when there are engineers sitting idle (having improved every square around a city) they still do not decide to irrigate the city square. One must take manual control of engineers and improve the city square manually. Surely it should be a high priorty to improve the city square since it is always used. This is with freeciv 2.1.8. ___ Reply to this item at: http://gna.org/bugs/?14055 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] [bug #14017] server crash when transferring a boat due to citizen migration
En/na Matthias Pfafferodt ha escrit:
Follow-up Comment #4, bug #14017 (project freeciv):
good question - I never played a game with a
gameloss unit. Should the unit teleported to
a random place? try the next city? the capital?
I did not resolve the issue with the gameloss unit...
But, at least, it does not crash the server...
I divided the list of units in two packs, the sea units and the
others...
Hope it helps...
Index: server/cityturn.c
===
--- server/cityturn.c (revision 15866)
+++ server/cityturn.c (working copy)
@@ -32,6 +32,7 @@
#include game.h
#include government.h
#include map.h
+#include movement.h
#include player.h
#include specialist.h
#include tech.h
@@ -2328,7 +2329,7 @@
struct tile *ptile_from, *ptile_to;
const char *name_from, *name_to, *nation_from, *nation_to;
char saved_name_from[MAX_LEN_NAME];
- struct city *rcity = NULL;
+ struct city *rcity = NULL, *rseacity = NULL;
if (!pcity_from || !pcity_to) {
return FALSE;
@@ -2409,17 +2410,64 @@
/* find closest city other of the same player than pcity_from */
rcity = find_closest_owned_city(pplayer_from, ptile_from,
FALSE, pcity_from);
+/* find closest city near sea */
+rseacity = find_closest_owned_city(pplayer_from, ptile_from,
+TRUE, pcity_from);
-if (rcity) {
- /* transfer all units to the closest city */
- transfer_city_units(pplayer_from, pplayer_from,
- pcity_from-units_supported, rcity, pcity_from,
- -1, TRUE);
- remove_city(pcity_from);
+if (rcity || rseacity) {
+ if (rcity == rseacity) {
- notify_player(pplayer_from, ptile_from, E_CITY_LOST,
-_(%s was disbanded by its citizens.),
-saved_name_from);
+/* transfer all units to the closest city */
+transfer_city_units(pplayer_from, pplayer_from,
+pcity_from-units_supported, rcity, pcity_from,
+-1, TRUE);
+ }
+ else {
+ /* split the unit list in sea and non-sea units */
+
+struct unit_list *non_sea_units = unit_list_new();
+struct unit_list *sea_units = unit_list_new();
+
+ unit_list_iterate_safe(pcity_from-units_supported, punit)
+ if (is_sailing_unit(punit)) {
+ unit_list_append(sea_units, punit);
+ }
+ else {
+ unit_list_append(non_sea_units, punit);
+ }
+ unit_list_iterate_safe_end;
+
+/* transfer non-sea units to the closest city */
+ if ((unit_list_size(non_sea_units) 0) (rcity != NULL)) {
+ transfer_city_units(pplayer_from, pplayer_from,
+ non_sea_units, rcity, pcity_from,
+ -1, TRUE);
+ } else {
+ unit_list_iterate_safe(non_sea_units, punit)
+ wipe_unit(punit);
+ unit_list_iterate_safe_end;
+ }
+
+/* transfer sea units to the closest sea city */
+ if ((unit_list_size(sea_units) 0) (rseacity != NULL)) {
+ transfer_city_units(pplayer_from, pplayer_from,
+ sea_units, rseacity, pcity_from,
+ -1, TRUE);
+ } else {
+ unit_list_iterate_safe(sea_units, punit)
+ wipe_unit(punit);
+ unit_list_iterate_safe_end;
+ }
+
+ }
+
+ /* remove the city */
+remove_city(pcity_from);
+
+notify_player(pplayer_from, ptile_from, E_CITY_LOST,
+ _(%s was disbanded by its citizens.),
+ saved_name_from);
+
} else {
/* it's the only city of the nation */
return FALSE;
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #13928] Don't navigate through unaccessible territorial waters
Follow-up Comment #1, bug #13928 (project freeciv): Those patches fix the problem. A new callback is added in the pf_parameter (can_invade_tile) to determine if the player can access this tile. It is not set if the unit isn't military. In common/player.[ch] is defined the usual callback: player_can_invade_tile(). In common/movement.c, the function test_unit_move_to_tile() also points to the new function player_can_invade_tile() to unsure the rules are same in all sides. (file #6329, file #6330) ___ Additional Item Attachment: File name: S2_1_pf_non_invade.diffSize:5 KB File name: trunk_pf_non_invade.diff Size:5 KB ___ Reply to this item at: http://gna.org/bugs/?13928 ___ 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 #14055] autosettler does not irrigate city square
Follow-up Comment #1, bug #14055 (project freeciv): I have to admit I don't know the current implementation of the ruleset with this the city irrigations rules. But, in standard rules, city gets automatically the irrigation and the farmland bonus. It is not needed to make infrastructure on the city tile. ___ Reply to this item at: http://gna.org/bugs/?14055 ___ 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 #14017] server crash when transferring a boat due to citizen migration
Follow-up Comment #5, bug #14017 (project freeciv): I did a better patch that does split the transfer of units in two packs: the sea ones and the others... Hope you like it ;-) BTW, which is the way to send patches to the bug tracker?... because i send a message to freeciv-dev@gna.org and the system just eat it!! (file #6337) ___ Additional Item Attachment: File name: sea_units_migration.diff Size:3 KB ___ Reply to this item at: http://gna.org/bugs/?14017 ___ 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 #14061] 'set minplayers 0' is needed for autogames
URL: http://gna.org/bugs/?14061 Summary: 'set minplayers 0' is needed for autogames Project: Freeciv Submitted by: syntron Submitted on: Dienstag 04.08.2009 um 09:15 Category: docs Severity: 2 - Minor Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: update the documentation for autogames (see summary) ___ File Attachments: --- Date: Dienstag 04.08.2009 um 09:15 Name: 0001--set-minplayers-0-is-needed-for-autogames.patch Size: 905B By: syntron http://gna.org/bugs/download.php?file_id=6338 ___ Reply to this item at: http://gna.org/bugs/?14061 ___ 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 #14063] no recursive calls to reset
URL: http://gna.org/bugs/?14063 Summary: no recursive calls to reset Project: Freeciv Submitted by: syntron Submitted on: Dienstag 04.08.2009 um 09:34 Category: general Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: as reset also reads the script it needs a check for recursive calls try it with the following script: -- test.serv --- set aifill 1 reset ___ File Attachments: --- Date: Dienstag 04.08.2009 um 09:34 Name: 0001-no-recursive-calls-to-reset.patch Size: 4kB By: syntron http://gna.org/bugs/download.php?file_id=6340 ___ Reply to this item at: http://gna.org/bugs/?14063 ___ 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 #14017] server crash when transferring a boat due to citizen migration
Follow-up Comment #6, bug #14017 (project freeciv): BTW, which is the way to send patches to the bug tracker?... because i send a message to freeciv-dev@gna.org and the system just eat it!! Mailing lists seem to be down at the moment (since last Wednesday, in fact). But even when mailing lists are functioning, you can't send patches to tracker through it, but you have to add them from tracker web interface. Just like you did. As for the patch itself, I'm sorry to say that it's just wrong. Problem is more generic than sea units teleporting to land cities. It's something like unit without BuildAnywhere unit class flag teleports to city in, and surrounded with, non-native tiles. In custom ruleset this may affect units other than sea units, or some sea units are not affected. ___ Reply to this item at: http://gna.org/bugs/?14017 ___ 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 #14063] no recursive calls to reset
Update of bug #14063 (project freeciv): Assigned to:None = cazfi ___ Reply to this item at: http://gna.org/bugs/?14063 ___ 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 #14061] 'set minplayers 0' is needed for autogames
Update of bug #14061 (project freeciv): Assigned to:None = cazfi ___ Reply to this item at: http://gna.org/bugs/?14061 ___ 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 #1189] [Patch] Allow airlifts to allied cities
Follow-up Comment #5, patch #1189 (project freeciv): Don't know how that happened. Fixed. (file #6348) ___ Additional Item Attachment: File name: airlift_allied_city_3.patchSize:0 KB ___ Reply to this item at: http://gna.org/patch/?1189 ___ 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 #14069] Update helptext to use trademindist
URL: http://gna.org/bugs/?14069 Summary: Update helptext to use trademindist Project: Freeciv Submitted by: syntron Submitted on: Mittwoch 05.08.2009 um 18:59 Category: general Severity: 2 - Minor Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: see summary ___ File Attachments: --- Date: Mittwoch 05.08.2009 um 18:59 Name: 0001-Update-helptext-to-use-trademindist.patch Size: 1kB By: syntron http://gna.org/bugs/download.php?file_id=6349 ___ Reply to this item at: http://gna.org/bugs/?14069 ___ 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 #14070] Helptext for F_SHIELD2GOLD
URL: http://gna.org/bugs/?14070 Summary: Helptext for F_SHIELD2GOLD Project: Freeciv Submitted by: syntron Submitted on: Mittwoch 05.08.2009 um 19:54 Category: general Severity: 2 - Minor Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: Add helptext for F_SHIELD2GOLD. It should name the advance / government it needs ... ___ File Attachments: --- Date: Mittwoch 05.08.2009 um 19:54 Name: 0001-Helptext-for-F_SHIELD2GOLD.patch Size: 1kB By: syntron http://gna.org/bugs/download.php?file_id=6350 ___ Reply to this item at: http://gna.org/bugs/?14070 ___ 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 #14072] Helptext for EFT_MIGRATION_PCT
Follow-up Comment #1, bug #14072 (project freeciv): fix missing space (file #6353) ___ Additional Item Attachment: File name: 0001-Helptext-for-EFT_MIGRATION_PCT.patch Size:1 KB ___ Reply to this item at: http://gna.org/bugs/?14072 ___ 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 #14079] cleanup of reestablish_city_trade_routes()
URL: http://gna.org/bugs/?14079 Summary: cleanup of reestablish_city_trade_routes() Project: Freeciv Submitted by: syntron Submitted on: Donnerstag 06.08.2009 um 14:09 Category: general Severity: 2 - Minor Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: several for() loops are used to reestablish the trade routes for a city. Combine all into the existing function for that. ___ File Attachments: --- Date: Donnerstag 06.08.2009 um 14:09 Name: 0001-cleanup-of-reestablish_city_trade_routes.patch Size: 4kB By: syntron http://gna.org/bugs/download.php?file_id=6358 ___ Reply to this item at: http://gna.org/bugs/?14079 ___ 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 #14017] server crash when transferring a boat due to citizen migration
Follow-up Comment #7, bug #14017 (project freeciv): check if unit can exist at the new tile in transfer_unit(); if not delete the unit What about gameloss units? I home the patch in #14037 solves this? ___ Reply to this item at: http://gna.org/bugs/?14017 ___ 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 #13861] [Patch] Ruins
Follow-up Comment #3, bug #13861 (project freeciv): tried it - nice to know there the forgotten city are ;-) ___ Reply to this item at: http://gna.org/bugs/?13861 ___ 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 #14037] unit_change_homecity_handling() teleports units
Follow-up Comment #7, bug #14037 (project freeciv):
rework changing of homecity / rehome of units and cities
* rename transfer_unit() to rehome_unit()
* merge transfer_city() and transfer_city_units()
* no more teleport of units!
some definitions for different functions:
unit_change_homecity_handling():
- change homecity of the unit
- takes care of owner
- does NOT move the unit
handle_unit_change_homecity():
- change homecity of a unit
- only checks if unit exists
- calls unit_change_homecity_handling()
ai_unit_make_homecity():
- calls handle_unit_change_homecity()
execute_orders():
- calls handle_unit_change_homecity()
transfer_city():
- transfers a city from one player to another
- units further away than distance given by kill_outside are killed
- possibility to also transfer all units to the new owner
- default: transfer only units at the city tile
- search new homecity for all supported units not on the city tile
unit_enter_city():
- call to transfer_city()
remove_city()
- rehome all units and kill the city
rehome_unit()
- change homecity of unit to another city of the player
- the current homecity is NOT considered
But, to answer you, I don't think in any case an unit have to be moved.
For me the transfer_unit() would take only the unit argument and look like:
if find a new possible homecity {
change_homecity();
return TRUE;
} else {
wipe_up();
return FALSE;
}
I decided to change it to a homeless unit. If no possible homecity can be
found, the current homecity is the last city of this player ...
This patch also solves bug #14017
(file #6360)
___
Additional Item Attachment:
File name: 0001-rework-changing-of-homecity-rehome-of-units-and-ci.patch
Size:33 KB
___
Reply to this item at:
http://gna.org/bugs/?14037
___
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 #14041] Lojbanistani city names all lowercase
Follow-up Comment #1, bug #14041 (project freeciv): Lojban is written almost entirely with lower-case letters [http://en.wikipedia.org/wiki/Lojban#Phonology_and_Orthography] so it was probably intentional. ___ Reply to this item at: http://gna.org/bugs/?14041 ___ 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 #14081] City unable to build sewer system
URL: http://gna.org/bugs/?14081 Summary: City unable to build sewer system Project: Freeciv Submitted by: None Submitted on: Thursday 08/06/2009 at 19:32 CEST Category: None Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: abarc...@u.washington.edu Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: The city of Sheresi (Egypt) is marked with a red X and reports that it needs an improvement to grow. When I examine the existing infrastructure, the sewer system is indeed not present. However, the sewer system also does not appear in the production list. If 'Show Future Targets' is selected, it is possible to add the sewer system to the worklist, but when it is on the top of the worklist it is converted to the previous target, as if it was already built or was missing a dependency. An aqueduct shows in the list of existing improvements. Quitting FreeCiv and restarting the game had no effect. Freeciv version 2.1.9 gui-gtk-2.0 Linux 2.6.30 #1 SMP x86_64 x86_64 x86_64 GNU/Linux ___ File Attachments: --- Date: Thursday 08/06/2009 at 19:32 CEST Name: egyptians.sav.gz Size: 96kB By: None Saved game demonstrating problem http://gna.org/bugs/download.php?file_id=6363 ___ Reply to this item at: http://gna.org/bugs/?14081 ___ 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 #14082] civclient crashes or hangs when caravan/freight enters city
URL: http://gna.org/bugs/?14082 Summary: civclient crashes or hangs when caravan/freight enters city Project: Freeciv Submitted by: None Submitted on: Thursday 08/06/2009 at 19:49 CEST Category: None Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: abarc...@u.washington.edu Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: When a caravan or freight arrives at a city, the box with the action to be taken sometimes hangs or crashes immediately. When it hangs it does not recover, and it is necessary to opt to stop waiting for it. This is happening when I am playing a game on a local machine against only AI players, and it only started happening with the most recent update (prior to that, the biggest cause of crashes was conquering a city). It happens frequently enough that I have started sending caravans to points outside of cities, and saving before I have them enter cities. In a typical game, it will happen once or twice. I have not been able to observe any pattern to the crashes. Freeciv version 2.1.9 gui-gtk-2.0 Linux #1 SMP x86_64 x86_64 x86_64 GNU/Linux ___ Reply to this item at: http://gna.org/bugs/?14082 ___ 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 #14083] city resets resource use without governor enabled
URL: http://gna.org/bugs/?14083 Summary: city resets resource use without governor enabled Project: Freeciv Submitted by: None Submitted on: Thursday 08/06/2009 at 19:55 CEST Category: None Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: abarc...@u.washington.edu Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: I have observed that sometimes a city will change from using the resource squares I have selected, even if (a) the governor is not enabled (for that city or for neighboring cities), (b) there is no competition with other cities for resources, and (c) the city has not grown. In some games I have found that I need to reset a city's resources every single turn, which is of course not much fun. Inevitably the change is from production to food. I do not have an example saved at the moment, but the next time I notice this happening, I will create an example file. It doesn't happen in every game, nor with every city. Freeciv version 2.1.9 gui-gtk-2.0 Linux #1 SMP x86_64 x86_64 x86_64 GNU/Linux ___ Reply to this item at: http://gna.org/bugs/?14083 ___ 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 #14084] wish: autoexplore route around peaceful territory
URL: http://gna.org/bugs/?14084 Summary: wish: autoexplore route around peaceful territory Project: Freeciv Submitted by: None Submitted on: Thursday 08/06/2009 at 19:59 CEST Category: None Severity: 1 - Wish Priority: 5 - Normal Status: None Assigned to: None Originator Email: abarc...@u.washington.edu Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: It would be nice if autoexplore for non-explorer units (such as vessels) would respect peace agreements by simply going around territory rather than requiring manual intervention. ___ Reply to this item at: http://gna.org/bugs/?14084 ___ 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 #14081] City unable to build sewer system
Follow-up Comment #1, bug #14081 (project freeciv): I checked your savegame. You have to research Sanitation to be allowed to build the sewer system ... Happy gaming! ___ Reply to this item at: http://gna.org/bugs/?14081 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
