[Freeciv-Dev] [patch #3857] Remove savegame.c:savefile_options_default[]
URL: http://gna.org/patch/?3857 Summary: Remove savegame.c:savefile_options_default[] Project: Freeciv Submitted by: cazfi Submitted on: Sat 20 Apr 2013 10:50:04 AM EEST Category: general Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.5.0, 2.6.0 ___ Details: savefile_options_default[] in savegame.c is not used for anything any more as we're not saving in such old formats (ones supported by savegame.c). Remove it. ___ File Attachments: --- Date: Sat 20 Apr 2013 10:50:04 AM EEST Name: SavefileOptionsDefaultRm.patch Size: 1kB By: cazfi http://gna.org/patch/download.php?file_id=17779 ___ Reply to this item at: http://gna.org/patch/?3857 ___ 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 #3858] Drop support for pre-2.0 savegame loading
URL: http://gna.org/patch/?3858 Summary: Drop support for pre-2.0 savegame loading Project: Freeciv Submitted by: cazfi Submitted on: Sat 20 Apr 2013 10:54:59 AM EEST Category: general Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.6.0 ___ Details: Require savegames to be loaded to be from version 2.0.0 or newer (was 1.9.0). Remove some support code for loading older saves. ___ File Attachments: --- Date: Sat 20 Apr 2013 10:54:59 AM EEST Name: Pre2Saves.patch Size: 17kB By: cazfi http://gna.org/patch/download.php?file_id=17780 ___ Reply to this item at: http://gna.org/patch/?3858 ___ 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] 2.4.0-beta2 release soon
At last, we're expecting to release 2.4.0-beta2 next weekend sometime (27-28 April). We have a vague hope that this will be the last beta before we go to release candidates. For translators: since this is a beta, I can't promise a string freeze, although I'm not aware of any expected string changes right now. Files at http://www.cazfi.net/freeciv/translations/S2_4/ are I think fresh. Translation updates are of course welcome. (Followups set to freeciv-i18n.) Cheers, Jacob Current translation stats for S2_4 (including nation legends): ca: 100%: 7115 translated. pl: 100%: 7115 translated. en_GB: 99.3%: 7065 translated, 39 fuzzy, 11 untranslated. es: 99.2%: 7058 translated, 34 fuzzy, 23 untranslated. fr: 98.7%: 7021 translated, 76 fuzzy, 18 untranslated. gd: 90%: 6415 translated, 489 fuzzy, 211 untranslated. ja: 85%: 6027 translated, 680 fuzzy, 408 untranslated. fi: 84%: 5951 translated, 680 fuzzy, 484 untranslated. da: 80%: 5714 translated, 877 fuzzy, 524 untranslated. de: 73%: 5188 translated, 1146 fuzzy, 781 untranslated. uk: 69%: 4931 translated, 1157 fuzzy, 1027 untranslated. nl: 68%: 4854 translated, 1335 fuzzy, 926 untranslated. it: 62%: 4446 translated, 1725 fuzzy, 944 untranslated. pt_BR: 59%: 4208 translated, 1965 fuzzy, 942 untranslated. ru: 58%: 4145 translated, 1929 fuzzy, 1041 untranslated. ga: 54%: 3875 translated, 31 fuzzy, 3209 untranslated. id: 52%: 3681 translated, 127 fuzzy, 3307 untranslated. sv: 51%: 3605 translated, 1977 fuzzy, 1533 untranslated. tr: 40%: 2878 translated, 2479 fuzzy, 1758 untranslated. et: 40%: 2849 translated, 2602 fuzzy, 1664 untranslated. zh_TW: 40%: 2839 translated, 12 fuzzy, 4264 untranslated. cs: 40%: 2820 translated, 2701 fuzzy, 1594 untranslated. eo: 39%: 2741 translated, 2031 fuzzy, 2343 untranslated. lt: 37%: 2654 translated, 2179 fuzzy, 2282 untranslated. ro: 35%: 2475 translated, 2745 fuzzy, 1895 untranslated. zh_CN: 34%: 2437 translated, 2863 fuzzy, 1815 untranslated. ar: 34%: 2387 translated, 3123 fuzzy, 1605 untranslated. nb: 33%: 2381 translated, 3001 fuzzy, 1733 untranslated. no: 33%: 2381 translated, 3001 fuzzy, 1733 untranslated. ko: 29%: 2062 translated, 1921 fuzzy, 3132 untranslated. sr: 29%: 2049 translated, 1522 fuzzy, 3544 untranslated. el: 28%: 2008 translated, 2355 fuzzy, 2752 untranslated. bg: 27%: 1936 translated, 282 fuzzy, 4897 untranslated. hu: 26%: 1851 translated, 3230 fuzzy, 2034 untranslated. pt: 24%: 1679 translated, 3251 fuzzy, 2185 untranslated. fa: 23%: 1644 translated, 2132 fuzzy, 3339 untranslated. he: 23%: 1640 translated, 1902 fuzzy, 3573 untranslated. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20750] packets.c:send_packet_data(): warning: variable 'packet_type' set but not used [-Wunused-but-set-variable]
URL: http://gna.org/bugs/?20750 Summary: packets.c:send_packet_data(): warning: variable 'packet_type' set but not used [-Wunused-but-set-variable] Project: Freeciv Submitted by: jtn Submitted on: Sat Apr 20 10:58:51 2013 Category: None Severity: 2 - Minor Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: S2_4 r22731 Discussion Lock: Any Operating System: GNU/Linux Planned Release: 2.4.0,2.5.0 ___ Details: Noticed scrolling by while making a test S2_4 release build: CC packets.lo packets.c: In function 'send_packet_data': packets.c:205:9: warning: variable 'packet_type' set but not used [-Wunused-but-set-variable] Since this wasn't an --enable-debug=yes build (no -Werror), this warning didn't stop the build. In fact it looks like this will only show up when debugging is off, because the variable is only used if DEBUG is defined, so it'll never break the build. Should still clean it up though. ___ Reply to this item at: http://gna.org/bugs/?20750 ___ 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 #18517] unable to drag items in Target Worklist to reorder.
Follow-up Comment #17, bug #18517 (project freeciv): Tested with crosser build that uses gtk+-2.24.10. Reordering by dragging seems to work. ___ Reply to this item at: http://gna.org/bugs/?18517 ___ 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] [task #7678] Windows packages for 2.4.0-beta2
Follow-up Comment #2, task #7678 (project freeciv): Now the very latest (on the mirror I'm using) ImageMagick, 6.8.4-10, compiles too. ___ Reply to this item at: http://gna.org/task/?7678 ___ 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 #20585] variable 'punit' set but not used in citytools.c
Update of bug #20585 (project freeciv): Status: Ready For Test = Fixed Assigned to:None = syntron Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20585 ___ 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] [task #7681] Distribute Windows build of Gtk3 client
URL: http://gna.org/task/?7681 Summary: Distribute Windows build of Gtk3 client Project: Freeciv Submitted by: jtn Submitted on: Sat Apr 20 15:23:04 2013 Should Start On: Sat Apr 20 00:00:00 2013 Should be Finished on: Mon Apr 20 00:00:00 2015 Category: None Priority: 5 - Normal Status: Need Info Privacy: Public Percent Complete: 0% Assigned to: None Open/Closed: Open Discussion Lock: Any Effort: 0.00 Planned Release: 2.5.0 ___ Details: Creating this task following on discussion in task #7599, to track progress and blockers for distributing a Windows binary package of the Gtk3 client, since at the moment it seems unwise to hook it to a specific release. Currently Need Info because it's blocked; target date/release is a placeholder. Current situation remains that there is no official win32 Gtk3 maintainer or builds (here http://www.gtk.org/download/win32.php or here http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/), despite some encouraging noises last year from Alexander Larsson (see task #7599). This StackOverflow thread http://stackoverflow.com/questions/6006689/where-can-i-download-precompiled-gtk-3-binaries-or-windows-installer lists some unofficial builds; don't know if these are what we need: * tarnyko.net http://www.tarnyko.net/en/?q=node/20 (also mentioned on live.gnome.org https://live.gnome.org/GTK+/Win32) * Niklas Gürtler https://mail.gnome.org/archives/gtk-list/2012-December/msg00046.html's installer here http://games.2g2s.de/?page_id=196 * OpenSUSE Build System http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_Factory/noarch/? Presumably another alternative is Marko's Crosser builds http://www.cazfi.net/freeciv/builds/win.html. ___ Reply to this item at: http://gna.org/task/?7681 ___ 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] [task #7599] Windows packages for 2.4.0-beta1
Follow-up Comment #16, task #7599 (project freeciv): (The Windows Gtk3 build story continues in task #7681.) ___ Reply to this item at: http://gna.org/task/?7599 ___ 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 #3759] Make freesounds the default soundset
Follow-up Comment #6, patch #3759 (project freeciv): Hey all. Bernd Jendrissek just pointed out to me that you were re-evaluating the freesound soundset. I'd be more than happy to take on the project of re-evaluating the licencing issues with the soundset. It would be fantastic to get it included. Would this patch be the best place to discuss it? ___ Reply to this item at: http://gna.org/patch/?3759 ___ 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 #3859] Nations ruleset: move government compatibility checking to nationlist.ruleset
URL: http://gna.org/patch/?3859 Summary: Nations ruleset: move government compatibility checking to nationlist.ruleset Project: Freeciv Submitted by: jtn Submitted on: Sat Apr 20 20:56:13 2013 Category: None Priority: 5 - Normal Status: In Progress Privacy: Public Assigned to: jtn Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.5.0 ___ Details: As I suggested in bug #19841, this patch moves the ignore_govs compatibility declaration from individual rulesets to default/nationlist.ruleset. (Still in the [compatibility] section, but the secfile format allows multiple instances of those.) It makes some other changes too: * ignore_govs renamed to allowed_govs * nationlist.ruleset contains a list of _all_ the govs that are mentioned in individual nation files, not just those that happen to be missing in some of our rulesets ** (The previous code would have handled this, as it happens.) * If a set of allowed govs has been specified at all, it is an error for a nation to mention a gov not on that list. ** Rationale: if our classic ruleset gets a new gov (say Tribal), then without this check, a nation referencing that gov would load OK with the default/classic ruleset (and hence might get checked in) but fail with non-default ruleset. * Nations' init_governments are now subject to this check too. ** (But not the nationset's default_government. It's only specified once and so spotting typos is less important, and a new ruleset could usefully set it to something not in the nationset without causing trouble.) (This probably warrants a ruleset capability bump.) ___ Reply to this item at: http://gna.org/patch/?3859 ___ 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 #3859] Nations ruleset: move government compatibility checking to nationlist.ruleset
Update of patch #3859 (project freeciv): Status: In Progress = Ready For Test ___ Additional Item Attachment: File name: trunk-nations-allowed-govs.patch Size:10 KB ___ Reply to this item at: http://gna.org/patch/?3859 ___ 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 #20751] assertion 'normal_player_count() = game.server.max_players' failed
URL: http://gna.org/bugs/?20751 Summary: assertion 'normal_player_count() = game.server.max_players' failed Project: Freeciv Submitted by: jorneg Submitted on: Sat Apr 20 20:15:51 2013 Category: general Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: GNU/Linux Planned Release: ___ Details: This is with S2_4 HEAD. 1: in sg_load_sanitycheck() [savegame2.c::5651]: assertion 'normal_player_count() = game.server.max_players' failed. 2: Backtrace: 2: 0: ./server/freeciv-server() [0x826215e] 2: 1: ./server/freeciv-server(vdo_log+0xa7) [0x825ff87] 2: 2: ./server/freeciv-server(do_log+0x3c) [0x825ffec] 2: 3: ./server/freeciv-server(fc_assert_fail+0x50) [0x8260040] 2: 4: ./server/freeciv-server(real_sanity_check+0xf4) [0x80fc2d4] 2: 5: ./server/freeciv-server() [0x8111920] 2: 6: ./server/freeciv-server(savegame2_load+0x1d8) [0x8111fa8] 2: 7: ./server/freeciv-server(load_command+0x414) [0x80894d4] 2: 8: ./server/freeciv-server() [0x808dbed] 2: 9: ./server/freeciv-server() [0x811508f] 2:10: /lib/libreadline.so.6(rl_callback_read_char+0x92) [0xa70302] 2:11: ./server/freeciv-server(server_sniff_all_input+0x1197) [0x8117457] 2:12: ./server/freeciv-server(srv_main+0x1d5) [0x807dc15] 2:13: ./server/freeciv-server(main+0x90f) [0x8073a4f] 2:14: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0x126bd6] 2:15: ./server/freeciv-server() [0x80730a1] 1: Por favor, informa de este mensaje a http://gna.org/projects/freeciv/ 2: Backtrace: 2: 0: ./server/freeciv-server() [0x826215e] 2: 1: ./server/freeciv-server(vdo_log+0xa7) [0x825ff87] 2: 2: ./server/freeciv-server(do_log+0x3c) [0x825ffec] 2: 3: ./server/freeciv-server(fc_assert_fail+0xd0) [0x82600c0] 2: 4: ./server/freeciv-server(real_sanity_check+0xf4) [0x80fc2d4] 2: 5: ./server/freeciv-server() [0x8111920] 2: 6: ./server/freeciv-server(savegame2_load+0x1d8) [0x8111fa8] 2: 7: ./server/freeciv-server(load_command+0x414) [0x80894d4] 2: 8: ./server/freeciv-server() [0x808dbed] 2: 9: ./server/freeciv-server() [0x811508f] 2:10: /lib/libreadline.so.6(rl_callback_read_char+0x92) [0xa70302] 2:11: ./server/freeciv-server(server_sniff_all_input+0x1197) [0x8117457] 2:12: ./server/freeciv-server(srv_main+0x1d5) [0x807dc15] 2:13: ./server/freeciv-server(main+0x90f) [0x8073a4f] 2:14: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0x126bd6] 2:15: ./server/freeciv-server() [0x80730a1] 1: in load_command() [stdinhand.c::3689]: assertion 'normal_player_count() = game.server.max_players' failed. 2: Backtrace: 2: 0: ./server/freeciv-server() [0x826215e] 2: 1: ./server/freeciv-server(vdo_log+0xa7) [0x825ff87] 2: 2: ./server/freeciv-server(do_log+0x3c) [0x825ffec] 2: 3: ./server/freeciv-server(fc_assert_fail+0x50) [0x8260040] 2: 4: ./server/freeciv-server(real_sanity_check+0xf4) [0x80fc2d4] 2: 5: ./server/freeciv-server(load_command+0x47a) [0x808953a] 2: 6: ./server/freeciv-server() [0x808dbed] 2: 7: ./server/freeciv-server() [0x811508f] 2: 8: /lib/libreadline.so.6(rl_callback_read_char+0x92) [0xa70302] 2: 9: ./server/freeciv-server(server_sniff_all_input+0x1197) [0x8117457] 2:10: ./server/freeciv-server(srv_main+0x1d5) [0x807dc15] 2:11: ./server/freeciv-server(main+0x90f) [0x8073a4f] 2:12: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0x126bd6] 2:13: ./server/freeciv-server() [0x80730a1] 1: Por favor, informa de este mensaje a http://gna.org/projects/freeciv/ 2: Backtrace: 2: 0: ./server/freeciv-server() [0x826215e] 2: 1: ./server/freeciv-server(vdo_log+0xa7) [0x825ff87] 2: 2: ./server/freeciv-server(do_log+0x3c) [0x825ffec] 2: 3: ./server/freeciv-server(fc_assert_fail+0xd0) [0x82600c0] 2: 4: ./server/freeciv-server(real_sanity_check+0xf4) [0x80fc2d4] 2: 5: ./server/freeciv-server(load_command+0x47a) [0x808953a] 2: 6: ./server/freeciv-server() [0x808dbed] 2: 7: ./server/freeciv-server() [0x811508f] 2: 8: /lib/libreadline.so.6(rl_callback_read_char+0x92) [0xa70302] 2: 9: ./server/freeciv-server(server_sniff_all_input+0x1197) [0x8117457] 2:10: ./server/freeciv-server(srv_main+0x1d5) [0x807dc15] 2:11: ./server/freeciv-server(main+0x90f) [0x8073a4f] 2:12: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0x126bd6] 2:13: ./server/freeciv-server() [0x80730a1] ___ File Attachments: --- Date: Sat Apr 20 20:15:51 2013 Name: cat10civ10.sav.gz Size: 249kB By:
[Freeciv-Dev] [bug #20751] assertion 'normal_player_count() = game.server.max_players' failed
Follow-up Comment #1, bug #20751 (project freeciv): Is that savegame also created with some recent freeciv revision, or is it from older freeciv? ___ Reply to this item at: http://gna.org/bugs/?20751 ___ 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] Nativity restrictions in clients
The client code seems to use UMT_*, TC_OCEAN, is_foo_unit(), and is_ocean() in several places for which I don't really understand the correct behaviour to support complex unit nativity. Suggestions, opinions, and pointers to open bugs or patches welcome. climisc.c:unit_color_type() This function uses UMT_* as a guide to set the correct background color for a unit, which seems only to be used in the Xaw client. I would think that with complex nativity, it makes sense to assign the background color for tiles based on terrain, player knowledge, etc. I don't have much familiarity with Xaw, so I don't understand if we can use logic like that used for the gtk2/3 clients' create_overlay_unit() (or some analog thereto) to initialise to black and then modify based on terrain/tileset definitions. unitselect_common.c:usdlg_check_unit_location() This function has support for selecting units based on move_type explicitly. I've never used this feature, so don't know common use cases. For complex nativity, I suspect that these become less useful: various amphibious units are inherently excluded, which may be unfortunate for rulesets with many ocean depths that allow most land units on the shallowest of oceans (which might not be particularly deep, and may not permit access by most seaworthy units). Units with restrictions within classic nativity (only some land, only some oceanic, only roads, etc.) may be selected inappropriately, as they might be unsuitable for use for the intended purpose (e.g. cannot move to some target). control.c:quickselect() This function has different heuristics for different environments. In rulesets that might have land transporters that carry land units, or sea transports that only carry sea units, or land units that can't move because they require roads, or similar complexities, I'm not sure that these heuristics are sufficient, nor that there aren't assumptions about available terrains and unit classes built into the heuristics. That said, I don't use this, so hesitate to apply a patch that might break someone's gameplay. Naively, I would think the following might work sensibly for arbitrary terrains and units: 1) Native military attack units 2) Native transports 3) Other native units 4) Non-native units On the other hand, ordered like that, for the classic ruleset (as an example), Air, Helicopter, and Missile units might be selected much more often than was intended. Perhaps reachability ought be added to the criteria checked, to decrease the chance of selection. Given that this feature is most useful when the player has no time to think, it is somewhat important not to be surprising, either by selecting the wrong unit or by failing to select the expected unit because of the current nativity restrictions. editor.c:editor_grab_tool() This just chooses ground units before sea units: I presume the intent is to deprioritise sea units in port (given the score reduction for transported units which adjusts this). My thought here is to prioritise native units over non-native units (so that the order depends on terrain), but I don't remember using this tool either (unless it is responsible for unit ordering in the unit pane in the editor), so don't know if this would break someone's workflow. Separately, this function seems to use UCF_UNREACHABLE as a proxy for aerial units, and selects them first. If the sorting is somewhat intended to describe altitude, this wouldn't work for Burrowing units from the alien ruleset, for example. If the intent is to prioritise important units somehow, where aerial==important, there's no need to adjust it, as most unreachable units are likely to be of particular interest in most rulesets. If I'm incorrect about the proxy use here, then nothing needs be done for UCF_UNREACHABLE. Those client uses of is_ocean() and TC_OCEAN not mentioned above seemed sane to me (and safe for complex nativity), although I wonder if the code ought standardise on one or the other representation of this idea (changelogs suggest general migration to is_ocean(), but some of the calls that use TC_OCEAN might need refactoring for this). The idea of selecting coastal cities may also be slightly less useful for rulesets with particularly complex nativity, as some coastal cities might not support many sea units, etc. Similarly, the current coastal check happens to also select all Oceanic cities that aren't built on a lake. -- Emmet HIKORY ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20542] in unit_virtual_destroy() [unit.c::1881]: assertion '!unit_transported(punit)' failed
Update of bug #20542 (project freeciv): Status: Ready For Test = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20542 ___ 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 #3692] Reduce SHIELD_WEIGHTING
Update of patch #3692 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3692 ___ 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 #20747] Units in nested transport considered defensive units
Follow-up Comment #1, bug #20747 (project freeciv): This affects both S2_4 and TRUNK, or? Also, I remember there being equivalent logic of transported unit stepping out to defend in defense value calculation in combat.c. Have you checked if it's ok in this respect? ___ Reply to this item at: http://gna.org/bugs/?20747 ___ 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 #3860] Nations ruleset: allow terrain checking against explicit compatibility list
URL: http://gna.org/patch/?3860 Summary: Nations ruleset: allow terrain checking against explicit compatibility list Project: Freeciv Submitted by: jtn Submitted on: Sun Apr 21 00:07:49 2013 Category: None Priority: 5 - Normal Status: In Progress Privacy: Public Assigned to: jtn Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.5.0 ___ Details: Similar to ignore/allowed_govs, it would be useful to be able to specify for our default nationlist what the set of terrains allowed in natural city names, so that it's possible to catch typos while allowing those nations to be used in rulesets without (e.g.) lake. This allows reversal of the downgrade of this condition to LOG_VERBOSE that happened in bug #15333. This patch also tightens up other error handling nearby, and removes lake from the civ1/civ2 cloned copies of the Aztec ruleset, as it is never appropriate there. ___ Reply to this item at: http://gna.org/patch/?3860 ___ 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 #3861] Nations ruleset: replace warn_city_style with allowed_city_styles
URL: http://gna.org/patch/?3861 Summary: Nations ruleset: replace warn_city_style with allowed_city_styles Project: Freeciv Submitted by: jtn Submitted on: Sun Apr 21 00:10:11 2013 Category: None Priority: 5 - Normal Status: In Progress Privacy: Public Assigned to: jtn Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.5.0 ___ Details: Similar to patch #3859 / patch # 3860. This replaces the warn_city_style option added in patch #2995. ___ Reply to this item at: http://gna.org/patch/?3861 ___ 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 #3860] Nations ruleset: allow terrain checking against explicit compatibility list
Follow-up Comment #1, patch #3860 (project freeciv): Seems like duplicate of patch #3708, but if you're adding patch here, it's probably better to mark #3708 as duplicate of this. ___ Reply to this item at: http://gna.org/patch/?3860 ___ 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 #3759] Make freesounds the default soundset
Follow-up Comment #7, patch #3759 (project freeciv): Would this patch be the best place to discuss it? Yes, that would keep the discussion stored where one would be looking for the info. ___ Reply to this item at: http://gna.org/patch/?3759 ___ 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 #20752] Errors in nation rulesets cause spurious messages about lack of defined barbarians
Update of bug #20752 (project freeciv): Status: In Progress = Ready For Test ___ Additional Item Attachment: File name: trunk-nations-ruleset-barbarian-errors.patch Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?20752 ___ 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 #3859] Nations ruleset: move government compatibility checking to nationlist.ruleset
Additional Item Attachment, patch #3859 (project freeciv): File name: trunk-nations-allowed-govs-bis.patch Size:10 KB ___ Reply to this item at: http://gna.org/patch/?3859 ___ 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 #3860] Nations ruleset: allow terrain checking against explicit compatibility list
Update of patch #3860 (project freeciv): Status: In Progress = Ready For Test Depends on: = patch #3859 ___ Additional Item Attachment: File name: trunk-nations-allowed-terrains.patch Size:11 KB ___ Reply to this item at: http://gna.org/patch/?3860 ___ 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 #3861] Nations ruleset: replace warn_city_style with allowed_city_styles
Update of patch #3861 (project freeciv): Status: In Progress = Ready For Test Depends on: = patch #3860 ___ Additional Item Attachment: File name: trunk-nations-allowed-citystyles.patch Size:5 KB ___ Reply to this item at: http://gna.org/patch/?3861 ___ 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 #19841] Fundamentalism fails in classic ruleset
Follow-up Comment #8, bug #19841 (project freeciv): Would it be better to have a section in nationlist.ruleset explicitly listing all allowed govs in leader titles (and e.g. terrains) [...] I've implemented this in the patch series starting at patch #3859. ___ Reply to this item at: http://gna.org/bugs/?19841 ___ 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 #3708] Reinstate terrain checks for natural city names
Update of patch #3708 (project freeciv): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #1: Will be fixed in patch #3860. ___ Reply to this item at: http://gna.org/patch/?3708 ___ 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 #3860] Nations ruleset: allow terrain checking against explicit compatibility list
Follow-up Comment #2, patch #3860 (project freeciv): Rats, missed that. ___ Reply to this item at: http://gna.org/patch/?3860 ___ 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 #3839] Low hanging nativity fixes
Update of patch #3839 (project freeciv): Status:None = In Progress Assigned to:None = cazfi ___ Follow-up Comment #1: all fairly lightweight. My gut feeling disagrees here (= I want to investigate this more carefully instead of going fast forward). Value of this patch is in pointing out places that need to be changed, but I suspect that some of the cases are much more complex than straightforward changes presented. I may even end up splitting this to several tickets to investigate some of the cases in more detail. ___ Reply to this item at: http://gna.org/patch/?3839 ___ 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 #20747] Units in nested transport considered defensive units
Follow-up Comment #2, bug #20747 (project freeciv): From code inspection, it appears that the same patch could also be applied to S2_4 (I'll test when my current autogames are complete), and that it would provide a similar benefit. About combat.c: get_virtual_defense_power() uses can_unit_exist_at_tile as a proxy for being able to defend, but in this function we don't know the actual unit (and it may not even currently exist for calls from advmilitary.c), so can't check to see if it happens to be transported when under attack. The specific unit certainly doesn't exist in unittools.c:find_a_good_partisan_spot(), although these aren't likely to be placed in transport, so it matters less. can_unit_attack_all_at_tile() and can_unit_attack_any_at_tile() are potentially open to gameplay irregularities from players choosing when to load/unload unreachable units if unreachable protects/doesn't protect, and depending on the targets vectors of potential attackers. It would take a lot more than this type of check to work around that. It may be that can_unit_attack_unit_at_tile() should check to see if the potential defender is capable of defense, but I suspect it is better not to do this, as units that can't defend just die, which is likely the desired behaviour, rather than anything that might prevent the attack. Am I missing something else that might be related to this? ___ Reply to this item at: http://gna.org/bugs/?20747 ___ 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 #3839] Low hanging nativity fixes
Follow-up Comment #2, patch #3839 (project freeciv): Heh, perhaps my definition of lightweight was adjusted by the remainder of the nativity stuff :) I've no objection to splitting this into bits: it was assembled from bits as I tried to clean up nativity everywhere: these were the ones that were tiny patches, showed no behaviour changes in autogame testing, and didn't trigger me to add TODO items reminding me to investigate later. For base_assess_defense_unit(), I'm very certain of the semantics, and there are a few other places in the code that have had that change made (this one appears to have been missed). For assess_danger_unit(), there are no precedents that I found, but the behaviour is precisely the same for rulesets without UMT_LAND units granted CanAttackNonNative (and the change seems sensible). For assess_danger(), I'm less certain, and it may be worth performing autogame testing with rulesets specifically designed to hit this condition (presence of UMT_LAND units with !CanOccupy and UMT_SEA units with CanOccupy). For kill_something_with(), I was pleasantly surprised not to have differences in autogame testing: I was expecting this to fall into the more complicated category. Of everything collected here, I'm least confident in this change. For dai_rampage_want(), I'm pretty sure the current code won't work usefully even in the presence of Big Land from the experimental ruleset, ignoring more interesting nativity (e.g. Hut on Mountains). That said, I'm not absolutely sure my solution happens to be correct. For the SDL client fix, it's mostly a random swipe to remove it from grep results. That function should really be rewritten entirely to do things correctly, and if the nativity issue is a good reminder about that, there's no reason to patch it away. ___ Reply to this item at: http://gna.org/patch/?3839 ___ 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 #20747] Units in nested transport considered defensive units
Follow-up Comment #3, bug #20747 (project freeciv): The same patch applies to S2_4 with a 1-line offset, and should be suitable there as well. ___ Reply to this item at: http://gna.org/bugs/?20747 ___ 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 #20751] assertion 'normal_player_count() = game.server.max_players' failed
Follow-up Comment #2, bug #20751 (project freeciv): This game is a savegame of a recent revision of S2_4, maybe a couple of weeks ago... ___ Reply to this item at: http://gna.org/bugs/?20751 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
