[Freeciv-Dev] [bug #19984] Client's limited knowledged used when displaying military unhappiness caused by unit
URL: http://gna.org/bugs/?19984 Summary: Client's limited knowledged used when displaying military unhappiness caused by unit Project: Freeciv Submitted by: cazfi Submitted on: Thu 26 Jul 2012 11:33:20 AM EEST Category: client 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: Client can display completely bogus information about military unhappiness caused by units, since it tries to determine it itself with its limited knowledge. I have not checked all clients carefully, but from quick grepping it seems that broken code exist in all of them. gtk3-client: city_dialog_update_supported_units(): 1. It gets value of effect EFT_MAKE_CONTENT_MIL to decide how many units get free upkeep. Client may end up displaying wrong number of units free of happiness upkeep 2. It calls city_unit_unhappiness() for each unit, which for units in fortress ends up checking if there's friendly city nearby. There could be allied city near that player does not know about (it would make sense that unknown cities would not lift unhappiness, but as server side does not work that way, client ends showing wrong information) ___ Reply to this item at: http://gna.org/bugs/?19984 ___ 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 #19739] Units aggressive though in Fortress
Update of bug #19739 (project freeciv): Status:None = Invalid Assigned to:None = cazfi Open/Closed:Open = Closed ___ Follow-up Comment #1: This turned out to be bug in my ruleset - units were not native_to fortress. ___ Reply to this item at: http://gna.org/bugs/?19739 ___ 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 #19900] Font preferences not respected
Follow-up Comment #6, bug #19900 (project freeciv): ...and for a difference, on a topic related note, a minor fix for help label colors - value taken from old Freeciv.h. (that line for font in tooltip doesn't seem to work, but the colors do) (file #16199) ___ Additional Item Attachment: File name: fix-help-colors.patch Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?19900 ___ 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 #3439] Rename my_chomp() - fc_chomp()
Update of patch #3439 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3439 ___ 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 #3445] Add Indonesian (id) localisation
Follow-up Comment #1, patch #3445 (project freeciv): The po-file I intend to commit is attached to this post to -i18n http://mail.gna.org/public/freeciv-i18n/2012-07/msg00017.html. ___ Reply to this item at: http://gna.org/patch/?3445 ___ 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 #19900] Font preferences not respected
Follow-up Comment #7, bug #19900 (project freeciv): Alright, it's hard to affect a tooltip, if it's not really a tooltip. I was looking at the info popups in city dialog - setting them to monospace makes the formating work again. (file #16201) ___ Additional Item Attachment: File name: fix-help-colors.patch Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?19900 ___ 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 #3441] Alt activity gfx tags
Update of patch #3441 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3441 ___ 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 #3395] Terrain flag requirement type
Update of patch #3395 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3395 ___ 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 #3316] Celtic nation
Update of patch #3316 (project freeciv): Planned Release: = 2.4.0-beta1,2.5.0 ___ Follow-up Comment #2: Patch #3432 wants to add this to S2_4. If it's going in, then it needs to go in for the first beta -- we can't add nations after that, as it would cause trouble for people moving savegames backwards and forwards between versions. ___ Reply to this item at: http://gna.org/patch/?3316 ___ 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 #3432] Core nation group
Update of patch #3432 (project freeciv): Depends on: = patch #3316 ___ Reply to this item at: http://gna.org/patch/?3432 ___ 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 #3446] Make terrain class property of terrain type instead of determining it from flags
URL: http://gna.org/patch/?3446 Summary: Make terrain class property of terrain type instead of determining it from flags Project: Freeciv Submitted by: cazfi Submitted on: Fri 27 Jul 2012 01:40:39 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 ___ Details: For extensibility of terrain class concept it should not be based on just if terrain type has certain flag(s) or not. Attached patch adds field class for terrain types and obsoletes flag Oceanic. ___ File Attachments: --- Date: Fri 27 Jul 2012 01:40:39 AM EEST Name: OceanicClass.patch.bz2 Size: 9kB By: cazfi http://gna.org/patch/download.php?file_id=16203 ___ Reply to this item at: http://gna.org/patch/?3446 ___ 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 #3447] map_claim_base()
URL: http://gna.org/patch/?3447 Summary: map_claim_base() Project: Freeciv Submitted by: cazfi Submitted on: Fri 27 Jul 2012 02:03:35 AM EEST Category: general 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: Attached WIP patch moves base ownership changes to central function of their own, map_claim_base(). This is going to be first one in series of base ownership patches. Goal of the series is to separate base ownership from border ownership. Primary reason is fixing problems related to vision providing bases (buoy). My current plan: - All bases in a tile have same owner (which can be nobody) - Bases on a tile can be owned even when tile is not (buoy can work on unowned territory) I'm not certain about other border ownership and base ownership interactions. - Can bases have no owner even if tile has owner (in a scenario with preset unowned bases) - If both tile and bases have owner, can bases be owned by player other than tile owner (unit walking to base claims base even if not territory) ___ File Attachments: --- Date: Fri 27 Jul 2012 02:03:35 AM EEST Name: ClaimBase.patch Size: 9kB By: cazfi http://gna.org/patch/download.php?file_id=16204 ___ Reply to this item at: http://gna.org/patch/?3447 ___ 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 #2911] Improvements to tutorial scenario
Update of patch #2911 (project freeciv): Category:docs = rulesets ___ Follow-up Comment #3: Even if you have more improvements to tutorial to be added later in mind, maybe you should commit this existing improvement already. ___ Reply to this item at: http://gna.org/patch/?2911 ___ 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 #3432] Core nation group
Update of patch #3432 (project freeciv): Depends on: = patch #3449 ___ Follow-up Comment #3: Re my comment #1, I've got some proposals for code changes to avoid these problems: * Long-term (for 2.5): patch #3448 * Short-term (for 2.4): patch #3449 ___ Reply to this item at: http://gna.org/patch/?3432 ___ 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 #3448] Nation sets: allow set of nations that will ever appear in-game to be chosen
Follow-up Comment #1, patch #3448 (project freeciv): Nations exiting from the core set will need to be carefully controlled to avoid savegame compatibility issues. If loading a savegame with a declared subset and nations inconsistent with it that we know about, we should probably just locally add them to the subset for the duration of that game. ___ Reply to this item at: http://gna.org/patch/?3448 ___ 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 #3432] Core nation group
Follow-up Comment #4, patch #3432 (project freeciv): I went through our supplied scenarios to see how the nations in them compare to this core set. Obviously some scenarios are never going to fit in the core (the Europe scenario obviously has a European bias), but some are close. Perhaps this should inform the set of five extras chosen for the core. Also, we could tweak the nations in the 2.4 scenarios to fit the core set (in a new ticket). * In with a shout: ** earth-160x90-v2.sav: 24/30 in core *** Missing: Gallic, British, Inuit, Papuan, Cambodian, Manchu. ** japan-88x100-v1.3.sav: 7/8 in core; only missing the Spanish ** north_america_116x100-v1.2.sav: 9/12 *** Missing: Spanish, Scottish, Irish. * Lost causes: ** british-isles-85x80-v2.80.sav: 1/5 in core ** europe-200x100-v2.sav: 13/37, or 15/37 with current extras ** france-140x90-v2.sav: 12/27, or 14/27 with current extras The Spanish come up a lot... maybe they should be in the extras? (I'm sure they've been in at least one commercial Civ.) ___ Reply to this item at: http://gna.org/patch/?3432 ___ 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 #3448] Nation sets: allow set of nations that will ever appear in-game to be chosen
Follow-up Comment #2, patch #3448 (project freeciv): I'll raise a separate ticket for a simpler stopgap design for 2.4.x. This is now patch #3449. ___ Reply to this item at: http://gna.org/patch/?3448 ___ 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] Nations in Freeciv - a plan
OK, how about this for a plan. It may even be possible to implement it in 2.4.x if we're quick -- I'm working on it now, so if you think this is a bad plan, speak up soon! In June, I wrote: Whew, I unleashed something here. [...] I think there's two things here: whether all these nations are enhancing the game and belong in the core Freeciv distribution at all (ignoring for a moment the impact on translators), and if so, how to help players navigate them, and then there's managing the impact on the translation team specifically. The proposal here is primarily about helping translation, with a side effect of providing a less overwhelming initial list to players. There are clearly lots of things we can do in future to help navigate the extended set; worry about them another time. If we are to be ruthless and somehow divide the nations into core and extended ones, well, I have no idea where to start :) I'd want to leave that up to Jos co, if they are willing. Jos has stepped up and devised a fair way to define a core of about 50 nations -- based on their past appearance in Civ games. Hats off, that should hopefully save some arguments. See http://gna.org/patch/?3432 for the proposed list. In this plan, all the nations would continue to ship with Freeciv, but users would be presented by default with these core nations, and in default gameplay, only those nations would come up. Users could easily choose the extended set without installing anything extra, in the knowledge that they might not be localised. The deal for translators would be that you get a clearly-defined, unchanging set of core nations to focus on. We can look into providing separate stats or even separate pot-files for the extended set. (Of course you should feel free to translate parts of the extended set if you want -- for instance Hubert suggested translating nation names, which come up in-game, and just leaving the legends alone.) As for the technical issues, I've got a couple of proposals for how this should work: - long-term (2.5.x+): http://gna.org/patch/?3448 - short-term (2.4.x): http://gna.org/patch/?3449 Is everyone equally unhappy with that? ;) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] [Freeciv-i18n] Nations in Freeciv
Michael Bauer writes: 20/06/2012 02:05, sgrìobh Jacob Nevins: At most, IMO, some of the existing content gets moved into some kind of expansion pack which there's no obligation to translate, but whose continued existence is otherwise accommodated. You've actually given me an idea there. If such a thing as an expansion pack could be done [...], then we could go with very short explanations in core and the extended ones via an expansion. That way we wouldn't lose anything. I'm trying to avoid solutions that involve having more than one copy of an individual nation file in existence... if we have two spanish.rulesets, they're bound to get annoyingly out of sync (compare the civ1/civ2 specials, which I recently harmonised the strings of as much as possible to avoid gratuitous strings differences for translators). (which, incidentally, we might also want to consider for those map editing aspects, I like the game and I play but I'm unlikely to ever build a map, if that could be separated out, that would help make stuff more manageable) I don't think the existence of the editor gets in the way much as a player if you don't invoke it, so I assume you mean the strings are getting in your way as a translator. The thing about the editor is that it's much easier to implement and keep up to date as part of the client than as a separate program, because it can share lots of the same functionality used when playing. (There was once a separate editor program, civworld, so things have moved in the other direction.) So unlike the nationsets, there's no realistic prospect of it becoming separate again. Are the extra strings from the editor that onerous? * More, finer-grained nation groups, and maybe subgroups (Europe/Baltic). [...] * More sophisticated UI for selecting nation groups. Being able to [...] * Make more use of the interrelationships embedded in the nations. [...] * Geographic selection: pick nations from a world map. Maybe augmented [...] I think those are interesting development ideas but nothing really that helps us around the length issue of the nations (for translators). Indeed not. See my other proposal for a deal that is perhaps more good for you. If we go with the above (sorry, slow brain) approach of a short set and a long set, would it be hard to code to have the long set appear via some sort of Expand button? See other post for long-term proposal in that vein. Basically: it's possible to implement this, yes. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #19986] universal_rule_name() returning weird strings
URL: http://gna.org/bugs/?19986 Summary: universal_rule_name() returning weird strings Project: Freeciv Submitted by: cazfi Submitted on: Fri 27 Jul 2012 04:11:49 AM EEST 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.5.0 ___ Details: universal_rule_name() returns wrong kind of strings for some types. Current callers are interested only about units and buildings, which work ok, so there's no user visible problems at the moment. (But I'm working on tool that needs to get these right) - Even though this is rule name some strings are collected for translation. - Minsize returns format string (%d) and it has extra explanatory word in it compared to what is *rule* name in ruleset (in ruleset type is separate field) - CityTile and Minyear return (none) instead of name Fix attached. For dynamically constructed MinSize and MinYear types static buffer is used. ___ File Attachments: --- Date: Fri 27 Jul 2012 04:11:49 AM EEST Name: URuleName.patch Size: 2kB By: cazfi http://gna.org/bugs/download.php?file_id=16206 ___ Reply to this item at: http://gna.org/bugs/?19986 ___ 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 #3447] map_claim_base()
Follow-up Comment #1, patch #3447 (project freeciv): This sounds a lot like what I was thinking of in bug #16385 (but I never got further than design). - All bases in a tile have same owner (which can be nobody) That's clearly what I was thinking before, but I don't think I'd thought about what happens if B's Engineer builds a new ownable base on a tile which already has A's ownable base of a different kind. - Can bases have no owner even if tile has owner (in a scenario with preset unowned bases) - If both tile and bases have owner, can bases be owned by player other than tile owner (unit walking to base claims base even if not territory) For the latter, I convinced myself that base and tile should have separate owners (after originally thinking the opposite) -- see ticket. I think that implies that the answer to the first question is yes. ___ Reply to this item at: http://gna.org/patch/?3447 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
