[Freeciv-Dev] [bug #18891] Can't play at all in Kubuntu Oneiric
Follow-up Comment #8, bug #18891 (project freeciv): I also cannot play in oneiric. At least with the gtk2/gtk3 clients, I can start the client but when I click start to begin the game the client hangs indefinitely consuming full CPU. ___ Reply to this item at: http://gna.org/bugs/?18891 ___ 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] compile issues
On Fri, Oct 28, 2011 at 5:30 PM, Matthias Pfafferodt matthias.pfaffer...@mapfa.de wrote: Am Mittwoch, 26. Oktober 2011, 23:25:49 schrieben Sie: On Wed, Oct 26, 2011 at 4:50 PM, Matthias Pfafferodt matthias.pfaffer...@mapfa.de wrote: Am Mittwoch, 26. Oktober 2011, 01:26:49 schrieb Jason Dorje Short: In file included from /usr/include/gtk-2.0/gtk/gtk.h:236:0, from colors.h:16, from chatline.c:44: /usr/include/gtk-2.0/gtk/gtkitemfactory.h:47:1: error: function declaration isn't a prototype [-Werror=strict-prototypes] cc1: all warnings being treated as errors This is a known bug which will not be fixed due to compatibility reasons (see the documentation in ./doc/HACKING). I think the check is important but it prevents building the gtk2 client. On my computer I did change the gtk2 header file to use his debug option but I know this is not always possible ... Yes, it says as much in the header. IMO it is essential that the code compile with --enable-debug=checks; the only solutions therefore are to remove this one check (which seems fine to me) or to make the checks work differently per-directory. The latter would probably be pretty easy actually with a bit of Makefile.am magic and some small changes to debug.m4 - that is, allowing the Makefile.am to set a DEBUG_CFLAGS variable that overrides the default. Could you check the two files in https://gna.org/patch/index.php?2960 ... Which two? And what am I testing them for? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #18872] Freeciv does not compile with clang
Follow-up Comment #1, bug #18872 (project freeciv): The warning you show is a minor bug perhaps, but the real question here is why is compilation using -Werror? You didn't pass --enable-debug=yes or --enable-debug=checks to the autogen / configure script? Or is the non-presence of gcc confusing it somehow? ___ Reply to this item at: http://gna.org/bugs/?18872 ___ 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] compile issues
On Wed, Oct 26, 2011 at 4:50 PM, Matthias Pfafferodt matthias.pfaffer...@mapfa.de wrote: Am Mittwoch, 26. Oktober 2011, 01:26:49 schrieb Jason Dorje Short: In file included from /usr/include/gtk-2.0/gtk/gtk.h:236:0, from colors.h:16, from chatline.c:44: /usr/include/gtk-2.0/gtk/gtkitemfactory.h:47:1: error: function declaration isn't a prototype [-Werror=strict-prototypes] cc1: all warnings being treated as errors This is a known bug which will not be fixed due to compatibility reasons (see the documentation in ./doc/HACKING). I think the check is important but it prevents building the gtk2 client. On my computer I did change the gtk2 header file to use his debug option but I know this is not always possible ... Yes, it says as much in the header. IMO it is essential that the code compile with --enable-debug=checks; the only solutions therefore are to remove this one check (which seems fine to me) or to make the checks work differently per-directory. The latter would probably be pretty easy actually with a bit of Makefile.am magic and some small changes to debug.m4 - that is, allowing the Makefile.am to set a DEBUG_CFLAGS variable that overrides the default. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] compile issues
On Mon, Oct 24, 2011 at 4:33 PM, Marko Lindqvist cazf...@gmail.com wrote: On 24 October 2011 22:20, Jason Dorje Short jdo...@gmail.com wrote: For the first time in some time, I have time for freeciv work. But on compiling, --enable-debug=checks (--enable-debug=yes in older branches) doesn't compile in trunk or in most branches anymore. One issue does seem to be in the GTK header files, both not under our control and commented in the headers as being deprecated in C99 but needed for backwards compatibility. That particular check (-W flag given to gcc) will have to be removed for it to compile. What distribution are you using? Are you using distribution's versions of both gcc and gtk+ (one would assume that those are compatible with each other)? I have no such problems with Debian Wheezy; gcc 4.6.1, gtk2 2.24.6 Ubuntu oneiric. $ gcc --version gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 $ dpkg -l | grep libgtk2.0-dev ii libgtk2.0-dev 2.24.6-0ubuntu5 Development files for the GTK+ library In file included from /usr/include/gtk-2.0/gtk/gtk.h:236:0, from colors.h:16, from chatline.c:44: /usr/include/gtk-2.0/gtk/gtkitemfactory.h:47:1: error: function declaration isn't a prototype [-Werror=strict-prototypes] cc1: all warnings being treated as errors -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #18217] GCC 4.6: variable 'xxx' set but not used
Follow-up Comment #9, bug #18217 (project freeciv):
Attached patch fixes trunk for me. I had to disable one warning, which
conflicts with gtkitemfactory.h:
/* We use () here to mean unspecified arguments. This is deprecated
* as of C99, but we can't change it without breaking compatibility.
* (Note that if we are included from a C++ program () will mean
* (void) so an explicit cast will be needed.)
*/
typedef void(*GtkItemFactoryCallback) ();
I also added a macro for marking unused variables within iterate macros. For
instance:
adjc_dir_iterate(tile0, tile1, dir) {
array[dir] = 1;
} adjc_dir_iterate_end;
the tile1 variable is unused, and really can't be used nor is it worthwhile
to write a new iterator for this case. (This was mentioned earlier in the bug
as well.) Adding UNUSED_VAR(tile1) marks it as unused for both the compiler
and should be good for coders reading it as well.
#define UNUSED_VAR(x) (void)(x)
There is probably a better definition that could be used here however.
Finally there is one location in api_server_edit.c where a return value looks
to me like it should be checked, but since it wasn't it triggered the warning.
I added a FIXME there but am not familiar enough with the code to know if
it's actually a problem.
(file #14260)
___
Additional Item Attachment:
File name: fix_compile_warnings_trunk.diff Size:13 KB
___
Reply to this item at:
http://gna.org/bugs/?18217
___
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] compile issues
For the first time in some time, I have time for freeciv work. But on compiling, --enable-debug=checks (--enable-debug=yes in older branches) doesn't compile in trunk or in most branches anymore. One issue does seem to be in the GTK header files, both not under our control and commented in the headers as being deprecated in C99 but needed for backwards compatibility. That particular check (-W flag given to gcc) will have to be removed for it to compile. Another common issue is a seemingly new catch by the compiler of unused variables that are set but never used. Many of these are accidental but some happen in iterate loops where a variable is provided but not used within the loop. For this I propose a macro to mark the variable as unused, which will tell both the compiler and the reader what's going on. My first task will be making up a patch for this, which IMO should be taken care of before the branching. If there's anything else I should look at though let me know. I'm on irc (#freeciv-dev on irc.freenode.org) if anyone wants to discuss in realtime. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16964] Mfg. Plant + electrical plant bonus does not match Help
Follow-up Comment #3, bug #16964 (project freeciv): For older versions of the game, it might be best to change the rules to match what the docs say - otherwise they'll probably stay wrong for lots of languages. For the new release though, go with the simplest rules IMO. ___ Reply to this item at: http://gna.org/bugs/?16964 ___ 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 #16797] Segmentation fault in tile_city()
Follow-up Comment #6, bug #16797 (project freeciv): Yep good catch. The actual bug is in the final loop at the bottom of the function but using ptile throughout does make it easier to read. I'm also going to set punit = NULL right before the loop so any future bugs of this kind trigger immediately, and add a comment and fix indentation. ___ Reply to this item at: http://gna.org/bugs/?16797 ___ 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 #16797] Segmentation fault in tile_city()
Update of bug #16797 (project freeciv): Severity: 3 - Normal = 5 - Blocker Status: Ready For Test = Fixed Assigned to: pepeto = jdorje Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?16797 ___ 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 #16775] lot of errors of type 'get_defender bug'
Follow-up Comment #8, bug #16775 (project freeciv):
--- server/unithand.c (revision 18197)
+++ server/unithand.c (working copy)
@@ -1409,7 +1409,9 @@
}
/* The attack is legal wrt the alliances */
-victim = get_defender(punit, pdesttile);
+if (is_attack_unit(punit)) {
+ victim = get_defender(punit, pdesttile);
+}
I think this part is wrong. By letting victim stay as NULL, this allows the
move to proceed. But this is the case where an explorer is trying to move
into an enemy tile which should not be allowed. I think the move needs to be
denied with a return call, as happens in a lot of places higher up in that
function.
-jason
___
Reply to this item at:
http://gna.org/bugs/?16775
___
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 #16836] Typo in norman.ruleset
Update of bug #16836 (project freeciv): Status:None = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?16836 ___ 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 #16362] ggz page gives Gtk-WARNING
Follow-up Comment #2, bug #16362 (project freeciv): I'll take a look at this next week. Some of the GTK errors in ggz-gtk though are due to deprecated widgets and hard to fix. If anyone good with GTK code would like to help out it'd be welcomed. Sorry for the spam: this comment was from me. ___ Reply to this item at: http://gna.org/bugs/?16362 ___ 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 #16362] ggz page gives Gtk-WARNING
Follow-up Comment #4, bug #16362 (project freeciv): Find me on irc sometime to discuss. ___ Reply to this item at: http://gna.org/bugs/?16362 ___ 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 #16318] strict aliasing and warnings
Follow-up Comment #1, bug #16318 (project freeciv): Pointer type casts like that are generally to be avoided in C, in my experience. Agreed that the generated files should be removed by 'make distclean'. ___ Reply to this item at: http://gna.org/bugs/?16318 ___ 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] Progress towards full ANSI C89 compatibility
On Tue, Jun 1, 2010 at 1:55 PM, Tim Reid standsthechurchcl...@gmail.com wrote: I was interested to see an impressive amount of work done on this project, and might be interested in contributing something along the lines of development, testing and/or documentation. I've started to have a look through the source, to get some idea of what's going on, and I've been pleasantly surprised that it mostly meets the stated goal of ANSI compatibility. Having some extensive experience writing portable C it seems like a useful exercise to learn about what code does what by making some of the few changes necessary to put it closer to achieving C89 conformance. Any objections? Some time ago we decided that sticking with C89 wasn't flexible enough. We began introducing C99 features; however each one is tested for at configure time. For the most part, I don't think removing these features would be a good thing. The specific features are variadic macros, variable arrays, struct/array initializers, and requiring the presence of stdint.h. See m4/c99.m4 for the checks for these. Within that context, improvements to the conformance of the code would surely be welcome. Specifically any non-C99 non-portable features should be removed if possible, and any other C99 features that are used should have checks added for them. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #15825] ggz page halted client
Update of bug #15825 (project freeciv): Assigned to:None = jdorje ___ Reply to this item at: http://gna.org/bugs/?15825 ___ 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 #1582] UTF-8 utilities
Follow-up Comment #4, patch #1582 (project freeciv): Truncation is fundamentally unavoidable unless we strdup-printf every string we make everywhere, which isn't going to happen. We can cut down on it by making buffers sufficiently long. ATM there is an issue with MAX_LEN_NAME. This is supposed to limit city names, for instance, at 32 characters. Instead it limits then at 32 bytes which is incorrect. Most places which use it should instead use a longer or malloc'd buffer, and use fc_utf8_strlen() to make sure the name isn't too long. The server should use utf-8 validation on all strings received from the client, or read from ruleset or savegame. The client should if possible use utf-8 validation on strings received from the server. How to handle invalid strings may depend on the situation; in most cases they can just be truncated. Having said that, I'm not too sure of the interface pepeto is presenting. * How do we know just because a character is 4 bytes long that bytes 2-4 are valid? Does UTF-8 allow any byte sequence in here? What about malicious chats from the client? * Casts should not be needed in passing values to these functions. Doing so is a sign the parameters used are not right. In fact I think one such case is quite wrong. * Each function provided should do everything that it needs to. Specifically, fc_utf8_char_size is not a useful function in its current form (except for internal usage). * Are we sure that using these variants everywhere is easier than converting all freeciv to wide characters? ___ Reply to this item at: http://gna.org/patch/?1582 ___ 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 #15825] ggz page halted client
Follow-up Comment #1, bug #15825 (project freeciv): Without a backtrace on this it'll be really hard to do anything with it. If it ever happens again, give the client a SEGV (killall -SEGV freeciv-gtk) and get a backtrace from the resulting core file. ___ Reply to this item at: http://gna.org/bugs/?15825 ___ 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 #15832] trunk will not compile
URL: http://gna.org/bugs/?15832 Summary: trunk will not compile Project: Freeciv Submitted by: jdorje Submitted on: Saturday 04/10/2010 at 01:05 Category: agents Severity: 5 - Blocker Priority: 9 - Immediate Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: ___ Details: $ /autogen.sh --enable-debug=some --enable-client=all --with-ggz-server --with-ggz-client make ...and a bit down... cma_fe.c: In function ‘select_preset’: cma_fe.c:495: warning: implicit declaration of function ‘log_assert_ret’ cma_fe.c: In function ‘sliders_scroll_callback’: cma_fe.c:639: error: too few arguments to function ‘cm_result_destroy’ This isn't from a pristine directory. -jason ___ Reply to this item at: http://gna.org/bugs/?15832 ___ 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 #15816] add a comment about a needed empty line in the nation.ruleset file
Follow-up Comment #3, bug #15816 (project freeciv): If an empty line is required there should be a comment in the file. I see the patch but isn't the empty line above the comment, making the comment actually wrong? And which versions (1.14 and on) does this apply to? Secondly, it does sound like it should be fixed. Why is an empty line required anyway? Can we remove that limitation for trunk? ___ Reply to this item at: http://gna.org/bugs/?15816 ___ 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 #15801] fix some S2_0 compiler warnings
Follow-up Comment #1, bug #15801 (project freeciv): This second attached patch does the same for 1.14. (file #8828) ___ Additional Item Attachment: File name: compile-warnings-1.14.diff Size:12 KB ___ Reply to this item at: http://gna.org/bugs/?15801 ___ 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 #15809] Non-localized string in city dialog
Update of bug #15809 (project freeciv): Status: Ready For Test = Fixed Assigned to:None = jdorje ___ Reply to this item at: http://gna.org/bugs/?15809 ___ 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 #15809] Non-localized string in city dialog
Update of bug #15809 (project freeciv): Category: client-gtk-2.0 = client ___ Reply to this item at: http://gna.org/bugs/?15809 ___ 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 #15809] Non-localized string in city dialog
Update of bug #15809 (project freeciv): Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?15809 ___ 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 #15808] Cosmetic English grammar/spelling/typographical fixes in strings
Follow-up Comment #1, bug #15808 (project freeciv): Good eye. Should it be struck by plague instead of struck by a plague? I guess it's correct either way. Also, bug #15802 should be lumped in with these. ___ Reply to this item at: http://gna.org/bugs/?15808 ___ 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 #15513] Put 'All' nations tab at the bottom
Update of bug #15513 (project freeciv): Status:None = Need Info ___ Follow-up Comment #1: Agreed. ___ Reply to this item at: http://gna.org/bugs/?15513 ___ 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 #15502] Translation Illegal treaty ... they already have this treaty level
Update of bug #15502 (project freeciv): Severity: 2 - Minor = 3 - Normal ___ Follow-up Comment #3: It sounds to me like there's some deeper issues than just the translation. Do you have a savegame and instructions that can reproduce this problem? And can you tell us what language is triggering it? ___ Reply to this item at: http://gna.org/bugs/?15502 ___ 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 #15741] SDL client crashes in build dialog
Follow-up Comment #12, bug #15741 (project freeciv): I still have no idea how to actually reproduce this or tell if the patch fixes it. It's up to you to verify and commit it. ___ Reply to this item at: http://gna.org/bugs/?15741 ___ 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 #14205] Bug with utf-8
Update of bug #14205 (project freeciv): Assigned to:None = jdorje ___ Reply to this item at: http://gna.org/bugs/?14205 ___ 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 #15738] map view not centered at the start
Follow-up Comment #13, bug #15738 (project freeciv): Agreed; that's just what I was going to suggest. On resizing the mapcanvas it is the center that should be preserved. However this could run into problems in the GTK client as it can be sized up/down in small increments quickly which would lead to lots of redraws. As a side note, perhaps when the mapcanvas is shrunk, the backing store should not also be shrunk. Then the buffering would be more efficient in such cases. -jason ___ Reply to this item at: http://gna.org/bugs/?15738 ___ 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 #15738] map view not centered at the start
Follow-up Comment #15, bug #15738 (project freeciv): Moving the upper left corner will lead to a much bigger redraw than will happen if the top left remains fixed. ___ Reply to this item at: http://gna.org/bugs/?15738 ___ 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 #15741] SDL client crashes in build dialog
Follow-up Comment #10, bug #15741 (project freeciv): Probably. I'll be more careful in future, and sorry about the inconvenience. ___ Reply to this item at: http://gna.org/bugs/?15741 ___ 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 #15747] bizarre compile error in gtk2 popup_pillage_dialog
Follow-up Comment #3, bug #15747 (project freeciv): Looks like just trunk is affected. ___ Reply to this item at: http://gna.org/bugs/?15747 ___ 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 #15741] SDL client crashes in build dialog
Update of bug #15741 (project freeciv): Status: Ready For Test = Need Info Assigned to: pepeto = None Planned Release:2.1.12, 2.2.1, 2.3.0 = ___ Reply to this item at: http://gna.org/bugs/?15741 ___ 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 #15741] SDL client crashes in build dialog
Update of bug #15741 (project freeciv): Status: Ready For Test = Need Info Planned Release:2.1.12, 2.2.1, 2.3.0 = ___ Reply to this item at: http://gna.org/bugs/?15741 ___ 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 #15741] SDL client crashes in build dialog
Update of bug #15741 (project freeciv): Status: Ready For Test = Need Info Planned Release:2.1.12, 2.2.1, 2.3.0 = ___ Reply to this item at: http://gna.org/bugs/?15741 ___ 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 #15741] SDL client crashes in build dialog
Follow-up Comment #8, bug #15741 (project freeciv): I only intentionally changed it to assign it to you. Perhaps I was working off an outdated version of the page itself and it reverted other fields? ___ Reply to this item at: http://gna.org/bugs/?15741 ___ 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 #15747] bizarre compile error in gtk2 popup_pillage_dialog
URL: http://gna.org/bugs/?15747 Summary: bizarre compile error in gtk2 popup_pillage_dialog Project: Freeciv Submitted by: jdorje Submitted on: Monday 03/29/2010 at 15:12 Category: client-gtk-2.0 Severity: 4 - Important Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: GNU/Linux Planned Release: ___ Details: With --enable-debug=yes dialogs.c: In function ‘popup_pillage_dialog’: dialogs.c:371: error: array subscript is above array bounds dialogs.c:371: error: array subscript is above array bounds ___ Reply to this item at: http://gna.org/bugs/?15747 ___ 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 #15747] bizarre compile error in gtk2 popup_pillage_dialog
Follow-up Comment #1, bug #15747 (project freeciv): As far as I can tell the message is in error. Replacing either one of the what - S_LAST - 1 formulas with just what fixes it. But replacing both breaks it again. This is either the cause of a compiler bug (unlikely) or a hidden bug somewhere else in this function that's triggering it. As a workaround, this patch also seems to stop the warning. (file #8733) ___ Additional Item Attachment: File name: mod.diff Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?15747 ___ 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 #15741] SDL client crashes in build dialog
Follow-up Comment #2, bug #15741 (project freeciv): Unfortunately I can't reproduce it. All I can say is that I was clicking around a lot in the change-production dialog when it happened. I don't believe any relevant code changes have happened since then (which was a few moments before I reported it). ___ Reply to this item at: http://gna.org/bugs/?15741 ___ 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 #15377] freeciv-gtk2.exe hangs
Follow-up Comment #20, bug #15377 (project freeciv): The patch I sent should fix bug #15658 which appears to be the same as this one. However rather than that patch I think someone should take the time to write proper ascii versions of those functions, just in case we end up with a non-superset-of-ascii locale some day. But I guess that's unlikely so it shouldn't really matter. -jason ___ Reply to this item at: http://gna.org/bugs/?15377 ___ 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 #15377] freeciv-gtk2.exe hangs
Update of bug #15377 (project freeciv): Operating System:None = Microsoft Windows ___ Reply to this item at: http://gna.org/bugs/?15377 ___ 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 #14205] Bug with utf-8
Follow-up Comment #6, bug #14205 (project freeciv): There is not any culprit other than the too-small buffer. MAX_LEN_NAME+8 is an incorrect byte length since the translated text is not a player name and has no fixed limit; the buffer is just too small. At 40 bytes it is easily enough to fit any real player name but that can be just 10-20 characters in some languages which is not enough. It's a bit of an inconsistency that MAX_LEN_NAME is used in various places as a byte limit (rather than a character limit) on leader/city/ruler names, but this hasn't been a problem so far and is unrelated to this bug report. Do feel free to improve the spacing; using correct spacing leads to a too-long line so I shortened it. From the screenshot, the translated text *is* a bit too long for the column. This isn't a bug but does make for a bad interface, and if the translator can shorten it he should. Hence the TRANS comment. If we really prefer not to use g_strdup_printf we can instead make the buffer really really long. Remember though that utf-8 strings can take up to 4 bytes per character, that here is no fixed limit on how long any translated text may be, and that truncation can potentially cause crashes within gtk2 while making it overlong just makes the interface ugly which the translator can then easily see and fix. I prefer the strdup approach for the client. So in summary, this patch should be all that is needed to fix the problem. I'm preparing a similar patch to fix a lot of other places (several i've noticed will surely trigger this same bug eventually if not fixed). ___ Reply to this item at: http://gna.org/bugs/?14205 ___ 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 #14205] Bug with utf-8
Follow-up Comment #7, bug #14205 (project freeciv): The attached patch improves buffering in many places using g_strdup_printf instead of fixed-width buffers. In a few locations this was too much work so I just made the buffers bigger instead. As previously mentioned, in several places the current buffers are certainly too small and will trigger bugs if not fixed. (file #8723) ___ Additional Item Attachment: File name: buffers.diff Size:30 KB ___ Reply to this item at: http://gna.org/bugs/?14205 ___ 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 #15741] SDL client crashes in build dialog
URL: http://gna.org/bugs/?15741 Summary: SDL client crashes in build dialog Project: Freeciv Submitted by: jdorje Submitted on: Monday 03/29/2010 at 00:33 Category: client-sdl Severity: 4 - Important Priority: 7 - High Status: Need Info Assigned to: None Originator Email: Open/Closed: Open Release: trunk Discussion Lock: Any Operating System: GNU/Linux Planned Release: ___ Details: Current trunk build. I'm playing a game and in the SDL client shift-click (I think) on colossus. That is to say, within the city dialog I went to change production, and I was playing around with various clickings to try to get the help to come up (which never happened) and after 30 seconds or so it crashed. 1: in copy_chars_to_string16() [gui_string.c::196]: assertion 'pString != ((void *)0)' failed. The above line is output many times, though I'm not sure it's actually related to the crash. Unfortunately I had core files turned off so no backtrace available on this one. ___ Reply to this item at: http://gna.org/bugs/?15741 ___ 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 #15377] freeciv-gtk2.exe hangs
Follow-up Comment #10, bug #15377 (project freeciv): Actually I came to the exact same conclusion Ulrik: we should simply rewrite the character functions to work only on ascii (range 0 to 127) characters, and leave others alone. Using the system-provided functions (such as tolower) which work in the current locale makes no sense and never will make sense. This means some UTF8 characters wont get properly converted which will cause minor bugs (for instance it wont do proper case comparison on non-ascii letters in player/ruler names), but will remove a much larger set of bugs (for instance it may currently do wrong case comparison on those same non-ascii letters). As for making or using a UTF-8 variant for these, it's a bit more complicated than that. You can't have isspace() or tolower() or isalpha() functions in utf8 that go byte-by-byte. This means the same job you were doing via byte iteration over the string has to be done entirely differently, in every case. Additionally, some of the places these functions are called they are given utf-8, some they are given ascii, and in some they may be given latin1 or a different character set - so again it all requires careful auditing of the users in that case, of which there are a lot. If we go that route I'd rather rewrite all freeciv core to use ucs2 or ucs4 (fixed-width unicode) strings and impose that on these functions, and then we get type-checking out of it as well. This wouldn't be that hard but then we have to convert all data files (in utf-8) and all GUI strings (also in utf-8, for gtk2) on both input and output, everywhere, which is a lot of lines of change. It's probably overkill. ___ Reply to this item at: http://gna.org/bugs/?15377 ___ 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 #15377] freeciv-gtk2.exe hangs
Follow-up Comment #11, bug #15377 (project freeciv): And, unfortunately limiting the functions to ascii-only is not going to work very well either for the is_ functions. is_alnum is most likely used for instance to check for valid ruler/city names and will fail on any non-ascii names now. Even if we add exceptions for any ruler/city names in the ruleset (probably already done) it's not desirable for any non-latin-alphabet players. Nonetheless here's the patch for it (very simple patch; someone might want to actually rewrite the functions to do the work directly for ascii). Out of curiosity, if I made a patch to switch freeciv's internal encoding (client, server, and network encoding) to UCS2/UCS4, would the change be supported by the current developers? Also as a side note, libc does include support for wide characters. However it's not defined what character set this actually is so we still have the current locale issues which is no good since we want to use the same character set at both client and server. -jason (file #8662) ___ Additional Item Attachment: File name: char.diff Size:2 KB ___ Reply to this item at: http://gna.org/bugs/?15377 ___ 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 #15377] freeciv-gtk2.exe hangs
Follow-up Comment #16, bug #15377 (project freeciv): Having 2 sets of functions is trickier than it sounds. For one, you have to be extremely careful which you use where. For a second, neither one should really be using the libc character functions. And for a third, the functions we're talking about _cant_ be written for variable-width character sets like utf-8 so they all have to be replaced with string variants. I took a look at doing this but it's just way too many places and too wide a spectrum of the codebase affected to do so without upping the bug rate. Glib or libutf8 can provide some help on some of these functions, I do believe. We dont have glib as a requirement for server compilation however, though it wouldnt be a big deal to add it. To change the internal encoding to ucs4 I would introduce a new typedef, typedef uint32 fc_char into fciconv.h. The majority of internal strings then get changed from char[] to fc_char[]. String conversion is mostly done already via the fciconv or gettext functions, but what would have to be added is conversion of all data files read (from utf8/ascii into ucs4) and to all gui strings (again between ucs4 and utf8, both ways and in a lot of places). Perhaps the biggest challenge though would be server-generated strings, which can't use sprintf but instead will need a ucs4 version of the same (probably available through an external library). -jason ___ Reply to this item at: http://gna.org/bugs/?15377 ___ 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 #14205] Bug with utf-8
Follow-up Comment #2, bug #14205 (project freeciv): How can I reproduce this? ___ Reply to this item at: http://gna.org/bugs/?14205 ___ 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 #14205] Bug with utf-8
Follow-up Comment #4, bug #14205 (project freeciv): Ah, well that's simple. It's a simple bug in update_conn_dialog that doesn't check the width of the AI name, probably a remnant from before when they were given artificial player names. Attached patch will fix this. It is likely to occur in many other places as long as we try to snprintf translated strings into fixed-width buffers; g_strdup_printf is the easy alternative for use in the gtk2 client. However it's also the case that the translation should probably be made shorter (in characters, not bytes) so that it doesn't make the dialog expand to fit it; the updated TRANS comment reflects this. -jason (file #8699) ___ Additional Item Attachment: File name: ai_name.diff Size:1 KB ___ Reply to this item at: http://gna.org/bugs/?14205 ___ 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 #15377] freeciv-gtk2.exe hangs
Follow-up Comment #5, bug #15377 (project freeciv): Yep, that is surely correct. These functions check whether c, which must have the value of an unsigned char or EOF, falls into a certain character class according to the current locale. Each of the character function wrappers in support.[ch] works only on characters in the current locale, which in freeciv parlance is the local encoding, and generally not the same as UTF-8 at all. In other words, these functions cannot be used on nearly all freeciv strings without causing these problems. Replacing these is not an easy task. Their very nature is to operate byte-by-byte, but with freeciv using utf-8 internally this is not possible. One alternative used elsewhere is to convert the utf-8 string to a fixed-width encoding such as UCS2 (similar to utf-16) or UCS4 (similar to utf-32) which can then be operated on byte-by-byte, but since that is also not the current locale the functions will not work on those characters either. Having all of Freeciv use ucs4 internally could even be an option, discussed previously that would prevent all such problems as there could then be no confusing internal strings from current locale strings; however, this would require a LOT of work and has been dismissed in the past. Additionally there may be a few locations where the text is ascii and the character functions will and should be used. Maybe. I'll take a look at where these functions are used and what might be done about them. -jason ___ Reply to this item at: http://gna.org/bugs/?15377 ___ 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 #15377] freeciv-gtk2.exe hangs
Follow-up Comment #1, bug #15377 (project freeciv): The catalan.ruleset is in utf8, in both S2_2 and trunk. This is correct and all characters are utf8. It's loaded into the server where it remains utf-8. It's then sent over the network in utf-8. It's received by the client and converted by iconv into the client encoding which is also utf-8. It's then sent to gtk2 as utf8. The isutf8 program can be used to confirm that files are in utf8. All ruleset, data, and code files should be in utf8. In fact the only text files that may be non-UTF8 within freeciv is the translations which have their codeset listed at top (even these may be utf-8, which should be encouraged). But using this utility does not show up any invalid files. So I dont see where this can be going wrong. It could be caused by a bug in windows GTK or windows iconv as i have heard this is not reproducable on other platforms with the GTK2 client. It might also be a bug in windows use of iconv, if it is trying to convert it out of utf-8 for some reason, but in that case the bug should probably show up on other platforms and other rulesets. Thirdly it could be an issue only triggered by 64bit; the other bug reports windows7 64bit but this one just says windows vista. I do notice the documentation on this is limited and in some cases incorrect. I'll make a patch to improve this. -jason ___ Reply to this item at: http://gna.org/bugs/?15377 ___ 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] Remove unmaintained clients
On Sat, Jan 2, 2010 at 1:30 PM, Pepeto pepet...@gmail.com wrote: I guess those removal would be a solution to speed up the development of Freeciv which is very slow nowadays. There cannot be more clients than active developers! Rather than preemptively remove them, IMO just label them as unmaintained and dont worry about compatibility when making core changes anymore. Either someone will notice the lack and step up to keep them up-to-date (they only really need minor updates before releases) or eventually they'll be outdated and can be removed. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] Translation Text
On Wed, Sep 23, 2009 at 6:25 AM, Marko Lindqvist cazf...@gmail.com wrote: Adding translator list to cc 2009/9/22 Jordi Negrevernis i Font jnegrever...@jnfprogramari.com: String found in es.po after running 'update po' or alike... By changing this option you change the active theme. This is the same as using the -- --theme command-line parameter. Would it be?: using the --t --theme command-line parameter. Short answer: Current string is technically correct, but maybe meaning is not very clear. Client gets two kinds of command-line parameters: those handled by client common code, and those specific to certain client. -- means that following parameters are not to be handled by common code but should be passed to client specific library. --theme is specific to SDL-client, so you would set theme for it like freeciv-sdl -- --theme human or freeciv-sdl -- -t human (freeciv-sdl is executable name in S2_2/trunk). -t means --tileset in client common side, so you can even have freeciv-sdl -t amplio -- -t human How about using %s so the translator doesnt have to worry about translating that part? By changing this option you change the active theme. This is the same as using the %s command-line parameter. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #1306] AI: Count all attacks to invasion.attack, not only 1 / unit
Follow-up Comment #3, patch #1306 (project freeciv): This seems like it should imbalance things in the other direction, and a lot further than the current inaccuracy. Though a ship may be able to attack 5 times, with decreasing health after each attack its usually only viable to hit 1-2x. So if you count each ship as 5 units that's going to give a vastly higher estimate of your attacking power than is accurate. ___ Reply to this item at: http://gna.org/patch/?1306 ___ 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] compilers that aren't C99
We made the decision a few years ago to support some of the features of C99, with a check for each. Variable-length arrays was one of them, and a very useful one in a lot of the code it's used in. I don't think we should go back. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40591) [Patch] Make tired attack a ruleset option
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40591 Offhand I recall the major issue with this was the AI, which would persistently waste units attacking while tired and without chance of victory. However you'd think the AI would do success-chance calculations which would include the tiredness penalty...? But I'd suggest checking it out and see if there are indeed problems there. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40581) [RFC] Remove all request_id stuff
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40581 I thought the request_id was intended to associate a packet sent to the client with the particular request that the client had sent to the server. Perhaps I digress, but - for instance: the player requests to buy something. The client does the check and finds the buy to be legit. It sends the buy request to the server. At the server end the buy succeeds and the city state changes, or perhaps the buy fails and a failed-buy packet (very rare as the client catches most such instances) would happen instead. Now at what point does the client state change? I don't know the current situation actually but there's two ways to do it. 1. When the client approves the buy and sends the info to the server, it goes ahead and updates the city info with the purchase. The server will most likely re-send the same info in a packet, which will result in, most likely, no change and no later update. However if the purchase fails at the server end the server needs to send a buy-failed packet which the client connects to the original buy attempt (very tricky and uses the request_id) and reverts the buy, or the server resends the original city info (which is actually an empty packet and all handled within the delta network code). The advantage is this works as well or better in all cases: only in the case of a failed buy is it any worse, and in the case of a high-lag connection it's better than case 2. The drawback is that the client needs much better checking of the purchase validity - including checking the game phase (not to buy in the middle of a turn-done or to avoid buying in one turn but through lag having the server handle the buy next turn). 2. When the server approves the buy and sends the city info back to the client, the client only then updates the purchase. This is, of course, safer and more reliable. But if there's a high-lag connection it'll be a lot less user-friendly - potentially cripplingly so. The saferness comes into play when a purchase fails at the server end; with case 1 you'd have the client incorrectly update the city info itself then receive the new (original) info back again and revert. Such situations would be rare however; they can happen with some rulesets or server mods maybe but are most likely to happen if the player tries to buy right as the turn ends and the server doesn't handle the request til the following turn. Okay having given that example, I still don't see a use there for the request_id. So how is it used again? Just as an outdated variant of the freeze/thaw mechanism? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] freeciv-web
Can you elaborate more on the freeciv-web application? What's the difference between that and gui-web? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] freeciv-web
Okay, I admit at the start that I've missed a lot of discussion on this, so I may be quite ignorant about what's going on. The freeciv-web interface seems conceptually sound, and at least partially playable (I haven't played more than a couple turns with it). But where's the code? In the branches of svn we have an old version of it, and it looks to me like it works straightforward as another gui-xxx directory. So what's holding us back from integrating it into trunk? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40508) Remove trunk
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40508 Tonight I intend to delete trunk, replacing it with the S2_2 branch. I'll be on irc for it if anyone wants to discuss. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40514) [patch] add Windows Unicode function support
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40514 I have to say, those changes are ugly. They'd be a lot better if some comments explained what was going on. Why can't iconv do these conversions, by setting the internal encoding to ucs-2? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40508) Remove trunk
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40508 No objection from here. I spent a fair chunk of time comparing diffs from 2.2 and trunk to see if the development branch had any patches that were missing from 2.2. I found a few minor ones (all mine IIRC) but eventually bogged down in the large diff. I'd say after another examination of the differences if you can't find anything we should feel free to delete move. I'm not at a development box until the 11th when I get back home. However if you examine the branches and give the go-ahead I can do the SVN operations through the cvs.freeciv.org machine if you like. For the record, I think the process would be: svn delete .../trunk svn move .../S2_2 .../trunk Does that sound right? It might be remove instead of delete. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40507) Civ2 to Freeciv scenario converter (alpha)
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40507 Would it be possible to make the savegame.c interface modular, so that freeciv could directly load multiple savegame formats? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40495) Server sends too much player infos
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40495 This is a significant bug and should be backported, possibly even back to 2.0. To avoid crashes maybe a placeholder data could be sent instead? Like anarchy rather than NULL government. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40489) animated png?
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40489 On Mon, Sep 15, 2008 at 6:58 PM, François Marlier [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=40489 Maybe some of you have already seen these http://labs.mozilla.com/2007/08/better-animations-in-firefox-3/ http://littlesvr.ca/apng/ apng extended libpng with backward compatibilty to allow animated png. It's just a matter of patching libpng. Maybe this could be of interrest to smoothly animate some tiles (like water) without eating too much CPU/GPU ressources? Perhaps. We still need the graphics to be made in the first place though. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40420) Editing mode allows adding units/cities to dead player
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40420 Or it could bring the dead player back to life...could be desirable for scenario editing but is a bit more work to code I'm sure. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40416) latest freetype2.m4 update requires autoconf 2.58
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40416 I quick google search indicates the AS_HELP_STRING use may be a typo: possibly just changing it to AC_HELP_STRING will fix things. Though I don't know that we want to be fiddling with imported m4 files. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40411) Bug: irrigation has no effect
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40411 On 7/27/08, Frank Van Geirt [EMAIL PROTECTED] wrote: I would like to report a bug. When my workers irrigate grassland the food production stays at 2. It should be 3. I irrigated next to ocean squares and river squares. Road building and mining seems to work fine. I am using freeciv-2.1.5. I compiled it myself, as the pre-compiled version from the Fedora 9 repository doesn't work. That's not a bug. Under despotism or some other governments, a -1 penalty is imposed on all production 3 or higher. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] borders and fog of war
Some games give the option of showing enemy start positions. This would potentially show the enemy's first city as fogged terrain, for instance. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40177) [Patched] Shared common library
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40177 On Sat, Jul 26, 2008 at 10:51 AM, Andreas Røsdal [EMAIL PROTECTED] wrote: I'm wondering if a shared common library, as implemented in this patch, would reduce the memory usage when running many civclient processes on the same system? The web client prototype launches one civclient process for each user, so if using a shared library could reduce the memory usage, this would be very useful for that. In theory it shouldn't. A modern operating system should share pages for the read-only parts of an application that has multiple invocations running. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40408) [Patch] Updating problem in trunk when capturing enemy cities
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40408 On Sat, Jul 26, 2008 at 7:47 PM, Nicolas R. Wadhwani [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=40408 Hi, In current trunk version if you capture an enemy city it still looks like it would belong to the previous owner before you captured it. Only if you would quit the game and rejoin/reload the captured city would appear in your city list and become accesible for changing the worklist, worker placement etc. Yep. This is because the handle_city_info function depends on noticing a change of owners between the current known owner of a tile and the new owner of the city sent by the server. However, this change of ownership is currently handled by handle_tile_info previously before the city info packet arrives. The result is that the borders and all are calculated correcty and updated immediately, but once the new packet for the change of the city ownership comes in the client assumes the owner remained the same because the tile already belongs to the player the server is sending as new owner. The check simply needs to be fixed. Whatever it is that's causing the city to be displayed as enemy is what needs to be checked for. This problem could probably alternatively solved by changing the order in which the packets are send by the server, but this would be a bit more complicated and inhibits the risk of messing up something I just don't see now that crucialy depends on updating the tiles before the cities or I dunno what else. Depending on the order of packets being correct is, in general, very bad. Each packet should be independent. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40316) enemy cities not shown in fogged tiles
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40316 Indeed Marko is right; this is a server problem after all. You should be sending the city ID of the dumb city. This code has been rewritten however and apparently I no longer have any clue how it works. See maphand.h. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] borders and fog of war
The problem we had before was this: * All borders were drawn. * Border information was only given for visible tiles. * The end result was that you couldn't see many tiles that you owned, causing a massive patchwork of borders within your own territory as you re-explored it. * Also when an enemy city changed hands and you re-explored that territory, it would cause a similar patchwork. It would be obvious to the player that a city was owned by the enemy but the display wouldn't know it yet since that tile hadn't been re-explored. There might be some way around this by clever adjustments to the display algorithm. For instance ptile-source could give the border source so any time a player discovered a changed tile the player map would toggle that city's owner and all borders owned by it. All borders would then be done in clumps rather than tile-by-tile. Another idea of course is to give full vision to tiles you own, which does indeed make plenty of sense - though it does not prevent enemies from finding your borders invisibly, as they don't have to enter your territory to see it. Yet another idea would be to give passive updates to tiles you own (keeping it fogged but re-updating all information, I believe this is the update_tile_knowledge() function or some such). This would prevent any patchwork issues on your own borders as you'd know about them expanding even though the tile was fogged. Some combination of these could be better than what we have now. But any new design must be thought out and then carefully playtested. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40316) enemy cities not shown in fogged tiles
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40316 On Wed, Jul 23, 2008 at 6:13 PM, guest user Freeciv wrote: There is the catch: Between the versions the ptile-city member has been replaced by ptile-worked which points to the city working on the tile, so many tiles are pointing to the same city (in the city radius I suppose). That was a terrible idea. Though I suppose at first glance it must have seemed attractive enough. Question: if you disconnect and reconnect to the server, are the fogged cities shown then? I cannot recall testing this. Wow, that was a GREAT idea! I just tested it and noticed that the cities are updated correctly (meaning they are visible when fogged) after rejoining the game. I moved up to one visible fogged city with an explorer and left again et voila: once the city got fogged again it disappeared from the map. The problem seems to occur when the fogged city becomes visible again or is fogged again. So the problem with the updating must be happening somewhere when the TILE_KNOWN_UNSEEN flag is set for a formerly seen tile or vice versa when it is reset to the TILE_KNOWN_SEEN. I'll try to check through all the code blocks where these status flags are checked and/or changed and compare them with the former code of S2_1. Maybe I'll get lucky and find the needle in the haystack before the few weeks pass by. ;) The problem must be that when the tile is fogged (in the tile packet), the ptile-worked flag is cleared. Looking for -worked = NULL in the code should find the offending code - it shouldn't be cleared if there's a city on the tile. It's also possible that the server is telling the client the tile is not worked. This would be a related error but in the server code. Though it could be fixed client-side I suppose. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40370) borders algorithm sucks
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40370 A lower granularity should be possible. Either the setting should allow the border_sq value to be set or it should be a floating-point value. Note for instance that the citymap is of radius sqrt(5) which is neither 2 nor 3. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40316) enemy cities not shown in fogged tiles
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40316 On Tue, Jul 22, 2008 at 4:34 PM, guest user Freeciv wrote: Attached patch will let the cities be visible in the fog after you viewed them with a unit or something else. Note that if you test it on a savegame affected by the current bug you will have to give the client the chance to get an update on the city list by the server. E.g. with the GTK client and current editor available just press key combos: ctrl + e, ctrl + f and ctrl + e again. This bug is introduced since 2.1; I have no idea how or if it could have been intentional. One thing is for sure though: that it needs to be fixed and fixed carefully. Bugs with dumb cities have been around forever and any massive change here will likely introduce more instability. Better is to try to revert to the 2.1 design. I think. Unfortunately I don't have the resources to look at this problem within the next few weeks but I hope someone can give it the attention it deserves. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40177) [Patched] Shared common library
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40177 It would be good to get feedback from packagers - like Jordi Mallach, the debian packager - on this concept. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40389) [Patch] Avoid bogus max rate exceeded -messages
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40389 On Mon, Jul 21, 2008 at 10:40 AM, Marko Lindqvist [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=40389 After rates are adjusted, message about rate exceeding is sent about all changed values - also those which took excess from other values. Fix attached. I don't like the idea of a function that has side effects returning a value that pretends like it's a pure function. And what's the purpose of the return value anyway? Wouldn't the simplest fix be just to change the != to in the three comparisons? On the other hand changing the function to return the new value (a struct player_economic) so that it didn't have side effects, might be worthwhile. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40386) [Patch] overview border layers not on ocean tiles
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40386 On Sun, Jul 20, 2008 at 6:07 AM, Nicolas R. Wadhwani [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=40386 Hi, If you play a lot with islands (especially with the 1x1 tiny_isles option activated) the overview map tend to look a little bit ugly with borders on, since ocean tiles are marked with the color of the player owning the tiles and you can't see the normal coasts anymore. This patch comes with a new option called Borders layer on ocean tiles that should be activated by default letting every thing just like it used to be before. Once you deactivate this option the color marked territory on the map should appear only on land tiles, letting you see the normal coastlines. I'm not quite familiar with the problem, do you have a screenshot? Are you sure it isn't already covered by one of the existing overview options? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40383) Hills are supposed to give 2 food for city tiles not 1
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40383 Probably to do with the way auto-improvements were changed in handling. City squares automatically get irrigation. Hill + irrigation = 2 food. Of course you can mine the hill too, then you get the irrigation and the mining bonus, which is a bit wrong but is the way it's always been. Forests can't be irrigated and so don't get the bonus. Is auto-irrigation handled correctly for cities on other terrain types? It should be 2 food for plains or grassland (in despotism), or 3 food (despotism) for wheat. -jason On 7/18/08, Madeline Book [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=40383 When a city is built on a hill it is supposed to get 2 food from the tile it is built on, but for some strange reason in S2_2/trunk this is now only 1 food. -- 庶民は餓死寸前である。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40365) [Patch] Restore civ2/2.0.x resource conversion rules
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40365 Can we get a fix for 2.1 that uses an optional capability? -jason On 7/19/08, Daniel Markstedt [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=40365 On Sat, 19 Jul 2008 07:25:41 +0900, Madeline Book [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=40365 Actually I don't like the way the tier field is obtained at the client side. It is brittle in that it assumes that terrains are sent in the same order as the server reads them from the ruleset. In other words, the protocol is not stateless, and this could be annoying later. (Though the potential for causing trouble of a bad tier field value on the client side is rather minor.) For S2_1 then, this drawback would be acceptable in order to not have to change packet formats, but for S2_2+ the tier field should be sent in PACKET_RULESET_RESOURCE, to remove the tier calculation from the client and keep it dumb. So I will re-work the S2_2/trunk version to make it more robust in this manner. Are there any objections to having the S2_1 version committed (depends on #40364) so that resource conversion behaves the same as it did in 2.0/civ2? Also, no problems with splitting the grassland resources resource into animal resources and plant resources? Or we could just leave S2_1 as is and have these resource conversion fixes/features for S2_2 only. I would vote for the latter. My standpoint is to not introduce gameplay-altering changes between minor versions - for a number of reasons. Let's get 2.2 out the door asap instead. :) ~Daniel ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40384) [Patch] Fix altering movement crash due to illegal phase
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40384 On 7/19/08, Marko Lindqvist [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=40384 With altering movement phase can end being 32, causing crash in client update_info_label(). Fix attached. I'm pretty sure that's intentional in the server. While the server is handling between-turn things, nobody gets to move, hence the phase is set to nobody (it could be -1 or game.nplayers). Setting it to 0 is wrong as this will tell player 0 to go ahead and move which is not right at all. It seems to me the only error is in the client assertion. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40384) [Patch] Fix altering movement crash due to illegal phase
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40384 On 7/19/08, Marko Lindqvist [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=40384 2008/7/19 Jason Dorje Short [EMAIL PROTECTED]: URL: http://bugs.freeciv.org/Ticket/Display.html?id=40384 On 7/19/08, Marko Lindqvist [EMAIL PROTECTED] wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=40384 With altering movement phase can end being 32, causing crash in client update_info_label(). Fix attached. I'm pretty sure that's intentional in the server. True, but it causes client crash due to illegal phase. Client cannot handle 'between turns' -phase. In S2_2/TRUNK special handling for this case should be added to client end. I'm not sure about S2_1. I need to investigate more carefully how phase and turn states interact. It's only illegal in that particular assertion. Fix the assertion and that is fixed! Though for backwards compatibility with old clients 2.1 may prefer a workaround. While the server is handling between-turn things, nobody gets to move, hence the phase is set to nobody (it could be -1 or game.nplayers). Setting it to 0 is wrong as this will tell player 0 to go ahead and move which is not right at all. Note that 1) it's still between end turn and begin turn packets 2) there is no start phase packet sent (illegal phase number just 'leaks' to client side as part of game info structure) I'm not actually sure that the phase matters at all between turns. But if it DOES, the correct value would be one that isn't equal to any player's number. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40375) [Editor] Property editor basic framework
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40375 Marko Lindqvist wrote: 2008/7/14 Madeline Book: Since there is a maximum of 255 packet types Is this likely to be problem in 2.2.x lifetime? If yes, we should change packet type size to 16 bits as soon as possible. We can break network compatibility now, but definitely not after 2.2.0 has been released. It would seem wise to change it now as there's is no downside to it. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40374) [Editor] build city improvements in the cityreport dialog
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40374 Nicolas R. Wadhwani wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=40374 Hi, This feature may have been in the editor previously but is probably commented out now, so I tried to implement it the proper way. With this patch you can let cities build items like improvements and units while in editor mode by clicking on the buy button of the general cityreport dialog (Hotkey F4 in the GTK GUI, where you get a list of all cities of one player). This will cost nothing for the player owning the city and the improvements/units will be immediately added to the given city without having to wait one turn like in the usual context of this button. This feature should work with any clients supporting the Editor mode however, it won't affect the buy button you get in the normal city dialog when double clicking on a city (either on the map or in the general cityreport). That's what I'm currently looking after to change, but it looks like this button and it's callback is implemented GUI specific, but that is just guessing of mine. As you may have thought I'm completely new to this project and am just mostly busy trying to learn to look through the existing code and guessing how I could work with it. So any further contributions may take some time. ;) Would it be simpler just to change the buy costs when in editor mode to 0? Then any buying action would simply grant the improvement. Other restrictions can be removed as well. Some client updates might be needed (if the buy cost is 0 the buy button should be renamed as Add; this could be useful for some modpacks potentially) but wouldn't be necessary for full functionality. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40370) borders algorithm sucks
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40370 Marko Lindqvist wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=40370 2008/7/10 Jason Dorje Short: Yes, sucks. Whoever designed it obviously never actually played the game. Borders never expand, even to the area covered by the city, while you're in a phase of growth. This means no matter how long you play you will generally never even control your own land. The visual effect is entirely unappealing as the whole screen gets covered with border lines. Good news is that this should be fixable by one-liner adjusting how vision-site size is determined. One problem with your screenshot is that all cities there are size 1 - borders are not even expected to be very far from cities in that point (not that I too much like the way these two things are tied together). What is the value of your borders setting? (Yes, someone changed how it behaves without touching /help borders text) My value is the default. And yeah, they're all size 1, that's what I mean by growth phase. Building all settlers they never grow, yet borders should ALWAYS grow to cover at least the city area in time. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40366) auth.c forward enum reference
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40366
auth.c:100: error: ISO C forbids forward references to ‘enum’ types
When compiling with --std=gnu99 -pedantic. This is an actual error in
that the code is technically not valid C. Easily fixed by reordering it.
-jason
Index: server/auth.c
===
--- server/auth.c (revision 14981)
+++ server/auth.c (working copy)
@@ -93,18 +93,6 @@
* many seconds to reply to the client */
static const int auth_fail_wait[] = { 1, 1, 2, 3 };
-static bool is_good_password(const char *password, char *msg);
-
-static bool authdb_check_password(struct connection *pconn,
- const char *password, int len);
-static enum authdb_status auth_db_load(struct connection *pconn);
-static bool auth_db_save(struct connection *pconn);
-
-#ifdef HAVE_AUTH
-static char *alloc_escaped_string(MYSQL *mysql, const char *orig);
-static void free_escaped_string(char *str);
-#endif /* HAVE_AUTH */
-
/**
The auth db statuses are:
@@ -119,8 +107,20 @@
AUTH_DB_NOT_FOUND
};
+static bool is_good_password(const char *password, char *msg);
+
+static bool authdb_check_password(struct connection *pconn,
+ const char *password, int len);
+static enum authdb_status auth_db_load(struct connection *pconn);
+static bool auth_db_save(struct connection *pconn);
+
#ifdef HAVE_AUTH
+static char *alloc_escaped_string(MYSQL *mysql, const char *orig);
+static void free_escaped_string(char *str);
+#endif /* HAVE_AUTH */
+#ifdef HAVE_AUTH
+
enum auth_option_source {
AOS_DEFAULT, /* Internal default */
AOS_FILE, /* Read from config file*/
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40368) S2_2/trunk unused resource definitions in data/civ1/terrain.ruleset ?
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40368 Madeline Book wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=40368 What is the purpose of having resources defined in the civ1 terrain ruleset, but with 'name' field set to unused? It seems completely unnecessary, and in fact S2_1 does not have such dummy entries. I bring this up because they annoyingly litter the editor's resource selection list. If nobody knows the intended purpose of these unused resource definitions, and I find that nothing of value is lost by removing them, I'll submit a patch to do so shortly. At one point the terrain types were enumerated in the code. It was then necessary to keep every terrain (and improvement, etc) in the same order. Thus the unused entries were needed to mark a terrain type that wasn't present in civ1. Unless I'm very wrong, they are not needed anymore. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40360) differences in trunk and S2_2
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40360 It is my intent to merge these two, in some form or fashion. After discussion, I believe it is best to keep 2.2 as the development version for another cycle. Therefore first we need to find any patches that were accidentally committed to just one branch (probably trunk) and merge them into the other if appropriate. Then S2_2 basically just gets copied over trunk, and then S2_2 gets deleted. At some future time when we are ready to branch off a 2.2 (or whatever the next version is) we will do so. In the meantime it is unnecessary to maintain two branches. So, here is a list of differences between the braches: The biggest one is the removal of embassies in trunk. Embassies should stay for now, until after the next (civ2-compatible) release. 39730 appears to be committed to 2.2 but not to trunk. I'm highly uncertain on this patch which removes a lot of random things and could easily introduce massive bugs. It changes the bribery code around heavily and was for some reason only applied to the stable branches. I'm still going through the diff so more to come. Or, well, hopefully not. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40360) differences in trunk and S2_2
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40360 PR#40052 was committed to trunk but not to 2.2. This gives some differences to autogen.sh, ser.in, and civ.in. Marko can you take a look at this? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40357) fix some GGZ handlers
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40357
This patch fixes several buggy GGZ server event handlers:
* The spectator events are actually unused since we don't support
spectators yet. But they should all go to the spectator handler.
* The error event must be handled, by exiting the server properly.
This is a pretty severe error so I'll commit these immediately.
-jason
Index: server/ggzserver.c
===
--- server/ggzserver.c (revision 14950)
+++ server/ggzserver.c (working copy)
@@ -31,6 +31,7 @@
#include ggzserver.h
#include score.h
#include sernet.h
+#include srv_main.h
bool with_ggz = FALSE;
@@ -173,6 +174,19 @@
}
/
+ Handles a ggzdmod error. This simply exits the server with an error
+ message.
+/
+static void handle_ggz_error(GGZdMod * ggz, GGZdModEvent event,
+ const void *data)
+{
+ const char *err = data;
+
+ freelog(LOG_ERROR, Error in ggz: %s, err);
+ server_quit();
+}
+
+/
Connect to the GGZ server, if GGZ is being used.
/
void ggz_initialize(void)
@@ -199,6 +213,12 @@
handle_ggz_seat_event);
ggzdmod_set_handler(ggzdmod, GGZDMOD_EVENT_SPECTATOR_JOIN,
handle_ggz_spectator_seat_event);
+ggzdmod_set_handler(ggzdmod, GGZDMOD_EVENT_SPECTATOR_LEAVE,
+ handle_ggz_spectator_seat_event);
+ggzdmod_set_handler(ggzdmod, GGZDMOD_EVENT_SPECTATOR_SEAT,
+ handle_ggz_spectator_seat_event);
+ggzdmod_set_handler(ggzdmod, GGZDMOD_EVENT_ERROR,
+ handle_ggz_error);
if (ggzdmod_connect(ggzdmod) 0) {
exit(EXIT_FAILURE);
}
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40356) Multiple bases on same tile
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40356 Marko Lindqvist wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=40356 We already had some discussion about multiple bases on same tile. Let's continue, and gather information, in its own ticket. I'm currently aware of two parts of code that would not work with more than one base on same tile: - Pillage selection has only any base resolution. - Bases can act as vision/border sites. These are identified by the tile they are placed on. About number of different bases ruleset format should allow: One reason for generic bases is to allow modpacks to contain unique bases. These would already be on map when game begins, and one cannot build more of them. For example, fantasy modpack could have some ancient towers around. Ruleset format should allow many such unique bases in addition to several buildable ones. Scripting allows unique behavior for any number of tiles, but that does not allow any graphics. Bases are visible. I have been looking in to possibility that there is boolean setting in ruleset defining if multiple bases can be on same tile. If it's true, ruleset can contain only one basetype / bit. If it's false, ruleset can contain (2^bits)-1 basetypes. It sounds like 1 base per tile is a lot easier to implement. Until there's a concrete need to break that barrier I wouldn't trouble yourself with generalizing it to multiple per tile. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40351) [Patch] Fix memory problem in ferry pathfinding
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40351 Marko Lindqvist wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=40351 Uninitialized extra cost from dangerous ocean drove valgrind crazy in S2_2 and TRUNK. Of course, there is no such thing as dangerous ocean in S2_2 and TRUNK. Fix attached. Can we remove dangerous terrain yet? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40349) else clauses in Makefile.am conditionals
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40349 I haven't looked up documentation on this but my feeling is these are bad - and, in every case I could find, unnecessary. make dist assumes all conditionals pass to find out what needs to be distributed. Thus, if you ever DID have to use the else clause, I can't see how that would fail to break make dist. On the other hand with the way we use else clauses they just fill empty variables which would be empty anyway. Attached patches fix this (2.1 patch applies to trunk/2.2 also). -jason Index: utility/ftwl/Makefile.am === --- utility/ftwl/Makefile.am (revision 14921) +++ utility/ftwl/Makefile.am (working copy) @@ -2,8 +2,6 @@ if FTWL FTWLLIB=libftwl.a -else -FTWLLIB= endif noinst_LIBRARIES = $(FTWLLIB) Index: data/Makefile.am === --- data/Makefile.am (revision 14921) +++ data/Makefile.am (working copy) @@ -16,8 +16,6 @@ CLIENT_EXTRA_FILES = freeciv.rc-2.0 endif CLIENT_FILES = $(COMMON_CLIENT_FILES) $(CLIENT_EXTRA_FILES) -else -CLIENT_FILES = endif if SERVER @@ -25,8 +23,6 @@ civ1.serv \ civ2.serv \ default.serv -else -SERVER_FILES = endif pkgdata_DATA = $(SERVER_FILES) $(CLIENT_FILES) @@ -54,20 +50,14 @@ if CLIENT CLIENTDATADIRS = amplio misc flags buildings isotrident trident isophex \ hex2t stdsounds themes wonders -else -CLIENTDATADIRS = endif if SERVER SERVERDATADIRS = default civ1 civ2 scenario nation -else -SERVERDATADIRS = endif if CLIENT ICONS = freeciv-client.png -else -ICONS = endif icondir = $(prefix)/share/pixmaps Index: data/icons/Makefile.am === --- data/icons/Makefile.am (revision 14921) +++ data/icons/Makefile.am (working copy) @@ -11,12 +11,6 @@ 64x64/freeciv-client.png icons_128_c = \ 128x128/freeciv-client.png -else -icons_16_c = -icons_32_c = -icons_48_c = -icons_64_c = -icons_128_c = endif if SERVER @@ -30,12 +24,6 @@ 64x64/freeciv-server.png icons_128_s = \ 128x128/freeciv-server.png -else -icons_16_s = -icons_32_s = -icons_48_s = -icons_64_s = -icons_128_s = endif #icons_svg = \ Index: Makefile.am === --- Makefile.am (revision 14921) +++ Makefile.am (working copy) @@ -4,30 +4,20 @@ if CLIENT CSUBDIRS = client -else -CSUBDIRS = endif if SERVER SSUBDIRS = ai dependencies server -else -SSUBDIRS = endif if SERVER if CLIENT MSUBDIRS = manual -else -MSUBDIRS = endif -else -MSUBDIRS = endif if MAKE_DATA DSUBDIRS = data -else -DSUBDIRS = endif Index: client/Makefile.am === --- client/Makefile.am (revision 14921) +++ client/Makefile.am (working copy) @@ -47,8 +47,6 @@ ## directory is included for 'make dist'. if MAKE_CLIENT_INCLUDE CLI_INCLUDE = include -else -CLI_INCLUDE = endif SUBDIRS = $(GUI_SUBDIR) $(CLI_INCLUDE) agents Index: utility/ftwl/Makefile.am === --- utility/ftwl/Makefile.am (revision 14929) +++ utility/ftwl/Makefile.am (working copy) @@ -2,8 +2,6 @@ if FTWL FTWLLIB=libftwl.a -else -FTWLLIB= endif noinst_LIBRARIES = $(FTWLLIB) Index: data/Makefile.am === --- data/Makefile.am (revision 14929) +++ data/Makefile.am (working copy) @@ -17,8 +17,6 @@ CLIENT_EXTRA_FILES = freeciv.rc-2.0 endif CLIENT_FILES = $(COMMON_CLIENT_FILES) $(CLIENT_EXTRA_FILES) -else -CLIENT_FILES = endif if SERVER @@ -26,8 +24,6 @@ civ1.serv \ civ2.serv \ history.serv -else -SERVER_FILES = endif pkgdata_DATA = $(SERVER_FILES) $(CLIENT_FILES) @@ -47,14 +43,10 @@ if CLIENT CLIENTDATADIRS = misc flags isotrident trident isophex -else -CLIENTDATADIRS = endif if SERVER SERVERDATADIRS = default civ1 civ2 scenario nation history -else -SERVERDATADIRS = endif SUBDIRS = $(CLIENTDATADIRS) $(SERVERDATADIRS) Index: Makefile.am === --- Makefile.am (revision 14929) +++ Makefile.am (working copy) @@ -2,30 +2,20 @@ if CLIENT CSUBDIRS = client -else -CSUBDIRS = endif if SERVER SSUBDIRS = ai server -else -SSUBDIRS = endif if SERVER if CLIENT MSUBDIRS = manual -else -MSUBDIRS = endif -else -MSUBDIRS = endif if MAKE_DATA DSUBDIRS = data -else -DSUBDIRS = endif Index: client/Makefile.am === --- client/Makefile.am (revision 14929) +++ client/Makefile.am (working copy) @@ -134,8 +134,6 @@ ## directory is included for 'make dist'. if MAKE_CLIENT_INCLUDE CLI_INCLUDE = include -else -CLI_INCLUDE = endif SUBDIRS = $(GUI_SUBDIR) $(CLI_INCLUDE) agents Index: Makefile.am
Re: [Freeciv-Dev] (PR#40165) Re: Expanded terrain set, request for info
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40165 Marko Lindqvist wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=40165 2008/3/24 Marko Lindqvist: TERRAIN_XXX_IDENTIFIER definitions have to go, and terrains must be selected by properly checking their flags, ocean_depth -value, or what ever is appropriate for each case. Attached patch removes code that creates these special ocean types. If such special features are needed in the future, they should be reimplemented in a proper, generic, fashion. civ1 civ2 rulesets have only one ocean type, default ruleset three types; Lake, Ocean and Deep Ocean. Great. I don't understand though what the identifiers are supposed to do? I understand and am happy that they're being removed but what could possibly have prompted the re-addition of hardcoded terrain identifiers in the first place? -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40342)
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40342 [EMAIL PROTECTED] wrote: Anything else I could/should try ? Run the server inside gdb (gdb civserver) and when it crashes get a backtrace (bt full) which you can send us. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39568) cannot sell an improvement
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39568
Daniel Markstedt wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39568
[dmarks - Sun Jun 29 01:22:46 2008]:
[jdorje - Sun Jun 29 01:17:09 2008]:
[pepeto - Mon Oct 15 17:07:29 2007]:
Isn't this ticket resolved? Or does it need some more improvement?
What about 2.0? Is it still broken there?
-jason
Yes it is.
Tried to merge the first revision of the patch to S2_0, but just
worsens the issue. With attached patch selling buildings is completely
broken.
Ahh so.
pcity-owner is a player id not a pointer. So this patch does the trick.
-jason
Index: client/gui-gtk-2.0/citydlg.c
===
--- client/gui-gtk-2.0/citydlg.c(revision 14909)
+++ client/gui-gtk-2.0/citydlg.c(working copy)
@@ -2389,8 +2389,7 @@
return;
}
- if (pdialog-pcity-did_buy || pdialog-pcity-did_sell ||
- pdialog-pcity-owner != game.player_idx) {
+ if (pdialog-pcity-did_sell || pdialog-pcity-owner != game.player_idx) {
return;
}
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] trunk doesn't compile
Marko Lindqvist wrote: 2008/6/29 Jason Dorje Short [EMAIL PROTECTED]: aiparatrooper.c:37:23: error: utilities.h: No such file or directory Include path problem. I cannot reproduce. 1) Makefile.am should contain $(top_srcdir)/server/generator -path. 2) Are your Makefile.in and Makefile regenerated? This might require that you have configured with --enable-maintainer-mode or run automake manually again now. Problem is fixed after rerunning autogen.sh. I still think it is *quite* wrong for the generator module code to be used outside of that directory. When we originally split that off, it was to make the code more modular, not to create a whole secondary set of dependencies to have to keep track of. That said get_continent_size() is not really generator-specific. In fact I'd think it should be in map.c... -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
