[Freeciv-Dev] [patch #3815] Provide information about unit class nativity in terrain help
Follow-up Comment #11, patch #3815 (project freeciv): S2_4 version (file #17837) ___ Additional Item Attachment: File name: StaticOceanMoveHelp-S2_4.patch Size:2 KB ___ Reply to this item at: http://gna.org/patch/?3815 ___ 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 #3869] Place partisans based on nativity
Update of patch #3869 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3869 ___ 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 #17887] Tech prerequisites misdisplayed in help if root_req set
Follow-up Comment #3, bug #17887 (project freeciv): root_reqs were enabled in the experimental ruleset post-2.3 in patch #2381; I'm thus setting a release goal of 2.4.0 This is one of the remaining 2.4 blockers. While this is not codewise reggression (root_req has had these problems for a long time), the issues are reggression in shipping experimental ruleset. If no fix is coming soon, I suggest getting rid of 2.4 blocker status by reverting experimental ruleset not to use root_req in S2_4. Newer branches would be left intact and then this would be 2.5 blocker. ___ Reply to this item at: http://gna.org/bugs/?17887 ___ 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 #3719] Distributing cimpletoon .blend sources
Follow-up Comment #4, patch #3719 (project freeciv): Something I have seen done for other projects in the past is to distribute a separate tarball with large assets used to generate graphics, textures, sounds, etc. in the same distribution locations. This has the advantage of making it easily available to those who want it, but not forcing everyone to use it. The occasional practice in Debian of ensuring all sources are present as part of the distributed tarball comes from being extra careful about the preferred form for modification clause in the GPL. Only by building the distributed binaries from the modification sources can one be certain that the distributed object code can be reliably reproduced from the modification sources (and consequently that any recipient can easily/safely modify the result to match their tastes) using the Debian system (this also acts as a test of any dependent tools: for example, if blender were an essential part of the workflow, it would be extra annoying for Debian users if the blender included in a given release of Debian couldn't reprocess the graphics for some other package in that release). This definition of source is not hardened in Debian policy, so that if freeciv declares that although these materials may have been used as part of a generation process, that generation process was in part manual, and the (smaller) graphics actually used by the game are the preferred targets for modification, that would likely be honoured. That said, the same logic that drives this practice may apply in other environments. Anyway, looking at data/graphics, we don't seem to have any build system instructions that can produce the png files from the blend files, making me think that the blend files aren't actually source code, but rather materials used by the artists in the construction of the source code png files. Mind you, that's only my opinion, but were I handling the release, I'd probably only reference source control or *maybe* provide a tarball, but avoid calling the blend files source code as much as possible. Alternately, if they are already considered source code, there should be automake hints that allow one to regenerate the graphics files from the blend files, and then they should definitely be in the tarball. ___ Reply to this item at: http://gna.org/patch/?3719 ___ 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 #20721] Recursive logging
Update of bug #20721 (project freeciv): Category:None = general Status:None = Ready For Test Planned Release: = 2.4.0, 2.5.0 ___ Follow-up Comment #1: Attached patch replaces logging functions in convert_string() with fprintf(). I think S2_3 is safe from this problem as the logging mutex is not used there. (file #17840) ___ Additional Item Attachment: File name: RecursiveLog.patch Size:1 KB ___ Reply to this item at: http://gna.org/bugs/?20721 ___ 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] Freeciv 2.4.0 second beta source code released
I wrote: The second beta of Freeciv 2.4.0 is now available for download. Here are the translation stats: en_GB: 100%: 7115 translated. ca: 100%: 7115 translated. fr: 100%: 7115 translated. pl: 100%: 7115 translated. es: 99.2%: 7058 translated, 34 fuzzy, 23 untranslated. gd: 93%: 6601 translated, 331 fuzzy, 183 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: 79%: 5640 translated, 837 fuzzy, 638 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] S2_5 branching
We're just a couple of days from branching S2_5 02-May. My timezone is EEST (UTC +3), and I'm about start the branching activities as soon as clock hits 00:00 here. So for you in western Europe, let alone in Americas, it will be still 01-May. After the bracnhing we will have four active branches: S2_3, S2_4, S2_5 and TRUNK. That's more thna we'd like to divide our attention to, but at the same time we don't want to postpone branching further and letting even more new features to get in to trunk then to be polished in stable branch forever. Let's hope that time between S2_5 branching and 2.5.0 release is not longer than the road from S2_4 to 2.4.0 has been. I'll refresh all po-files under version control against latest strings before the branching. One of the new features in 2.6 is inclusion of Alien World ruleset ( http://www.cazfi.net/freeciv/alien/ ). Strings from the ruleset will be added to trunk translation as soon as S2_5 has been safely branched without the strings. I'll upload po-files with these strings to http://www.cazfi.net/freeciv/translations/S2_6/ within 24 hours from the branching. Next milestone for 2.5 after branching will be datafile format and network protocol freezes. We are not yet even planning the dates for these, but please make any tickets that must go in before the freezes as dependency of the relevant task-tickets, so once we start to plan the dates, we see what needs to be done. - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3885] base_assess_defense_unit() BadCityDefender handling
URL: http://gna.org/patch/?3885 Summary: base_assess_defense_unit() BadCityDefender handling Project: Freeciv Submitted by: cazfi Submitted on: Sun 28 Apr 2013 10:35:11 PM EEST Category: ai 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: Like in inspirational patch #3839, replace check for sea unit with BadCityDefender check. Also add halving of the defense power in case unit is BadCityDefender to match how attacker gets double firepower in get_modified_firepower(). ___ File Attachments: --- Date: Sun 28 Apr 2013 10:35:12 PM EEST Name: AssessDefenseBadCityDefense.patch Size: 622B By: cazfi http://gna.org/patch/download.php?file_id=17845 ___ Reply to this item at: http://gna.org/patch/?3885 ___ 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 #5, patch #3839 (project freeciv): base_assess_defense_unit() change now part of patch #3885 ___ 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] [patch #3876] Remove redundant tile_remove_base() call
Update of patch #3876 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3876 ___ 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 #3826] Allow bases on city tiles
Update of patch #3826 (project freeciv): Status:None = Ready For Test Assigned to:None = cazfi Planned Release: = 2.5.0, 2.6.0 ___ Reply to this item at: http://gna.org/patch/?3826 ___ 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 #20616] Oracle not exactly doubling effect of Temples
Update of bug #20616 (project freeciv): Status:None = Ready For Test Planned Release: = 2.4.0, 2.5.0, 2.6.0 ___ Follow-up Comment #1: Attached patch fixes this for civ1 civ2 rulesets. (file #17846) ___ Additional Item Attachment: File name: DoublingOracle.patch Size:3 KB ___ Reply to this item at: http://gna.org/bugs/?20616 ___ 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 #20588] Scorched spot etc not localised
Follow-up Comment #1, bug #20588 (project freeciv): Not submitting patch until the fix for bug #20543 is committed I take you meant the patch that was already submitted for bug #20543, and has now been committed. Bug is still not closed, but there's nothin submitted to clash with. ___ Reply to this item at: http://gna.org/bugs/?20588 ___ 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 #19542] Incorrect form of address in diplomatic dialog
Follow-up Comment #2, bug #19542 (project freeciv): Could we live with providing just two strings, one for each leader gender? ___ Reply to this item at: http://gna.org/bugs/?19542 ___ 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 #16383] Option to forbid RiverNative units moving diagonally / cross-continent
Update of bug #16383 (project freeciv): Status: In Progress = Ready For Test ___ Follow-up Comment #19: Untested patch (file #17847) ___ Additional Item Attachment: File name: CardinalRiverMoveRestrictions.patch Size:2 KB ___ Reply to this item at: http://gna.org/bugs/?16383 ___ 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 #16383] Option to forbid RiverNative units moving diagonally / cross-continent
Update of bug #16383 (project freeciv): Planned Release: 2.5.0 = 2.6.0 ___ Follow-up Comment #20: - Really prevent the move if no suitable road to travel found. It was falling to default MR_OK after checking the roads - Player notify text about the reason move failed As this might need heavy adjustments later for special cases like attacks, and this is more like new feature than extension to road/river type rework of 2.5, I'm not targeting this to 2.6 only. (file #17848) ___ Additional Item Attachment: File name: CardinalRiverMoveRestrictions-2.patch Size:3 KB ___ Reply to this item at: http://gna.org/bugs/?16383 ___ 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 #20722] [metaticket] S2_4 unit transport issues
Update of bug #20722 (project freeciv): Depends on: = bugs #20747 ___ Reply to this item at: http://gna.org/bugs/?20722 ___ 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 #19825] in dbv_isset() [bitvector.c::116]: assertion 'bit pdbv-bits' failed.
Update of bug #19825 (project freeciv): Status: Ready For Test = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?19825 ___ 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 #3885] base_assess_defense_unit() BadCityDefender handling
Follow-up Comment #1, patch #3885 (project freeciv): While this seems logically correct with the assumption that we are in a city, it doesn't work so well if pcity==NULL, and would represent a significant behaviour change under those circumstances. Previously, for defending without a city, using the classic ruleset, Battleship (16 before quadratic check) beats Mech Inf. (9 before quadratic check), and for defending with a city Mech Inf. (27 before quadratic check) beats Battleship (16 before quadratic check). With this proposed patch, Mech Inf. always beats Battleship (9 vs. 8 outside city and 27 vs. 8 inside city), which seems a bit strong. While this could be handled by wrapping the defense /= 2; line with a pcity check, I think the fact that the firepower multiplier is in the else clause is an attempt to handle the defender firepower reduction of BadCityDefender, with the result that the conditional should be extended to check if we're defending a city before applying the BadCityDefender penalties, granting the firepower bonus in other conditions. So, if we're willing to change behaviour anyway, we should probably grant traditional sea units a bonus if they aren't in the city, similar to how we penalise them for being in a city. The attached patch has the same behaviour as the prior patch for cities, and results in Battleship/Mech Inf. ratings outside a city of 32/9 by the same scale above (and, terrain aside, a battleship tends to be a better defender outside a city). The safety of this patch is extended in part by the need to revisit this function again to resolve the is_ground_unit() call: my prior attempts to do so have not resulted in good behaviour, which I've attributed to other issues with the AI using !is_ground_unit() units generally. (file #17849) ___ Additional Item Attachment: File name: badcitydefender-firepoweradjustments.patch Size:1 KB ___ Reply to this item at: http://gna.org/patch/?3885 ___ 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 #20045] assertion failed with civ2civ3 over S2_4
Follow-up Comment #17, bug #20045 (project freeciv): If allied transports are involved, this could be bug #20727 (transport moving out of sight, getting unloaded for removal from client end before cargo moves) ___ Reply to this item at: http://gna.org/bugs/?20045 ___ 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 #6, patch #3839 (project freeciv): Reduced patch, no longer including base_assess_defense_unit() or kill_something_with() (file #17850) ___ Additional Item Attachment: File name: low-hanging-nativity-fixes-reduced.patch Size:2 KB ___ 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 #20726] Units in allied transport already when treaty made not shown
Follow-up Comment #1, bug #20726 (project freeciv): I tested this with S2_3 too. It didn't give failing asserts, but the behavior was the same. So at least this is not a reggression since 2.3, and thus not necessarily 2.4.0 blocker. ___ Reply to this item at: http://gna.org/bugs/?20726 ___ 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 #16383] Option to forbid RiverNative units moving diagonally / cross-continent
Follow-up Comment #21, bug #16383 (project freeciv): %s cannot move road diagonally doesn't parse for me (seems to imply the road is being moved, rather than the unit). How about %s cannot move diagonally on available roads. It would be nice to know *which* road was cardinal or relaxed+disconnected for this notice, but that gets unpleasant to read in the presence of several cardinal or relaxed+disconnected roads the unit might have used. For reduction of text, could the tile_virtual_destroy() call be moved outside the if (!can_exist_at_tile()) conditional, or does it need to have been destroyed prior to the road iteration? In terms of program flow, it makes no difference aside from call ordering, but if we ever wanted to change things, it means more lines to edit to change the call. ___ Reply to this item at: http://gna.org/bugs/?16383 ___ 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] Here be dragons
I have a buggy, impractical, hard to use, untested, unfinished recorder for Freeciv games that makes it possible to replay a game to the Freeciv server. By connecting to the server where the game is being replayed on and join as an observer the record can be viewed. Being able to observe a game you played after it is over may help you become a better player. Showing off your skills may be fun. Demonstrating a strategy for beginners and AI's that learn by watching may also be interesting. It may also have potential as a real paranoid debugging tool by testing that each packet is the same when nothing is supposed to have changed (not implemented yet). This is so untested that I haven't recorded an entire Freeciv game in it. I have only compiled it and tried it on Debian Wheezy/AMD64. I don't know if it even will build on Windows or OS X. I don't know if I got the documentation I just wrote right. But I suspect that unless I publish this now I'll again be distracted by some minor area of it. On the other hand I don't want the current bad state to scare away people that later, when the probability of things working is higher, could have become valuable testers. I therefore need some advice from people that know the Freeciv community better than me: * should I post this to the forum as well as here or will a post there attract those that are scared away for good? * will distributing a source bundle addition to the URL to my Bazaar repository attract the kind of people that gets scared away when they can't make it work? Some additional warnings: It need to start from a Freeciv save of a started game. Only one human player is well supported. (Well supported relative to the rest. I have, as I said, never played a full game using it) It requires using Freeciv trunk. It suffer from threading issues. While I worked on it I sometimes panic coded, then got stuck in panic code, started to plan grand abstractions that I half way implemented, started panic coding again while forgetting the half done abstractions, etc. In other words the code is over and under engineered at the same time. Basing something on it as it is now probably isn't a good idea. The code can be downloaded via Bazaar by the command bzr branch http://folk.ntnu.no/kvilhaug/bazaar/FreecivRecorder/ If you try it I would appreciate bug reports. If it actually works I would also like to hear about it. -- Sincerely Sveinung Kvilhaugsvik ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
