Follow-up Comment #9, bug #21038 (project freeciv):
I just downloaded Freeciv-2.4.1-win32-gtk2-setup.exe and tested the Korean
IME. It works fine. I can type Korean in the chatline.
___
Reply to this item at:
http://gna.org/bugs/?21038
Update of bug #21038 (project freeciv):
Summary: Can't enter text with CJK input methods = replace
gtk+ DLLs with version 2.24.10 = Can't enter text with some CJK input
methods = replace gtk+ DLLs with version 2.24.10
___
URL:
http://gna.org/patch/?4469
Summary: Reset curl handle between uses
Project: Freeciv
Submitted by: cazfi
Submitted on: Sun 02 Feb 2014 01:07:24 PM EET
Category: general
Priority: 5 - Normal
URL:
http://gna.org/patch/?4470
Summary: Target-specific city production boost effect
Project: Freeciv
Submitted by: jtn
Submitted on: Sun Feb 2 11:43:51 2014
Category: None
Priority: 5 - Normal
Update of bug #21572 (project freeciv):
Category: client = client-gtk-2.0
___
Follow-up Comment #1:
You can already use the F-keys to switch tabs (F1 = main view, F6 = science
etc). Is that not
Follow-up Comment #1, bug #21557 (project freeciv):
You can get similar glitches with width with some tilesets as you switch
between unit stacks of =3 and 3 units, as the more units arrow comes and
goes, causing the left column to get wider (I've been noticing this with
amplio2hexbig). When it
Follow-up Comment #3, patch #4461 (project freeciv):
This currently has hard target of 2.5.0, as S2_5/trunk currently have
regression wrt S2_4 (due to bug #21312 only being reverted on S2_4).
___
Reply to this item at:
Follow-up Comment #9, bug #20058 (project freeciv):
I've grabbed a copy, don't know when I'll try it.
I never did, apparently, and I don't seem to have kept the file cazfi
prepared.
Is there still an experiment that can usefully be done here?
Update of bug #16914 (project freeciv):
Status:None = Works For Me
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Closing, as we
Follow-up Comment #8, patch #4460 (project freeciv):
Thank you cazfi.
I uploaded a .zip here instead of a diff patch because I wanted to know the
opinion of the developers about the changes, and as you have explained, to
know the best procedure to include them in the trunk.
My next planned step
Update of bug #18532 (project freeciv):
Status: Confirmed = Fixed
Assigned to:None = jtn
Open/Closed:Open = Closed
Planned Release:
Follow-up Comment #4, bug #19452 (project freeciv):
This feels like it could be related to bug #18532 (which has
more diagnosis).
That bug is now fixed.
I suspect this is the same problem, but I haven't tried the reproduction case
here, so not claiming as fixed just yet.
URL:
http://gna.org/bugs/?21583
Summary: Client can connect to manually started server rather
than its own spawned one
Project: Freeciv
Submitted by: jtn
Submitted on: Sun Feb 2 14:56:08 2014
Category: None
Follow-up Comment #4, bug #21088 (project freeciv):
Bug #21170 might be another instance of this?
___
Reply to this item at:
http://gna.org/bugs/?21088
___
Message sent via/by Gna!
Update of bug #21088 (project freeciv):
Planned Release: 2.4.1,2.5.0,2.6.0 =
___
Reply to this item at:
http://gna.org/bugs/?21088
___
Message sent
Follow-up Comment #10, bug #21547 (project freeciv):
FWIW, tested cproc's r24327 build and cazfi's r24328 crosser build on Windows
7 32-bit and they seem OK in this regard (although I stumbled on another
entertaining behaviour: bug #21583).
Follow-up Comment #1, bug #21583 (project freeciv):
How fast one after another the programs were started? I just wonder if this
could be race-situation that the manually started server had not yet reserved
the port by the time client checks if it's available.
Follow-up Comment #4, bug #21475 (project freeciv):
FWIW, didn't see this with cazfi's r24328 crosser build (win32stack-0.12).
But this is presumably unsurprising as the Gtk2 DLL there is 2.24.20.
___
Reply to this item at:
Follow-up Comment #5, bug #21475 (project freeciv):
But this is presumably unsurprising as the Gtk2 DLL there is
2.24.20.
Yes, for crosser-0.12 release I downgradet gtk2 to 2.24.20 for this very
reason.
___
Reply to this item at:
Follow-up Comment #10, bug #20058 (project freeciv):
Turks, leader İsmail Enver
Just tried this with both cproc's r24327 test build
http://download.gna.org/freeciv/packages/windows/testing/S2_4-r24327/ and
cazfi's r24328 crosser build, and neither showed any funny messages in the
chat window
Follow-up Comment #4, bug #18440 (project freeciv):
Just tried both cproc's r24327 test build
http://download.gna.org/freeciv/packages/windows/testing/S2_4-r24327/ and
cazfi's S2_4 r24328 crosser build (with win32stack-0.12).
cproc's build did not show the issue but cazfi's did show it:
1:
Follow-up Comment #5, bug #18440 (project freeciv):
(On starting a standalone server, this is.)
___
Reply to this item at:
http://gna.org/bugs/?18440
___
Message sent via/by Gna!
Follow-up Comment #21, bug #18517 (project freeciv):
Just to be sure, I tried this in cproc's r24327 test build
http://download.gna.org/freeciv/packages/windows/testing/S2_4-r24327/
(pre-2.4.2) and it was fine. (Probably already released ones are fine too, I
didn't test.)
Follow-up Comment #2, bug #21583 (project freeciv):
How fast one after another the programs were started?
The manually started server had been running for some time (maybe minutes?) so
I doubt it's a straightforward port claiming race.
___
Follow-up Comment #3, bug #21583 (project freeciv):
I think this _has_ to do with #21547.
I guess the problem is that Freeciv assumes it's not possible for two
processes to listen on 0.0.0.0:5556 and 127.0.0.1:5556 simultaneously, or
something.
(Can I just note that I hate interface binding
URL:
http://gna.org/bugs/?21585
Summary: All settlers/workers on autosettler do nothing.
Project: Freeciv
Submitted by: chrisk
Submitted on: So 02 Feb 2014 17:39:14 CET
Category: None
Severity: 3 - Normal
Follow-up Comment #1, bug #21585 (project freeciv):
Starting a default game and set all settler and workers on auto make them idle
on one (same) place.
screenshot attached
chris@leo:~$ freeciv-gtk2 -v
Encodings: Data=UTF-8, Local=UTF-8, Internal=UTF-8
Freeciv Version 2.4.1+ (modified r24334)
Follow-up Comment #1, patch #4470 (project freeciv):
For buy cost there could be another effect, something like:
[effect_aqueduct_production_river]
type = Buy_Discount_Pct
value = +50
reqs =
{ type, name, range
Improvement, Aqueduct, Local
Extra, River, Adjacent
}
Would allow
Follow-up Comment #6, patch #4392 (project freeciv):
Strategic resources would be awesome. From what I understand (and that is
quite little at least at the moment) about freeciv, it would seem that all
resource should be implemented using extras/flags, effects and requirements.
And I do not think
Follow-up Comment #2, bug #21585 (project freeciv):
I've noticed this too, for a while.
I assume that it's because autosettlers work to make things better for cities
(they only work terrain in city radii, I think), so in the absence of any
cities they have nothing to do.
I don't consider this a
Follow-up Comment #3, bug #21585 (project freeciv):
no. its a special case.
Christian
___
Reply to this item at:
http://gna.org/bugs/?21585
___
Nachricht gesendet von/durch Gna!
Follow-up Comment #4, bug #21583 (project freeciv):
can't reproduce on Linux
No surprise -- I think this stuff tends to be horribly OS-dependent.
This is one reason why changing anything in this area scares me, especially
just before a release.
Another similar source of fun is whether
This is build report automatically generated by Fullmoon Ilmarinen (0.5.50.0)
Fullmoon operated by Marko Lindqvist cazf...@gmail.com This build is from
TRUNK.
Component svn, Host build.cazfi.net, Phase Source update(1): FAILED
___
Freeciv-dev
Follow-up Comment #2, bug #21557 (project freeciv):
I agree, there are two parts to this issue:
1) Prevent glitches when map canvas resized to larger
2) Reduce resizing the map canvas during the game
The patch #19893 is a quick fix only to 1).
Also, I have noticed this only with GTK2 client,
Follow-up Comment #5, bug #21583 (project freeciv):
This is one reason why changing anything in this area scares
me, especially just before a release.
Yes. The question is whether we consider this current problem a reggression
from 2.4.1?
The bug itself certainly isn't, but the fact that
Follow-up Comment #6, bug #21583 (project freeciv):
find_next_free_port() erronously returned 5557 in 2.4.1 despite
finding 5556 being available
Obvious low-risk workaround for 2.4.1: Start looking for the port for
client-spawn server from 5557, so in most cases it will get 5557 like it used
36 matches
Mail list logo
