Follow-up Comment #5, bug #17301 (project freeciv):
why is it that some borders are permanently visible while
others are ephemeral and will disappear from the map when
fogged?
That sounds like a bug to me -- I wouldn't expect borders to
disappear when fogged. This isn't a behaviour
Update of bug #17198 (project freeciv):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
Release: = 2.2.4
Update of bug #17246 (project freeciv):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #17302 (project freeciv):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #17267 (project freeciv):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #17270 (project freeciv):
Planned Release:2.3.0, 2.4.0 = 2.3.1, 2.4.0
___
Follow-up Comment #1:
This is for 2.3.1 / 2.4.0 as it changes the ruleset(s)
Update of bug #17269 (project freeciv):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #17161 (project freeciv):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #17163 (project freeciv):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
checks and sets a defined
state. Furthermore, a check if the goal is known is added. Could you please
test it?
(file #11590)
___
Additional Item Attachment:
File name: 20101215-trunk-set-the-research-goal-to-a-defined-state.patch
Size:1 KB
Update of bug #17236 (project freeciv):
Status: Ready For Test = In Progress
___
Follow-up Comment #5:
I do get the following error message with this patch:
(freeciv-gtk2:5850): Gtk-WARNING **:
Follow-up Comment #12, bug #16639 (project freeciv):
Tried both to run with '-F' as well as inside gdb directly, but
failed to get a core dump after several tries.
If you can reproduce the assert, it should core dump if started with '-F'
...
However, it's relatively easy to repro the
Follow-up Comment #13, bug #16639 (project freeciv):
If you can reproduce the assert, it should core dump if started
with '-F' ...
Where should the dump file be located?
I'm trying at the moment. Do you know if there was a civil war /
barbarian war at this point (new player!)?
Maybe, but
Follow-up Comment #14, bug #16639 (project freeciv):
Where should the dump file be located?
A file named 'core' or 'core.pid' should be in the directory there you
started the program.
I'm trying at the moment. Do you know if there was a civil war /
barbarian war at this point (new
Pepeto writes:
Le mardi 30 novembre 2010 à 14:47 -0800, David Hartglass a écrit :
For example, currently the type CONNECTION is SINT16, however this
gives us errors (setting CONNECTION to be UINT8, as in the older
versions, fixes this). Is CONNECTION supposed to be SINT16? If not,
are
Update of patch #1470 (project freeciv):
Status: Ready For Test = Done
Open/Closed:Open = Closed
___
Reply to this item at:
URL:
http://gna.org/bugs/?17328
Summary: PACKET_SERVER_JOIN_REPLY changed shape between
2.2.x and 2.3.x
Project: Freeciv
Submitted by: jtn
Submitted on: Wed Dec 15 22:46:48 2010
Category: None
Severity: 3
I wrote:
Pepeto writes:
Le mardi 30 novembre 2010 à 14:47 -0800, David Hartglass a écrit :
For example, currently the type CONNECTION is SINT16, however this
gives us errors (setting CONNECTION to be UINT8, as in the older
versions, fixes this). Is CONNECTION supposed to be SINT16?
Follow-up Comment #1, bug #17328 (project freeciv):
You said about all...
However, changing CONNECTION to UINT8 may be a mistake as the server
currently is able to handle 256 connections (ids 1 to 257).
Moreover, the id of a connection is determined as a increasing counter. So if
a connection
19 matches
Mail list logo