[Freeciv-Dev] [patch #3753] Remove river road types when removing tiny isles
URL: http://gna.org/patch/?3753 Summary: Remove river road types when removing tiny isles Project: Freeciv Submitted by: cazfi Submitted on: Tue 26 Feb 2013 11:23:39 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: Make mapgenerator to remove river road types when removing tiny isles. ___ File Attachments: --- Date: Tue 26 Feb 2013 11:23:39 AM EET Name: TinyIsleRoadRiver.patch Size: 747B By: cazfi http://gna.org/patch/download.php?file_id=17346 ___ Reply to this item at: http://gna.org/patch/?3753 ___ 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 #3754] Extend road rivers when ocean transformed to land
URL: http://gna.org/patch/?3754 Summary: Extend road rivers when ocean transformed to land Project: Freeciv Submitted by: cazfi Submitted on: Tue 26 Feb 2013 11:40:21 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: When ocean is transformed to land causing river not to reach ocean, extend river road types to ocean. ___ File Attachments: --- Date: Tue 26 Feb 2013 11:40:21 AM EET Name: OceanTransformRoadRiver.patch Size: 1kB By: cazfi http://gna.org/patch/download.php?file_id=17347 ___ Reply to this item at: http://gna.org/patch/?3754 ___ 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] Comment changes (was: [bug #20494] Uninitialized PACKET_UNIT_ORDERS)
Marko Lindqvist writes: [...] Should have added comment at least to remind why exactly so. [...] Where I work, we have a policy that every commit is accounted to a bug like here, but we have an exception for comment-only changes, on the grounds of having the barrier to improving comments be as low as possible (not requiring the overhead of raising a bug etc). We have a special pseudo-job CommentChange to associate such commit with. This generally seems to work for us and is not abused. I've noticed I have a reticence to just comment something I've found because of the bug overhead. Should we do something similar for Freeciv? Could be restricted to more trusted developers (e.g. those with svn access?), and extensive changes touching many files which require some explanation can of course continue to go in regular tickets. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20561] Move translations from freeciv-server to the clients.
URL: http://gna.org/bugs/?20561 Summary: Move translations from freeciv-server to the clients. Project: Freeciv Submitted by: o01eg Submitted on: Втр 26 Фев 2013 10:07:53 Category: general Severity: 1 - Wish Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: 2.5.0 Discussion Lock: Any Operating System: None Planned Release: ___ Details: If server and clients have different locales messages display in server's locale instead client's. What about move all translationable strings from the server to clients what allows players with different locales get fully translated game? ___ Reply to this item at: http://gna.org/bugs/?20561 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Comment changes (was: [bug #20494] Uninitialized PACKET_UNIT_ORDERS)
On 26 February 2013 11:49, Jacob Nevins 0jacobnk.fc...@chiark.greenend.org.uk wrote: Marko Lindqvist writes: [...] Should have added comment at least to remind why exactly so. [...] Where I work, we have a policy that every commit is accounted to a bug like here, but we have an exception for comment-only changes, on the grounds of having the barrier to improving comments be as low as possible (not requiring the overhead of raising a bug etc). We have a special pseudo-job CommentChange to associate such commit with. This generally seems to work for us and is not abused. I've noticed I have a reticence to just comment something I've found because of the bug overhead. Should we do something similar for Freeciv? Could be restricted to more trusted developers (e.g. those with svn access?), and extensive changes touching many files which require some explanation can of course continue to go in regular tickets. The reason I sometimes fail to do minor improvement tickets about things I've noticed while working on something else is simply that my source tree contains the main patch I'm working on, and thus cannot be used to create the minor one. I then sometime forgot the minor thing before have tree free for it (using git would help, I know). But I'm not against making comment-only commits easier if that makes life easier for you. I'd expect ticket still to be raised if there's anything others may want to comment on (i.e., you are not absolutely certain about your new comment) and commit message quality should remain high (usually to contain explanation what was wrong with the old comment) - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20561] Move translations from freeciv-server to the clients.
Follow-up Comment #1, bug #20561 (project freeciv): I've thought about this. Not really practical; consider messages that are currently constructed out of bits (unit names, numbers, ...) on the server and sent as single strings to the client; you'd need to send the format string and arguments to the client to be localised and assembled there; changing any text on the server will lead to incomplete localisation on clients that aren't exactly the same version (unless we somehow keep strings from old servers in the localisations for new clients); any modpack-specific text can currently be localised in one place on the server would remain unlocalised unless you managed to deploy translations to everyone's client; and so on. Another option I've considered is having the client tell the server its locale, and have the server give clients messages in their own locale. I think that's easier than the above, but still fraught; you have to refrain from flattening format strings until the fan-out to individual clients so that you can send different strings to different clients; text saved in savefiles (event cache) is hard; etc. ___ Reply to this item at: http://gna.org/bugs/?20561 ___ 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 #20561] Move translations from freeciv-server to the clients.
Follow-up Comment #2, bug #20561 (project freeciv): What if send client packet with arguments instead the format string like here http://svn.gna.org/viewcvs/freeciv?view=revisionrevision=22161 Is modpack-specific text can be translated now? ___ Reply to this item at: http://gna.org/bugs/?20561 ___ 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 #3755] Road type out increase regardless of terrain
URL: http://gna.org/patch/?3755 Summary: Road type out increase regardless of terrain Project: Freeciv Submitted by: cazfi Submitted on: Tue 26 Feb 2013 06:31:30 PM EET Category: general Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.5.0 ___ Details: This ticket is about resolving one remaining problem in converting river specials as road types. Currently road types have output_incr values and terrain types road_output_incr_pct values. For given road type on given terrain these are multiplied to get the actual increase. Classic rulesets have trade increase for Roads on certain terrains. This is currently converted to gen-roads as having terrain specific pct as 100% for terrains where increase happens and 0% where it does not. At the same time these rulesets have trade increase for Rivers, which applies on all terrains. That is: Road increase happens on different terrains than River increase, while our current format supports only same terrain specific modifier to be used for all road types. I'm still evaluating which way to resolve this is most sensible. Certainlty we are not going to 3D table of (terrain type/road type/output type) bonuses. ___ Reply to this item at: http://gna.org/patch/?3755 ___ 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 #3755] Road type output increase regardless of terrain
Update of patch #3755 (project freeciv): Summary: Road type out increase regardless of terrain = Road type output increase regardless of terrain ___ Reply to this item at: http://gna.org/patch/?3755 ___ 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 #20543] lua error: Execution time limit exceeded in script
Follow-up Comment #4, bug #20543 (project freeciv): Testing my patch I've noticed that there's something wrong with the supposed randomness of it. Every map I create has Scorched Spot and Deep Trench and no other labels while each label should appear with same probability. ___ Reply to this item at: http://gna.org/bugs/?20543 ___ 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 #3741] Use ruleset author flag names in README.effects
Update of patch #3741 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3741 ___ 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 #3756] RFC: UI for building generic roads, bases, etc
URL: http://gna.org/patch/?3756 Summary: RFC: UI for building generic roads, bases, etc Project: Freeciv Submitted by: jtn Submitted on: Tue Feb 26 23:46:55 2013 Category: client Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: (Updated from a [http://mail.gna.org/public/freeciv-dev/2012-02/msg00224.html post to freeciv-dev in Feb 2012.) We now allow rulesets to define arbitrary sets of bases, and from 2.5, roads; we're heading towards all tile extras being handled the same way (see comments in patch #2951). However, we only have a fixed set of keystrokes available in the UI, which is going to be an obstacle to ruleset authors making use of this. For bases, we fudged this for bases with fortress-like / Type A (F) and airbase-like / Type B (E), assigned in the ruleset, but if we're introducing the same generality to much more frequently built infrastructure like roads, we need a better solution, I think. On the one hand, we don't want to restrict rulesets to having at most one valid road-like activity in a given situation (as with the default rulesets) -- I think ruleset authors should have the freedom to have a unit that can build any of five different road types on a given tile at a given time, if they want. Nor should rulesets be penalised by forcing players to go through menus to select activities if the ruleset differs too much from a traditional one -- activities should always be keyboard-selectable. On the other hand, available keystrokes are a scarce resource, so we probably can't give ruleset authors free rein over the entire keyboard -- we need the freedom to assign new keystrokes in future (for activities like convert, or for out-of-game actions). I suspect we'll have to limit all these activities to using R/I/M/F/E. Here's a sketch of a UI design to deal with this: * each activity gets a keystroke specified in the ruleset from the limited pool * each activity within the same keystroke group gets assigned a unique number from 0 to 9 (by the server, or maybe the ruleset) * if a keystroke is ambiguous -- say, R is for both Road and, er, Cycle-path -- then the player can type R followed by 1 for Road and R, 2 for Cycle-path * the game pops up a little menu after R is pressed listing R,1: Road, R,2: Cycle-path to remind/introduce the mappings; this goes away when a number key (or Esc) is pressed * the game tries to spot cases where the keystroke is unambiguous (like today's Road / Railroad -- only one is ever valid, at least for a single unit or units on the same tile) and enacts the relevant activity immediately on pressing R (so simple rulesets don't get the penalty of the multi-level selection system) * keystrokes 0 through 9 do nothing if typed outside of activity selection (so if you type R,1 where Road was the only option, you end up with what you wanted -- you don't have to second-guess whether you're about to press an ambiguous key) This satisfies the following criteria: * Can have lots of activities (up to 10 per keystroke -- still an arbitrary limit, but a much bigger one) * Keystrokes for a given ruleset are discoverable (through the menu system, or the popup when you press R) * But experienced players don't need to use the menus, and keystrokes for a given ruleset can be learned and communicated (R,1 always means the same thing) One of the trickier parts of the above system will be the logic to spot unambiguous situations. However, it doesn't matter if it's not perfect. Would also need to account for connect-with-X, but that seems do-able as an extension to the above. The other awkwardness with bringing the existing irrigation and mines into this system is the terrain conversions that the I and M keystrokes can trigger (e.g., mining grassland to forest). So, terrain conversions would need to be pulled into the above keystroke system, or whatever else anyone suggests. With the above system, there would be no need to restrict given keystrokes to activity classes -- R wouldn't have to be only for roads (although ruleset authors may choose to do it that way). That would allow the I/M keys to retain their current behaviour in the standard rulesets (and probably add O to the pool of available keystrokes). (This idea should probably be considered in combination with the ideas in patch #3713 and bug #16905 -- particularly the ideas of non-focus-stealing popups during keyboard action selection, and entering long strings of orders. But there's no particular reason their implementation would have to happen all at the same time, I think.) ___ Reply to this item at:
[Freeciv-Dev] [bug #20551] failed to compile luasql: not compatible with Lua 5.2
Follow-up Comment #8, bug #20551 (project freeciv): Applying the patch (file #17336) I get cc1: warnings being treated as errors ls_mysql.c: In function ‘cur_nullify’: ls_mysql.c:193: error: no return statement in function returning non-void And indeed that appears to be true. The whole function cur_nullify() is new in the patch. (My normal build has SQLite and MySQL backends enabled, but not PostgreSQL). ___ Reply to this item at: http://gna.org/bugs/?20551 ___ 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 #20551] failed to compile luasql: not compatible with Lua 5.2
Follow-up Comment #9, bug #20551 (project freeciv): (Erm, I should have said that's in dependencies/luasql-2.1.1/src/ls_mysql.c.) ___ Reply to this item at: http://gna.org/bugs/?20551 ___ 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 #20565] automake warning: variable `EXTRA_freeciv_manual_DEPENDENCIES' is defined but...
URL: http://gna.org/bugs/?20565 Summary: automake warning: variable `EXTRA_freeciv_manual_DEPENDENCIES' is defined but... Project: Freeciv Submitted by: jtn Submitted on: Wed Feb 27 00:33:54 2013 Category: bootstrap Severity: 2 - Minor Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: GNU/Linux Planned Release: 2.5.0 ___ Details: Recently I've been getting the following warning when automake runs (e.g. as part of autogen.sh): tools/Makefile.am:45: variable `EXTRA_freeciv_manual_DEPENDENCIES' is defined but no program or tools/Makefile.am:45: library has `EXTRA_freeciv_manual' as canonical name (possible typo) The relevant bit of tools/Makefile.am is: # This is a bit of a hack. The program links in with the server lib # but also uses some files from the client. EXTRA_freeciv_manual_DEPENDENCIES = \ $(top_builddir)/client/helpdata.lo ___ Reply to this item at: http://gna.org/bugs/?20565 ___ 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 #20565] automake warning: variable `EXTRA_freeciv_manual_DEPENDENCIES' is defined but...
Update of bug #20565 (project freeciv): Planned Release: 2.5.0 = 2.4.0,2.5.0 ___ Follow-up Comment #1: Actually this is happening on S2_4 as well (only it's manual/Makefile.am there). ___ Reply to this item at: http://gna.org/bugs/?20565 ___ 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 #20565] automake warning: variable `EXTRA_freeciv_manual_DEPENDENCIES' is defined but...
Follow-up Comment #2, bug #20565 (project freeciv): That's a good warning, the line in question does nothing sensible. It came with bug #20095. It seems like something one meant to do just temporarily while developing/testing the patch (not yet removing dependency list completely, but renaming it to dummy name), but then forgot to final one. ___ Reply to this item at: http://gna.org/bugs/?20565 ___ 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 #3745] Set have_river_overlay correctly in case of road with compat_special = River
Update of patch #3745 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3745 ___ 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 #20553] Units with both icon and orientation sprites display icon everywhere
Update of bug #20553 (project freeciv): Status: Ready For Test = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20553 ___ 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 #3737] Make get_defense_power() static
Update of patch #3737 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3737 ___ 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 #20565] automake warning: variable `EXTRA_freeciv_manual_DEPENDENCIES' is defined but...
Update of bug #20565 (project freeciv): Status:None = Ready For Test ___ Follow-up Comment #3: Fixes attached (file #17355, file #17356) ___ Additional Item Attachment: File name: ManualDepLdadd.patch Size:0 KB File name: ManualDepLdadd-S2_4.patch Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?20565 ___ 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 #20551] failed to compile luasql: not compatible with Lua 5.2
Follow-up Comment #10, bug #20551 (project freeciv): No caller expects return value, so making the return value void. I'm more worried about the fact that this didn't turn out as error in my build. Despite -Werror it shows it just as an warning. (file #17357) ___ Additional Item Attachment: File name: LuasqlEffect230-2.patch.bz2Size:8 KB ___ Reply to this item at: http://gna.org/bugs/?20551 ___ 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 #20567] Lua random() not really random
URL: http://gna.org/bugs/?20567 Summary: Lua random() not really random Project: Freeciv Submitted by: cazfi Submitted on: Wed 27 Feb 2013 09:30:30 AM EET Category: None 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: Noticed in bug #20543. Supposedly random() values in lua script give same result in every game. api_utilities_random() seems unnecessarily complicated. If fc_rand() works as it should, shouldn't min + fc_rand(max + 1 - min) be sufficient here? ___ Reply to this item at: http://gna.org/bugs/?20567 ___ 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 #20567] Lua random() not really random
Follow-up Comment #1, bug #20567 (project freeciv): There must be some problem in how main gameseed is restored after map has been generated (note that it's already restored by the time map_generated lua signal). Actually, if restoring of gameseed worked like it seems to be designed, our new 2.4 feature of trying to generate map with different seed if first fails would not work. The map generation random seed would be the same on the second attempt as on first if main gameseed would have been succesfully restored after first attempt. ___ Reply to this item at: http://gna.org/bugs/?20567 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
