[Freeciv-Dev] [bug #21083] verbose logging (-d 3) + log_error() = server hang due to recursive logging
URL:
http://gna.org/bugs/?21083
Summary: verbose logging (-d 3) + log_error() = server
hang due to recursive logging
Project: Freeciv
Submitted by: jtn
Submitted on: Sat Aug 31 12:48:37 2013
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
Status: None
Assigned to: None
Originator Email:
Open/Closed: Open
Release: S2_4 r23235
Discussion Lock: Any
Operating System: None
Planned Release:
___
Details:
Server hung consuming no CPU when I was testing an error case, but only when I
had both -d 3 and -l foo.log on the server command line.
I think the problem is that when log_error() is called on the server, it
provokes a chat message to send to clients in the depths of log_real(); with
-d 3 the resulting network traffic is itself logged, leading to a deadlock
waiting for a lock on the logfile. (I think.)
This is similar to bug #20721 but the fix will be more involved.
#0 __lll_lock_wait ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132
No locals.
#1 0x7fe7fd750065 in _L_lock_858 ()
from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#2 0x7fe7fd74feba in __pthread_mutex_lock (mutex=0xab45e0)
at pthread_mutex_lock.c:61
__PRETTY_FUNCTION__ = __pthread_mutex_lock
type = 11224544
#3 0x005eed1b in log_real (level=LOG_VERBOSE, print_from_where=false,
where=0x7fff5e28baa0 in send_packet_chat_msg_100() [packets_gen.c::7122]:
, msg=0x7fff5e28bca0 packet_chat_msg_100: sending info about ()) at
log.c:400
last_msg = Map has no land, so cannot assign start positions!\000e:
0).\000 jtn\000, '0' repeats 44 times, '\000' repeats 404 times
repeated = 0
next = 2
prev = 0
prev_level = LOG_ERROR
buf =
\240\272(^\377\177\000\000\240\272(^\377\177\000\000\240\272(^\377\177\000\000պ(^\377\177\000\000\237\274(^\377\177\000\000\240\272(^\377\177\000\000\237\274(^\377\177,
'\000' repeats 42 times, \032\000\000\000\004\000\000\000\002, '\000'
repeats 11 times\377, \377\377\377\000\000\000\000\000\000\000\000
tarting\020\271(^\377\177\000\000\240\274(^\377\177\000\000\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\370\276(^\377\177\000\000\377\377\377\377\000\000\000\000\bbh\000\000\000\000\000\240\274(^\377\177\000\000\240\257\253\374\347\177\000\000\000\000\000\000\000\000\000\000\240\274(^\377\177\000\000\240\274(^\377\177\000\000\240\274(^\377\177\000\000\240\274(^\377\177\000\000ʼ(^\377\177\000\000\237\276(^\377\177\000\000\240\274(^\377\177\000\000\237\276(^\377\177,
'\000' repeats 19 times,
\002\000\000\000\000\000\000\240\272(^\377\177\000\000\220...
fs = optimised out
#4 0x005ebb75 in backtrace_log (level=LOG_VERBOSE,
print_from_where=optimised out, where=optimised out,
msg=optimised out) at fcbacktrace.c:100
No locals.
#5 0x005ef4fb in vdo_log (file=0x6805f8 packets_gen.c,
function=0x694390 send_packet_chat_msg_100, line=7122,
print_from_where=false, level=LOG_VERBOSE, message=optimised out,
args=0x7fff5e28bef8) at log.c:377
buf_where = in send_packet_chat_msg_100() [packets_gen.c::7122]:
\000\000\000\060\000\000\000\060\000\000\000P\274(^\377\177\000\000P\273(^\377\177\000\000\213\274(^\377\177\000\000
\341\364\000\000\000\000\000F00, '\000' repeats 25 times,
#115511\000\004, '\000' repeats 13 times, (^\377\177, '\000' repeats 18
times, `\335\365\347\177, '\000' repeats 18 times,
о(^\377\177\000\000\001\000\000\000\377\177\000\000\000\000\000\000\000\000\000\000\030\277(^\377\177\000\000\000\000\000\000\377\177\000\000
Ы\374\347\177\000\000\000\001, '\000' repeats 14 times,
A\000\000\000\377...
buf_msg = packet_chat_msg_100: sending info about
()\000\374\347\177\000\000\374\377\377\377\377\377\377\377u\006j, '\000'
repeats 21 times,
`\\u\375\347\177\000\000\000\276(^\377\177\000\000\000\000\000\000\377\177\000\000\000\000\000\000\000\000\000\000\030\000\000\000\060\000\000\000\360\277(^\377\177\000\000\060\277(^\377\177\000\000\260\303(^\377\177\000\000X\305(^\377\177\000\000g\006j\000\000\000\000\000%\000\000\000\000\000\000\000\314\312t\374\347\177\000\000\001\200\255\373\060\060\060\060v\006j,
'\000' repeats 13 times,
\003\000\000\000\000\000\000\000\207\271(^\377\177\000\000\070\277(^\377\177\000\000\177\000\000\000\000\000\000\000^\001x\374\347\177\000\000\030\000\000\000\060\000\000\000
\301(^\377\177\000\000...
#6 0x005ef5cd in do_log (file=optimised out,
function=optimised out, line=optimised out,
print_from_where=optimised out, level=optimised out,
message=optimised out) at log.c:477
args = {{gp_offset = 48, fp_offset = 48,
overflow_arg_area = 0x7fff5e28bfd0,
reg_save_area =
[Freeciv-Dev] [bug #21068] With tiny maps, startpos.c::381]: assertion 'player_count() = sum' failed
Update of bug #21068 (project freeciv): Status:None = Ready For Test Assigned to:None = jtn Planned Release: = 2.3.5,2.4.1,2.5.0,2.6.0 ___ Follow-up Comment #1: I suspect the problem is that there is no land at all Yes, that's the cause (Map has 0 continents and 1 oceans). Patch attached bails out of start position assignment a little more cleanly (allowing the map generation to retry in 2.4 and later, not that that helps in my scenario where I think land generation is impossible). (file #18803, file #18804) ___ Additional Item Attachment: File name: trunk-S2_5-startpos-no-land.patch Size:6 KB File name: S2_4-S2_3-startpos-no-land.patch Size:4 KB ___ Reply to this item at: http://gna.org/bugs/?21068 ___ 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 #21068] With tiny maps, startpos.c::381: assertion 'player_count() = sum' failed
Update of bug #21068 (project freeciv): Summary: With tiny maps, startpos.c::381]: assertion 'player_count() = sum' failed = With tiny maps, startpos.c::381: assertion 'player_count() = sum' failed ___ Reply to this item at: http://gna.org/bugs/?21068 ___ 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 #20809] Government type list disappears
Update of bug #20809 (project freeciv): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #2: Think this is a duplicate of bug #18764 (which is a horrible Heisenbug that we haven't tracked down). ___ Reply to this item at: http://gna.org/bugs/?20809 ___ 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 #18764] No Governments available for switching
Update of bug #18764 (project freeciv): Release: 2.3.0,2.3.1 = 2.3.0,2.3.1,2.4.0-beta1 ___ Follow-up Comment #14: See also bug #20809 (reported on 2.3.1 on Ubuntu 12.04). ___ Reply to this item at: http://gna.org/bugs/?18764 ___ 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 #21072] Map size hangs past 75
Update of bug #21072 (project freeciv): Release: 2.4.0 RC1 = 2.4.0-RC1 ___ Follow-up Comment #2: Haven't tried on Windows, but unable to reproduce on Linux in several tries (map sizes up to 128 are generated within a small number of seconds on my PC). ___ Reply to this item at: http://gna.org/bugs/?21072 ___ 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 #21084] Segfault on client quit -- gen_roads implicated?
URL: http://gna.org/bugs/?21084 Summary: Segfault on client quit -- gen_roads implicated? Project: Freeciv Submitted by: jtn Submitted on: Sat Aug 31 14:01:05 2013 Category: client-gtk-2.0 Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: trunk r23246 Discussion Lock: Any Operating System: None Planned Release: 2.6.0 ___ Details: When I started a game in the trunk Gtk2 client and then quit, it segfaulted. Haven't investigated further. #0 0x005f2425 in genlist_link_data (plink=0x301010100030101) at genlist.c:731 No locals. #1 0x005d9c7d in road_by_compat_special (compat=ROCO_ROAD) at road.c:146 _e__iter = 0x301010100030101 _e_ = optimised out _etl_ = optimised out __FUNCTION__ = road_by_compat_special #2 0x00459e55 in real_menus_update () at menu.c:2063 road_buf = `u\203\002\000\000\000\000!\301\062\340a\177\000\000p/c\000\000\000\000\000\306D\355\340a\177\000\000 h$\003\000\000\000\000Ʈ\355\340a\177\000\000\000EZT\377\177\000\000\000\000\000\000\000\000\000\000\001, '\000' repeats 15 times, \001\000\000\000\000\000\000\000\354\006F\000\000\000\000\000\340Ӵ\002, '\000' repeats 21 times, \020\000\000\000\000\000\000\344\002w\002\000\000\000\000\377\377\377\377\377\377\377\377p\002w\002\000\000\000\000[WN\330a\177, '\000' repeats 18 times\340, \340\202\002\000\000\000\000\274\061c\000\000\000\000\000\001\000\000\000\000\000\000\000\223\340\222\341a\177\000\000\200\t\203\002\000\000\000\000\000\215z\001)\374\303`\000\000\000\000\000\000\000\000\340\340\202\002\000\000\000\000@EZT\377\177\000\000\354:F\000\000\000\000\000\320\035%\315a\177\000\000Z\257q\330a... proad = optimised out safe_group = 0xa9f5a80 edit_group = 0xa9f5d40 unit_group = 0xa9f5d90 playing_group = 0xa9f5de0 punits = 0x0 units_all_same_tile = true units_all_same_type = true menu = optimised out acttext = \340]\237\n\000\000\000\000\000\226\341\004, '\000' repeats 12 times\321, \065\230\341a\177\000\000PpL\000\000\000\000\000\004\257\064\340a\177\000\000\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\340]\237\n\000\000\000\000\000\226\341\004\000\000\000\000\340]\237\n\000\000\000\000e\315\062\340a\177\000\000\020\215\237\n\000\000\000\000\340]\237\n\000\000\000\000\000\226\341\004, '\000' repeats 11 times irrtext = \000EZT\377\177\000\000\000EZT\377\177\000\000PpL\000\000\000\000\000\033\237\317\340a\177\000\000@]\237\n\000\000\000\000\340DZT\377\177\000\000\200Z\237\n\000\000\000\000\236\266E\000\000\000\000\000\200DZT\377\177\000\000\060^\237\n\000\000\000\000\340]\237\n\000\000\000\000\220]\237\n\000\000\000\000\067, '\000' repeats 23 times, `#x\002\000\000\000 mintext = Z\000\000\000\000\000\000\000\001\000\000\000\001\000\000\000\004\000\000\000\000\000\000\000\000(\005\000\000\064\000\000Z\000\000\000\377\177\000\000\000(\005\000\000(\005\000\060DZT\377\177\000\000\340\214\202\002, '\000' repeats 28 times, \027\061\340a\177\000\000m\016c\000\000\000\000\000\240\003\000\000\000\000\000\000y\231h\000\000\000\000\000\240\003\000\000\000\000\000 transtext = \035\000\000\000\000\000\000\000ſ\375\337a\177\000\000y\231h\000\000\000\000\000\240\003\000\000\000\000\000\000m\016c\000\000\000\000\000\022\001\000\000\000\000\000\000y\231h\000\000\000\000\000\022H_\000\000\000\000\000\240\003, '\000' repeats 30 times, 0rL\000\000\000\000\000\065I_, '\000' repeats 14 times\215, z\001)\374\303` pterrain = optimised out conn_possible = optimised out proad = optimised out extras = optimised out __FUNCTION__ = real_menus_update #3 0x004c73c3 in update_unqueue (data=optimised out) at update_queue.c:317 callback = 0x4c7050 menus_update_callback uq_data = optimised out MY_mem_MY_iter = optimised out MY_it_MY_iter = 0x7fff545a4500 MY_iter = 0x7fff545a4500 hash = 0x6501240 #4 0x0044abda in idle_callback_wrapper (data=0xae5caa0) at gui_main.c:2038 cb = 0xae5caa0 #5 0x7f61e1947d53 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 No symbol table info available. #6 0x7f61e19480a0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 No symbol table info available. #7 0x7f61e194849a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 No symbol table info available. #8 0x7f61e0db62f7 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 No symbol table info available. #9 0x0044dba9 in ui_main (argc=1, argv=0x7fff545a4ab8) at
[Freeciv-Dev] [bug #21070] Too many messages from trading gold...
Update of bug #21070 (project freeciv): Release: 2.4.0 RC1 = 2.4.0-RC1 ___ Follow-up Comment #1: Do you mean This deal is not very good for us? Yes, that's a pain. See also bug #17755. ___ Reply to this item at: http://gna.org/bugs/?21070 ___ 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 #21063] freeciv-manual server options output is broken
Update of bug #21063 (project freeciv): Category:None = docs Operating System: Microsoft Windows = Any Summary: Assertion failed in freeciv-manual.exe under 2.4.0-RC1 gtk Sdl = freeciv-manual server options output is broken ___ Follow-up Comment #2: freeciv-manual is a bit neglected, really... Checking, on 2.4.0-RC1, the server options output of freeciv-manual is completely blank. This is probably related to the assertion failures. This seems to be a regression from 2.3.x, where output is produced for each option, although even there it's a bit broken (Level and Category seem to be wrong for each option and are (null) for many). ___ Reply to this item at: http://gna.org/bugs/?21063 ___ 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 #21055] Error in country selecction.
Update of bug #21055 (project freeciv): Category: general = rulesets Severity: 4 - Important = 1 - Wish Status:None = Invalid Open/Closed:Open = Closed ___ Follow-up Comment #2: The catalan nation is in the medieval group. Indeed, on all branches (including S2_3 and 2.3.4) the groups for Catalan are groups=Medieval, Early Modern, European The published policy (in doc/README.nations http://svn.gna.org/viewcvs/freeciv/trunk/doc/README.nations?view=markup) only requires nations in the Modern group to be currently sovereign states. A nation in Freeciv should preferrably be a current independent country or a historical kingdom or realm. A nation that is currently governed by or the part of a greater political entity, or in other ways lacks complete independence could in most cases be made a Freeciv nation as well, but must never be listed as _modern_ (see 'Nation grouping' below.) ... Modern nations are existing and politically independent countries; a nation listed as ancient, medieval or early modern should have had an independent dynasty or state in ancient (until 500 AD), medieval (500 - 1500) or early modern (1500 - 1800) times respectively. Hence, closing as invalid. ___ Reply to this item at: http://gna.org/bugs/?21055 ___ 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 #21085] SDL in-city tile UI too small
URL: http://gna.org/bugs/?21085 Summary: SDL in-city tile UI too small Project: Freeciv Submitted by: None Submitted on: Sat 31 Aug 2013 03:18:55 PM UTC Category: client-sdl Severity: 2 - Minor Priority: 5 - Normal Status: None Assigned to: None Originator Email: lmsca...@gmail.com Open/Closed: Open Release: 2.3 and up Discussion Lock: Any Operating System: Microsoft Windows Planned Release: ___ Details: IN the SDL client, tiles viewed in the city UI (for moving citizens to other tiles, etc.) are tiny, leaving a large amount of black space around the tiles in the city tile box in the city dialog. ___ Reply to this item at: http://gna.org/bugs/?21085 ___ 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 #15804] fix city map (variable city radii, sdl client)
Follow-up Comment #4, bug #15804 (project freeciv): Also reported in bug #21085. ___ Reply to this item at: http://gna.org/bugs/?15804 ___ 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 #21085] SDL in-city tile UI too small
Update of bug #21085 (project freeciv): Status:None = Duplicate Open/Closed:Open = Closed ___ Follow-up Comment #1: Indeed they are. Not to minimise the importance of this defect, but it's a duplicate of the existing bug #15804. (Patches would be most welcome.) ___ Reply to this item at: http://gna.org/bugs/?21085 ___ 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 #21086] freeciv-manual fails to find classic ruleset on trunk
URL: http://gna.org/bugs/?21086 Summary: freeciv-manual fails to find classic ruleset on trunk Project: Freeciv Submitted by: jtn Submitted on: Sat Aug 31 19:43:28 2013 Category: docs Severity: 3 - Normal Priority: 5 - Normal Status: In Progress Assigned to: jtn Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: Any Planned Release: 2.3.5,2.4.1,2.5.0,2.6.0 ___ Details: ...because game.server.rulesetdir is not initialised, because game_init() is called before i_am_server(), and so doesn't initialise server-specific variables including rulesetdir. (In fact this is a problem back to at least S2_3, but we used to get away with it because the hardcoded default in the ruleset search path corresponded to an actual ruleset. You can see trouble in -d 3.) ___ Reply to this item at: http://gna.org/bugs/?21086 ___ 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 #4078] read the action enablers from the rule set (and send them to the client)
Update of patch #4078 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4078 ___ 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 #21086] freeciv-manual fails to find classic ruleset on trunk
Update of bug #21086 (project freeciv): Status: In Progress = Ready For Test ___ Additional Item Attachment: File name: trunk-S2_5-manual-default-rulesetdir.patch Size:0 KB File name: S2_4-S2_3-manual-default-rulesetdir.patch Size:0 KB ___ Reply to this item at: http://gna.org/bugs/?21086 ___ 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 #21063] freeciv-manual server options output is broken
Follow-up Comment #3, bug #21063 (project freeciv):
Attached patch addresses the cause of the assertion failures (failure to call
init_settings()), and the drivel in Level etc in S2_3.
Unfortunately it also provokes a segfault in S2_4 and later (S2_3 seems fine).
When the ruleset is loaded, the [settings] section causes the action function
for *all* settings to be invoked, which calls aifill(), which looks to
add/remove players and falls over something in the AI type stuff. (I bet it
only works on S2_3, which predates AI types, by luck.)
Making freeciv-manual work is not likely to be a high priority for me, so
anyone should feel free to pick this up and find the least awful way to bodge
around it.
#0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:32
No locals.
#1 0x0053c242 in ai_type_by_name (search=0x0) at ai.c:285
len = optimised out
#2 0x004bf365 in server_create_player (player_id=optimised out,
ai_type=0x0, prgbcolor=0x0) at plrhand.c:1509
pslot = optimised out
pplayer = 0x38a6b70
__FUNCTION__ = server_create_player
#3 0x0045b6cd in aifill (amount=optimised out) at srv_main.c:1893
leader_name =
360_@327377177 00 00 00_@327377177 00 00 01 00 00 00 00 00 00 00310_@327377177
00 00377 00 00 00 00 00 00 00224pg 00 00 00 00
filled = 1
pplayer = optimised out
limit = optimised out
__FUNCTION__ = aifill
#4 0x004581c3 in setting_action (pset=0x932ed8) at settings.c:3243
No locals.
#5 settings_ruleset (file=0x2b50670, section=0x67711c settings)
at settings.c:3282
pset_iter = 0x1f8c390
pset = 0x932ed8
_setting_list = optimised out
name = optimised out
j = 0
__FUNCTION__ = settings_ruleset
#6 0x0044f5f3 in load_ruleset_game (rsdir=0xb0988b classic)
at ruleset.c:4886
food_ini = optimised out
teams = 0
gni_tmp = 1
sec = optimised out
nval = 4
file = 0x2b50670
sval = optimised out
filename = 0x389fed0 data/classic/game.ruleset
text = optimised out
svec = optimised out
i = 4
name = 0x0
ok = true
#7 load_rulesetdir (rsdir=0xb0988b classic) at ruleset.c:5765
techfile = 0x1fbd8a0
unitfile = 0x203b6b0
buildfile = 0x1fbd360
govfile = 0x203b7b0
terrfile = 0x2091fb0
cityfile = 0x20d4a80
nationfile = 0x20d30e0
effectfile = 0x2a9a690
ok = true
__FUNCTION__ = load_rulesetdir
#8 0x0044f9ae in load_rulesets (restore=0x0) at ruleset.c:5647
No locals.
#9 0x0043433f in manual_command () at civmanual.c:145
doc = optimised out
filename =
370P223 00 00 00 00 00 00261277ѕ212230v220303-370 01 00 00 00 00K325a,
' 00' repeats 12 times
manuals = optimised out
my_conn = {id = 0, sock = 0, used = true, established = false,
packet_header = {length = 1, type = 0}, closing_reason = 0x0,
observer = 29, playing = 0xfe51c11b02b6, buffer = 0x1f8e480,
send_buffer = 0x1f984b0, last_write = 0x0,
ping_time = 1.3833838083554903e-322, self = 0x3a0,
username =
PeA327377177 00 00j247244336(177 00 00 60_A327377177 00 00340 61E, ' 00'
repeats 13 times, @bA327377177 00,
addr =
pdA327377177 00 00 71 00 00 00 00 00 00 00 20227 00337(177 00 00pdA327377177
00 00240bA327377177 00 00 71 00 00 00 00 00 00 00 70 00 00 00 00 00 00 00240 03
00 00 00 00 00 00pdA327377177 00 00j247244336(177 00 00340_A327377177 00 00340
61E,
' 00' repeats 13 times, @bA327377177 00 00260bA327377177 00 00q, ' 00'
repeats 11 times377,
177 00 00b 00 00 00 00 00 00 00240bA327377177 00 00260bA327377177 00 00340 61E
00 00 00 00 00240 03 00 00 00 00 00 00260bA327377177 00 00Ǫ244336(177 00
00330.223 00 00 00 00 00360A223 00 00 00 00 00 00F223 00 00 00 00 00@I223 00 00
00 00 00220)223 00 00 00 00 00370 66223 00 00 00 00 00@223 00 00 00 00 00(P223
00 00 00 00,
capability =
250I223 00 00 00 00 00350?223 00 00 00 00 00340=223 00 00 00 00 00230 70223 00
00 00 00 00 30?223 00 00 00 00 00220C223 00 00 00 00 00220P223 00 00 00 00
00370P223 00 00 00 00 00X5223 00 00 00 00 00310D223 00 00 00 00 00XO223 00 00
00 00 00XB223 00 00 00 00 00360 64223 00 00 00 00 00260223 00 00 00 00 00b;223
00 00 00 00 00260 61223 00 00 00 00 00 20 60223 00 00 00 00 00x0223 00 00 00 00
00250/223 00 00 00 00 00@/223 00 00 00 00 00(C223 00 00 00 00 00 20J223 00 00
00 00 00HK223 00 00 00 00 00360N223 00 00 00 00 00210A223 00 00 00 00 00
A223 00 00 00 00 00220 66223 00 00 00 00 00300 65223 00 00 00 00 00310 67223 00
00 00 00 00320,223 00 00 00 00 00360'223 00 00 00 00 00230+223 00 00 00 00
00...,
access_level = ALLOW_CTRL,
notify_of_writable_data = 0x4531e0 settings_list_cmp, {client = {
last_request_id_used = 0, last_processed_request_id_seen = 0,
[Freeciv-Dev] [patch #3451] New Civilization - Faroese
Update of patch #3451 (project freeciv): Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3451 ___ 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 #4000] Urartian nation
Update of patch #4000 (project freeciv): Assigned to:None = mixcoatl Open/Closed:Open = Closed ___ Follow-up Comment #1: The Urartians are already in the game: http://svn.gna.org/viewcvs/freeciv/trunk/data/nation/urartian.ruleset ___ Reply to this item at: http://gna.org/patch/?4000 ___ 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 #3451] New Civilization - Faroese
Update of patch #3451 (project freeciv): Status:None = Duplicate ___ Reply to this item at: http://gna.org/patch/?3451 ___ 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 #4032] Kushan empire
Update of patch #4032 (project freeciv): Assigned to:None = mixcoatl Open/Closed:Open = Closed ___ Follow-up Comment #1: The Kushans are already in the game: http://svn.gna.org/viewcvs/freeciv/trunk/data/nation/kushan.ruleset ___ Reply to this item at: http://gna.org/patch/?4032 ___ 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 #4033] Novgorod nation
Update of patch #4033 (project freeciv): Assigned to:None = mixcoatl Open/Closed:Open = Closed ___ Follow-up Comment #1: The Novgorodians are already in the game: http://svn.gna.org/viewcvs/freeciv/trunk/data/nation/novgorodian.ruleset ___ Reply to this item at: http://gna.org/patch/?4033 ___ 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 #20770] Barbarian nations in unknown group in civ1 ruleset
Update of bug #20770 (project freeciv): Status:None = Ready For Test Planned Release: 2.4.0,2.5.0 = 2.4.1,2.5.0,2.6.0 ___ Additional Item Attachment: File name: trunk-S2_5-civ1-barbarians.patch Size:1 KB File name: S2_4-civ1-barbarians.patch Size:1 KB ___ Reply to this item at: http://gna.org/bugs/?20770 ___ 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 #4000] Urartian nation
Follow-up Comment #2, patch #4000 (project freeciv): Sorry, I dont see it in the game. I have the 2.4.0 RC1 version. Is there everywhere a new version? ___ Reply to this item at: http://gna.org/patch/?4000 ___ Mensaje enviado vía/por Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4000] Urartian nation
Follow-up Comment #3, patch #4000 (project freeciv): I'm afraid they were added after 2.4.x branched from trunk, so will debut in 2.5.0. (They were added in patch #3277.) ___ Reply to this item at: http://gna.org/patch/?4000 ___ 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 #4032] Kushan empire
Update of patch #4032 (project freeciv): Status:None = Duplicate ___ Follow-up Comment #2: (added in patch #3276) ___ Reply to this item at: http://gna.org/patch/?4032 ___ 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 #4033] Novgorod nation
Update of patch #4033 (project freeciv): Status:None = Duplicate ___ Follow-up Comment #2: (added in patch #2014) ___ Reply to this item at: http://gna.org/patch/?4033 ___ 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 #4000] Urartian nation
Follow-up Comment #4, patch #4000 (project freeciv): You can see nations in current development version (that's going to become 2.6) from http://svn.gna.org/viewcvs/freeciv/trunk/data/nation/ ___ Reply to this item at: http://gna.org/patch/?4000 ___ 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 #3278] Ligurian nation
Update of patch #3278 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3278 ___ 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 #3911] Improve protocol documentation
Update of patch #3911 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3911 ___ 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 #4078] read the action enablers from the rule set (and send them to the client)
Follow-up Comment #13, patch #4078 (project freeciv): At http://freeciv.wikia.com/wiki/Editing_rulesets I see that other concepts in game.ruleset aren't documented. Should I, may I or should I not document it there? ___ Reply to this item at: http://gna.org/patch/?4078 ___ 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 #3279] Rusyn nation
Update of patch #3279 (project freeciv): Status: Ready For Test = Done Open/Closed:Open = Closed ___ Follow-up Comment #2: Add Rusyn nation by Andrzej G. artaxes. See Gna patch #3279 (accidentally wrote patch See Gna patch #32798 when comitting) ___ Reply to this item at: http://gna.org/patch/?3279 ___ 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 #4104] Don't hard code pollution/fallout specials for global warming/cooling
Follow-up Comment #3, patch #4104 (project freeciv):
Maybe this is an appropriate point to post a musing I've had for a while.
== Lua-scripted climate change ==
The current rules for climate change (see Math of Freeciv
http://www.freeciv.org/wiki/Math_of_Freeciv#Global_Warming_and_Nuclear_Winter
on the wiki) are somewhat arbitrary, and ruleset authors might well want to
customise them, but they are baked into the game engine and not very
configurable at all (even numerically).
As a thought experiment, how much of the climate change engine could we move
into Lua script? What could we do to our Lua framework to enable this, and
ideally other similar ruleset-specific game features? What would we (or
ruleset authors) lose from this?
*Input:* It should be possible to hook this all onto the 'turn_started'
signal. To implement today's behaviour where it depends on pollution/fallout
on the map, the Lua function can do a 'whole_map_iterate'. _Missing:_ Lua code
can't actually see if pollution/fallout is on a tile currently; that would
need adding. (Per this ticket, this would be the code you edited to remove
that hardcoding.)
I don't know how much slower Lua is than C code, but hopefully any overhead
would be bearable once per turn.
*State:* The variables that accumulate climate change risk
(heating/warminglevel/globalwarming etc) could perfectly well be Lua global
variables; simply-typed variables are saved and reloaded in savegames, so can
be removed from the server C code (but see below for more on this). The most
arbitrary/tweakable part of the engine, the calculation, could be implemented
entirely in Lua and be completely up to the ruleset author.
*Output:* When the algorithm decides climate change has occurred, it must
change the world. In principle do-able, but there are several missing parts
(easily added): Lua can't change terrain type; nor has it got a way to know
map dimensions, necessary for current random terrain alteration (maybe it can
use 'server.setting.get()' on xsize/ysize but that's a bit of a hack). It also
needs to emit a message to players, which it can do with 'notify.event' (there
is a special event type E.GLOBAL_ECO that users can filter on, but in general
Lua-added functionality that we haven't foreseen won't be able to have its own
distinct event types).
To implement today's behaviour, this code would need access to
terrain.warmer_wetter_result etc from the ruleset (more on this below), and
also to terrain_control.ocean_reclaim_requirement_pct (can_reclaim_ocean()),
and to terrain type flags (TER_NO_CITIES), none of which are exposed currently
but could easily be.
*UI:* What the client sees must necessarily be fixed; we can't generalise away
from there being exactly two kinds of catastrophe ('global warming' and
'nuclear winter') which have a linear scale and particular sprites, because
that's baked into clients and the network protocol, and we have no way of
generalising it.
This is the strongest hindrance to ruleset authors unilaterally adding new
similar features entirely via script; at most they can notify players by
textual messages (perhaps disasters could have been implemented like this).
*Configurability:* One of the problems about pushing functionality and
configurability to Lua script rather than providing server and ruleset options
is that, if done lazily, it forces ruleset authors to code. It would be nice
if the requirement for this could be minimised; ideally an engine author in
Lua could make a parameterised engine which non-coding ruleset authors could
tweak by editing simple setting-like parameters. (For instance, we'd probably
want to provide a ruleset-adaptive Lua version of the current engine in
default.lua taking its parameters from the ruleset.)
Thoughts on possible parameterisation and how it might be achieved:
* The terrain transformations (warmer_wetter_result etc). Currently these four
ruleset parameters are *only* used in the climate change code, so if that were
moved to Lua the presence of these parameters remaining hardcoded in the
ruleset format would be an ugly restriction.
** Of course, once the climate change script becomes ruleset-dependent then
the transformation arcs could just be rendered directly in the code: if
forest then jungle etc. Can we do better?
** Perhaps we could arrange for arbitrary key/value properties not understood
by the Freeciv core to come from the ruleset (associated with terrains and
similar objects) and be accessible by name from Lua in a dictionary-like
object?
*** We could just implicitly put any unrecognised property seen in the ruleset
in this dictionary (but this loses ability to spot ruleset typos and also
potential namespace management problems between us and script authors);
*** or we could give script-accessible properties their own namespace (and
move warmer_wetter_result etc into it).
** This would keep all the terrain knowledge in one place in the ruleset.
* Maybe the causes of climate change: if
[Freeciv-Dev] [patch #4104] Don't hard code pollution/fallout specials for global warming/cooling
Follow-up Comment #4, patch #4104 (project freeciv): Sigh, missed some bits: * Re UI/state: since the notion of risk of warming/cooling must remain hardcoded, the state for that should probably remain in the server and be accessed from Lua via get()/set() methods. But the intermediate variables in the calculation can move out of the server into Lua. * Re configurability: currently we have server settings 'globalwarming' and 'nuclearwinter'. Lua script can access those, and since these notions remain hardcoded that's probably sufficient here, but for other features the question of how a server operator similarly controls them arises. They can use '/lua cmd feature=0', which exposes the detail that a thing's implemented in Lua (and we need to ensure it works correctly in a .serv file). Otherwise we could invent some way for scripts to register operator-tweakable settings via init hooks, or just a name/value dictionary exposed to Lua. ___ Reply to this item at: http://gna.org/patch/?4104 ___ 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 #4123] Correct government graphic tags to alien ruleset
Update of patch #4123 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?4123 ___ 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] Fullmoon build results
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): Succeeded Component autogen.sh, Host build.cazfi.net, Phase Other command(0): Succeeded Component server, Host build.cazfi.net, Phase Build(2): Succeeded Component gtk2, Host build.cazfi.net, Phase Build(2): Succeeded Component sdl, Host build.cazfi.net, Phase Build(2): Succeeded Component xaw, Host build.cazfi.net, Phase Build(2): Succeeded Component qt, Host build.cazfi.net, Phase Build(2): Succeeded Component stub, Host build.cazfi.net, Phase Build(2): Succeeded Component QualityCheck, Host build.cazfi.net, Phase Check(4): FAILED ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [patch #4126] Document action enablers
URL: http://gna.org/patch/?4126 Summary: Document action enablers Project: Freeciv Submitted by: sveinung Submitted on: Sun 01 Sep 2013 12:52:28 AM GMT Category: docs Priority: 5 - Normal Status: Ready For Test Privacy: Public Assigned to: sveinung Originator Email: Open/Closed: Open Discussion Lock: Any Planned Release: ___ Details: in README.actions. ___ File Attachments: --- Date: Sun 01 Sep 2013 12:52:28 AM GMT Name: document_actions.patch Size: 1kB By: sveinung http://gna.org/patch/download.php?file_id=18816 ___ Reply to this item at: http://gna.org/patch/?4126 ___ 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 #21087] Non-ASCII character in rusyn.ruleset
URL: http://gna.org/bugs/?21087 Summary: Non-ASCII character in rusyn.ruleset Project: Freeciv Submitted by: cazfi Submitted on: Sun 01 Sep 2013 04:15:40 AM EEST Category: general Severity: 3 - Normal Priority: 9 - Immediate Status: Ready For Test Assigned to: cazfi Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: 2.6.0 ___ Details: rusyn.ruleset has non-ASCII character (–) causing msgmerge to fail. Fix attached for immediate commit. Problem found by fullmoon autobuild. ___ File Attachments: --- Date: Sun 01 Sep 2013 04:15:40 AM EEST Name: AsciiRusyn.patch Size: 810B By: cazfi http://gna.org/bugs/download.php?file_id=18817 ___ Reply to this item at: http://gna.org/bugs/?21087 ___ 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 #21087] Non-ASCII character in rusyn.ruleset
Update of bug #21087 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?21087 ___ 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 #21084] Segfault on client quit -- gen_roads implicated?
Follow-up Comment #1, bug #21084 (project freeciv): Seems like ruleset data is not valid - maybe it's freed already when this idle_callback gets called. ___ Reply to this item at: http://gna.org/bugs/?21084 ___ 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 #4110] Extra conflicts
Follow-up Comment #1, patch #4110 (project freeciv): - Made tile_extra_apply() non-static - Use tile_extra_apply() instead of tile_add_special() in edithand.c - Removed tile_add_special() with hardcoded conflicts completely (file #18818) ___ Additional Item Attachment: File name: ExtraConflicts-2.patch.bz2 Size:6 KB ___ Reply to this item at: http://gna.org/patch/?4110 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
