[Freeciv-Dev] [patch #3692] Reduce SHIELD_WEIGHTING
Update of patch #3692 (project freeciv): Status: In Progress = Ready For Test ___ Follow-up Comment #4: Here is the patch I've been using a couple of months now. I've tested mainly with the modified ruleset I use for any serious freeciv games I play, but at least in brief autogame testing also default settings + classic ruleset seems to be slightly benefit. There's slim hope to get that part kludged (while we wait for more extensive rewrite to future versions) by increasing TRADE_WEIGHTING so that Plains gets roads (1/1/0 - 1/1/1) rather than is turned to Forest (1/1/0 - 1/2/0). This seems to work to some extend at least. Often Plains (1/1/0) get roads (1/1/1) and are then irrigated (2/1/1). (file #17756) ___ Additional Item Attachment: File name: AIPriorities.patch Size:0 KB ___ 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 #20690] maxplayers setting does not prevent midgame player /create
Update of bug #20690 (project freeciv): Status: Ready For Test = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20690 ___ 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 #19474] max_players cleanup
Update of bug #19474 (project freeciv): Category:None = general Status:None = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?19474 ___ 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 #20714] Turn done button not sensitive after failed capability check with another server
Update of bug #20714 (project freeciv): Category:None = general Planned Release: = 2.5.0, 2.6.0 ___ Follow-up Comment #1: I assume this to be because of recent changes to make packet types in initial protocol 8bit while they are usually 16bit. There seems to be some other problems as well, hinting that it's just coinsidence that Turn done button is affected - more likely network stream reading is just out-of-sync. ___ Reply to this item at: http://gna.org/bugs/?20714 ___ 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 #20542] in unit_virtual_destroy() [unit.c::1881]: assertion '!unit_transported(punit)' failed
Update of bug #20542 (project freeciv): Status:None = Ready For Test ___ Follow-up Comment #5: I think that it is necessary to explicitly clear transported_by after unit_transport_unload() in player_clear() Attached patch does that. (file #17759) ___ Additional Item Attachment: File name: UntransportClient.patchSize:0 KB ___ 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] UTYF_BOMBARDER and nativity (was: patch #3830)
Jacob Nevins wrote: (Since I wasn't sure: this is referring to normal attack that the comments call bombardment, not the technical meaning of bombard that UTYF_BOMBARDER units do. That has its own hardcoded restrictions on terrain type, but fixing that should be the subject of a separate ticket.) Regarding those: is there any documentation of the rationale for the UTYF_BOMBARDER restrictions? I've looked at them a few times, but don't have a clear idea of the intention behind the various restrictions. At least in some places, the comments and code don't seem to match at all (e.g. the error about being transported when testing is_ocean_tile() in unithand.c:unit_move_handling()). The particular restriction that confuses me the most is that one cannot bombard while in transport (from unit.c:can_unit_bombard()), even if the tile is native, so that a player could disembark the unit, bombard, and reembark the unit (thereby increasing pointless micromanagement). Looking at some of the rulesets that use bombarder, one interesting use I found was having bombers and helicopters as bombarders, which fought normally against units at sea (kill and be killed), but only weakened units on land (from LTex28B), although the behaviour in this ruleset of a bomber attacking a helicopter changes based on the terrain beneath the helicopter: perhaps this is not yet a complete idea. One thought I had was to remove all hardcoded terrain and transport restrictions, allow bombard if can_exist_at_tile() when the target has UCF_CAN_FORTIFY and otherwise perform a normal attack, but I don't know if there are uses of bombarders that would be broken with such a solution, or if regardless of current uses, there is an interest in making it even more general (e.g. using another vector to determine targets or similar). -- Emmet HIKORY ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] UTYF_BOMBARDER and nativity (was: patch #3830)
Short answer: It was probably implemented with some specific unit in mind to begin with, getting some of the details right more by coincidence than correct design, and it has been subject to some bitrot. On 18 April 2013 23:42, Emmet Hikory per...@shipstone.jp wrote: Jacob Nevins wrote: (Since I wasn't sure: this is referring to normal attack that the comments call bombardment, not the technical meaning of bombard that UTYF_BOMBARDER units do. That has its own hardcoded restrictions on terrain type, but fixing that should be the subject of a separate ticket.) Regarding those: is there any documentation of the rationale for the UTYF_BOMBARDER restrictions? I've looked at them a few times, but don't have a clear idea of the intention behind the various restrictions. At least in some places, the comments and code don't seem to match at all (e.g. the error about being transported when testing is_ocean_tile() in unithand.c:unit_move_handling()). The particular restriction that confuses me the most is that one cannot bombard while in transport (from unit.c:can_unit_bombard()), even if the tile is native, so that a player could disembark the unit, bombard, and reembark the unit (thereby increasing pointless micromanagement). Over the years I've fixed similar checks from many places from the code. At least in most cases it has been idiom for what now should be cannot act while transported on non-native terrain - that was the same thing when sea units were the only ones capable of transporting other units + they were capable of carrying only land units. One thought I had was to remove all hardcoded terrain and transport restrictions, allow bombard if can_exist_at_tile() when the target has UCF_CAN_FORTIFY and otherwise perform a normal attack, but I don't know if there are uses of bombarders that would be broken with such a solution, or if regardless of current uses, there is an interest in making it even more general (e.g. using another vector to determine targets or similar). In general that sounds like a right direction to go. Just don't reuse CanFortify for something unrelated (as far as I can see). - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] UTYF_BOMBARDER and nativity (was: patch #3830)
Marko Lindqvist wrote: Short answer: It was probably implemented with some specific unit in mind to begin with, getting some of the details right more by coincidence than correct design, and it has been subject to some bitrot. Heh. That makes it easier :) On 18 April 2013 23:42, Emmet Hikory wrote: One thought I had was to remove all hardcoded terrain and transport restrictions, allow bombard if can_exist_at_tile() when the target has UCF_CAN_FORTIFY and otherwise perform a normal attack, but I don't know if there are uses of bombarders that would be broken with such a solution, or if regardless of current uses, there is an interest in making it even more general (e.g. using another vector to determine targets or similar). In general that sounds like a right direction to go. Just don't reuse CanFortify for something unrelated (as far as I can see). I was thinking that the ability to fortify was semantically similar to the ability to avoid being killed by a bombardier: the unit in question would be able to hunker down using available cover to protect themselves (whereas a unit unable to fortify presumably cannot use available cover, so cannot protect themselves from the bombardier). That said, I'll implement it with a different flag: do you think it should be UTYF, UCF, or UCF+UTYF exception? -- Emmet HIKORY ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3851] Remove extra files from gui-gtk-3.0 theme directory
URL: http://gna.org/patch/?3851 Summary: Remove extra files from gui-gtk-3.0 theme directory Project: Freeciv Submitted by: cazfi Submitted on: Fri 19 Apr 2013 01:15:01 AM EEST Category: client-gtk-3.0 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 ___ Details: Following files in data/themes/gui-gtk-3.0/Freeciv/gtk-3.0 are leftovers from the time everything was copied from gtk2-client theme, and should be removed from under version control (they are not part of distribution tarballs): gtkrc menubar.rc panel.rc ___ Reply to this item at: http://gna.org/patch/?3851 ___ 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 #3313] Nets to experimental ruleset
Update of patch #3313 (project freeciv): Status: Ready For Test = In Progress Planned Release: 2.5.0 = ___ Reply to this item at: http://gna.org/patch/?3313 ___ 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 #3852] Lua 5.2.2
URL: http://gna.org/patch/?3852 Summary: Lua 5.2.2 Project: Freeciv Submitted by: cazfi Submitted on: Fri 19 Apr 2013 02:09:55 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: Update included lua to version 5.2.2. Store freeciv specific source changes also as patch to help future updates. ___ File Attachments: --- Date: Fri 19 Apr 2013 02:09:55 AM EEST Name: Lua522.patch.bz2 Size: 17kB By: cazfi http://gna.org/patch/download.php?file_id=17761 ___ Reply to this item at: http://gna.org/patch/?3852 ___ 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 #3829] Allow compatible roads
Follow-up Comment #4, patch #3829 (project freeciv): Err, rather, the code is just confusing: suggestions for comments to avoid confusing future readers welcome. Rulesets add compatible roads to the integrates vector. load_ruleset_terrain(): Adds road being loaded to the (server-side) integrators list Adds any road in the integrates INI vector to the (server-side) integrators list Sets a bitvector to match the INI vector for integrates packets.def: sends the integrates bitvector handle_rulesets_ready(): Adds road being processed to the (client-side) integrators list Adds any roads in the integrates bitvector to the (client-side) integrators list tile_move_cost_ptrs(): Iterates over the integrators list when checking roads. So, for both client and server, every road always integrates with itself, regardless of the notation in the ruleset. Further, the identical road is always first in the integrators list, so that continuation on the same road is checked first when calculating move cost (which is expected to be the most common case, and for fast roads, the lowest cost (important as movement over fast roads requires the greatest number of calls to tile_move_cost_ptrs). Therefore, the originally submitted patch should be fine to process (unless something else is discovered in testing). That said, perhaps integrates and integrators need greater differentiation to reduce confusion, or, as noted above, perhaps the code needs more comments. ___ Reply to this item at: http://gna.org/patch/?3829 ___ 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 #3829] Allow compatible roads
Follow-up Comment #5, patch #3829 (project freeciv): am I blind Yes, I am. I assumed it to work that way, yet I somehow missed the line where it did it. regardless of the notation in the ruleset. Oh, but if ruleset *does* have road type itself (redundantly) listed, it will be added twice to the list, no? Or generally: any road can be added multiple times to the server side list. This should be easy to check from the bitvector side. If the bit is already set, do not add road again. ___ Reply to this item at: http://gna.org/patch/?3829 ___ 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 #3829] Allow compatible roads
Follow-up Comment #6, patch #3829 (project freeciv): Further, the identical road is always first in the integrators list, so that continuation on the same road is checked first when calculating move cost (which is expected to be the most common case, and for fast roads, the lowest cost For shaving cycles it actually might make sense to order roads in the list from lowest cost to highest. tile_move_cost_ptrs() could rely on that order to break iteration as soon as it finds first integrating road. ___ Reply to this item at: http://gna.org/patch/?3829 ___ 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 #3829] Allow compatible roads
Follow-up Comment #7, patch #3829 (project freeciv): Ah, good point. Perhaps rather than adding roads to the integrators list at parse time, it ought just set the bitvector (redundantly setting it causes no issue, and checking that it is set likely usually wastes cycles). Once the iterates bitvector is set, a list can be constructed from it, sorted by cost (lowest to highest), and stored as integrators. Having a separate chunk of code specifically setting integrators should also make the entirety more readable, so that this confusion doesn't arise again (as both of us read it as wrong last week, the current code is clearly suboptimal). I don't think it is safe to terminate the tile_move_cost_ptrs() loop once a road is found, because we can't know that it hasn't hit the RMM_RELAXED condition, but the cost of iterating through the remainder should be low, because we check (cost iroad-move_cost) early enough that the remainder of the iteration should go quickly. ___ Reply to this item at: http://gna.org/patch/?3829 ___ 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
Follow-up Comment #4, patch #3826 (project freeciv): The attached patch should address all comments, and applies against trunk. Thanks for pointing out how roads/bases are removed when terrain is changed. For some reason, in the initial testing, I wasn't successful in restricting bases in cities from the ruleset without passing the city, but it seems to work now, and I cannot remember the specific failing test. (file #17762) ___ Additional Item Attachment: File name: allow-bases-in-cities+comment-fixes.patch Size:36 KB ___ 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] [patch #3830] Change shore bombardment model to use nativity rather than UMT_*
Follow-up Comment #3, patch #3830 (project freeciv): Updated patch attached restoring original behaviour. The sea unit in harbor case gets adjusted anyway because of BadCityDefender (but, yes, this shouldn't be conflated). The ground unit defending against air unit case made fp=2 ground units weaker at anti-air when attacked from sea, which convinces me not to argue the situation (as it doesn't make sense to have different anti-air capabilities depending on the position of the air unit). That said, I'm not sure I understand the specific meaning of this check in a nativity-based environment if it doesn't mean that units have a hard time attacking/defending when they are not native to the target tile. (file #17763) ___ Additional Item Attachment: File name: native-bombardment+restricted.patch Size:0 KB ___ Reply to this item at: http://gna.org/patch/?3830 ___ 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 #3804] Enabling restricted air transport
Follow-up Comment #23, patch #3804 (project freeciv): Updated functional patches to use try_to_save_unit() instead of unit_can_be_saved(). Once applied, this ticket should be closed, without the unit patch. (file #17765, file #17766) ___ Additional Item Attachment: File name: refactor-wipe-unit+rename.patch Size:8 KB File name: enable-air-transport+rename.patch Size:16 KB ___ Reply to this item at: http://gna.org/patch/?3804 ___ 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 #3837] Unify UCF_ATT*NON_NATIVE and relevant type flags
Follow-up Comment #5, patch #3837 (project freeciv): Patch attached for S2_3. The pf_tools functions are not adjusted, as the nature of the flags in question don't have much meaning for UMT_LAND units (which restriction is imposed by pft_fill_parameter()). For S2_4, I'm much less certain of the correct solution. It seems to be possible to build a Big Land unit on non-native terrain (e.g. forest/river), which unit then cannot move until the Bridge Building technology is known (at which point the city gets a road, which makes it native, so that the check is irrelevant). In the absence of UCF_ATT_FROM_NON_NATIVE, I'm unsure of the correct logic to use for the pf_tools checks to allow an e.g. Catapult to attack an adjacent square when there is yet no road available in the city to make the tile native, even if the adjacent square is native to Catapults. Suggestions welcome. (file #17767) ___ Additional Item Attachment: File name: S2_3-use-can_attack-foo-functions-more.patch Size:2 KB ___ Reply to this item at: http://gna.org/patch/?3837 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
