http://bugs.freeciv.org/Ticket/Display.html?id=14969 >
The existing patch made the testing and network slightly more efficient --
using a bitvector instead of a list of pointers -- but that's too much
change for the current state of 2.1 release. I'm not sure it is really
helpful in execution, as
http://bugs.freeciv.org/Ticket/Display.html?id=39756 >
Pepeto _ wrote:
> Why 2.0.10 should be different?
>
Because 2.0.10 does not yet exist.
The idea of compatibility (and the concept of capabilities in the
professional programming world and computer science) is that
versions interoperate *onl
http://bugs.freeciv.org/Ticket/Display.html?id=10400 >
Lately, your patches have been formatted with base64 as
application/octet-stream, usually reserved to binary data.
That actually makes them much longer than the original text,
and difficult to review (and impossible to search for later).
Are
http://bugs.freeciv.org/Ticket/Display.html?id=1 >
There are actually quite a few reports on this topic (see PR#14969),
and several proposed solutions.
The most comprehensive requires new data structures to support the
commercial civ variants (and import of those scenarios). This
is/was a l
http://bugs.freeciv.org/Ticket/Display.html?id=39757 >
Thank you for your interest in 2.0.9. Current efforts are for the
release of 2.1, where this code does not appear. This will be
queued for the (unlikely) future release of 2.0.10.
___
Freeciv-d
http://bugs.freeciv.org/Ticket/Display.html?id=39756 >
Pepeto _ wrote:
> The best thing would be to update automatically the science report when
> the stock change, but the problem is you cannot change it in the already
> distributed clients, could be an idea for S2_1, S2_2.
>
Here again, the ut
http://bugs.freeciv.org/Ticket/Display.html?id=39759 >
William Allen Simpson wrote:
> Now, they are 8 hours in the future!
>
My mistake, misread the day, looks like only a couple just had a
burp holding messages from yesterday in a queue for gna.org.
Received: from rt.fr
http://bugs.freeciv.org/Ticket/Display.html?id=39759 >
William Allen Simpson wrote:
> That's time-travel, backward in time!
>
> Could whomever is responsible, wherever this server is located, please
> fix the time?!?!
>
Now, they ar
William Allen Simpson wrote:
> Marko Lindqvist wrote:
>> Only remaining showstopper level problem is air goto. We do have
>> Pepeto's patch for that, but it might require closer inspection.
>>
> Will handle.
>
I cannot find Marko's "almost identi
http://bugs.freeciv.org/Ticket/Display.html?id=39755 >
Frozen client, who knows what's happening So far, no crash.
Anybody else with a crash traceback?
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=39759 >
The rt.freeciv.org time has been getting progressively worse. Today,
it's more than 1/2 hour early.
In http://bugs.freeciv.org/Ticket/Display.html?id=39755
As is clear by the "Correspondence added", I sent a message
Sat, 06 Oct 2007 12
http://bugs.freeciv.org/Ticket/Display.html?id=39755 >
Daniel Markstedt wrote:
> Backtrace from a crash attached.
>
A singularly non-useful trace, no symbols? It does seem to be from a
packet that does a move_unit(), I'll see whether I can reproduce
_
Marko Lindqvist wrote:
> Only remaining showstopper level problem is air goto. We do have
> Pepeto's patch for that, but it might require closer inspection.
>
Will handle.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/f
Daniel Markstedt wrote:
> We're already a week into October, the month when 2.1.0-final is
> expected. Can't we make a final effort to patch this up, releasing
> beta7 followed by RC1 and shipping it with this list of known bugs?
>
> We need to get this out of the door; it's now or never!
>
Forge
http://bugs.freeciv.org/Ticket/Display.html?id=39743 >
Pepeto _ wrote:
> 1-Static or dynamics datas?
>
> The most of the main structures (player, connection, advance, ...)
> except city and unit are declared static (for example
> game.players[MAX_NUM_PLAYERS + MAX_NUM_BARBARIANS];). Is this a
>
http://bugs.freeciv.org/Ticket/Display.html?id=39725 >
Pepeto _ wrote:
> There shouldn't have any rule about freelog() level translation. It must
> just be adapted to the every case. It always was like this, I don't
> think there is any reason to change it.
>
Pepeto, you are wrong. They have *a
http://bugs.freeciv.org/Ticket/Display.html?id=39725 >
Marko Lindqvist wrote:
> Messages meant for end-user should be translated.
>
Error messages meant for users are sent as message packets.
LOG_ERROR is *never* meant for users, it is for developers.
See HACKING:
Messages and text in genera
http://bugs.freeciv.org/Ticket/Display.html?id=39726 >
Upon inspection, there were quite a few errors in that section.
Committed trunk revision 13667.
Committed S2_2 revision 13668.
Index: data/helpdata.txt
===
--- data/helpdata.tx
http://bugs.freeciv.org/Ticket/Display.html?id=39725 >
Upon inspection, more errors found. Only LOG_NORMAL should be translated.
Committed trunk revision 13665.
Committed S2_2 revision 13666.
Index: client/gui-sdl/gui_string.c
===
http://bugs.freeciv.org/Ticket/Display.html?id=39723 >
Upon inspection, noticed other grammatical errors, too.
Committed trunk revision 13663.
Committed S2_2 revision 13664.
Index: settings.c
===
--- settings.c (revision 13662)
++
http://bugs.freeciv.org/Ticket/Display.html?id=39731 >
Daniel Markstedt wrote:
> On 9/27/07, Egor Vyscrebentsov <[EMAIL PROTECTED]> wrote:
>> So, what do you want? A function which will return string contains
>> leader name and title in proper order?
>
> Yes. After that, all clients have to be m
Daniel Markstedt wrote:
> Most of the discussion took place in PR#39690 IIRC.
>
Not somewhere I'd expect such a major decision to be discussed, buried at
the end of a thread discussing something else entirely.
I'm opposed to removing embassies from the game code. It's required for
proper civ* em
Per I. Mathisen wrote:
> On Mon, 24 Sep 2007, William Allen Simpson wrote:
>> Apparently without discussion, 2.1 has been officially abandoned, as 2.2
>> has been branched in the repository.
>
> If you did not read the discussion, how could you reach the conclusion it
>
http://bugs.freeciv.org/Ticket/Display.html?id=39715 >
Also reported by [EMAIL PROTECTED] on freeciv-dev list with savegame
and proposed patch:
Re: [Freeciv-Dev] Segfault bug in advance_has_flag in common/tech.c
Committed trunk revision 13640.
Index: server/techtools.c
Thanks, see (PR#39715) Crash when discovering a Future Tech.
In the future, please post to [EMAIL PROTECTED] for tracking.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=39609 >
Committed trunk revision 13639.
Index: client/control.c
===
--- client/control.c(revision 13638)
+++ client/control.c(working copy)
@@ -59,7 +59,6 @@
static struct unit
Apparently without discussion, 2.1 has been officially abandoned, as 2.2
has been branched in the repository. I will no longer work on 2.1.
Unfortunately, nobody has yet added the 2.2 tag in RT. I cannot tag
things for 2.2, until then I won't be working on 2.2 either.
According to http://freeci
Brian Dunstan wrote:
> This soon produced a segfault which I traced to
> advance_has_flag() in common/tech.c
>
Thanks for the savegame. Your proposed patch should not be applied, as
the whole point of the function is to find bad indices, and use the
segfault to locate the bad call!
The proper pa
http://bugs.freeciv.org/Ticket/Display.html?id=39609 >
William Allen Simpson wrote:
> Does anybody remember? Otherwise, I'm getting rid of it.
>
Going, going, gone.
Index: client/control.c
===
--- client/control.
http://bugs.freeciv.org/Ticket/Display.html?id=39718 >
Great! Normally, this would be svn moved first and then updated.
Also, all the other nations have to be updated for cross-references.
I think this kind of thing should definitely be fixed for 2.1!
___
Marko Lindqvist wrote:
> I hope beta7 to be last beta, and to that goal I would like to see
> just a couple of more problems fixed before it. I will list them
> later.
>
My take is that with a few more problems fixed, it should be ready,
based on the list of features that are its requirements:
h
http://bugs.freeciv.org/Ticket/Display.html?id=39698 >
Daniel Markstedt wrote:
> Ok, so instead of backtracking with 2.2, would it be possible to add a
> forward-compatibility layer to 2.1? Simply speaking, the savegame code
> would read a 2.2 map and interpret ' ' '.' ',' ';' etc as identical
>
http://bugs.freeciv.org/Ticket/Display.html?id=39698 >
Daniel Markstedt wrote:
> So is it impossible to create a ruleset for 2.1.99 that defines only
> one ocean type?
>
Well, I'm pretty sure there are a couple of ways
The easiest would be to create the world, and then hand edit the file to
http://bugs.freeciv.org/Ticket/Display.html?id=39715 >
That's correct. This is related to the debugging in PR#39714.
The flags aren't valid for A_FUTURE (or A_UNKNOWN or A_UNUSED), and these
should never be set to TECH_KNOWN. Where is that happening?
Please send traceback! And savegame just
http://bugs.freeciv.org/Ticket/Display.html?id=39714 >
Yes, debugging accidentally left during commit for PR#39525. Thanks for
the clue! Committed revision 13614.
Index: common/tech.c
===
--- common/tech.c (revision 13613)
+
http://bugs.freeciv.org/Ticket/Display.html?id=39714 >
Petr Baudis wrote:
> ... Server crashed to me when I was researching
> the last technology in tree and entered a hut with a unit.
>
Mine, am looking at this end case
___
Freeciv-dev maili
http://bugs.freeciv.org/Ticket/Display.html?id=39698 >
It may be possible to use the trunk (2.1.99) editor for 2.1, but it's not
practical. The 2.1 files are two years older and incompatible. Sadly,
some "powers that be" decided not to include the editor in 2.1.
_
http://bugs.freeciv.org/Ticket/Display.html?id=15854 >
Marko Lindqvist wrote:
> Ok, it *is* possible to add focus units when goto is active. Replaced
> assert() with hover cancel. This is all that S2_1 needs. For trunk we
> may consider adding new goto_map for additional units in focus (if
> th
http://bugs.freeciv.org/Ticket/Display.html?id=39642 >
I strongly disagree with the creation of en_US.po
Strings that exist, and need trivial fixing for grammar (not content),
should be updated in both the code source and *all* the translation *.po
keys. It's easy to do, and there's no effort n
http://bugs.freeciv.org/Ticket/Display.html?id=39693 >
Daniel Markstedt wrote:
> It's IMHO ok to add new translatable strings while implementing new
> functionality. What should be avoided is making minor adjustments to
> existing ones.
>
Wasn't new functionality, was a 2.1 bug fix. But OK, I'l
http://bugs.freeciv.org/Ticket/Display.html?id=39693 >
No, that's not the best fix. You shouldn't test the destination before
testing whether a goto is active. The !goto_get_turns does both.
I used the existing infinity and existing "Turns to target: %d", just to
avoid making new translations.
http://bugs.freeciv.org/Ticket/Display.html?id=39637 >
My mistake. Checking the history, it should be "building".
Committed revision 13559.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=39683 >
My mistake. Every call actually *is* for IF_GOLD, so I didn't catch the
copy and paste error.
Committed revision 13558.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/lis
Egor Vyscrebentsov wrote:
> This change cause snapshots tarball making to break. No errors in this
> commit, every change of api.pkg will break 'make dist': tolua is not
> made. One more reason I'm againt of just removing generated files
> from svn. (Not that our Makefiles are ok, though)
>
My und
http://bugs.freeciv.org/Ticket/Display.html?id=39609 >
As I was testing several related bugs (PR#29982, PR#39339, PR#39430):
"goto_get_turns: Assertion unit_is_in_focus(punit) failed"
I found that hitting escape caused the list of focused units to disappear.
Clicking anywhere on the map resto
http://bugs.freeciv.org/Ticket/Display.html?id=39430 >
The described test works in current code, presumably due to recent
PR#18010 revisions.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=39339 >
Correction, it was hidden in goto_map_iterate() definition.
However, this may be related to PR#29982 and/or PR#39340, dealing with
unit focus during clicks on sidebar and popups respectively.
__
http://bugs.freeciv.org/Ticket/Display.html?id=39339 >
There was no assert anymore in goto_get_turns(), even prior to recent
PR#18010 revisions.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=29982 >
The described test works in current code. Moreover, there was no assert
anymore in goto_get_turns(), even before PR#18010 revisions.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail
http://bugs.freeciv.org/Ticket/Display.html?id=18010 >
Pepeto _ wrote:
> 15) the first tile (the unit tile) is an invalid destination when the
> unit just entered in the goto state whereas, it's valid if you move
> first the cursor on an other tile.
>
Odd, pf_* code is sometimes returning a "val
http://bugs.freeciv.org/Ticket/Display.html?id=18010 >
The working patch for trunk handles all the above issues. (The patch
for S2_1 differs in 2 lines, but we're waiting for a beta release.)
Index: client/control.c
===
--- client
http://bugs.freeciv.org/Ticket/Display.html?id=18010 >
11) request_unit_connect() doesn't update the cursor (to show invalid).
12) Escape to back out of waypoints doesn't work for HOVER_CONNECT
(missing in test of hover_state).
13) The number of turns displayed in client/text.c (and its do
Marko Lindqvist wrote:
> But we agree that earlier release would be better than waiting for
> this? I can accept waiting up to Sunday, though.
>
Oh, absolutely!
The only thing I see is the PR#39599 and PR#39600, as they are needed to
compile
___
F
http://bugs.freeciv.org/Ticket/Display.html?id=18010 >
I've tracked the problem to:
r11378 | jdorje | 2005-12-23 -- PR#14365, battlegroups, and
r11391 | jdorje | 2005-12-26 -- PR#14992, unitlists.
The code is still almost identical in both S2_1 and trunk.
There are quite a few problems with
Daniel Markstedt wrote:
> Fine, I'll schedule a new release for Friday then. Would that give you
> enough time to root out any obvious issues?
>
Friday?!?! I thought we were going to do it yesterday
I'll see whether I can re-architect Pepeto's goto fixes. Cannot promise
anything. But I was
(PR#39596) 2.1.0 capability cleanup
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=39596 >
Committed S2_1 revision 13366.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=39596 >
Daniel Markstedt wrote:
> Compiles here on OSX 10.3.9. Setup-specific problem?
>
Doesn't compile on MacOS 10.3.9 here, running up-to-date MacPorts.
Of course, I seem to remember there were header differences in Daniel's
setup that throw a l
http://bugs.freeciv.org/Ticket/Display.html?id=39597 >
Committed trunk revision 13364, S2_1 revision 13365.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=39597 >
Specifically, for all BSD systems!
socklen_t was originally created and defined for BSD, belongs in
sys/socket.h, and is always 32-bits (as a field in a struct).
Apparently, some other systems toss it in the wrong place, and are not
compati
http://bugs.freeciv.org/Ticket/Display.html?id=39597 >
PR#19481 (commits 13355 and 13356) broke compile for non-windows systems.
In file included from netintf.c:57:
netintf.h:64: warning: redefinition of `socklen_t'
/usr/include/sys/socket.h:79: warning: `socklen_t' previously declared here
make
http://bugs.freeciv.org/Ticket/Display.html?id=39596 >
Consolidate mandatory capabilities.
Left ReportFreezeFix, as this is not in trunk and therefore may be removed
before conclusion of beta cycle.
Not yet checked in, as PR#19481 (Commits 13355 and 13356) broke compile for
non-windows systems.
Daniel Markstedt wrote:
> Less than 24h remain until the time when I intended to create the
> 2.1.0-beta6 release. However, Marko has asked me to postpone it to
> sort out a network protocol incompatibility issue, so I won't force
> that deadline.
>
> What other critical issues remain to get this
http://bugs.freeciv.org/Ticket/Display.html?id=39434 >
Marko Lindqvist wrote:
> As a part of feature development, #18380 is not meant to be ported to S2_1.
>
As primarily a bug fix, #18380 should have been ported to S2_1, still
unreleased. And it's not too late
_
http://bugs.freeciv.org/Ticket/Display.html?id=39587 >
http://freeciv.wikia.com/wiki/TODO-2.1
Help texts were supposed to be one of the 2.1 improvements.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=39584 >
Marko Lindqvist wrote:
> No po/Makefile of any kind is generated if there is --disable-nls
> configure option.
>
> To reproduce:
> > mkdir completely_empty_builddir
> > cd completely_empty_builddir
> > ../freeciv.src/autogen.sh --disabl
http://bugs.freeciv.org/Ticket/Display.html?id=18010 >
Pepeto _ wrote:
> I'm using S2_1 with gtk-2.0 support.
>
>> GTK2 'y' or 'Y' does not select units in multiple tiles. It selects the
>> same unit from among units in a stack on a single tile
> Are you sure? Here, with 'y', I select all t
http://bugs.freeciv.org/Ticket/Display.html?id=18010 >
Pepeto _ wrote:
> In this example, you need 2 engineers or more (or explorers, if you move
> one on the other island). One of this unit is on a island, the other is
> on the second island. There are land unit, so, if you select them both
> (a
http://bugs.freeciv.org/Ticket/Display.html?id=18010 >
Still unable to reproduce. Contrary to your instructions, you do not have
2 or more engineers in any city. There are 2 cities. One has a transport.
The other 1 settler, 1 engineer, and 4 explorers.
Using 'y' and then 'g' on the currently
http://bugs.freeciv.org/Ticket/Display.html?id=18010 >
I found another trace in an earlier report, too. Merged.
Pepeto _ wrote:
> Let try this, and you will understand very fast what is wrong.
>
Thanks for more complete instructions.
___
Freeciv-d
http://bugs.freeciv.org/Ticket/Display.html?id=39462 >
Pepeto _ wrote:
> 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...
>
Thought I'd test them without the patch first to get the crash.
Nope. The curren
http://bugs.freeciv.org/Ticket/Display.html?id=39572 >
Committed trunk revision 13343, S2_1 revision 13344.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
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 tech
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 packet de
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 cr
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 develo
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/cap.c
>
That is not a documented packet
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 RU
http://bugs.freeciv.org/Ticket/Display.html?id=39576 >
There are a number of ancient open bugs, and recently resolved PR#39437
merely tossed bad attributes.
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
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
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.
___
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
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() is
http://bugs.freeciv.org/Ticket/Display.html?id=39462 >
OK, I don't know anything about this goto code, but I like getting rid
of the static variable, and the code seems sensible.
Are there some old bug reports with games we can test?
I'd hope to get this in 2.1b5, so we should test the heck out
http://bugs.freeciv.org/Ticket/Display.html?id=39566 >
Trunk version ported to S2_1 revision 13338.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=39572 >
Found another myrand() turn that isn't saved, this time for
make_history_report() in report.c. Patch for trunk:
Index: server/report.c
===
--- server/report.c (revision 13
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 to test everything.
_
http://bugs.freeciv.org/Ticket/Display.html?id=39397 >
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 you
in S2_1?
And are we ever going to have
http://bugs.freeciv.org/Ticket/Display.html?id=19044 >
Jason Dorje Short wrote:
> This patch allows S2_0 to load (some) games from S2_1.
>
This is a patch against S2_0. It isn't part of the S2_1 code base, and
should not be part of the 2.1 meta ticket.
Worse,
> ... and no specials can be load
http://bugs.freeciv.org/Ticket/Display.html?id=39462 >
Pepeto _ wrote:
> This is a first patch to fix the bug. With this, you cannot get a crash
> with goto, patrol and connect. However, the cursor doesn't work well,
Thank you! Is this trunk or 2.1?
> sometimes it's give a right move cursor,
STOP, STOP!
Don't announce it yet, the first tests crash (PR#39570).
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=39570 >
Found same in S2_0, too
Committed S2_0 revision 13334. (blindly untested)
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=39570 >
Committed S2_1 revision 1. (blindly untested)
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=39570 >
Committed trunk revision 13332. (tested)
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=39570 >
William Allen Simpson wrote:
> So, we're looking for some bogon committed to both trunk and S2_1 recently.
>
Found it! Bad patch from PR#39507.
Took inf_close() out of section_file_read_dup(), but forgot the very fi
http://bugs.freeciv.org/Ticket/Display.html?id=39570 >
Christian Prochaska wrote:
> got one in Linux (but not in Windows):
>
Excellent! I'll walk it back.
Also, confirmed same problem in trunk:
inputfile.c:179: failed assertion `inf != NULL'
Abort trap
So, we're looking for some bogon committ
http://bugs.freeciv.org/Ticket/Display.html?id=39570 >
Christian Prochaska wrote:
> When .civclientrc is missing (after a fresh install) the client aborts:
>
> inputfile.c:179: assert_sanity: Assertion `inf != ((void *)0)' failed
>
We'll need somebody whose assert() generates a stack trace.
http://bugs.freeciv.org/Ticket/Display.html?id=19705 >
Daniel Doran wrote:
> In the Microprose game Civilization II, only grassland could have
> "Resource Shields". Changing the terrain type to anything else caused
> the resource to change to one of the two special resources specific to
> the
http://bugs.freeciv.org/Ticket/Display.html?id=39434 >
Marko Lindqvist wrote:
> What is keeping this ticket open?
>
The general principal that developer/reporters close their own tickets?
The fact that trunk is different, and needs further analysis?
Ulrik was really active for awhile, I hope
http://bugs.freeciv.org/Ticket/Display.html?id=39566 >
Marko Lindqvist wrote:
> All users seem to use worklist named "worklist", which of course
> again works (even if I'm not big fan of naming structures and their
> instances with the same name).
>
Agreed, been changing them as practical
601 - 700 of 915 matches
Mail list logo
