[Freeciv-Dev] [patch #3805] Allow paratroopers to land on transport
Follow-up Comment #3, patch #3805 (project freeciv): New boolean setting in game.ruleset [civstyle] for controlling if dropping to transport is allowed should be sufficient. ___ Reply to this item at: http://gna.org/patch/?3805 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3815] Provide information about unit class nativity in terrain help
Update of patch #3815 (project freeciv): Status:None = Ready For Test Assigned to:None = cazfi ___ Follow-up Comment #1: Usually jtn has had the last say in help changes, but OTOH he may be busy with other things. Feel free to take this ticket from me if you want. Either way is fine by me. I think S2_4 would benefit from such a help improvement. ___ Reply to this item at: http://gna.org/patch/?3815 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3815] Provide information about unit class nativity in terrain help
Follow-up Comment #2, patch #3815 (project freeciv): I didn't mean to rush processing of this patch with the comment in patch #3816 , rather I just wanted to provide a hint for testing, as when I checked the submitted patch against revision 22638 it didn't apply cleanly. Anyway, I believe that terrain-nativity-help.S2_4.patch should provide essentially the same value ported to S2_4. I was unable to build S2_4 from revision 22639 due to a LUA error (which I presume related to some local configuration on my machine), so this is entirely theoretical, rather than a tested patch. (file #17643) ___ Additional Item Attachment: File name: terrain-nativity-help.S2_4.patch Size:1 KB ___ Reply to this item at: http://gna.org/patch/?3815 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20695] Disaster nreq processing causes disasters mostly not to happen
Update of bug #20695 (project freeciv): Status:None = Ready For Test Assigned to:None = cazfi ___ Follow-up Comment #1: Going with nreqs removal patch. One tangential came to mind when reading the patch: does ruleset sanity checking consider negated effect requirements? (at worst lack of this means it rejects rulesets thinking requirements to be conflicting when they are not, but also fails to spot req and same req negated to be conflicting) ___ Reply to this item at: http://gna.org/bugs/?20695 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20695] Disaster nreq processing causes disasters mostly not to happen
Follow-up Comment #2, bug #20695 (project freeciv): Only for nreqs for effects, which I would expect to be removed in the spirit of having one correct function to do each thing that needs doing. The place it might be would be sanity_check_req_set, but that doesn't seem to be aware of the idea of negated requirements (and, further, is likely to choke on some negated requirements sets because of the limit on multiple requirements of the same type). I believe the general activity of sorting that to be outside the scope of this bug, but it is certainly within the scope of one of my TODO items (positive disjunctive requirement specification), so I'll be sure to check for such impossible conditions with that set of patches. ___ Reply to this item at: http://gna.org/bugs/?20695 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3805] Allow paratroopers to land on transport
Follow-up Comment #4, patch #3805 (project freeciv): This updated patch is controlled by game.info.paradrop_to_transport. This is disabled in most rulesets, but enabled in experimental for testing. If the commiter doesn't feel it appropriate to enable it in experimental, please change TRUE to FALSE pre-commit. Note that this requires a change to the capabilities string for the new value. Some conditional orders have been adjusted to more easily terminate early. (file #17644) ___ Additional Item Attachment: File name: transport-paradrop+ruleset-option.patch Size:8 KB ___ Reply to this item at: http://gna.org/patch/?3805 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3815] Provide information about unit class nativity in terrain help
Follow-up Comment #3, patch #3815 (project freeciv): Seems like a fine change to me. ___ Reply to this item at: http://gna.org/patch/?3815 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] [patch #3815] Provide information about unit class nativity in terrain help
Emmet Hikory writes: I was unable to build S2_4 from revision 22639 due to a LUA error (which I presume related to some local configuration on my machine), so this is entirely theoretical, rather than a tested patch. What's the nature of the failure? If we're releasing 2.4.0-beta2 soon, I'm interested in portability hazards. (Guess: are you switching a single working directory between trunk and S2_4? This is currently fraught, requiring make maintainer-clean and starting again. This bites me in my mad git-svn setup.) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20698] Version check incorrectly considers 2.4.0 older than 2.4.0-beta1
URL: http://gna.org/bugs/?20698 Summary: Version check incorrectly considers 2.4.0 older than 2.4.0-beta1 Project: Freeciv Submitted by: jtn Submitted on: Mon Apr 1 12:58:16 2013 Category: general Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: jtn Originator Email: Open/Closed: Open Release: 2.4.0-beta1 Discussion Lock: Any Operating System: Any Planned Release: 2.4.0-beta2,2.5.0 ___ Details: Split out from bug #20680. Bug exists in our copy of cvercmp. There's a fix upstream http://www.cazfi.net/other/cvercmp.html (1.0.2, r22), but I want to think if we can do a bit better. ___ Reply to this item at: http://gna.org/bugs/?20698 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20680] Client crash on contacting metaserver, dependent on latest version advertised by metaserver
Follow-up Comment #10, bug #20680 (project freeciv): Giving this ticket to jtn to decide whjat to in freeciv copy. I've decided to prevaricate :) -- bug #20698 raised, so we can get this crasher out of the way. (Which I'll do immediately, with a patch taking into account the upstream changes for this crashing issue.) ___ Reply to this item at: http://gna.org/bugs/?20680 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20680] Client crash on contacting metaserver, dependent on latest version advertised by metaserver
Update of bug #20680 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20680 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] [patch #3815] Provide information about unit class nativity in terrain help
Mon, Apr 01, 2013, Jacob Nevins wrote: What's the nature of the failure? If we're releasing 2.4.0-beta2 soon, I'm interested in portability hazards (Guess: are you switching a single working directory between trunk and S2_4? This is currently fraught, requiring make maintainer-clean and starting again. This bites me in my mad git-svn setup.) Ah, yes, precisely. Thanks for the explanation: I wondered why it didn't work. I had thought that git reset --hard would be sufficient, but perhaps that requires being less agressive with info/exclude :) Strangely, it had worked previously for some of my deeper history investigation, but perhaps I just got lucky (or went far enough back in time that the build system figured my machine was lying to it). Do I need to do anything other than `make maintainer-clean` to operate in this manner, or are there other tricks that are important if porting patches to stable branches for accurate testing? -- Emmet HIKORY ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] Switching working directory between branches (was: [patch #3815] Provide information about unit) class nativity in terrain help
Emmet Hikory writes: Jacob Nevins wrote: (Guess: are you switching a single working directory between trunk and S2_4? This is currently fraught, requiring make maintainer-clean and starting again. This bites me in my mad git-svn setup.) Ah, yes, precisely. Thanks for the explanation: I wondered why it didn't work. I had thought that git reset --hard would be sufficient, but perhaps that requires being less agressive with info/exclude :) Strangely, it had worked previously for some of my deeper history investigation, but perhaps I just got lucky (or went far enough back in time that the build system figured my machine was lying to it). This is a relatively recent thing. This -dev post from February 24 refers: https://mail.gna.org/public/freeciv-dev/2013-02/msg00609.html (sorry, self-signed certificate on gratuitously-https site) Do I need to do anything other than `make maintainer-clean` to operate in this manner, or are there other tricks that are important if porting patches to stable branches for accurate testing? I have a single git repository that I synchronise with upstream with git-svn. I don't have one working directory per branch because of fears about what happens to the svn metadata when you clone. Until recently, it's been sufficient to git checkout S2_4 then make -- it re-runs autogen as necessary, remembering my options to 'configure', and options only applicable to newer branches don't faze older ones -- it requires a rebuild from clean, but ccache and a fast machine make this bearable. (No need for git reset of any kind.) Post patch #3230, my procedure for switching between trunk and older branches is: $ make maintainer-clean $ git checkout new-branch $ ./autogen.sh --no-configure-run $ ./configure [my-favourite-configure-options] CC=ccache gcc CXX=ccache g++ $ make ccache is still effective at making this more or less tolerable. But I should probably look into how hard it would be to maintain multiple working directories while using git-svn, since this is all a bit mad. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20699] Bugs in undisbandable unit drowning
URL: http://gna.org/bugs/?20699 Summary: Bugs in undisbandable unit drowning Project: Freeciv Submitted by: cazfi Submitted on: Mon 01 Apr 2013 04:20:51 PM EEST Category: general Severity: 3 - Normal Priority: 5 - Normal Status: Ready For Test Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: 2.4.0, 2.5.0 ___ Details: While hunting another drowning bug, noticed a problem in undisbandable unit saving block. Even after undisbandable unit has been saved by teleporting it, it gets added to remain list of units to handle later. This can have many kind of ill effects since it also means that drowning counter is inconsistent with contents of remain Fix attached. Also: pcity was declared in outer block which didn't need it. Set its visibility to inner block only. ___ File Attachments: --- Date: Mon 01 Apr 2013 04:20:51 PM EEST Name: UndisbandDrowning.patch Size: 2kB By: cazfi http://gna.org/bugs/download.php?file_id=17646 --- Date: Mon 01 Apr 2013 04:20:51 PM EEST Name: UndisbandDrowning-S2_4.patch Size: 2kB By: cazfi http://gna.org/bugs/download.php?file_id=17647 ___ Reply to this item at: http://gna.org/bugs/?20699 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20630] Changing tileset twice crashes client
Follow-up Comment #2, bug #20630 (project freeciv): I vaguely wonder if the assertion failure in bug #20694 (after changing tileset) is somehow related. ___ Reply to this item at: http://gna.org/bugs/?20630 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20626] Client crashes with GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
Update of bug #20626 (project freeciv):
Status:None = Confirmed
Planned Release: = 2.3.5,2.4.0,2.5.0
___
Follow-up Comment #1:
I can confirm serious trouble with this savegame, although not the exact
symptom of the title.
Loading game into 2.3.4 client and following instructions, I got what looks
like a client segfault:
1: Lost connection to server: lagging connection.
1: in player_research_get() [research.c::64]: assertion '((void *)0) !=
pplayer' failed.
1: Please report this message at http://gna.org/projects/freeciv/
Segmentation fault (core dumped)
(no backtrace, sorry). Repeating the experiment just got Lost connection to
server: read error, suggesting the server died.
Loading game into separate server and connecting with client, I got a segfault
on the server (no assertion failure). Backtrace:
#0 0x7fce02a32c7d in _IO_vfprintf_internal (s=0x7600f020,
format=value optimised out, ap=0x7600f1b0) at vfprintf.c:1623
len = value optimised out
string_malloced = value optimised out
step0_jumps = {0, -1811, -1724, -1635, -1543, -1456, -1355, -1165,
-879, -691, -359, -446, -95, -4821, 1919, 1157, 1808, 1895, 1907,
2772, 2526, 1966, 4001, 4091, 2485, -4724, 3071, -177, -4821,
-1254}
space = 0
is_short = 0
use_outdigits = 0
step1_jumps = {0, 0, 0, 0, 0, 0, 0, 0, 0, -691, -359, -446, -95,
-4821, 1919, 1157, 1808, 1895, 1907, 2772, 2526, 1966, 4001, 4091,
2485, -4724, 3071, -177, -4821, 0}
group = 0
prec = value optimised out
step2_jumps = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -359, -446, -95, -4821,
1919, 1157, 1808, 1895, 1907, 2772, 2526, 1966, 4001, 4091, 2485,
-4724, 3071, -177, -4821, 0}
string = 0x31 Address 0x31 out of bounds
left = 0
is_long_double = 0
width = value optimised out
step3a_jumps = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -272, 0, 0, 0, 1919,
1157, 1808, 1895, 1907, 0, 0, 0, 0, 4091, 0, 0, 0, 0, 0, 0}
alt = 0
showsign = 0
is_long = 0
is_char = 0
pad = value optimised out
step3b_jumps = {0 repeats 11 times, -95, 0, 0, 1919, 1157, 1808,
1895, 1907, 2772, 2526, 1966, 4001, 4091, 2485, -4724, 3071, 0, 0,
0}
step4_jumps = {0 repeats 14 times, 1919, 1157, 1808, 1895, 1907,
2772, 2526, 1966, 4001, 4091, 2485, -4724, 3071, 0, 0, 0}
is_negative = value optimised out
base = 0
the_arg = {pa_wchar = 1277193825 L'a', pa_int = 1277193825,
pa_long_int = 3978990955651952225,
pa_long_long_int = 3978990955651952225, pa_u_int = 1277193825,
pa_u_long_int = 3978990955651952225,
pa_u_long_long_int = 3978990955651952225,
pa_double = 1.0858648781729312e-42,
pa_long_double = invalid float value,
pa_string = 0x373837314c206e61 Address 0x373837314c206e61 out of
bounds,
pa_wstring = 0x373837314c206e61 Address 0x373837314c206e61 out of
bounds, pa_pointer = 0x373837314c206e61, pa_user = 0x373837314c206e61}
spec = value optimised out
_buffer = {__routine = 0x3ff0, __arg = 0x3ff0,
__canceltype = 53946656, __prev = 0x4d0dce}
_avail = 0
thousands_sep = 0x0
grouping = 0x Address 0x out of
bounds
done = 24
f = 0x5dbfc2 s%c%c%s%c
lead_str_end = 0x5dbfa8 %c%s tgt=%s x=%d y=%d%c%s%c%c%s%c
work_buffer =
Ȉ370 01 00 00 00 00p205Z 00 00 00 00 00p 00 00 00 00 00 00 00 35226_ 00 00 00
00 00 30 00 00 00 00 00 00 00 62317V 00 00 00 00 00C 00_GB.UTp205Z 00 00 00 00
00321 01 00 00 00 00 00 00L205Z 00 00 00 00 00200326+ 02,
' 00' repeats 12 times,
J) 01 00 00 00 00@357L 03 00 00 00 00@357L 03 00 00 00 00m326V 00 00 00 00
00P354 00366377177 00 00P354 00366377177 00 00361 00 00 00 00 00 00 00257215YQ
00 00 00 00 01 00 00 00 00 00 00 00232U@,
' 00' repeats 13 times,
01 00 00 00 00 00 00 00200362+ 02 00 00 00 00P354 00366377177 00 00 01,
' 00' repeats 15 times, 03 00 00 00 00 00 00 00265]@ 00 00 00 00 00...
workstart = 0x0
workend = 0x7600eed8 ]
ap_save = {{gp_offset = 24, fp_offset = 48,
overflow_arg_area = 0x7600f290,
reg_save_area = 0x7600f1d0}}
nspecs_done = value optimised out
save_errno = 2
readonly_format = 0
args_malloced = 0x0
specs = value optimised out
specs_malloced = false
jump_table =
01 00 00 04 00 16 00 06 00 00a 02 00 03t 00 05b 00 00 00 00 00 00 00
32 00 31 00 23 23 23 00 35 00 00f 00 00 00 00 00 00 25 00 00 00 00 22 00r 00 00
00 00 00 00 32 00 24 17 23 23 23n 17 34 00v 30 27 21 26f 00 25 33 20 00 00 22
00r
[Freeciv-Dev] [bug #20595] Errow while setting temperature below 14 with temperate map
Follow-up Comment #3, bug #20595 (project freeciv): The requested map is too cold to allocate starting postions. Try setting the temperature to a value greater than 14. Unfortunately, trying to anticipate all the ways in which generator settings could lead to failure to allocate starting positions would be rather difficult, especially trying to determine the threshold for individual settings -- the process is complex and I think any such advice is likely to be perturbed into unreliability. I think at best we could give some sort of general hint to the user to review their map settings and try to make the world less uninhabitable (too cold, too hot, too wet, too small, too crowded etc). ___ Reply to this item at: http://gna.org/bugs/?20595 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20498] Pirate archers alone in the water
Follow-up Comment #14, bug #20498 (project freeciv): Maybe so, I had no reproducible case to test against. But now I had, and it got fixed almost accidentally by bug #20699 patch. When pirate ship is wiped (usually retired) and it has both undisbandable Barbarian Leader and men in it, and Leader gets teleported away (should *this* happen for barbarian leaders?), counter of units to drown gets subtrackted by one, but that unit then is not the Leader himself... ___ Reply to this item at: http://gna.org/bugs/?20498 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20561] Allow server messages to be translated to client's locale
Update of bug #20561 (project freeciv): Release: 2.5.0 = Summary: Move translations from freeciv-server to the clients. = Allow server messages to be translated to client's locale ___ Follow-up Comment #5: Well, yes, client-side localisation would require network changes. I think there's the germ of an idea here, but I'm still convinced that if we go to the effort of making per-client localised server messages possible at all, then the right place to actually translate them is on the server, not the client. Retitling accordingly. ___ Reply to this item at: http://gna.org/bugs/?20561 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20543] lua error: Execution time limit exceeded in script
Update of bug #20543 (project freeciv): Planned Release: = 2.5.0 ___ Reply to this item at: http://gna.org/bugs/?20543 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20534] Worklist glitch: unit icons bleed past their boundaries
Follow-up Comment #3, bug #20534 (project freeciv): My guess would be you're hitting following documented case: When the destination rectangle contains parts not in the source image, the data at the edges of the source image is replicated to infinity. (documented for instance here https://developer.gnome.org/gdk-pixbuf/2.22/gdk-pixbuf-scaling.html#gdk-pixbuf-composite) Thanks, yes, that's almost certainly it. So the trick is to avoid doing that. ___ Reply to this item at: http://gna.org/bugs/?20534 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3805] Allow paratroopers to land on transport
Follow-up Comment #5, patch #3805 (project freeciv): I think enabling this in experimental ruleset makes sense. But that requires update also to doc/README.ruleset_experimental. ___ Reply to this item at: http://gna.org/patch/?3805 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3806] Update mkinstalldirs
Update of patch #3806 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3806 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3821] Drop terrain options
Update of patch #3821 (project freeciv): Planned Release: = 2.5.0 ___ Reply to this item at: http://gna.org/patch/?3821 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3820] Avoid selecting RMM_RELAXED roads when they are less good
Update of patch #3820 (project freeciv): Planned Release: = 2.5.0 ___ Reply to this item at: http://gna.org/patch/?3820 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3817] Generalise MR_BAD_TYPE_FOR_CITY_TAKE_OVER_BY_SEA
Update of patch #3817 (project freeciv): Planned Release: = 2.5.0 ___ Follow-up Comment #1: Does some earlier check prevents sea units (that can_attack_from_non_native for shore bombardment) from taking over cities? ___ Reply to this item at: http://gna.org/patch/?3817 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3811] Remove S_RIVER
Update of patch #3811 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3811 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3812] Leader to civil war player
Update of patch #3812 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3812 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20600] dai_player_load: add 'const' to struct section_file
Update of bug #20600 (project freeciv): Status:None = Ready For Test Planned Release: = 2.5.0 ___ Follow-up Comment #1: This change makes sense for the ai module API even if lua ai won't be part of 2.5. ___ Reply to this item at: http://gna.org/bugs/?20600 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20577] new parameter gameloss_style: GameLoss player's property is redistributed instead of disappearing
Follow-up Comment #22, bug #20577 (project freeciv): - Use give_midgame_initial_units() (from patch #3812) to give units for newly created player. This also corrects behavior so that Leader units are given instead of GameLoss ones (if this ever makes any difference) I now also tested this. It works at least technically - I'm not sure if everything makes sense for the gameplay, but I consider this ready for initial commit. We can improve it later. (file #17648) ___ Additional Item Attachment: File name: GamelossStyle-4.patch Size:19 KB ___ Reply to this item at: http://gna.org/bugs/?20577 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3726] Booleanize all save functions for savegame v2
Follow-up Comment #5, patch #3726 (project freeciv): Could you produce new version of this patch to go in before S2_5 branching in a month? ___ Reply to this item at: http://gna.org/patch/?3726 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3539] Scorelog: new tags and details
Update of patch #3539 (project freeciv): Status: Ready For Test = None ___ Follow-up Comment #6: I'd like to have this one finished to conclude scorelog changes for 2.5. Do you happen to already have any utilities to process these new scorelog formats? ___ Reply to this item at: http://gna.org/patch/?3539 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3616] Give ransom from multiple barbarian leaders
Update of patch #3616 (project freeciv): Planned Release: 2.5.0 = 2.6.0 ___ Reply to this item at: http://gna.org/patch/?3616 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #19474] max_players cleanup
Update of bug #19474 (project freeciv): Depends on: = bugs #20693 ___ Reply to this item at: http://gna.org/bugs/?19474 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #19830] Gtk2 client may segfault at network game page
Update of bug #19830 (project freeciv): Status:None = Duplicate Assigned to:None = cazfi Open/Closed:Open = Closed ___ Follow-up Comment #1: Duplicate of #20680, I think. ___ Reply to this item at: http://gna.org/bugs/?19830 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #17582] [metaticket] Headers depend on config.h
Update of bug #17582 (project freeciv): Planned Release: 2.5.0 = 2.6.0 ___ Reply to this item at: http://gna.org/bugs/?17582 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #14585] Wish: client-side progress bar for end-turn activities
Update of bug #14585 (project freeciv): Status: In Progress = None Planned Release: 2.5.0 = 2.6.0 ___ Follow-up Comment #3: Probably the best estimate is that turn change takes as long as previous one. Requires that previous turn change has happened, though (or storing it to savegame, and hoping that server that saved and one that loaded are equally powerful) ___ Reply to this item at: http://gna.org/bugs/?14585 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16164] Aircraft commit suicide if 'autoattack' is set
Follow-up Comment #4, bug #16164 (project freeciv): I think units that have fuel should not autoattack at all except when defending refuel point where they would then remain. ___ Reply to this item at: http://gna.org/bugs/?16164 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3651] Setting TRUNK for 2.6 development
Follow-up Comment #1, patch #3651 (project freeciv): - Updated against current svn (file #17649) ___ Additional Item Attachment: File name: 2.6Trunk-2.patch Size:8 KB ___ Reply to this item at: http://gna.org/patch/?3651 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20652] Homeless ai caravan crash
Update of bug #20652 (project freeciv): Status: Ready For Test = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?20652 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3824] Allow sprites for 2 upkeep
URL: http://gna.org/patch/?3824 Summary: Allow sprites for 2 upkeep Project: Freeciv Submitted by: jtn Submitted on: Mon Apr 1 23:25:11 2013 Category: client Priority: 5 - Normal Status: In Progress Privacy: Public Assigned to: jtn Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: 2.5.0 ___ Details: As noted in bug #20521, it's not currently possible for a tileset to specify sprites for 2 upkeep of any kind in the city dialog. This patch extends the tileset format to allow specifying sprites for up to 10 upkeep. If a given level is not specified, the largest smaller specified sprite is used (if any), so the last specified sprite could be a 3+ type icon. (The syntax should be backward-compatible, so we could consider backporting this to stable branches if we wanted to fix the problem that we have a ruleset where the icons are misleading.) ___ Reply to this item at: http://gna.org/patch/?3824 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3824] Allow sprites for 2 unit upkeep
Update of patch #3824 (project freeciv): Summary: Allow sprites for 2 upkeep = Allow sprites for 2 unit upkeep ___ Reply to this item at: http://gna.org/patch/?3824 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3824] Allow sprites for 2 unit upkeep
Update of patch #3824 (project freeciv): Status: In Progress = Ready For Test ___ Additional Item Attachment: File name: trunk-unit-upkeep-sprites.patch Size:3 KB ___ Reply to this item at: http://gna.org/patch/?3824 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20695] Disaster nreq processing causes disasters mostly not to happen
Update of bug #20695 (project freeciv): Planned Release: = 2.5.0 ___ Reply to this item at: http://gna.org/bugs/?20695 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20691] road_superhighway_trade_bonus in terrain.ruleset doesn't work
Update of bug #20691 (project freeciv): Status:None = Ready For Test Assigned to:None = cazfi Planned Release: = 2.3.5, 2.4.0, 2.5.0 ___ Reply to this item at: http://gna.org/bugs/?20691 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3815] Provide information about unit class nativity in terrain help
Update of patch #3815 (project freeciv): Planned Release: = 2.4.0, 2.5.0 ___ Reply to this item at: http://gna.org/patch/?3815 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3816] Cleanup nativity handling to ignore specials
Update of patch #3816 (project freeciv): Status:None = Ready For Test Assigned to:None = cazfi ___ Reply to this item at: http://gna.org/patch/?3816 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3540] Effect description
Update of patch #3540 (project freeciv): Planned Release: 2.5.0 = 2.6.0 ___ Reply to this item at: http://gna.org/patch/?3540 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3793] [metaticket] Help updates for 2.5.0
Update of patch #3793 (project freeciv): Depends on: = patch #3137 ___ Reply to this item at: http://gna.org/patch/?3793 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20700] assert (index) = 0 (index) MAP_INDEX_SIZE failed
URL: http://gna.org/bugs/?20700 Summary: assert (index) = 0 (index) MAP_INDEX_SIZE failed Project: Freeciv Submitted by: cazfi Submitted on: Tue 02 Apr 2013 02:05:14 AM EEST Category: None Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: r22640 Discussion Lock: Any Operating System: None Planned Release: ___ Details: Attached autogame asserts (but only at turn 393 and it has a lot of players for server to handle, so be prepared to long wait if you run the autogame) bt full #0 0x7668defb in raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42 No locals. #1 0x00670b52 in fc_assert_fail (file=0x71e181 common/map.h, function=0x71eb00 index_to_map_pos_y, line=718, assertion=0x71e158 (index) = 0 (index) MAP_INDEX_SIZE, message=0x74ef94 nologmsg:%s) at utility/log.c:520 level = LOG_FATAL #2 0x0057befe in index_to_map_pos_y (index=78302080) at common/map.h:718 map_x = 32767 map_y = -163131160 __FUNCTION__ = index_to_map_pos_y #3 0x0057e695 in unit_tile_link (punit=0x4a38b60) at common/featured_text.c:1126 buf = [l tgt=\tile\ x=88 y=47]AEGIS Cruiser[/l]\000\000\000], '\000' repeats 82 times tag_name = 0x71e512 l #4 0x00497cab in sell_random_unit (pplayer=0x1755660, punitlist=0x493b490) at server/cityturn.c:1914 punit = 0x4a38b60 gold_upkeep = 2 r = 2 __FUNCTION__ = sell_random_unit #5 0x0049801c in player_balance_treasury_units_and_buildings ( pplayer=0x1755660) at server/cityturn.c:1971 pimprlist = 0x481df30 punitlist = 0x493b490 sell_unit = true __FUNCTION__ = player_balance_treasury_units_and_buildings #6 0x004939c0 in update_city_activities (pplayer=0x1755660) at server/cityturn.c:581 cities = 0x7fffdec8 i = 0 r = 0 buf = '\000' repeats 96 times, PEe\001\000\000\000\000PEe\001\000\000\000\000PEe\001\000\000\000\000\330\336\377\377\377\177\000\000$, '\000' repeats 11 times, %, '\000' repeats 11 times, p\340\377\377\377\177\000\000\023\307d\000\000\000\000\000(\215\271\000\000\000\000\000\240\340\377\377\377\177\000\000\267\324d\000\000\000\000 n = 27 gold = 11 __FUNCTION__ = update_city_activities #7 0x0043d24a in end_phase () at server/srv_main.c:1029 MY_i = 98 pplayer = 0x1755660 __FUNCTION__ = end_phase #8 0x00440e64 in srv_running () at server/srv_main.c:2337 eot_timer = 0x1646be0 save_counter = 19 i = 0 is_new_turn = true need_send_pending_events = false __FUNCTION__ = srv_running #9 0x004420ee in srv_main () at server/srv_main.c:2788 __FUNCTION__ = srv_main #10 0x004366df in main (argc=6, argv=0x7fffe368) at server/civserver.c:454 inx = 6 showhelp = false showvers = false option = 0xb968a0 \261\232 __FUNCTION__ = main ___ File Attachments: --- Date: Tue 02 Apr 2013 02:05:14 AM EEST Name: mapindex.serv Size: 183B By: cazfi http://gna.org/bugs/download.php?file_id=17651 ___ Reply to this item at: http://gna.org/bugs/?20700 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3539] Scorelog: new tags and details
Follow-up Comment #7, patch #3539 (project freeciv): I have tools to process the new scorelog format. If you are interested to see how they work, I have created this thread http://freeciv-mundi.org/forum/viewtopic.php?f=17t=535 to answer the question. ___ Reply to this item at: http://gna.org/patch/?3539 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20521] Government Upkeep_Factor help wrong
Follow-up Comment #1, bug #20521 (project freeciv): However, the help for [civ2] Settlers says: Settlers in a Republic or Democracy require twice as much food per turn, and in Communist or Fundamentalist societies, three times as much. I haven't checked the original game, but two references I've found (1 http://www.strategyplanet.com/allsid/civilization%202/government.asp, 2 http://strategywiki.org/wiki/Civilization_II/Government) don't mention it, and the first indicates that food upkeep is 1 for these govs. Did we make this up? * The three times as much text came from me in patch #1390. I presume I was just updating docs to match the ruleset, so we can't take that as intention. * Going back, I think r11293 http://svn.gna.org/viewcvs/freeciv?revision=11293view=revision (when effects were added) bumped it from 2 to 3, and that this was probably inadvertent. * Going back further, upkeep=2 seems to have been deliberate; r4517 http://svn.gna.org/viewcvs/freeciv?revision=4517view=revision deliberately changed it for Communism, and r3761 http://svn.gna.org/viewcvs/freeciv?revision=3761view=revision implemented Fundamentalism in this state. So I think we should at least reduce it to 2 (under a new ticket), and possibly back to 1 (depending on whether we can find out what commercial Civ2 did). (I can see a possible game balance argument for having high settler upkeep, to balance the military advantages of these governments, but the civ2 ruleset isn't the place for such tweaks.) (Incidentally, if we are intentionally shipping rulesets with upkeep 3, it's not ideal that the upkeep icon can only go up to 2 -- I only noticed this by hovering over the unit icon to get the upkeep numbers.) Patch #3824 will address this limitation. ___ Reply to this item at: http://gna.org/bugs/?20521 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20700] assert (index) = 0 (index) MAP_INDEX_SIZE failed
Follow-up Comment #2, bug #20700 (project freeciv): I don't know if it's the problem I'm seeing, but there's apparent problem with the code when multiple units are being sold. If there's both transport and its cargo in the list of potential units to sell, selling transport first will cause, due to recursive wiping, cargo also to get destroyed, but to remain in the list of potential units to sell. ___ Reply to this item at: http://gna.org/bugs/?20700 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #20700] assert (index) = 0 (index) MAP_INDEX_SIZE failed
Update of bug #20700 (project freeciv): Category:None = general Status:None = Ready For Test Planned Release: = 2.3.5, 2.4.0, 2.5.0 ___ Follow-up Comment #3: If there's both transport and its cargo in the list of potential units to sell, selling transport first will cause, due to recursive wiping, cargo also to get destroyed, but to remain in the list of potential units to sell. Untested patch for that one. (file #17652, file #17653) ___ Additional Item Attachment: File name: SellCargoBeforeTransport.patch Size:3 KB File name: SellCargoBeforeTransport-S2_3.patch Size:3 KB ___ Reply to this item at: http://gna.org/bugs/?20700 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3817] Generalise MR_BAD_TYPE_FOR_CITY_TAKE_OVER_BY_SEA
Follow-up Comment #2, patch #3817 (project freeciv): Not so concretely or specifically, but ruleset authors may model shore bombardment by not allowing the unit to take over the city (set either UTYF_CIVILIAN or fail to set UCF_CAN_OCCUPY_CITY). In all shipped rulesets, unit classes identifed as Sea don't have UCF_CAN_OCCUPY_CITY, so this doesn't require any changes to these rulesets to meet this requirement, but if a ruleset author wanted to define a naval unit with an embedded marine component, this is possible. The code enforces this by having checks 5 and 6 part of the same conditional, with 6 as an else clause only checked when 5 fails (any Sea unit in the rulesets would be sending MR_BAD_TYPE_FOR_CITY_TAKE_OVER instead). I don't expect any changes in behaviour with the current rulesets (and my testing included failing to take over a city with a Battleship in the default ruleset). In the message production, the patch explicitly checks for both can_attack_from_non_native() and utype_can_take_over() to cover this (an earlier revision of the patch incorrectly reported that all can_attack_from_non_native() units could conquer from non-native). ___ Reply to this item at: http://gna.org/patch/?3817 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #16164] Aircraft commit suicide if 'autoattack' is set
Follow-up Comment #5, bug #16164 (project freeciv): In the case where occupychance 0, should a fueled unit with autoattack still autoattack from a refueling point? If it does, should it return to base immediately thereafter in the event it does occupy, or should it avoid autoattacking in the event that this would cause it not to be able to later refuel (e.g. units with OneAttack that are on their last turn of fuel)? ___ Reply to this item at: http://gna.org/bugs/?16164 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #3805] Allow paratroopers to land on transport
Follow-up Comment #6, patch #3805 (project freeciv): Oops, right. Updated patch (transport-paradrop+option+docs.patch) includes that. (file #17654) ___ Additional Item Attachment: File name: transport-paradrop+option+docs.patch Size:8 KB ___ Reply to this item at: http://gna.org/patch/?3805 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
