http://bugs.freeciv.org/Ticket/Display.html?id=40069 >
Looks identical (or at least indistinguishable) from PR#40068.
-jason
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=40068 >
> [wsimpson - Sat Feb 02 23:07:04 2008]:
>
> Jason Short wrote:
> > Looks to me like this means dsite->location is invalid. I have no
> > familiarity with this code however.
> >
> That's (my) very new border code. I'll take a look at it.
>
http://bugs.freeciv.org/Ticket/Display.html?id=40070 >
get_city_bonus is passing in a NULL city. This is allowed according to
the effects interface (undocumented of course) but because it calls
city_owner that function now segfaults on it.
I have no definite opinion on whether NULL targets are
http://bugs.freeciv.org/Ticket/Display.html?id=40070 >
This will be applicable to all branches!
In 2.1, has 60 occurrences in 20 files.
In 2.2, has 63 occurrences in 23 files.
In this case, the code already has a FIXME over two years old!
It clearly indicates:
/* It is a virtual unit, so
http://bugs.freeciv.org/Ticket/Display.html?id=40069 >
In this report, tile0=0x2b.
In PR#40068, tile0=0x4, and the client crashed, too.
Let's keep this separate, to deal with the border recalculation issue.
___
Freeciv-dev mailing list
Freeciv-dev@
http://bugs.freeciv.org/Ticket/Display.html?id=40070 >
In this case, the traceback clearly shows the NULL city:
city_owner (pcity=0x0) at city.c:654
That's properly failing checks added by PR#39998 and PR#39895 respectively:
assert(NULL != pcity && NULL != pcity->owner);
But for the rec
http://bugs.freeciv.org/Ticket/Display.html?id=40068 >
Jason Short wrote:
> Saving and loading doesn't generally give identical AI behavior so if
> this is caused by AI units moving or something then you won't get the
> same behavior from the savegame most likely.
>
I've argued about this before
http://bugs.freeciv.org/Ticket/Display.html?id=40068 >
Christian Knoke wrote:
> These 2 messages needn't necessarly be connected. I just copied the outbut
> on the terminal after the crash.
>
Yes, and that's excellent bug reporting practice! That tells us that the
client asserted sometime befor
http://bugs.freeciv.org/Ticket/Display.html?id=40068 >
Du schriebst am 03. Feb um 04:30 Uhr:
> (civclient:17913): Gtk-CRITICAL **: gtk_progress_set_percentage: assertion
> `percentage >= 0 && percentage <= 1.0' failed
> 2: Verbindung zum Server verloren!
These 2 messages needn't necessarly be c
http://bugs.freeciv.org/Ticket/Display.html?id=40071 >
Committed trunk revision 14376.
Committed S2_2 revision 14377, with update-po to add TRANS comments.
Reminder, ./autogen.sh before make!
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://
http://bugs.freeciv.org/Ticket/Display.html?id=40025 >
I have been playing a game lately, and watching what happens as the size of
my empire increases. I believe this effect of additional unhappy citizens
didn't happen in 2.0 (at least, that would explain why, when I imported an
almost perfect sa
http://bugs.freeciv.org/Ticket/Display.html?id=40025 >
Joan Creus wrote on Feb 03, 06:40 (-0800):
>
> http://bugs.freeciv.org/Ticket/Display.html?id=40025 >
>
> I have been playing a game lately, and watching what happens as the size of
> my empire increases. I believe this effect of additional
It seems that through various versions of Freeciv, the
behavior of
specials squares when they were terraformed has been
changed. I propose
that one could choose from a list of possible
behaviors when setting up
the game, rather than taking the option out of the
game creator's
hands. This coul
http://bugs.freeciv.org/Ticket/Display.html?id=40073 >
There's a problem with reproducing reports for 2.2 savegames. Over the past
9 months, I've spent considerable time improving the reproducibility of 2.1
(PR#39365, PR#39572, etc.)
Searching for myrand() differences between 2.1 and 2.2, found
http://bugs.freeciv.org/Ticket/Display.html?id=40072 >
Thanks, looking
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=40025 >
Christian Knoke wrote:
> This is in there since some time of 2.1. Something has been changed
> intendedly, I don't remember what it was.
>
Wasn't paying much attention at the time, but it made the empire happiness
code actually work! As it
http://bugs.freeciv.org/Ticket/Display.html?id=40025 >
2008/2/3, Christian Knoke <[EMAIL PROTECTED]>:
>
>
> http://bugs.freeciv.org/Ticket/Display.html?id=40025 >
>
>
> This is in there since some time of 2.1. Something has been changed
> intendedly, I don't remember what it was.
>
> I have notic
Jonathan Kaplan wrote:
> ... but what would be
> ideal would be putting a *large* range of options available as a
> user-controlled setting.
Shudder. That's horrible. How do you test?
Remember, this has to handle civ1/2/3-like games, so civ1 Swamp resource
Oil has to turn into civ2 Peat, an
http://bugs.freeciv.org/Ticket/Display.html?id=40073 >
Committed trunk revision 14378.
Committed S2_2 revision 14379.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
William Allen Simpson wrote:
> Jonathan Kaplan wrote:
>> ... but what would be
>> ideal would be putting a *large* range of options
available as a
>> user-controlled setting.
>
> Shudder. That's horrible. How do you test?
>
> Remember, this has to handle civ1/2/3-like games, so
civ1 Swamp res
http://bugs.freeciv.org/Ticket/Display.html?id=40069 >
I've poked and prodded this, and cannot get it to crash again. My guess is
that it's an array overrun of some kind from elsewhere, as the ->location is
the first entry in the common/vision.h struct vision_site{}. The values in
the reports m
21 matches
Mail list logo
