http://bugs.freeciv.org/Ticket/Display.html?id=40113 >
It was too hard to do it all in one patch. Please check whether the
current revision fixes your problem?
I'll finish removing the duplicates later
___
Freeciv-dev mailing list
Freeciv-dev@g
http://bugs.freeciv.org/Ticket/Display.html?id=40115 >
Committed trunk revision 14425.
Committed S2_2 revision 14426.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=40115 >
Almost all references to game.info.player_idx were eliminated in PR#39872.
This removes the remaining 9 instances in 6 files.
While investigating, another bug was discovered! When players are
renumbered during pre-game, aconnection.player w
http://bugs.freeciv.org/Ticket/Display.html?id=40113 >
I indicated earlier in the discussion thread where you added the revised
test that is now failing, because the two pointers are updated by
different packets and apparently aren't always equal
I assumed you had a reason for making the cha
http://bugs.freeciv.org/Ticket/Display.html?id=40113 >
Madeline Book wrote:
> ... In the case where the client's player is then
> created (attach_connection_to_player(pconn, NULL) returns
> TRUE, server/connecthand.c +137) the server does not
> notify the client that its game.info.player_idx has
http://bugs.freeciv.org/Ticket/Display.html?id=40114 >
Committed trunk revision 14423.
Committed S2_2 revision 14424.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=40113 >
Madeline Book wrote:
> If only I knew of some way to find the relevant PR#s (besides
> PR#39872)! How do you suggest I go about doing that? I am not
> very good yet with RT's search capabilities.
>
Please re-read the thread, either in your e
http://bugs.freeciv.org/Ticket/Display.html?id=40113 >
Madeline Book wrote:
> So I supposed it should be set for clients connecting to
> a server somewhere remotely (e.g. a to play a game online).
>
It should be set by the server and sent to the client after the client has
been selected for a
http://bugs.freeciv.org/Ticket/Display.html?id=40113 >
Now that I've had some sleep
Madeline Book wrote:
> Yes, I was afraid of something like that. So what are the
> semantics of client.playing?
It is set from game.info.player_idx -- exclusively.
> Is it supposed to be NULL
> when the c
http://bugs.freeciv.org/Ticket/Display.html?id=40111 >
Per I. Mathisen wrote:
> It is not a bug. Also, making diplomats partially invisible would
> upset a game balanced already tilted too much in favour of diplomats
> and spies as it is.
>
Madeline didn't write that. I did.
And we already kno
http://bugs.freeciv.org/Ticket/Display.html?id=40113 >
I have examined all instances of send_conn_info(), and with one exception,
they seem to come after send_player_info() -- which is how client.playing
is set. Please post the exact commands that you send.
And have you tested with any previous
http://bugs.freeciv.org/Ticket/Display.html?id=40113 >
This appears to be wrong. This might set client.playing for an observer,
which would violate quite a bit of existing logic.
It should not be possible for an observer to pick a nation. Is that what
you tried? (You didn't mention that in yo
http://bugs.freeciv.org/Ticket/Display.html?id=40110 >
Madeline Book wrote:
> Unfortunately for you, posting a comment about a side-effect
> of your patch does not imply that the person posting the comment
> tested your patch. But never fear, there is PR#40113.
>
Unfortunately for all of us, pos
http://bugs.freeciv.org/Ticket/Display.html?id=40113 >
Cannot duplicate, running client with internal server. Tried random nation
button (my usual test), random nation button on nation dialog, and picking
specific nation. All work.
___
Freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=40110 >
Madeline Book wrote:
> I never tested the code
WTF! The whole purpose of posting patches for comments is that the patches
are actively tested!
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
http://bugs.freeciv.org/Ticket/Display.html?id=40114 >
This is the last substantive use on the client side. For unknown reasons,
it parallels code in common/aicore/cm.c -- which is called and over-writes
the calculations!
The only advantage is this code has some debug counting and logging; that
http://bugs.freeciv.org/Ticket/Display.html?id=40110 >
Since Madeline's testing revealed no bugs in the code execution, and the
request(s) for additional game options are discussed in other tickets:
Committed trunk revision 14421.
Committed S2_2 revision 14422.
___
http://bugs.freeciv.org/Ticket/Display.html?id=40112 >
Madeline Book wrote:
> for stealth fighters/bombers, consider that submarines can
> in fact be detected by their effect on city workers when their
> controlling player is foolish enough to move them into the
> field of the enemy city
>
T
http://bugs.freeciv.org/Ticket/Display.html?id=40111 >
Madeline Book wrote:
> Spies and diplomats do not have the Partial_Invis flag.
This is a bug. These units should not show up until adjacent to cities,
and should be completely invisible to passing units.
_
http://bugs.freeciv.org/Ticket/Display.html?id=40110 >
Madeline Book wrote:
> I mean a server setting (in
> server/settings.c) like savepalace or killcitizen,
> I don't see why
> this should be for things (?) that change only from
> ruleset to ruleset
>
Neither should be server se
http://bugs.freeciv.org/Ticket/Display.html?id=40110 >
Madeline Book wrote:
> And as for appealing to realism (I assume that is what
> you mean by "usual expectations",
I meant the actual behavior of civ1/2/3. We only need "options" for things
that change from ruleset to ruleset.
Does an air
http://bugs.freeciv.org/Ticket/Display.html?id=40110 >
The first and most obvious part of the patch updates the tile/vision
documentation somewhat, as it was woefully out of date!
Renamed some of the enum known_type to reflect their source, and replaced
the order dependent < <= >= > tests.
Move
http://bugs.freeciv.org/Ticket/Display.html?id=40106 >
Committed trunk revision 14419.
Committed S2_2 revision 14420.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=39872 >
Originally had thought about client.player, but changed it to .playing
after considering the meaning. In freeciv, "player" is the civilization,
not the user. That's what's somewhat confusing.
The clients are playing (or observing) the civi
http://bugs.freeciv.org/Ticket/Display.html?id=40106 >
Currently, the worked tile fields are not sent. Instead, the worked pointers
are set using the city_info packet city_map[].
This patch merely passes the worked city id value. A future patch will
change the client to use the field.
Also, t
http://bugs.freeciv.org/Ticket/Display.html?id=40105 >
I'm completely unable to find anywhere that documents why spec_sprite is
actually useful?!?!
/* Skip the normal drawing process. */
/* FIXME: this should avoid calling load_sprite since it's slow and
* increases the refcount withou
http://bugs.freeciv.org/Ticket/Display.html?id=39872 >
Forgot to mention that although this was intended as a cleanup, it
eventually solved some annoying non-crashing bugs. Apparently, the
civmanual was badly borked; some server tests always ran as player 0;
and nobody *really* uses the help in
http://bugs.freeciv.org/Ticket/Display.html?id=39872 >
William Allen Simpson wrote:
> Trunk will take some more effort
>
To work around Per's removal of embassies.
Committed trunk revision 14418.
___
Freeciv-dev mailing li
http://bugs.freeciv.org/Ticket/Display.html?id=40104 >
Committed trunk revision 14415.
Committed S2_2 revision 14416.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=40100 >
Just noting in passing that there's Yet Another Copy of the city worker in
citymap.c, this time as an -(pcity->id). What a mess!
We have a citymap (whole world), city_map for each city, the world tiles,
and player tiles With conversion
http://bugs.freeciv.org/Ticket/Display.html?id=40101 >
I tried to figure out how that came into the code base, and wasn't
successful. It's not in 2.0, and none of my searching found it.
Ah well, I wish all our problems were so easy to solve
Thanks!
Committed trunk revision 14412.
Committe
http://bugs.freeciv.org/Ticket/Display.html?id=40100 >
I've asked on the developers list, and nobody knows a reason for this
anachronistic structure. Any time there are 2 different copies of the
same data, there's bound to be trouble keeping them synchronized.
The server side doesn't depend on
http://bugs.freeciv.org/Ticket/Display.html?id=40099 >
An assert() failure is *always* a bug! It's something the developer added
to test and any such failure should never happen.
Could you reply with the message, and attach the savegame?
___
Freeci
http://bugs.freeciv.org/Ticket/Display.html?id=40098 >
Committed trunk revision 14405.
Committed S2_2 revision 14406.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=40098 >
In PR#40073, I moved the code from client/tilespec.c into utility/rand.c,
but now it seems to assert() on larger maps. Changed the assert() to allow
larger values. And use standard header definitions!
Index: utility/rand.c
http://bugs.freeciv.org/Ticket/Display.html?id=40096 >
After more testing, the previous patch still expanded the range much too
quickly, so I've scaled it some more, with every size having some effect.
Here's the list for borders 4:
City 2.1now
Size r**2 r**2
1 4 2 unit
http://bugs.freeciv.org/Ticket/Display.html?id=40096 >
With the recent changes that being to deviate from 2.1 border behavior,
it's about time to add expanded vision to the mix.
This should expand to the same limit as the borders, or where the borders
would be over the ocean. But it does some s
http://bugs.freeciv.org/Ticket/Display.html?id=40095 >
Committed trunk revision 14398.
Committed S2_2 revision 14399.
Leaving open for possible 2.1 backport.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=40095 >
In PR#40072, the first reported error has Tenochtitlan shown with the wrong
border. This patch does not fix the underlying issue, but is a step toward
making the savegame playable.
This patch also fixes other problems found along the way...
http://bugs.freeciv.org/Ticket/Display.html?id=39563 >
Not having seen anything in 12 hours, and the proposed patch being so trivial,
Committed trunk revision 14396.
Committed S2_2 revision 14397.
Thanks, Marko!
___
Freeciv-dev mailing list
Freeciv
http://bugs.freeciv.org/Ticket/Display.html?id=40093 >
Committed trunk revision 14394.
Committed S2_2 revision 14395.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=40092 >
I've been testing this patch since I reported the fix in PR#40072, and it was
long past time:
Committed trunk revision 14392.
Committed S2_2 revision 14393.
___
Freeciv-dev mailing list
Freeciv-
http://bugs.freeciv.org/Ticket/Display.html?id=40092 >
In PR#40072, the second reported error has Teotitlan shown with the wrong
owner. This patch does not fix the underlying issue, but is a step toward
making the savegame playable.
The savegame.c:2800 code tries to fix inconsistent games. Thi
http://bugs.freeciv.org/Ticket/Display.html?id=39563 >
OK, seems reasonable. I'd say commit.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=39563 >
Here's my proposed patch to rid us of this troublesome beast
Index: ai/advdomestic.c
===
--- ai/advdomestic.c(revision 14391)
+++ ai/advdomestic.c(working copy)
@@ -
http://bugs.freeciv.org/Ticket/Display.html?id=39563 >
Thank you for finding my mistake in PR#39553!
This worthless function is only called 4 places, and the first place I've
looked is:
ai/advmilitary.c:1223:
if (best_choice.want > choice->want) {
/* We want attacker more than what we
http://bugs.freeciv.org/Ticket/Display.html?id=40087 >
Moved the existing ruleset_error() intercept into the con_handle_log()
callback, so that server log messages can be sent to all connections.
Currently, only LOG_FATAL and LOG_ERROR.
Renamed E_MESSAGE_WALL to E_LOG_FATAL, as that was already
http://bugs.freeciv.org/Ticket/Display.html?id=40088 >
This is implied by the sanitycheck repair in PR#40086, that presumably
happened in the PR#40072 savegame.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-de
http://bugs.freeciv.org/Ticket/Display.html?id=40086 >
Leaving open, as this needs to to be retrofitted for 2.1, too.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=40086 >
Define FREE_WORKED_TILES for counting is_free_worked_tile(), currently
only 1! Should generalize in rulesets?
Fix real_sanity_check_city() to prevent removing city workers for any
is_free_worked_tile(). Should consolidate with other functi
http://bugs.freeciv.org/Ticket/Display.html?id=40087 >
Rewrite sanitycheck, and intercept other freelog() error and fatal messages.
Send via the Chat/Event message interface.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/list
http://bugs.freeciv.org/Ticket/Display.html?id=40086 >
Jason Dorje Short wrote:
> The CM code is in common/aicore/cm.c.
>
Well, I've spent a bit of time looking at that, and its pretty difficult.
Whomever wrote that was a genius, or an idiot
Anyway, using the old tried and true pedestrian d
http://bugs.freeciv.org/Ticket/Display.html?id=40072 >
An interesting savegame -- it reproducibly demonstrates three different
bugs! Two of which are detailed in the report. In the savegame file,
Tenochtitlan:
the city id (176) hasn't changed.
originally owned by player1 "Aztec"
curre
http://bugs.freeciv.org/Ticket/Display.html?id=40085 >
Somebody had sent me private email bragging about his/her DoS against some
game server, and telling me this was needed. I didn't bother to reply.
Anyway, per host blocking will adversely affect NATs and VPNs. The real
DoS problem is TCB sa
http://bugs.freeciv.org/Ticket/Display.html?id=40084 >
Forgot to mention that it fixes the bug already reported in PR#40080,
increasing the ai->stats.diplomat_reservations bit vector from 32767
(wrong) to 65536. Better not to overflow, even as a better solution
may be developed in the future
http://bugs.freeciv.org/Ticket/Display.html?id=40084 >
Some of the preliminary steps toward the PR#40080 long-term goal. This
patch mostly clears the decks for shorter-term crashing bug fixes.
It includes some code already in 2.1 (PR#39980), used for initializing the
game_identifier. Moved fro
http://bugs.freeciv.org/Ticket/Display.html?id=40080 >
William Allen Simpson wrote:
> There are at least 148 *city->id references in 44 files (and untold others
> with other pointer names).
>
This is a seriously daunting task!
The agents.c code passes city ids around.
28
http://bugs.freeciv.org/Ticket/Display.html?id=40080 >
There are at least 148 *city->id references in 44 files (and untold others
with other pointer names).
I've found a serious overflow bug already. The ids are unsigned short, the
range is 65536 numbers, but ai/aidata.c allocates all players a
http://bugs.freeciv.org/Ticket/Display.html?id=39563 >
#defined LOG_WANT symbol, moved other local LOG_* to front of file
Does not fix anything other than logging!
Committed trunk revision 14384.
Committed S2_2 revision 14385.
Leaving open for future examination by others. This code is chock-
http://bugs.freeciv.org/Ticket/Display.html?id=40080 >
In PR#40075, Jason Dorje Short wrote:
> ... Why not just use the ptile->index as the city id? Cities
> can't ever move and there can't ever be more than once city on a
> tile...right?
>
___
http://bugs.freeciv.org/Ticket/Display.html?id=40075 >
Michael Kaufman wrote:
> On Mon, Feb 04, 2008 at 07:49:58PM -0800, Jason Dorje Short wrote:
>> ... Why not just use the ptile->index as the city id? ...
>
> ...
> without knowing the tile location that the city sits on (the capital city?)
http://bugs.freeciv.org/Ticket/Display.html?id=40075 >
William Allen Simpson wrote:
> ==12774== Address 0x5391ca0 is 0 bytes inside a block of size 76 free'd
> ==12774==at 0x402365C: free (vg_replace_malloc.c:323)
> ==12774==by 0x80E6669: reality_check_city
http://bugs.freeciv.org/Ticket/Display.html?id=40075 >
Jason Dorje Short wrote:
> I got this with chris's recent savegame but I have no idea if it's
> related. Attached is the previous savegame; no clue if it's reproducable.
>
It helps pinpoint one of the potential problems from PR#40068 & PR#
http://bugs.freeciv.org/Ticket/Display.html?id=40069 >
Jason Dorje Short wrote:
> If this value is on the stack, what is right next to it that might be
> overrun in memory?
>
It's on the heap. It could be anything I've tried swapping the name
back to front so that gets overrun instead, but
http://bugs.freeciv.org/Ticket/Display.html?id=39563 >
Found the old report and merged with it. Added some PR# links, instead
of the revision numbers Marko used in the report.
Funny, I've been waiting for Marko to fix this, as it's his original
report, but now I see that Per flagged it for me
http://bugs.freeciv.org/Ticket/Display.html?id=40079 >
Committed trunk revision 14381.
Committed S2_2 revision 14382.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=40079 >
While poking at the memory problems, tried moving city ids to avoid the
possible overrun, and was checking how ids were allocated. Discovered that
the running game never marks the used id numbers! And never checks they've
run out of id numb
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
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
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=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=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=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=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=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 >
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=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=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=40068 >
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.
What I don't understand is why it's not reproducible?
http://bugs.freeciv.org/Ticket/Display.html?id=10400 >
This has been waiting since 2004 Oct -- really shouldn't let better be the
enemy of good. There are many more LOG_FATAL and LOG_ERROR than LOG_NORMAL.
Will do others later, as they are likely reductions in translation rather
than more transl
http://bugs.freeciv.org/Ticket/Display.html?id=40066 >
In PR#40043, the disfunctional wordwrap was removed for server/stdinhand.c
(stdout) and others.
In PR#40062, the Usage: could sometimes use some wordwrap and prettifying.
Ideally, the server/commands.c and server/settings.c text should not
http://bugs.freeciv.org/Ticket/Display.html?id=40062 >
I looked at cmd_reply_prefix(), and chose not to use it for the Usage: lines.
It really isn't multi-lingual friendly. Saved for another ticket.
I looked at command_named(). It should be re-written to be more like
find_player_by_name_prefix
http://bugs.freeciv.org/Ticket/Display.html?id=40064 >
My trivial patch was only meant to change an existing array from sentence
fragments for easier translation. Then, it ballooned from fixed size to
variable, and fancier, and
Used sizeof() instead of ARRAY_SIZE(). Fixed.
Excellent repor
http://bugs.freeciv.org/Ticket/Display.html?id=40064 >
Jason Short wrote:
> Looks like this is cause by 40063.
>
That would be highly surprising, as PR#40063 had not been committed yet!
Anyway, I've just committed it minutes ago, and I'll do some testing now
with the savegame provided Than
http://bugs.freeciv.org/Ticket/Display.html?id=40063 >
Added +1 to ensure only top rank is rated Supreme (unless tied).
Added clamp to final entry.
Committed S2_2 revision 14364.
Committed trunk revision 14365.
Index: server/report.c
=
http://bugs.freeciv.org/Ticket/Display.html?id=40020 >
Committed S2_1 revision 14348.
Committed S2_2 revision 14349.
Committed trunk revision 14350.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=40057 >
Jason, the requisite time has passed -- are you committing this, or am I?
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
http://bugs.freeciv.org/Ticket/Display.html?id=39620 >
Marko, the requisite time has passed -- are you committing this, or am I?
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
Christian Knoke wrote:
> #: data/default/script.lua:30
> #, fuzzy, c-format
> msgid ""
> "The %s have acquired %s from ancient scrolls of wisdom."
>
Some months ago, the 2.2 (then trunk) had the hut code moved to lua scripts.
Doesn't it work properly now?
And why the long sp
http://bugs.freeciv.org/Ticket/Display.html?id=40063 >
... for better scaling (and more variety).
Index: server/report.c
===
--- server/report.c (revision 14347)
+++ server/report.c (working copy)
@@ -158,25 +158,38 @@
http://bugs.freeciv.org/Ticket/Display.html?id=40059 >
Based on discussion on the -i18n list, it seems that removing the
possessive names is highly desirable. And, that swapping the fields is
common. Also, there's a list of sentence fragments immediately following
the header. Changed to allow
http://bugs.freeciv.org/Ticket/Display.html?id=40006 >
Christian Prochaska wrote:
> Did you "make install" before starting the client?
>
Nope, should not be needed. I'm running the client (with ./civ) in the
build directory itself. All the default paths seem to be working: ./data,
etc. The ga
http://bugs.freeciv.org/Ticket/Display.html?id=40006 >
As I mentioned in PR#40007, I cannot even get them to display, other than
for the OK, Yes, No, and Cancel buttons. Jason says "... the GTK library is
using japanese correctly, but freeciv is still using the untranslated
strings. I have troub
http://bugs.freeciv.org/Ticket/Display.html?id=40062 >
Originally reported in PR#40061 for the debug command, investigation showed
that many of the commands had duplicate command usage synopses. Moreover,
the server/commands.c version was often out-of-date.
Merge all usage synopses into server/
http://bugs.freeciv.org/Ticket/Display.html?id=40060 >
Christian Knoke wrote:
>> debug
> Speicherzugriffsfehler (core dumped)
>
Unable to reproduce. Works here for both 2.1 and 2.2.
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.
http://bugs.freeciv.org/Ticket/Display.html?id=40036 >
Jason Dorje Short wrote:
> Unfortunately I don't seem to get this behavior anymore, though people
> keep reporting its symptoms. Every time I kill my client the server
> saves the game properly, without aitoggling the human.
>
That supposed
http://bugs.freeciv.org/Ticket/Display.html?id=40058 >
Jason Short wrote:
> Patch is fine but the comment is a bit misleading - generally the
> returned value is passed off to GTK which wants it in UTF-8 (aka the
> internal encoding). When used in the server this may not be the case.
>
Changed
http://bugs.freeciv.org/Ticket/Display.html?id=40057 >
Jason Dorje Short wrote:
> If you are asking about encodings, gui-sdl uses the call inside freelog
> which expects the string in the internal encoding (utf-8).
>
OK.
> Can we remove gui-mui?
>
Already done (2.2 and beyond).
___
http://bugs.freeciv.org/Ticket/Display.html?id=40059 >
PR#34192 added a trailing year. Not only does that make no sense as English
grammar, the patch didn't update all (any) of the translations, and thus
creates a msgstr error report.
The existing reports use a possessive for the names of the h
1 - 100 of 915 matches
Mail list logo
