URL: http://bugs.freeciv.org/Ticket/Display.html?id=39548
[EMAIL PROTECTED] - So 12. Aug 2007, 16:50:47]:
This fixes warning when neither SOCKET_ZERO_ISNT_STDIN nor
HAVE_READLINE is defined.
- ML
There are actually two locations where the handle_stdin_close() function
might get
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39462
[wsimpson - Jeu. Aoû. 16 01:18:04 2007]:
Are there some old bug reports with games we can test?
This is a save game you can test this, with select the engineers with Y,
on the 2 islands. Then you can test goto, patrol and connect...
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39548
On 16/08/07, Christian Prochaska [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] - So 12. Aug 2007, 16:50:47]:
This fixes warning when neither SOCKET_ZERO_ISNT_STDIN nor
HAVE_READLINE is defined.
There are actually two locations
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39462
[wsimpson - Jeu. Aoû. 16 01:18:04 2007]:
Are there some old bug reports with games we can test?
This is a save game you can test this, with select the engineers with Y,
on the 2 islands. Then you can test goto, patrol and connect...
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39462
This patch should work faster (when there are a lot of unit for
example). This one can be apply on 2.1 and trunk. Enjoy...
--- client/control.c.old 2007-08-15 20:28:54.0 +0200
+++ client/control.c 2007-08-16 10:49:38.0
On 16/08/07, Daniel Markstedt [EMAIL PROTECTED] wrote:
I suggest we hold off announcing or creating builds for beta5, and
make beta6 as soon as this crashbug has been resoved.
Addition to #39548 is release-critical too.
- ML
___
Freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39397
Du schriebst am 15. Aug um 17:35 Uhr:
Christian Knoke wrote:
Currently trunk runs and compiles ok, and beta4 svn doesn't compile
because of lt.po, so I can't test.
We're still awaiting your confirmation that this bug is fixed for
On 16/08/07, William Allen Simpson [EMAIL PROTECTED] wrote:
Daniel Markstedt wrote:
I suggest we hold off announcing or creating builds for beta5, and
make beta6 as soon as this crashbug has been resoved.
Should be able to svn merge the changes into beta5. Just wait a few
days for folks
On 8/16/07, Marko Lindqvist [EMAIL PROTECTED] wrote:
On 16/08/07, William Allen Simpson [EMAIL PROTECTED] wrote:
Daniel Markstedt wrote:
I suggest we hold off announcing or creating builds for beta5, and
make beta6 as soon as this crashbug has been resoved.
Should be able to svn
On 16/08/07, Daniel Markstedt [EMAIL PROTECTED] wrote:
beta6. Shall
we say I make the release late night Sunday 19th GMT (early Monday
morning for me.)
Ok
- ML
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39536
On 11/08/07, Marko Lindqvist [EMAIL PROTECTED] wrote:
I think we should set real release number for stable branch only for
the time it takes to tag. That is:
1) Set release version number to branch
2) Tag
3) Set branch version
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39573
On 16/08/07, Daniel Markstedt [EMAIL PROTECTED] wrote:
Detta är servern för Freeciv version 2.1.0-beta4 (betaversion).
Not *the* beta4, but quite recent svn version of S2_1 (before version
number bump to beta4+), I presume.
In that
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39574
Reported in the past (for example, PR#39397), the client tries to load
graphics for a never displayed None -- or as the older bug(s)
improperly displayed, Nichts (fixed by PR#39389).
The iterator at client/tilespec.c tilespec_reread()
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39574
On 16/08/07, William Allen Simpson [EMAIL PROTECTED] wrote:
Moreover, this seems a symptom of a larger problem. It would be far
more efficient to only load graphics as the set changes, rather than
piecemeal as individual packets
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39536
Marko Lindqvist wrote:
This ticket can be closed when procedure is documented.
For svn purists the latter is preferable.
Remember, unlike CVS, in subversion tags are the same as branches. There
is no implementation difference, zero
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39575
at revision 13068, 13069 and 13070, ATTRIBUTE_CHUNK_SIZE had been changed.
But, ATTRIBUTE_CHUNK_SIZE is used to define packets.
PACKET_PLAYER_ATTRIBUTE_CHUNK=47; pre-send, sc,cs,handle-via-packet
UINT32 offset, total_length,
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39462
I like the more recent patch much less. It doesn't get rid of the inane
static variables.
Oh well, it's up to you. But settle on something that works well, so
that it can be adequately tested before Saturday.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39558
Michael Kaufman wrote:
sorry, yes inventions are technically trinary, but for purposes of passing
to the client, they're binary, since update_research() is called upon
receiving a player_info packet.
Wow, is that wrong! I'll delete
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39575
Pepeto _ wrote:
IT'S VERY DANGEROUS TO CHANGE PACKET DEFINITIONS WITHOUT REDEFINE
CAPABILITY STRING.
There is no documented packet specific capability string.
There is no released version with this new code.
IT'S VERY DANGEROUS TO
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39575
[wsimpson - Jeu. Aoû. 16 13:48:36 2007]:
Pepeto _ wrote:
There is no released version with this new code.
IT'S VERY DANGEROUS TO RUN DEVELOPMENT CODE AGAINST RELEASED SERVERS.
You want to run development code, you also have to
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39575
On 16/08/07, William Allen Simpson [EMAIL PROTECTED] wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39575
Pepeto _ wrote:
IT'S VERY DANGEROUS TO CHANGE PACKET DEFINITIONS WITHOUT REDEFINE
CAPABILITY STRING.
There
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39575
On 16/08/07, Pepeto _ [EMAIL PROTECTED] wrote:
at revision 13068, 13069 and 13070, ATTRIBUTE_CHUNK_SIZE had been changed.
But, ATTRIBUTE_CHUNK_SIZE is used to define packets.
Yes, this has to reverted from S2_1 and S2_0 immediately.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39577
When you bribe a city in 2.0, the units are not transfered correctly.
Actually, you get all the homecities of the units.
It seems there were an error at revision 13057:
(PR#39431) Cannot add settlers to city
patch by Timothy Brownawell
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39575
Marko Lindqvist wrote:
On 16/08/07, William Allen Simpson [EMAIL PROTECTED] wrote:
There is no documented packet specific capability string.
version.in, common/capsomething.c
That is not a documented packet specific capability
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39575
Pepeto _ wrote:
You are wrong, the 2.0 branch is supposed be stable. All the user with a
2.0.* client would be able to play on a 2.0.* server without
compatibility problems.
You don't have a 2.0.* client. That's an unreleased
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39575
[wsimpson - Jeu. Aoû. 16 15:22:31 2007]:
Pepeto _ wrote:
You are wrong, the 2.0 branch is supposed be stable. All the user with a
2.0.* client would be able to play on a 2.0.* server without
compatibility problems.
You
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39577
Pepeto _ wrote:
But wipe_unit(vunit) in 2.0 is needed, because transfer_unit() makes
already a new unit. In 2.1, the same structure is used, so there is no
problem.
Then that's a bug in transfer_unit(). My fix prevents a reported
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39577
[wsimpson - Jeu. Aoû. 16 15:33:37 2007]:
Pepeto _ wrote:
But wipe_unit(vunit) in 2.0 is needed, because transfer_unit() makes
already a new unit. In 2.1, the same structure is used, so there is no
problem.
Then that's a bug
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39558
Michael Kaufman wrote:
sorry, yes inventions are technically trinary, but for purposes of passing
to the client, they're binary, since update_research() is called upon
receiving a player_info packet.
Wow, is that wrong! I'll
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39579
A verbose log of packets shows that for a single client game, loading,
and then immediately quitting, the entire ruleset is sent 3 times!
Some rulesets are sent 5 times:
PACKET_RULESET_NATION_GROUPS
PACKET_RULESET_NATION
The
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39578
Just starting a saved game (with 3 players) has too many player_info packets.
The comments in client/packhand.c say:
/* If the server sends out player information at the wrong time, it is
* likely to give us inconsistent player
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39575
On Thu, 16 Aug 2007, William Allen Simpson wrote:
If there were packet specific capabilities
There are. See doc/README.delta
- Per
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39575
[per - Jeu. Aoû. 16 22:10:35 2007]:
On Thu, 16 Aug 2007, William Allen Simpson wrote:
You don't have a 2.0.* client. That's an unreleased development client.
We have for a long time been running a fresh checkout of stable
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39575
On Thu, 16 Aug 2007, William Allen Simpson wrote:
You don't have a 2.0.* client. That's an unreleased development client.
We have for a long time been running a fresh checkout of stable branches
for pubserver games, since this way we
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39576
On Thu, 16 Aug 2007, William Allen Simpson wrote:
Problem: the attributes are sent and stored as serialized data, so the
server has no way to check validity of format. Many reports of bad
lengths, and other validity problems. The
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39462
This is the final patch, which include a new get_line_dest() function
(now, it would really return the destination tile and not the first unit
destination which could be his own tile). I tried to optimize the code
in time.
Sorry, I know
36 matches
Mail list logo
