[Freeciv-Dev] [patch #2206] execute_orders() changes
Follow-up Comment #3, patch #2206 (project freeciv): Caravan changes has micromanagement consequences in longturn similar games. Caravans on goto enter cities when turn changes, and player is not connected. When (s)he then connects to game to handle his/her turn, client does not automatically popup those caravans in target cities that have no movement left. With current behavior this is just fine. Your proposed change requires people to check their every city in case such a unit is inside already ready to act. This is interesting, do you have a link to the ticket which implemented this. I tested many times with trunk, I couldn't get any caravan popup when reconnecting. Isn't this already broken? ___ Reply to this item at: http://gna.org/patch/?2206 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20498] Pirate archers alone in the water
Update of bug #20498 (project freeciv): Planned Release: 2.4.0-beta2, 2.5.0 = 2.4.0, 2.5.0 ___ Follow-up Comment #3: Now I no longer have seen that... there's client side problems while observing, but those are not so critical. ___ Reply to this item at: http://gna.org/bugs/?20498 ___ 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 #2206] execute_orders() changes
Follow-up Comment #4, patch #2206 (project freeciv): By popup I actually meant that the units get focus on their turn. ___ Reply to this item at: http://gna.org/patch/?2206 ___ 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 #2206] execute_orders() changes
Follow-up Comment #5, patch #2206 (project freeciv): By popup I actually meant that the units get focus on their turn. I don't understand. I tried many times, I get no caravan-arrival-popup, nor caravans are not included in the unit focus chain. I testing with current trunk. Also, I checked svn logs about caravan or arrival, I didn't find anything... ___ Reply to this item at: http://gna.org/patch/?2206 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #2206] execute_orders() changes
Follow-up Comment #6, patch #2206 (project freeciv): I'm not talking about anything specific to caravans or their arrival. Units with movement left get focus, units without don't. Assuming roads, and full 3/3 movement point for both, place one caravan 6 tiles and another 5 tiles away from a city. Set goto to the city for both. They immediately move to 3 2 tiles away from the city. Log out your client, let the turn pass (set timeout in server and let it pass), and login back. For all the units automatically getting focus, press 'space'. Notice that the caravan with 1/3 movement left gets the focus, and could establish traderoute, but caravan with 0/3 move left never gets the focus unless you go to search for it from inside the city. ___ Reply to this item at: http://gna.org/patch/?2206 ___ 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 #2206] execute_orders() changes
Follow-up Comment #7, patch #2206 (project freeciv): Notice that the caravan with 1/3 movement left gets the focus, and could establish traderoute, but caravan with 0/3 move left never gets the focus unless you go to search for it from inside the city. Yes, I notice this *with* and *without* the patch applied. I see no difference. What am I missing? ___ Reply to this item at: http://gna.org/patch/?2206 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20086] in astr_vadd() [astring.c::164]: assertion '(size_t) -1 != new_len' failed.
Follow-up Comment #3, bug #20086 (project freeciv): Does this patch also solve your problem? Yes, problem solve. Thanks! ___ Reply to this item at: http://gna.org/bugs/?20086 ___ Messaggio inviato con/da Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #2206] execute_orders() changes
Follow-up Comment #8, patch #2206 (project freeciv): Without the patch it's the correct behavior as one does not want to do anything with the units. But once those units with 0 move could establish traderoute already this turn, optimal playing requires micromanagement to search all the cities for caravans who have just arrived and could now be ordered to establish the traderoute. It gives the edge to those players who micromanage that way, so everyone is forced to do so. ___ Reply to this item at: http://gna.org/patch/?2206 ___ 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 #2206] execute_orders() changes
Follow-up Comment #9, patch #2206 (project freeciv): I think I now understand what you mean. I didn't change anything in the current rules. Caravan with 0 moves left always could establish trade routes (pressing 'r' for example) or help for wonders. The only change in this patch is that actions which doesn't require moves left in the rules (like establishing trade routes, help for wonders, disband) are not delayed by one turn in the execution of the unit orders. It additionally ignores if the building the infrastructures which have been already built by others units. ___ Reply to this item at: http://gna.org/patch/?2206 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20519] Unloading problem in release builds
URL: http://gna.org/bugs/?20519 Summary: Unloading problem in release builds Project: Freeciv Submitted by: cazfi Submitted on: Sun 17 Feb 2013 12:02:26 PM EET Category: general 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.4.0, 2.5.0 ___ Details: Functionality to remove cargo from the list of transporter's transported units is inside fc_assert() so it won't happen at all when asserts are disabled. Fix attached I'm worried. The fact that there's some such cases of functionality inside fc_assert() indicates that someone has not been aware of its dangers and could have made same mistake in many places. I'll see if CodingStyle needs updating in this respect. ___ File Attachments: --- Date: Sun 17 Feb 2013 12:02:26 PM EET Name: ReleaseTransportedList.patch Size: 904B By: cazfi http://gna.org/bugs/download.php?file_id=17234 ___ Reply to this item at: http://gna.org/bugs/?20519 ___ 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 #20086] in astr_vadd() [astring.c::164]: assertion '(size_t) -1 != new_len' failed.
Update of bug #20086 (project freeciv): Status:None = In Progress Assigned to:None = pepeto Planned Release: = 2.4.0, 2.5.0 ___ Reply to this item at: http://gna.org/bugs/?20086 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20519] Unloading problem in release builds
Follow-up Comment #1, bug #20519 (project freeciv): (Bug #20084 was a previous, very similar instance of this problem.) ___ Reply to this item at: http://gna.org/bugs/?20519 ___ 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 #20084] Unloading transports impossible on NDEBUG builds
Follow-up Comment #4, bug #20084 (project freeciv): The story continues in bug #20519... ___ Reply to this item at: http://gna.org/bugs/?20084 ___ 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 #2206] execute_orders() changes
Follow-up Comment #10, patch #2206 (project freeciv): Oh, sorry for the noise then. ___ Reply to this item at: http://gna.org/patch/?2206 ___ 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 #3711] Caravan popups as part of unit focus queue?
URL: http://gna.org/patch/?3711 Summary: Caravan popups as part of unit focus queue? Project: Freeciv Submitted by: jtn Submitted on: Sun Feb 17 10:23:00 2013 Category: client Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: Following on from discussion in patch #2206: In general, it does feel like we need a new workflow for caravan orders (and maybe other things like diplomat actions). Having the popup occur in the flurry of turn-change activities was bad for various reason (e.g. taking focus, obscuring the action), which is why we have Pop up caravan actions as an option (r15533 http://svn.gna.org/viewcvs/freeciv?view=revisionrevision=15533), but if you turn that off it's easy to forget that a caravan is ready. Commercial CivIV has a fairly forced workflow, where it takes you through decisions like city production, promotions, and units in some fixed order. This helps not forget things, but it's still not ideal; if you don't want to deal with a thing at the point it prompts because you need other information (you're locked out of seeing all information due to the forced workflow), you have to cancel and remember to go back and review the thing later. I wonder if there's scope for putting pending-caravan-decisions on the unit focus queue, and popping up the caravan dialog whenever focus gets to a unit, and allowing the usual unit focus keys like W to dismiss the popup non-permanently (so it will appear again next time the unit comes up)? In this world, a unit capable of an action would stay on the queue even if it had no movement points left. That still doesn't quite fix the case where your first unit after turn change needs a popup, but you don't want the popup obscuring your view of the post-turn action -- although it'll help a bit as the popup will naturally pop up a bit later. Perhaps you want the option of some unobtrusive proxy for the popup, like a particular modification to the unit icon. (Obviously having the specify-action-in-advance envisaged by bug #16905 would also help some players, but it would still be good to have a better workflow for those not making plans in advance.) ___ Reply to this item at: http://gna.org/patch/?3711 ___ 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 #3712] CodingStyle warning against functioality inside fc_assert()
URL: http://gna.org/patch/?3712 Summary: CodingStyle warning against functioality inside fc_assert() Project: Freeciv Submitted by: cazfi Submitted on: Sun 17 Feb 2013 12:24:28 PM EET Category: docs Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.3.5, 2.4.0, 2.5.0 ___ Details: CodingStyle seemed to have nothing about how one should not include necessary functionality inside fc_assert() -family of macros. This patchs adds warning against it. ___ File Attachments: --- Date: Sun 17 Feb 2013 12:24:28 PM EET Name: AssertsAndFunctionality.patch Size: 736B By: cazfi http://gna.org/patch/download.php?file_id=17235 ___ Reply to this item at: http://gna.org/patch/?3712 ___ 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 #2206] execute_orders() changes
Follow-up Comment #11, patch #2206 (project freeciv): (I started musing here about improvements to the caravan popup workflow, but really it should be the topic of a separate ticket, so: patch #3711.) ___ Reply to this item at: http://gna.org/patch/?2206 ___ 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 #16905] Goto and do XXX for caravans
Follow-up Comment #3, bug #16905 (project freeciv): What should the UI look like here? (I haven't looked at warclient.) One option: you do a normal path goto (G), only after you finalise it by clicking on the destination tile, if it's a place you can do an action, it pops up something looking like the normal caravan popup (only with Your Caravan Has Arrived text changed, obviously). When you choose an action, then the orders are committed (you can tell when this happens because the goto line doesn't disappear until after you dismiss the popup). To get the previous behaviour, choose Keep Moving. Once the UI is decided, this is presumably mostly a case of unifying caravan actions (and maybe also diplomat actions?) with the vocabulary used by unit orders. I think the client must already have more or less enough smarts to know what actions are possible at a given proposed destination tile without reference to the server? (If we ever expose more of the power of unit orders, e.g. goto-and-sentry, goto-and-fortify, I guess that might be combined with this UI.) ___ Reply to this item at: http://gna.org/bugs/?16905 ___ 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 #3711] Caravan popups as part of unit focus queue?
Follow-up Comment #1, patch #3711 (project freeciv): Sounds much better than the minimal fix I've been wanting for the case when player is not logged in during turn change, misses the popups, and never gets them once (s)he logs in. Currently caravan either automatically creates traderoute (if target was non-allied city) or just goes inside the city (if own or allied city). ___ Reply to this item at: http://gna.org/patch/?3711 ___ 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 #20361] Pathfinding may prefer move+attack to simply attacking adjacent target
Update of bug #20361 (project freeciv): Planned Release:2.4.0, 2.5.0 = 2.3.5, 2.4.0, 2.5.0 ___ Follow-up Comment #8: Attaching better version: consider the last move of the path as a constant single move when attacking and entering foreigner cities to establish trade route for getting straighter paths. In the savegame example, the old behaviour is still possible using waypoints. (file #17236) ___ Additional Item Attachment: File name: path_finding_dont_leave.diff Size:2 KB ___ Reply to this item at: http://gna.org/bugs/?20361 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20519] Unloading problem in release builds
Follow-up Comment #2, bug #20519 (project freeciv): It looks like fc_assert_ret() isn't disabled in NDEBUG builts. ___ Reply to this item at: http://gna.org/bugs/?20519 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16905] Goto and do XXX for caravans
Follow-up Comment #4, bug #16905 (project freeciv): unifying caravan actions (and maybe also diplomat actions?) with the vocabulary used by unit orders In fact I see enum unit_orders already has ORDER_BUILD_WONDER and ORDER_TRADE_ROUTE. So caravans are sorted (but diplomats are not -- I'm not sure how often you plan diplomat moves that far in advance anyway). ___ Reply to this item at: http://gna.org/bugs/?16905 ___ 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 #16905] Goto and do XXX for caravans
Follow-up Comment #5, bug #16905 (project freeciv): It could also looks like menu items like Go to and Establish trade route using unit orders. We already have a menu item named Go to and Build city... ___ Reply to this item at: http://gna.org/bugs/?16905 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1483] Add checks in dataio.c
Update of patch #1483 (project freeciv): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #3: After applying patch #3685, patch #3686, patch #3687, patch #3688 patch #3705 and fixing bug #20513, this patch has no more sense. ___ Reply to this item at: http://gna.org/patch/?1483 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3712] CodingStyle warning against functioality inside fc_assert()
Follow-up Comment #1, patch #3712 (project freeciv): Some relevant comment in bug #20519 ___ Reply to this item at: http://gna.org/patch/?3712 ___ 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 #3712] CodingStyle warning against functionality inside fc_assert()
Update of patch #3712 (project freeciv): Summary: CodingStyle warning against functioality inside fc_assert() = CodingStyle warning against functionality inside fc_assert() ___ Reply to this item at: http://gna.org/patch/?3712 ___ 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 #20519] Unloading problem in release builds
Follow-up Comment #4, bug #20519 (project freeciv): I agree with you. ___ Reply to this item at: http://gna.org/bugs/?20519 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3713] Keyboard-driven goto-and-do-XXX for more XXX
URL: http://gna.org/patch/?3713 Summary: Keyboard-driven goto-and-do-XXX for more XXX Project: Freeciv Submitted by: jtn Submitted on: Sun Feb 17 11:09:56 2013 Category: client Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: The unit orders system in the network protocol is potentially quite powerful, allowing a client to express an arbitrary series of moves and other actions. We have a few common cases exposed in the client, for instance: * Go to and build city (Shift-B) * Connect with road/railroad/irrigation However, there are plenty more that would be useful -- go-to-and-sentry, go-to-and-fortify, go-to-and-set-homecity, maybe even go-to-and-load. Inventing unique keystrokes and menu items for all of the combinations that people would find useful is likely to be impractical -- we're short of keystrokes already, and the menus are likely to become unwieldy. We could allow specification of arbitrary commands to terminate a 'G' goto mode in the client. For instance: * Go-to-and-sentry: press 'G', point to destination (a line will be drawn), press 'S': goto mode terminated, and move-followed-by-sentry sent to server. * Go-to-and-fortify: similarly, 'G', move, 'F'. (Suffers from usual fortress-vs-fortify confusion, but no worse than before.) This would increase the problem of knowing what a unit's orders are: if you middle-click, you see the unit's path, but not what else it's up to. Some additional icon on tile where a unit is doing something other than a move could help here. A cheap fix would be to reuse the unit's activity overlay (yellow 'S' in corner), displaying it at the relevant tile with no associated unit. * However, that doesn't catch non-activity actions such as build city. * Unit activity icons without units may be confusingly far from the affected path/tile, especially in iso tilesets. Maybe they would ideally be centred on the tile in this case. * Also it might be confusing if there's a unit already on the action tile. * No reason to not also apply this to the connect with road type orders. This helps power users who've read the documentation, but isn't very discoverable for new users. It could be made more discoverable by having a Go to and... submenu with options like Go to and sentry; this would launch goto mode such that the final click adds the relevant order. As a reminder which submode you're in, the notation proposed above could be used as a prompt -- if you've selected go-to-with-sentry, a yellow 'S' follows the end of line / mouse pointer to remind you what will by default happen when you click. This can also be used for caravan actions, since we have keystrokes for those: * go-to-and-help-build-wonder: 'G', move, 'W'. * go-to-and-make-traderoute: 'G', move, 'R'. ** Ambiguous with 'go to and build single road at destination', but I think that's rare enough that we can live with it. We could even allow Shift+R (connect with road) to be a valid keystroke in goto mode, enabling this case and more. (This would not be a replacement for the more interactive click-on-destination-popup I propose in bug #16905.) ___ Reply to this item at: http://gna.org/patch/?3713 ___ 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 #16905] Goto and do XXX for caravans
Follow-up Comment #6, bug #16905 (project freeciv): Well, yes, but we end up with enormous unwieldy menus and run out of unique keystrokes pretty quickly by doing that; I'm looking for a solution that can be keyboard-driven without requiring a unique keystroke for every combination. (Obviously this assumes the popup can be keyboard-driven. If it can't currently, it should be.) Although... I've had another idea for goto-and-do-XXX without popups, which would also apply to caravan actions. See patch #3713. ___ Reply to this item at: http://gna.org/bugs/?16905 ___ 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 #6, bug #19841 (project freeciv): Late comment (again, I should really review patches before they're committed, sorry): Would it be better to have a section in nationlist.ruleset explicitly listing all allowed govs in leader titles (and e.g. terrains), rather than having to specify the delta between the ruleset and the default nationset in each ruleset's nations.ruleset? That has the advantage that it's more obvious to the maintainers of the default nationset what the allowed govs/terrains are -- they need only look at the single nationlist.ruleset, not reconcile multiple rulesets and wondering what else is out there; and it's clear to ruleset authors who intend to re-use the default nationset what sort of ruleset features it expects. Something like [ruleset_compatibility] leader_govs = Anarchy, Despotism, Monarchy, Communism, Fundamentalism, Republic, Democracy city_terrains = river, lake, ocean, glacier, desert, forest, grassland, hills, jungle, mountains, plains, swamp, tundra ___ 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] [bug #19841] Fundamentalism fails in classic ruleset
Follow-up Comment #7, 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), rather than having to specify the delta between the ruleset and the default nationset in each ruleset's nations.ruleset? Well, yes. Only that it would mean splitting [compatibility] section between ruleset specific part (warn_city_style) and nationlist.ruleset. But maybe warn_city_style should be replaced with similar list of city styles anyway. ___ 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] [bug #20520] player_set_nation() assertions failed
URL: http://gna.org/bugs/?20520 Summary: player_set_nation() assertions failed Project: Freeciv Submitted by: pepeto Submitted on: dim. 17 févr. 2013 13:20:52 CET Category: general Severity: 3 - Normal Priority: 5 - Normal Status: Ready For Test Assigned to: pepeto Originator Email: Open/Closed: Open Release: trunk r22341 Discussion Lock: Any Operating System: None Planned Release: 2.5.0 ___ Details: When trying to change of ruleset, I get: 1: in player_set_nation() [player.c::739]: assertion 'pnation-player == NULL' failed. 1: Please report this message at http://gna.org/projects/freeciv/ 1: in player_set_nation() [player.c::739]: assertion 'pnation-player == NULL' failed. 1: Please report this message at http://gna.org/projects/freeciv/ 1: in player_set_nation() [player.c::739]: assertion 'pnation-player == NULL' failed. 1: Please report this message at http://gna.org/projects/freeciv/ 1: in player_set_nation() [player.c::739]: assertion 'pnation-player == NULL' failed. 1: Please report this message at http://gna.org/projects/freeciv/ 1: in player_set_nation() [player.c::735]: assertion 'pplayer-nation-player == pplayer' failed. 1: Please report this message at http://gna.org/projects/freeciv/ 1: in player_set_nation() [player.c::735]: assertion 'pplayer-nation-player == pplayer' failed. 1: Please report this message at http://gna.org/projects/freeciv/ 1: in player_set_nation() [player.c::739]: assertion 'pnation-player == NULL' failed. 1: Please report this message at http://gna.org/projects/freeciv/ 1: in player_set_nation() [player.c::735]: assertion 'pplayer-nation-player == pplayer' failed. 1: Please report this message at http://gna.org/projects/freeciv/ 1: in player_set_nation() [player.c::739]: assertion 'pnation-player == NULL' failed. 1: Please report this message at http://gna.org/projects/freeciv/ 1: in player_set_nation() [player.c::735]: assertion 'pplayer-nation-player == pplayer' failed. 1: Please report this message at http://gna.org/projects/freeciv/ 1: in player_set_nation() [player.c::739]: assertion 'pnation-player == NULL' failed. 1: Please report this message at http://gna.org/projects/freeciv/ 1: in player_set_nation() [player.c::735]: assertion 'pplayer-nation-player == pplayer' failed. 1: Please report this message at http://gna.org/projects/freeciv/ 1: in player_set_nation() [player.c::739]: assertion 'pnation-player == NULL' failed. 1: Please report this message at http://gna.org/projects/freeciv/ This is linked with patch #3688, using nation_count() for serialize a NULL nation to the clients. Unfortunately, player infos are sent many times when switching ruleset (after nations have been freed and when loading the ruleset settings). It results that client:nation_count() != server:nation_count() and produces these errors. I didn't notice yet, but the NATION type for packet handling is SINT16, so the attached fix replace nation_count() by NATION_NONE for computing the PACKET_PLAYER_INFO. ___ File Attachments: --- Date: dim. 17 févr. 2013 13:20:52 CET Name: trunk_packet_player_nation.diff Size: 630 o By: pepeto http://gna.org/bugs/download.php?file_id=17237 ___ Reply to this item at: http://gna.org/bugs/?20520 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20490] Player owner reconnecting to player while delegate user attached = server assertion failures, crash
Update of bug #20490 (project freeciv): Status:None = Confirmed ___ Follow-up Comment #1: I can confirm, but it needs a step more : * pamcakes: /delegate restore ___ Reply to this item at: http://gna.org/bugs/?20490 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20490] Player owner reconnecting to player while delegate user attached = server assertion failures, crash
Follow-up Comment #2, bug #20490 (project freeciv): Oops, I missed the vital step in my description! Should have been * ... * pamcakes: /delegate take Ur-Nammu [herp's player] * *herp rejoins* * bad things happen to server This is the scenario the backtraces come from. ___ Reply to this item at: http://gna.org/bugs/?20490 ___ 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 #20490] Player owner reconnecting to player while delegate user attached = server assertion failures, crash
Update of bug #20490 (project freeciv): Category:None = general Status: Confirmed = Ready For Test ___ Follow-up Comment #3: I think the backtrace attached was after herp reconnect. Attached patch that fix both way to reproduce these bad things. (file #17238) ___ Additional Item Attachment: File name: connection_delegate_restore.diff Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?20490 ___ Message posté via/par Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20513] dataio.c compiler warnings
Follow-up Comment #12, bug #20513 (project freeciv): For the record: But I thought that sizeof(long) were equal to 8 bytes on 64 bits computers. Not on LLP64 platforms... there's a useful taxonomy of 64-bit data models http://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models on Wikipedia. ___ Reply to this item at: http://gna.org/bugs/?20513 ___ 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 #20003] Security advisory
Follow-up Comment #24, bug #20003 (project freeciv): (Since this is a security bug: for those watching at home: the post-commit discussion here spawned a bunch of patches intended to make the low-level protocol handling more obvious and the endpoints less tolerant of malformation, e.g. patch #3685, patch #3687. I don't think any new security issues have been identified as a result of this work?) ___ Reply to this item at: http://gna.org/bugs/?20003 ___ 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 #3693] Worker food upkeep less important factor
Follow-up Comment #3, patch #3693 (project freeciv): Needless to say, this patch require rebalancing of _WEIGHTING constants in patch #3692 once again. Otherwise AI builds far too many workers. Is that a thing that we'll need to do before 2.4.0-beta2, then? ___ Reply to this item at: http://gna.org/patch/?3693 ___ 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 #20521] Government Upkeep_Factor help wrong
URL:
http://gna.org/bugs/?20521
Summary: Government Upkeep_Factor help wrong
Project: Freeciv
Submitted by: jtn
Submitted on: Sun Feb 17 15:16:48 2013
Category: docs
Severity: 3 - Normal
Priority: 5 - Normal
Status: None
Assigned to: None
Originator Email:
Open/Closed: Open
Release: S2_4 r22361
Discussion Lock: Any
Operating System: None
Planned Release:
___
Details:
Noticed with civ2 ruleset, but will affect others.
In the autogenerated help for civ2 Fundamentalism and Communism we have:
* You pay 2 times normal Food upkeep for your units.
No other government types mention this.
However, the help for Settlers says:
Settlers in a Republic or Democracy require twice as much food per turn, and
in Communist or Fundamentalist societies, three times as much.
And by experiment, this appears to be accurate.
(Incidentally, if we are intentionally shipping rulesets with upkeep 3, it's
not ideal that the upkeep icon can only go up to 2 -- I only noticed this by
hovering over the unit icon to get the upkeep numbers.)
Root cause is that the government help (helptext_government()) cherry-picks
effects that apply to the current government, but doesn't consider effects
that aren't government-specific. The effect structure in civ2/effects.ruleset
looks like:
[effect_base_unit_upkeep]
name = Upkeep_Factor
value = 1
[effect_communism_unit_upkeep]
name = Upkeep_Factor
value = 2
reqs =
{ type, name, range
Gov, Communism, Player
OutputType, Food, Local
}
...
So effect_base_unit_upkeep is not taken into account. For many descriptions
that sort of thing doesn't matter, but for Upkeep_Factor which is
multiplicative it's very misleading.
This explains why no help text is seen for Republic/Democracy: the resultant
factor is 1, which isn't seen as worth mentioning.
A fix that would help here would be to explicitly look for and take account of
completely unqualified effects like base_unit_upkeep here.
That doesn't catch more complicated interactions, but most of those would
hopefully be specific enough that it's reasonable to say gov X pays 2x
upkeep and expect the player to know that in condition Y that's a base level
that's modified. (In general, this generated help text will never cope with
all these circumstances; the best we can hope for is to remain silent when
things get complicated.)
(This is with S2_4; haven't checked other branches yet.)
___
Reply to this item at:
http://gna.org/bugs/?20521
___
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 #3693] Worker food upkeep less important factor
Follow-up Comment #4, patch #3693 (project freeciv): Is that a thing that we'll need to do before 2.4.0-beta2, then? This alone doesn't seem to give worse balance than original situation, quite the contrary. The problem arose only when I had seeked better balance with one patch #3692 version, and both patches worked together to increase number of Workers built. ___ Reply to this item at: http://gna.org/patch/?3693 ___ 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 #20522] AI assumes all terrain improvement units (F_SETTLERS) cost population?
URL: http://gna.org/bugs/?20522 Summary: AI assumes all terrain improvement units (F_SETTLERS) cost population? Project: Freeciv Submitted by: jtn Submitted on: Sun Feb 17 15:47:07 2013 Category: ai Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: S2_4 r22361 Discussion Lock: Any Operating System: Any Planned Release: ___ Details: While reviewing patch #3693, I noticed that in contemplate_terrain_improvements(), this code: want = (want - unit_food_upkeep(virtualunit) * FOOD_WEIGHTING / 2) * 100 / (40 + unit_foodbox_cost(virtualunit)); (which runs in the context of F_SETTLERS units, which actually means terrain improvers) is I think considering units with a population cost. However, unit_foodbox_cost() doesn't actually look at the unit type; it seems to assume that any unit it might be called with has a nonzero pop_cost and thus consume food from the city when created. Clearly this isn't true of Workers in the default ruleset. unit_foodbox_cost() seems bogus in other ways (at least on S2_4): * If passed a non-virtual unit, it returns a fixed cost of 30. (Fortunately it never is.) * Asserts pcity != NULL only after use. * Doesn't consider pop_cost 1. * (I assume the calculation is not referring to the effect on city food of actually building the unit -- as far as I can tell, there is none beyond clipping it, which itself isn't accounted for -- but the marginal amount of food that will be required to get back to where the city would have been had it not built the unit.) If these are real issues, I guess that fixing them is likely to mess up balance / fudge factors. (Only checked S2_4.) ___ Reply to this item at: http://gna.org/bugs/?20522 ___ 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 #20484] get_virtual_defense_power() assuming TerrainDefense
Update of bug #20484 (project freeciv): Status: Ready For Test = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20484 ___ 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 #20508] Nations functional typo fixes
Update of bug #20508 (project freeciv): Status: Ready For Test = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20508 ___ 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 #20524] Impossible terrain for city name
URL: http://gna.org/bugs/?20524 Summary: Impossible terrain for city name Project: Freeciv Submitted by: None Submitted on: Sun Feb 17 21:47:42 2013 Category: rulesets Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: 2.3.3 Discussion Lock: Any Operating System: Microsoft Windows Planned Release: ___ Details: Testing a data/nations/native.ruleset I tried to determine how terrain conditions actually work, e.g., are special resources such as wheat, fruit, or gems also supported. As a quick plausibility check before the tests I started the cities with... cities = Oops (glacier), ;test impossible terrain [other successfully tested cities without terrain conditions] ...and got Oops as first city, so that test failed. Therefore I modified the syntax to... cities = Oops (glacier), ;test impossible terrain [other successfully tested cities without terrain conditions] ...and the implicitly started server hanged. After some time, while I was already editing this bug report, the client reported the German version of sorry, you have to start the server manually. Conclusion, the name (conditions) syntax in my first attempt was correct, but condition (glacier) has no effect. ___ Reply to this item at: http://gna.org/bugs/?20524 ___ 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 #20511] omniscient is_square_threatened()
Update of bug #20511 (project freeciv): Status: Ready For Test = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20511 ___ 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 #3695] Native tile to river
Update of patch #3695 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3695 ___ 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 #3714] Remove CardinalOnly road flag
URL: http://gna.org/patch/?3714 Summary: Remove CardinalOnly road flag Project: Freeciv Submitted by: cazfi Submitted on: Mon 18 Feb 2013 12:43:48 AM EET 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 ___ Details: Remove CardinalOnly road type flag as obsolete. Move cost is now determined by move_mode, and river drawing happens with distinct roadtype River. ___ File Attachments: --- Date: Mon 18 Feb 2013 12:43:48 AM EET Name: CardinalOnlyRm.patch Size: 8kB By: cazfi http://gna.org/patch/download.php?file_id=17241 ___ Reply to this item at: http://gna.org/patch/?3714 ___ 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 #3701] Multiple river types
Update of patch #3701 (project freeciv): Summary: Multiple road types = Multiple river types ___ Follow-up Comment #1: - Updated against svn HEAD (file #17242) ___ Additional Item Attachment: File name: MultiRiverTypes-2.patchSize:7 KB ___ Reply to this item at: http://gna.org/patch/?3701 ___ 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 #20522] AI assumes all terrain improvement units (F_SETTLERS) cost population?
Follow-up Comment #1, bug #20522 (project freeciv): Taking the unit type in to account here would have its problems, though. It's calculating general UTYF_SETTLERS want, not that of specific unit type. In theory this want may make it later to build a UTYF_SETTLER unit, but of different type than virtual one used here. In somewhat related note it's not necessarily good idea that it's worker want of the very city used when deciding if worker should be built. The cities that need workers most probably need other things too (new underdevelopet cities). Even higher wants may win over quite high worker want, such a city might not be able to build workers (chicken egg), and even when it builds workers, that is away from other important projects. At the same time well-off nearby city may have no urgent tasks at all, so it could very well build the workers for the other city to use. ___ Reply to this item at: http://gna.org/bugs/?20522 ___ 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 #3715] Threaded AI cities generating Worker task requests
URL: http://gna.org/patch/?3715 Summary: Threaded AI cities generating Worker task requests Project: Freeciv Submitted by: cazfi Submitted on: Mon 18 Feb 2013 04:32:04 AM EET Category: ai Priority: 5 - Normal Status: In Progress Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.5.0 ___ Details: This proof-of-concept patch adds first real work to threaded AI's subthread. In the beginning of the player phase, cities evaluate potential worker tasks in their area, and send best one to the main thread to set for the city. When workers then have time, they take these tasks. This still needs a lot of work before it gives as good results as current model of settlers always looking for job themselves. - Supports only a few worker tasks, no road or base building - Assumes that any task it evaluates is possible, i.e., may request impossible tasks - Virtually no mutex protection so threads may handle the city simultaneously leading them to get inconsistent values - Does not give out values of the tasks. Worker may end working on almost-zero-value task of one city when nearby city has urgent task. - Does not care about lenght of the work, only about value of sfinished work ___ File Attachments: --- Date: Mon 18 Feb 2013 04:32:04 AM EET Name: ThreadedCityRequests.patch Size: 7kB By: cazfi http://gna.org/patch/download.php?file_id=17243 ___ Reply to this item at: http://gna.org/patch/?3715 ___ 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 #3716] README.packaging: mention that threaded ai is usable
URL: http://gna.org/patch/?3716 Summary: README.packaging: mention that threaded ai is usable Project: Freeciv Submitted by: cazfi Submitted on: Mon 18 Feb 2013 05:17:24 AM EET Category: docs 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: As threaded AI now uses default AI, and thus has all the functionality classic AI does, mention it in README.packaging ___ File Attachments: --- Date: Mon 18 Feb 2013 05:17:24 AM EET Name: ThreadedDocWorking.patch Size: 661B By: cazfi http://gna.org/patch/download.php?file_id=17244 ___ Reply to this item at: http://gna.org/patch/?3716 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
