[Freeciv-Dev] [patch #3997] Remove requirement types Special, Base, and Road
Update of patch #3997 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3997 ___ 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 #20976] Missing road editing functionality
URL: http://gna.org/bugs/?20976 Summary: Missing road editing functionality Project: Freeciv Submitted by: cazfi Submitted on: Wed 17 Jul 2013 10:18:30 AM EEST Category: editor Severity: 3 - Normal Priority: 5 - Normal Status: Ready For Test Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: 2.5.0, 2.6.0 ___ Details: I noticed several places in editor code where roads had no equivalent code to bases. I've not tried to figure out all the bugs this is causing, but here is one that I tested as an example: If tile already has road when you middle click it to edit it in the properties dialog, and you then edit some other properties of the tile, existing road disappears once you apply your changes. That's because bit for original road was never set in edit packet. Fix attached ___ File Attachments: --- Date: Wed 17 Jul 2013 10:18:30 AM EEST Name: RoadEditor.patch Size: 3kB By: cazfi http://gna.org/bugs/download.php?file_id=18308 ___ Reply to this item at: http://gna.org/bugs/?20976 ___ 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 #20977] Ferry stats changed when virtual unit closed
URL: http://gna.org/bugs/?20977 Summary: Ferry stats changed when virtual unit closed Project: Freeciv Submitted by: cazfi Submitted on: Wed 17 Jul 2013 11:56:38 AM EEST Category: ai Severity: 3 - Normal Priority: 5 - Normal Status: Ready For Test Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: 2.5.0, 2.6.0 ___ Details: Ferry stats are changed even if unit being closed is virtual unit. Upon unit creation stats are changed only for real units. Fix attached. ___ File Attachments: --- Date: Wed 17 Jul 2013 11:56:38 AM EEST Name: VirtualFerryClose.patch Size: 654B By: cazfi http://gna.org/bugs/download.php?file_id=18309 ___ Reply to this item at: http://gna.org/bugs/?20977 ___ 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 #4011] Lua: edit.change_terrain and edit.place_resource
URL: http://gna.org/patch/?4011 Summary: Lua: edit.change_terrain and edit.place_resource Project: Freeciv Submitted by: gorb Submitted on: Wed 17 Jul 2013 10:46:27 AM GMT Category: general Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: Add two new lua functions in module edit: edit.change_terrain, change terrain edit.place_resource I've tested with: function map_labels() local terrain = find.tile(170,230) edit.change_terrain(terrain, 'Mountains') local terrain = find.tile(170,230) edit.place_resource(terrain, 'Gold') end function turn_cb(turn, year) if turn == 0 then map_labels() end end Works, the result is a transformation from deep ocean to mountain, with a resource (gold), but there are messages. Only change function: in begin_turn() [srv_main.c::881]: assertion 'cont 0' failed. ( 170, 230) at Mountains in begin_phase() [srv_main.c::948]: assertion 'cont 0' failed. ( 170, 230) at Mountains Both functions (change and place): in begin_phase() [srv_main.c::948]: assertion 'cont 0' failed. ( 170, 230) at Mountains ___ File Attachments: --- Date: Wed 17 Jul 2013 10:46:27 AM GMT Name: change_terrain_and_place_resource.diff Size: 3kB By: gorb http://gna.org/patch/download.php?file_id=18310 ___ Reply to this item at: http://gna.org/patch/?4011 ___ 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 #20978] Ferry set to ABANDON_BOSS when it's in fact available
URL: http://gna.org/bugs/?20978 Summary: Ferry set to ABANDON_BOSS when it's in fact available Project: Freeciv Submitted by: cazfi Submitted on: Wed 17 Jul 2013 01:56:58 PM EEST Category: ai Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: ___ Details: dai_manage_ferryboat() may end up setting ferry passenger status to ABANDON_BOSS when boss has left the ferry ok and it has (correctly) AVAILABLE status. It first manages the boss, and then does the check if boss is on board on assumption that boss is still to board. If boss is not yet in, and there's other units waiting in, it decides to abandon the boss by setting passanger (presumably from old boss id) to ABANDON_BOSS. This ignores the case where boss has actually already finished with the boat, and freed it, while boss was managed. At the very least this causes ferry stats to be miscounted. I don't know if this can explain why AI ends building such huge numbers of unused ferries - maybe it ends considering all existing ferries being allocated because of this bug. ___ Reply to this item at: http://gna.org/bugs/?20978 ___ 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 #20978] Ferry set to ABANDON_BOSS when it's in fact available
Update of bug #20978 (project freeciv): Status:None = In Progress ___ Follow-up Comment #1: Patch for TRUNK S2_5 attached. In addition to not taking control away from old boss if he no longer has it to begin with, restore control to old boss in those cases where new boss cannot be found. This latter change is the more important one. Before it was possible that ABANDON_BOSS status was left to ferry which then was never able to get rid of it (as it was neither completely available nor assigned for specific unit) (file #18311) ___ Additional Item Attachment: File name: FerryAbandonAvailable.patchSize:2 KB ___ Reply to this item at: http://gna.org/bugs/?20978 ___ 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 #4012] FERRY_ABANDON_BOSS to value -2
URL: http://gna.org/patch/?4012 Summary: FERRY_ABANDON_BOSS to value -2 Project: Freeciv Submitted by: cazfi Submitted on: Wed 17 Jul 2013 02:38:57 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: Set FERRY_ABANDON_BOSS to value (-2) to ease debugging. Old value 0 could also mean (erronously assigned) virtual unit id. ___ File Attachments: --- Date: Wed 17 Jul 2013 02:38:57 PM EEST Name: AbandonMinus2.patch Size: 690B By: cazfi http://gna.org/patch/download.php?file_id=18312 ___ Reply to this item at: http://gna.org/patch/?4012 ___ 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 #20886] Fortresses can be used to take over territory within peaceful neighbour's city radius
Follow-up Comment #5, bug #20886 (project freeciv): how do you prevent (without killing the builder) peaceful player from building the base Even allied countries do not *completely* trust the military units of others. This is typically handled with a SOFA [Status Of Forces Agreement] treaty, that spells out what activities are allowed and specifies penalties for violations. Then again, maybe building the fortress should be always allowed, but the change is made to who owns the fortress in the end. I think this is a better solution. ___ Reply to this item at: http://gna.org/bugs/?20886 ___ 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 #4013] No tech want for obsolete unit
URL: http://gna.org/patch/?4013 Summary: No tech want for obsolete unit Project: Freeciv Submitted by: cazfi Submitted on: Wed 17 Jul 2013 08:00:03 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: Currently process_attacker_want() considers unit if it it's not obsolete OR its tech requirement is not yet known. In the latter case calculated want is used only for boosting want for tech allowing the unit. There's no point in researching tech for unit that would be immediately obsolete. Attached patch makes process_attacker_want() not to consider obsolete units even in this case. ___ File Attachments: --- Date: Wed 17 Jul 2013 08:00:03 PM EEST Name: ObsUnitNoTechBoost.patch Size: 862B By: cazfi http://gna.org/patch/download.php?file_id=18316 ___ Reply to this item at: http://gna.org/patch/?4013 ___ 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 #4014] process_attacker_want() veterancy handling
URL: http://gna.org/patch/?4014 Summary: process_attacker_want() veterancy handling Project: Freeciv Submitted by: cazfi Submitted on: Wed 17 Jul 2013 08:23:45 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: process_attacker_want() gets veterancy of the unit considered to be built as boolean (though stored in int variable) based on if the city has building providing EFT_VETERAN_BUILD effect for the unit. This boolean values is then passed on as veterancy level. Attached patch makes it to use real EFT_VETERAN_BUILD effect value. This is more correct in several ways: - Effect value can be other than 1, including multiple effects cancelling each other to result of 0 - Effect can be provided by something else than building in the city (even in supplied rulesets some wonders can provide it while positioned in *another* city) ___ File Attachments: --- Date: Wed 17 Jul 2013 08:23:45 PM EEST Name: ProcessAttackerVeterancy.patch Size: 2kB By: cazfi http://gna.org/patch/download.php?file_id=18317 ___ Reply to this item at: http://gna.org/patch/?4014 ___ 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 #4007] Qt- map_canvas_repaint
Update of patch #4007 (project freeciv): Status: Ready For Test = Done Assigned to:None = mir3x Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4007 ___ 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 #4015] Occupying unit value
URL: http://gna.org/patch/?4015 Summary: Occupying unit value Project: Freeciv Submitted by: cazfi Submitted on: Wed 17 Jul 2013 09:33:43 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: ___ Details: Attacker unit capable of occupying a city has value based solely on its own price. - Unit that could also kill defenders, and value for that would be calculated higher than city occupying value, still get the lower value. From the logging from my test games that actually happens a lot - resulting in that those units that *cannot* occupy and thus get assigned the defender killing value are preferred over units capable of occupying - Target city does not affect the value of occupying Attached patch for TRUNK S2_5 fixes both parts. Occupying unit value is based on city value, and final value is higher of the occupying and defender killing values. To get effectively worth of any enemy city (including those running another ai type) new functions added to ai callback interface and building advisor code is adjusted. These changes are too intrusive for S2_4, but I'm about to make S2_4 version that takes care of the case where defender killing value should be used instead of low (in S2_4) occupying value. ___ File Attachments: --- Date: Wed 17 Jul 2013 09:33:43 PM EEST Name: OccupierValue.patch Size: 8kB By: cazfi http://gna.org/patch/download.php?file_id=18318 ___ Reply to this item at: http://gna.org/patch/?4015 ___ 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 #4016] Qt::global code style fixup
URL: http://gna.org/patch/?4016 Summary: Qt::global code style fixup Project: Freeciv Submitted by: mir3x Submitted on: Wed 17 Jul 2013 08:43:30 PM CEST Category: client-qt Priority: 3 - Low 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: Fixed some code style in all files: mostly: -brackets and xxx_itereate_end macro -empty lines after variables -moved variables to the beggining of block ___ File Attachments: --- Date: Wed 17 Jul 2013 08:43:30 PM CEST Name: Qt-global-codestyle-fixup-S25.patch.bz2 Size: 14B By: mir3x http://gna.org/patch/download.php?file_id=18319 --- Date: Wed 17 Jul 2013 08:43:30 PM CEST Name: Qt-global-codestyle-fixup-S26.patch.bz2 Size: 16kB By: mir3x http://gna.org/patch/download.php?file_id=18320 ___ Reply to this item at: http://gna.org/patch/?4016 ___ 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 #4015] Occupying unit value
Update of patch #4015 (project freeciv): Planned Release: = 2.4.0, 2.5.0, 2.6.0 ___ Follow-up Comment #1: S2_4 version. Assuming this makes it to 2.4.0, but postponing to 2.4.1 is not a problem if required. (file #18321) ___ Additional Item Attachment: File name: OccupierValue-S2_4.patch Size:1 KB ___ Reply to this item at: http://gna.org/patch/?4015 ___ 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 #20980] Apollo Program won't update city nation upon change
URL: http://gna.org/bugs/?20980 Summary: Apollo Program won't update city nation upon change Project: Freeciv Submitted by: dynv Submitted on: Wed 17 Jul 2013 08:19:44 PM GMT Category: client Severity: 2 - Minor Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: 2.3.4, gui-gtk-2.0 Discussion Lock: Any Operating System: Microsoft Windows Planned Release: ___ Details: Apollo Program won't update city nation upon change, neither its banner nor the contextual menu (on line starting with City:). Although there's a workaround since the border color change ; and one doesn't even need to meet the nation to know the new color, the Nations tab show its owner (in Border column/field). ___ Reply to this item at: http://gna.org/bugs/?20980 ___ 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 #20971] Martial_Law_Max has no effect
Update of bug #20971 (project freeciv): Status: Ready For Test = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20971 ___ 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 #20981] Bug
URL: http://gna.org/bugs/?20981 Summary: Bug Project: Freeciv Submitted by: noob Submitted on: Wed 17 Jul 2013 08:41:45 PM GMT Category: None Severity: 4 - Important Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: Microsoft Windows Planned Release: ___ Details: ___ File Attachments: --- Date: Wed 17 Jul 2013 08:41:45 PM GMT Name: dd.sav.bz2 Size: 24kB By: noob http://gna.org/bugs/download.php?file_id=18322 ___ Reply to this item at: http://gna.org/bugs/?20981 ___ 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 #20981] Savegame: error restoring 'generator' . (You cannot disable the map generator.)
Update of bug #20981 (project freeciv): Summary: Bug = Savegame: error restoring 'generator' . (You cannot disable the map generator.) ___ Follow-up Comment #1: See http://forum.freeciv.org/f/viewtopic.php?f=8t=101 for details of the symptom. ___ Reply to this item at: http://gna.org/bugs/?20981 ___ 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 #4002] Use base_extra_get() road_extra_get()
Update of patch #4002 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4002 ___ 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 #4005] Extras vector
Follow-up Comment #2, patch #4005 (project freeciv): - Updated against svn (file #18323) ___ Additional Item Attachment: File name: ExtrasVector-3.patch.bz2 Size:16 KB ___ Reply to this item at: http://gna.org/patch/?4005 ___ 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 #4016] Qt::global code style fixup
Follow-up Comment #1, patch #4016 (project freeciv): For such patch touching a bit every place in Qt-client we need to synchronize a bit to avoid patch conflicts. I just committed patch #4002 that touched Qt-client code. I also just updated patch #4005 that will touch Qt-client, but decided not to make it to apply on top of this one - either one needs to be changed to apply on top of the other. I'd like #4005 to go in first, as it's so important step in extras implementation on top of which to build further development. It's also huge patch that would easily suffer bitrot from almost any part of the code, not just Qt-client. Any further patches I'd make so that they apply on top of this one. ___ Reply to this item at: http://gna.org/patch/?4016 ___ 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] Tentative S2_4 string freeze for 2.4.0-RC1
It's time to get 2.4.0 moving. We think the next build will be a release candidate rather than another beta. http://www.freeciv.org/wiki/NEWS-2.4.0-RC1 has the current change list. I'm declaring a tentative string freeze in preparation for that, and calling for translation updates. Tentative only because we haven't yet been through the list of pending bugs and patches, so it's possible that there's something worth breaking a freeze for; but probably there won't be. If any string changes are committed, I'll post to -i18n. It's possible the release will be made in just under a week's time, although more likely that it'll be at least two weeks. For translators, the files at http://www.cazfi.net/freeciv/translations/S2_4/ are up-to-date with the latest strings. Here are the current translation stats for the head of S2_4 (r23064): en_GB: 100%: 7117 translated. pl: 100%: 7117 translated. fr: 99.9%: 7115 translated, 2 fuzzy. ca: 99.9%: 7113 translated, 3 fuzzy, 1 untranslated. es: 99.1%: 7056 translated, 37 fuzzy, 24 untranslated. gd: 93%: 6599 translated, 334 fuzzy, 184 untranslated. ja: 85%: 6025 translated, 683 fuzzy, 409 untranslated. fi: 84%: 5955 translated, 641 fuzzy, 521 untranslated. da: 80%: 5712 translated, 880 fuzzy, 525 untranslated. de: 79%: 5638 translated, 840 fuzzy, 639 untranslated. uk: 69%: 4929 translated, 1160 fuzzy, 1028 untranslated. nl: 68%: 4852 translated, 1338 fuzzy, 927 untranslated. it: 62%: translated, 1728 fuzzy, 945 untranslated. pt_BR: 59%: 4206 translated, 1968 fuzzy, 943 untranslated. ru: 58%: 4143 translated, 1932 fuzzy, 1042 untranslated. ga: 54%: 3875 translated, 31 fuzzy, 3211 untranslated. id: 52%: 3680 translated, 127 fuzzy, 3310 untranslated. sv: 51%: 3604 translated, 1979 fuzzy, 1534 untranslated. tr: 40%: 2878 translated, 2480 fuzzy, 1759 untranslated. et: 40%: 2849 translated, 2603 fuzzy, 1665 untranslated. zh_TW: 40%: 2838 translated, 12 fuzzy, 4267 untranslated. cs: 40%: 2820 translated, 2702 fuzzy, 1595 untranslated. eo: 39%: 2741 translated, 2033 fuzzy, 2343 untranslated. lt: 37%: 2654 translated, 2180 fuzzy, 2283 untranslated. ro: 35%: 2475 translated, 2746 fuzzy, 1896 untranslated. zh_CN: 34%: 2437 translated, 2864 fuzzy, 1816 untranslated. ar: 34%: 2387 translated, 3124 fuzzy, 1606 untranslated. no: 33%: 2381 translated, 3002 fuzzy, 1734 untranslated. nb: 33%: 2381 translated, 3002 fuzzy, 1734 untranslated. ko: 29%: 2062 translated, 1923 fuzzy, 3132 untranslated. sr: 29%: 2049 translated, 1522 fuzzy, 3546 untranslated. el: 28%: 2008 translated, 2356 fuzzy, 2753 untranslated. bg: 27%: 1935 translated, 284 fuzzy, 4898 untranslated. hu: 26%: 1851 translated, 3232 fuzzy, 2034 untranslated. pt: 24%: 1679 translated, 3252 fuzzy, 2186 untranslated. fa: 23%: 1644 translated, 2134 fuzzy, 3339 untranslated. he: 23%: 1640 translated, 1904 fuzzy, 3573 untranslated. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4017] Victory conditions setting
URL: http://gna.org/patch/?4017 Summary: Victory conditions setting Project: Freeciv Submitted by: cazfi Submitted on: Thu 18 Jul 2013 02:30:49 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: Convert boolean spacerace setting in to bitwise victories (victory conditions) setting. Initially the new setting has just the one bit, spacerace. ___ File Attachments: --- Date: Thu 18 Jul 2013 02:30:49 AM EEST Name: VictoryConditions.patch Size: 19kB By: cazfi http://gna.org/patch/download.php?file_id=18328 ___ Reply to this item at: http://gna.org/patch/?4017 ___ 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 #4018] Allied victory controlled by victory conditions setting
URL: http://gna.org/patch/?4018 Summary: Allied victory controlled by victory conditions setting Project: Freeciv Submitted by: cazfi Submitted on: Thu 18 Jul 2013 03:48:14 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: Replace old boolean alliedvictory setting with bit in bitwise vicrory conditions setting. ___ File Attachments: --- Date: Thu 18 Jul 2013 03:48:14 AM EEST Name: AlliedCondition.patch Size: 9kB By: cazfi http://gna.org/patch/download.php?file_id=18329 ___ Reply to this item at: http://gna.org/patch/?4018 ___ 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 #4019] Culture
URL: http://gna.org/patch/?4019 Summary: Culture Project: Freeciv Submitted by: cazfi Submitted on: Thu 18 Jul 2013 04:31:47 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: Add concept of culture. In this initial version it's same as value of effect Performance for each city. It affects only player score (50 points of culture is worth one point in total score) ___ File Attachments: --- Date: Thu 18 Jul 2013 04:31:47 AM EEST Name: Culture.patch Size: 7kB By: cazfi http://gna.org/patch/download.php?file_id=18330 ___ Reply to this item at: http://gna.org/patch/?4019 ___ 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 #20980] Apollo Program won't update city nation upon change
Follow-up Comment #1, bug #20980 (project freeciv): The next turn the cities updated their nation. Although I'm wondering if it had to do with the fact that I made contact with one (the same turn as the change); if the contact fixed the problem, it would partly remain a problem. Now I'm wondering if the Apollo Program is supposed to take 2/5/... years to make its survey. If it's supposed to be shorter, the update should be instantaneous, no? ___ Reply to this item at: http://gna.org/bugs/?20980 ___ 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 #4020] History
URL: http://gna.org/patch/?4020 Summary: History Project: Freeciv Submitted by: cazfi Submitted on: Thu 18 Jul 2013 04:58:23 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: Add cumulative history type culture. Cities history increases by EFT_HISTORY value each turn. Total culture is sum of history and performance. ___ File Attachments: --- Date: Thu 18 Jul 2013 04:58:23 AM EEST Name: History.patch Size: 6kB By: cazfi http://gna.org/patch/download.php?file_id=18331 ___ Reply to this item at: http://gna.org/patch/?4020 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
