URL: http://bugs.freeciv.org/Ticket/Display.html?id=14236
This can probably be closed. The message is gone from the source, and
all the places the function is called check for A_UNSET now.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39364
Recently compiled on iMacG5 with MacOS 10.3.9 and MacPorts.
export LDFLAGS=-L/opt/local/lib
export CPPFLAGS=-I/opt/local/include
export CC=gcc -no-cpp-precomp
./configure --disable-nls --enable-client=gtk2
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39365
Recent (2006 May 2) MacOS compile of freeciv-2.1.0-beta4.tar.bz2.
This is a very obscure error, and likely not worth fixing before release,
unless a new beta is produced. It should be fixed in any subsequent
2.1.n release.
Reproduce
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39365
Daniel Doran wrote:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39365
I have never experienced any other behavior from Freeciv. freeciv-1.x
versions on Win and Linux exhibited the precise behavior described.
Never is an
William Allen Simpson wrote:
In 1995, somebody added me to the RT users. I've changed email, and my
subscription to this list was updated (last year), but it doesn't seem to
have updated the RT entry. Could somebody fix it?
I've finally been able to login and change the password (something
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39365
Jason Dorje Short wrote:
There is a whole sequence of tickets devoted to this bug. It is a
well-known bug but no progress toward fixing it has been made in quite
some time. The problem is the sequence of random calls in the reload
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39365
I ended up with even more random debugging (attached patch), and solved
the problems, or at least several of them.
Also found an uninitialized founder_boat along the way.
My solution to the problems is entirely in savegame.c, saving
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39365
Those patches were against the 2.1.0b4 source, here's the savegame.c
patch against current revision 12954.
Untested. It compiles.
--- ../savegame.c Thu May 3 12:42:30 2007
+++ server/savegame.c Sun May 13 16:17:45 2007
@@
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39365
Those patches were against the 2.1.0b4 source, here's the rand.c
patch against current revision 12954, better conforming to your
recent formatting.
--- ../rand.c Sun May 13 16:05:47 2007
+++ utility/rand.c Sun May 13 16:33:20
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39365
Those patches were against the 2.1.0b4 source, here's the city.c
patch against current revision 12954 (single line added).
I didn't realize how much has been added since 2.1.0! Hopefully,
2.1.0 can be laid to bed soon
---
James Supancic wrote:
I am thinking about working on an Ogre3D GUI for freeciv. I've been
looking over the code in freeciv/freeciv/client/gui-* and think I
might be able to develop something nice.
This would be wonderful! I actually looked at doing it 18+ months ago,
but decided it would be
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39342
Per I. Mathisen wrote:
Given how much FoW you usually have, this will make your real borders
really hard to visualize and plan with respect to.
I do not really see a good and simple fix to this issue. We need to change
the way
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39372
or vice versa.
I think that the celebrate_size is a better name for both.
Currently, the code is:
/* City Parameters */
game.info.celebratesize =
secfile_lookup_int_default(file, GAME_DEFAULT_CELEBRATESIZE,
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39370
Per I. Mathisen wrote:
Yes. Patch to change this most welcome.
Apparently, it was a conscious decision by some prior developer. There
is a documented vision parameter that is only FALSE for cities.
Therefore, I propose a
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39342
Per Inge Mathisen wrote:
So this is like today, only that you forget borders after a turn if
you do not see the border source? It is actually rather complicated,
and it does not answer my worry above that it will make borders hard
to
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39370
Oh bother, I see that while I was poking at keeping things backward
compatible, you made a sweeping change. Ah well, here's my 2.1.0b4
proposal as applied to trunk Mix and match?
URL: http://bugs.freeciv.org/Ticket/Display.html?id=8398
Per I. Mathisen wrote:
I think the proper solution to this problem is that ceasefires do not
count down, but can be broken at any time by any government without penalty.
I disagree. The count down is an essential game function. And
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39367
William Allen Simpson wrote:
3: Unused entries in file data/default/nations.ruleset:
3: unused entry: nation_barbarian.is_observer
3: unused entry: nation_bosnia.ciwilwar_nations
3: unused entry: nation_bosnia.ciwilwar_nations
Per Inge Mathisen wrote:
On 5/18/07, William Allen Simpson [EMAIL PROTECTED] wrote:
Here's the first installment on trivial nation fixes for 2.1.0b4 and
trunk.
Most of the S2_1 changes were already done (please 'svn up' before
making the patch), and the rest would invalidate
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39370
Per I. Mathisen wrote:
I do not see why we should worry about that. It is nice that people can
play mods that feel like Civ1/2 with Freeciv, but we do not need to
support all kinds of small oddball configurations and/or bugs that
I've been waiting around several days to see whether somebody fixes this?
registry.c: In function `section_file_save':
registry.c:816: error: `BUG_URL' undeclared (first use in this function)
registry.c:816: error: (Each undeclared identifier is reported only once
registry.c:816: error: for each
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39378
The hut rules are currently static in unittools.c unit_enter_hut().
The rules should vary for civ1, 2, 3 4.
For civ3 4, huts should respond more favorably to a scout, and
very favorably within a national boundary.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39379
There is greater variety in civ3 (and other) terrain.
Hills can be dry, grassy, and/or forested.
Mountains can be dry, wet, icy, or volcanos.
Oceans have several depths, with ridges, trenches, and vents/volcanos.
Of course, not every
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39381
With so many previous attempts, it seemed prudent to split off my effort
for water into a separate ticket, so that they can cross reference.
This is a more extensive consolidation.
water (formerly ' '):
+ fresh lake (higher
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39381
Patch data/default/terrain.ruleset
Index: data/default/terrain.ruleset
===
--- data/default/terrain.ruleset(revision 12965)
+++ data/default/terrain.ruleset
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39379
Second draft, with minor corrections reconciling earlier attempts:
land:
a ice (arctic, glacier)
A ice + hills
t tundra
T tundra + hills
d desert
D desert + hills
p plain
P plain + hills + evergreen
q plain
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39381
I've discovered that the current state of the trunk is inconsistent.
There appear to be parts of several patches from different PRs. As soon
as the deep tiles are referenced, the client will not start.
The current amplio terrain2.spec
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39381
Here is my second pass at the code. Amplio is ready, but everything else
is broken. Have to keep the name Ocean for various nations to work, so
that is assigned to Coast, as differentiated from Lake and Sea.
Of course, this doesn't
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39382
Tried testing my civ3 oceans against civ2 and civ1, just to make sure my
code is behaving -- lo and behold, they already crash the server --
without my help
civ2
2: Loading rulesets
1: No sea barbarian nation defined. At least one
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39383
While trying to debug some of my terrain changes, it was frustrating that
some error messages had empty (missing/blank) fields. Numerous messages
tried to insert a translated name into log messages that are not translated.
(I'm running
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39383
In this version, I moved the translation into the accessor functions, as
this seemed to be better than spread around in 3 places, especially as the
other places in the code forgot to test for NULL and '\0' (empty string).
Comments in the
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39386
Committed trunk revision 12976.
Note that this makes it obvious that the code does not even come close to
the doc/README.graphics documentation! (Very confusing to new coders.)
Moreover, the match_type = full requires the cell_type =
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39385
It is a patch to client/cityrepdata.c in the S2_1 branch and it builds
fine and seems to work
Of course, since this is an enhancement (not a bug fix, and especially one
that adds new translation), it would be for trunk first, and
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39385
I've a different patch against trunk. The documentation in comments on
how to add are wrong. I shuffled the fields a bit. To make up for the
extra space, I turned off the governor field default.
This doesn't show costs larger than
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39383
William Allen Simpson wrote:
There's a warning, because the current resource list is const, and this
modifies the pointer. Updating the const can happen later.
trunk revision 12977
S2_1 revision 12978
Remaining const struct
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39385
Ulrik Sverdrup wrote:
I did this with the field width wrong as well, but I think we should
reserve a width up to 5 for build costs. I can imagine wonders costing
more than 1 if you buy them from scratch in the derfault ruleset.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39389
Per I. Mathisen wrote:
All LOG_ERROR, LOG_VERBOSE and LOG_FATAL messages should be without
translation.
To summarize, only LOG_NORMAL should be translated, because those are
displayed to the user.
I am not sure if this is written
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39390
This is definitely odd. The history shows that's been around a very long
time
S2_1/ChangeLog:30707:
Thu Jun 17 13:07:54 1999 Nicolas Brunel [EMAIL PROTECTED]:
* acconfig.h, config.h.in, configure.in, client/civclient.c,
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39391
I don't get those warnings/errors, either. Of course, I'm running gcc 3.3
on a G5 -- gcc 4.1 itself won't even compile on this system, something wrong
with the register assignment last time I checked (months ago).
But since getting
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39385
And now the debate:
Could this be pulled up into 2.1 at this late date?
It was a more of a bug fix than a mere enhancement, and on that basis
alone, I'm in favor.
It is missing one new (rarely seen) menu translation. How do I know
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39385
Per I. Mathisen wrote:
The question is, does it change translations? If so, I'd say no. It is
frozen for new features and translation string changes now. We need to get
it out soon... :/
Soon, as in 15 months ago? There are still
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39385
Committed S2_1 revision 12989.
Committed trunk revision 12990.
At this point, both should function exactly the same. Except Russian.
I was surprised to discover that there were quite a few conflicts with S2_1,
because folks have been
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39396
S2_1 revision 12993
trunk revision 12994
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39364
S2_1 revision 12993
trunk revision 12994
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39397
Christian Knoke wrote:
3: Don't have graphics tags or for tech_type Nichts
...
0: Don't have graphics tags t.ocean1 or for base terrain Ocean
This looks like the same kind of thing reported in PR#39388. But I've
had absolutely
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39386
The rather different code in S2_1 was difficult to compare without
straightening it, too. This makes the differences more apparent, and
hopefully will assist debugging recent reports of load failures in
certain configurations.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39389
Combined with (PR#39386) cleanup tilespec.c in hopes of debugging recent
reports of tile load failures in certain configurations.
The freelog removal of translation (in most cases) should clarify the
file and rule names as they are
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39397
Christian Knoke wrote:
svn update
./autogen.sh
make
su -c make install
civclient
~$ which civclient
/usr/local/bin/civclient
Thank you, very helpful. The major difference between your test and my test:
I'm running in the
William Allen Simpson wrote:
Per Inge Mathisen wrote:
Also, while on the topic of api_gen.c|h, I do not see why these
automatically generated source files are in the repository? All the
tools required to generate them are already in the repository.
I agree. And there was a part of a bug
William Allen Simpson wrote:
AFAIK, all that needs to be done is svn delete them, and they should go
away. Somebody must have deliberately added them in the past?
Yes, for cross compiling from linux to windows in:
http://bugs.freeciv.org/Ticket/Display.html?id=13571
There is a better way
Question: is tolua used for anything other than pre-compilation?
That is, AFAICT tolua is only used to build api_gen.*
Therefore, tolua would never be anything other than natively compiled,
and would not be distributed in a binary distribution?
Only lua would be generated for the target
Per Inge Mathisen wrote:
On 6/18/07, William Allen Simpson [EMAIL PROTECTED] wrote:
1) install the latest lua. Make sure it works. Surely the latest lua will
still work with the older tolua!
No, tolua 5.0 does not work with lua 5.1, unfortunately. And there is
no more recent version
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39403
Apparently not using the CPPFLAGS?
===
export LDFLAGS=-L/opt/local/lib
export CPPFLAGS=-I/opt/local/include
export CC=gcc -no-cpp-precomp
./autogen.sh --enable-nls --enable-client=gtk2
--prefix=/Users/wastrel/freeciv-i18n
...
+
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39403
Must be using old instructions. Found some newer ones at:
http://freeciv.wikia.com/wiki/Install-MacOSX
There, it specifies putting them all in the CC variable:
export CC=gcc -no-cpp-precomp -I/opt/local/include -L/opt/local/lib
Per I. Mathisen wrote:
BTW, the sources need some changes to work with new lua and tolua
versions, as you can see in r12995-9, and I am not sure if those changes
are compatible with older lua versions.
Well, I expect to find out over the next couple of days :-)
I'm putting the tolua++
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39406
Egor Vyscrebentsov wrote:
svn branches/S2_1 rev 13004.
gui-xaw and gui-gtk-2.0 do not compiled on my machine with
following error:
freeciv-s2_1/client/packhand.c: In function ‘handle_ruleset_building’
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39388
Daniel Markstedt wrote:
On 6/10/07, William Allen Simpson [EMAIL PROTECTED] wrote:
What tileset?
Any.
Using my improved error logging (most recently r13003 for S2_1), we
discovered that this was not accurate.
As I mentioned
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39397
As I was looking for similar reports, I discovered that you've been
reporting the same Ocean problem since beta 1
#16078: Beta1: civclient crash on game load
http://bugs.freeciv.org/Ticket/Display.html?id=16078
SVN 2.1 22
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39388
The ancient bug had been fixed in trunk months ago.
Tested against all 5 tilesets.
Committed S2_1 revision 13006.
Index: client/tilespec.c
===
--- client/tilespec.c
It appears that tolua++ is a dead end. It hasn't had any fixes for
over a year, and the version 1.0.92 doesn't compile as distributed.
I have no confidence in a coder that accidentally deleted the include
of the primary header file. Clearly somebody that doesn't compile
before commit (and has
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39411
Excellent catch!
(Also, fixed some indentation here.)
Committed S2_1 revision 13012, trunk revision 13013.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39414
The included tolua is not compatible with improvements in lua 5.1, suffers
from some bugs, pointers are identical to unsigned integers, and the code
has not been updated in a long time.
The next incarnation, called tolua++, has
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39416
After my travails trying to integrate toluaxx, I'm back to my original
thought that (like gettext) lua should *optionally* be included for
systems that don't already have a lua package (--with-included-lua).
That is, for cross-building
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39409
Thank you!
Since I was the last to touch this code, I've handled it (again), although
it's not my usual bailiwick.
Also, found that a bug fix had been applied to trunk and not to S2_1, so
that's added, too
Committed trunk revision
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39409
As I was testing the patch, I noticed that there were 6 available node
colors. Not all make sense for edges, but flagging those currently
reachable and researching might be visually helpful on long lines.
I also noticed the .h comments
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39409
Forgot to send the patch, same for both commits.
Index: client/reqtree.c
===
--- client/reqtree.c(revision 13016)
+++ client/reqtree.c(working copy)
@@ -107,8
URL: http://bugs.freeciv.org/Ticket/Display.html?id=37378
Looking through related reports, this is the only remaining open I've
linked these reports a bit. Any others?
Now that there are colored links in the tech tree, it might be a good time
to revisit the color selection.
For example,
URL: http://bugs.freeciv.org/Ticket/Display.html?id=11533
While searching for color reports, found these two and linked them
http://bugs.freeciv.org/Ticket/Display.html?id=2771
I'm replying on the more recent one, currently client-gtk-2.0, the older is
currently client (generic).
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39397
Christian Knoke wrote:
Now, with Revision 13020, the ocean tiles problem seems gone,
Yes, there were two t.ocean1 reports. Sadly, you'd neglected to mention
that you are/were using trident tileset, not default amplio. Made it
hard
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39365
Marko Lindqvist wrote:
See #2346 and #11348
Actually there is a lot of stuff like #11348 in AI code.
Thanks, I've added some links in RT for future reference.
___
Freeciv-dev mailing
URL: http://bugs.freeciv.org/Ticket/Display.html?id=11348
building want is still not saved, but I've saved the next_recalc time in
PR#39365, as that random turn was kicking the random state.
I'm not sure I agree about building want. As long as it is entirely
predictable, it should simply be
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39426
These seem inextricably combined.
This patch gets my verbose log down to only 57 lines! Considering that
the first verbose logs I made (May 10) had 728 lines, and probably twice
that with the many:
3: last message repeated 2 times
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39426
Committed trunk revision 13038. Surprisingly few differences from S2_1.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39405
That turned out to be relatively easy to fix. Send more reports!
Committed S2_1 release 13041.
Index: client/gui-xaw/repodlgs.c
===
--- client/gui-xaw/repodlgs.c
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39405
Christian Prochaska wrote:
Some pointer-to-integer conversion warnings are left. Patch attached.
Looks good to me by visual inspection.
Committed S2_1 revision 13043.
___
Freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39433
Now, I've come full circle to the terrain name translation that started me
down this path a month ago! This patch renames some of the terrain
functions to match similar functions in other headers.
terrain_by_identifier
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39432
A bug in the nation debugging code. It fails to test for NULL
before using a pointer.
Reverted (with FIXME comments) until logic can be resolved.
Committed revision 13045.
___
Freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39434
William Allen Simpson wrote:
Thanks! Added comments. Probably shouldn't be destroyed until after
the messages are sent, but the logic isn't readily apparent.
Comparing against trunk, found that this has been substantially
rewritten
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39431
Timothy Brownawell wrote:
If I try to add a settler to an existing city, the game ends (retuns to
the welcome screen) and prints 2: lost connection to server.
I am unable to duplicate this S2_1 behavior. Do you have a savegame?
My
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39436
As discovered in PR#39386, PR#39388, and PR#39389, tile blending had
diverged between 2.1 and trunk.
In 2.1, is_blended = [0|1] indicates whether there is blending on a
tile. This doesn't actually work. A 0 tile next to an 1 tile
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39431
Excellent work! That's the second time recently we've seen a problem with
code expecting pointers to be valid after removing a unit (the other in
wipe_unit() itself). So, I just hand checked all 60 calls to wipe_unit(),
and that seems
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39436
While coding, a simpler approach appeared. Not as general, but has the
advantage of no changes to existing tilespec files in S2_1 or trunk.
Used the current is_blended as is, but read it as an integer. The files
don't have any
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39436
Committed trunk revision 13053.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39431
Committed trunk revision 13054.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39437
Ties-Jan wrote:
Attached I have a savegame with the error.
Load the game and start as Ivan the Terrible (Russian). The game will crash.
Thanks for the report. You'll have to go back to your old savegame!
===
*** malloc:
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39437
A similar crashing bug was reported to the development list over a year
ago, but not logged in the bug database?
Extract of Message
Subject: [Freeciv-Dev] Security bugs in Freeciv
Date: Sat, 8 Jul 2006 14:31:24 +0200
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39439
OK, but the proper English would be Making.
I've noticed that translation of abbreviations is problematic, so we
shouldn't use them.
Also, nr. might be German abbreviation, but it's not usual English, and
mixing languages is probably
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39435
Like gui_main.c, that should use BUG_URL. And like some other usage,
I'd prefer the Thank you.
report it at %s. Thank you.), BUG_URL);
Index: client/gui-sdl/mapview.c
===
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39435
On second thought, anybody that's using CVS/SVN versions already knows
about how to update the client, we should just drop that part.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39435
Committed trunk revision 13055, S2_1 revision 13056.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39439
Nope, only SDL has anything like of Freeciv, all the rest are
for Freeciv
Committed trunk revision 13055, S2_1 revision 13056.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39440
Good idea. However, have to get permission to add new translation
strings for 2.1.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39431
Committed S2_0 revision 13057.
Also, another wipe_unit(vunit) removed from server/citytools.c,
already removed from S2_1, but I cannot find the bug report.
Index: server/citytools.c
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39435
Should I fix these in S2_0?
I see that Per updated the define, but these old strings still are there.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39440
OK. I made a small revision after checking the other routines, as the
decision whether the menu items exists and the default is already made
earlier by can_unit_add_or_build_city(), no need for the extra default.
Also added {}.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39437
While I have not delved deeply enough to discern the underlying cause of
attributes with bad lengths (probably a code path with an uninitialized
variable), here is a patch to allow the game to proceed without crashing.
Basically,
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39437
trunk revision 13068.
S2_1 revision 13069.
S2_0 revision 13070.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=14387
S2_0 partial implementation for dataio.c only, as part of PR#15840 in:
S2_0 revision 13071.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
URL: http://bugs.freeciv.org/Ticket/Display.html?id=15840
William Allen Simpson wrote:
As for the additions in the proposed patch that serialize new fields in
dio_get_diplstate and dio_put_diplstate, that would not be backward
compatible with S2_0, and therefore ignored for these purposes
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39441
Christian Prochaska wrote:
What about PR#36441 and PR#36496?
PR#36491 should be committed, too, IMHO.
Wow, these are ancient; should have been in 2.0.9 -- added to ticket.
And they have patches! I'll check them in later today.
1 - 100 of 666 matches
Mail list logo
