[Freeciv-Dev] [bug #19007] fix known map in savegame2
Update of bug #19007 (project freeciv): Planned Release: 2.3.1,2.4.0,2.5.0 = 2.3.12,2.4.0,2.5.0 ___ Reply to this item at: http://gna.org/bugs/?19007 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #19007] fix known map in savegame2
Update of bug #19007 (project freeciv): Planned Release: 2.3.12,2.4.0,2.5.0 = 2.3.2,2.4.0,2.5.0 ___ Reply to this item at: http://gna.org/bugs/?19007 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #18776] /remove perhaps faulty
Update of bug #18776 (project freeciv): Status: Ready For Test = In Progress Planned Release: 2.3.1,2.4.0 = 2.3.2,2.4.0 ___ Reply to this item at: http://gna.org/bugs/?18776 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #19007] fix known map in savegame2
Update of bug #19007 (project freeciv): Status: Ready For Test = In Progress ___ Follow-up Comment #4: I did not find this ticket yesterday evening. My proposal is to deactivate the /remove command after a game was started for 2.3.1. Thus, there is time to do all the checks needed to get the command working. As posted in bug #18776 there are further bugs if a client is connected at the time a player is removed. There's a newer file of the same name attached to bug #18776: file #14574. Does that supersede file #14565 attached here? Yes. From what I understand, if there are a lot of players saving their vision is buggy. It seems the /remove problem uncovered a number of bugs with saving a game. See above; the changes due to the removal of a player have to be send to the connected clients else their state is incorrect. ___ Reply to this item at: http://gna.org/bugs/?19007 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [bug #18641] allow remove command for access level = ADMIN in running games
Update of bug #18641 (project freeciv): Open/Closed: Closed = Open Planned Release: 2.4.0,2.3.1 = 2.4.0,2.3.2 ___ Follow-up Comment #11: I'm going to temporarily revert this fix for 2.3.1 as it exposes other bugs. See bug #18776 comment 32 http://gna.org/bugs/index.php#comment32. ___ Reply to this item at: http://gna.org/bugs/?18641 ___ 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 #19029] Trouble saving/loading players' known territory for player indices =40
URL:
http://gna.org/bugs/?19029
Summary: Trouble saving/loading players' known territory for
player indices =40
Project: Freeciv
Submitted by: jtn
Submitted on: Sat Nov 19 17:26:25 2011
Category: general
Severity: 5 - Blocker
Priority: 5 - Normal
Status: None
Assigned to: None
Originator Email:
Open/Closed: Open
Release: 2.3.1
Discussion Lock: Any
Operating System: Any
Planned Release: 2.3.2,2.4.0,2.5.0
___
Details:
Split out from bug #18776 / bug #19007. This is the /8 *32 confusion
discussed in 18776 comment 21 http://gna.org/bugs/index.php?18776#comment21
and later.
In savegame2.c:sg_save_map_known():
int *known = fc_calloc(lines * MAP_INDEX_SIZE, sizeof(*known));
/* HACK: we convert the data into a 32-bit integer, and then save it as
* hex. */
whole_map_iterate(ptile) {
players_iterate(pplayer) {
if (map_is_known(ptile, pplayer)) {
p = player_index(pplayer);
l = p / 32;
known[l * MAP_INDEX_SIZE + tile_index(ptile)]
|= (1u (p - l * 8));
}
} players_iterate_end;
} whole_map_iterate_end;
The p - l * 8 should be p - l * 32. There's a symmetric error in
sg_load_map_known().
I think the consequence is that known information is not saved/loaded for
players with indices 40 and above; instead, zeroes are saved/loaded. (The
arithmetic starts going wrong at index 32, but indices 32..39 are saved/loaded
by luck, in the wrong bit positions; after that all the data is shifted off
the left end.)
This affects any game with 40 players (including barbarians) regardless of
whether /remove is used. It can also affect games with fewer players if
/remove is used (in-game or pre-game).
There are some patches attached to bug #18776 which partially address this,
e.g. file #14574, but they don't deal with backwards compatibility with old
savefiles. This will be tricky.
___
Reply to this item at:
http://gna.org/bugs/?19029
___
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 #19007] Player slots miscounted when saving/loading known tiles = crashes and/or players forgetting territory
Update of bug #19007 (project freeciv): Status: In Progress = Ready For Test Planned Release: 2.3.2,2.4.0,2.5.0 = 2.3.1,2.4.0,2.5.0 Summary: fix known map in savegame2 = Player slots miscounted when saving/loading known tiles = crashes and/or players forgetting territory ___ Follow-up Comment #5: Per bug #18776 comment 32 http://gna.org/bugs/index.php?18776#comment32, I'm repurposing this bug to be just about the slot miscounting (which is what the currently attached file, file #14565, fixes). IMO, this is a low-risk change so I'm going to put it in 2.3.1. The other stuff mentioned in comment #2 and comment #3 -- divisor confusion -- is for a new bug: bug #19029. Description copied from the other bug: == Player slots miscounted when loading/saving known tiles == file #14579: 0005-basic-fix-known-map-in-savegame2.patch (which is basically the same as file #14565) _Bug:_ if the usage of player slots is sparse, then depending on luck and alignment, you can see either: * Segfaults or other misbehaviour, due to indexing off the end of a malloc'd array. * The known-tiles status of higher-indexed players is not saved or loaded. Such players will probably forget all the map they knew on reload. (I don't know if that has knock-on effects elsewhere, since their player maps will presumably have an opinion on what the terrain at those tiles is supposed to be. Can't rule out segfaults/assertion failures.) With the fix, I think loading from a savefile affected by the bug will produce the following warning: Saved game contains incomplete map data. This can happen with old saved games, or it may indicate an invalid saved game file. Proceed at your own risk. and carry on. That seems appropriate. Any knock-on effects will be present in games loaded from these savegames. Gaps in player slots can appear whenever /remove is used, whether in-game or pre-game. (Thus, reverting bug #18641 won't hide this bug.) _Risk/benefit:_ this change is simple and looks low-risk to me; can't see that it can break things, especially if /remove is not used. It fixes an observed segfault (bug #18776 comment 21). *Conclusion:* Apply this basic patch before 2.3.1. Cross fingers. ___ Reply to this item at: http://gna.org/bugs/?19007 ___ 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 #18776] /remove after game start causes crashes due to player vision mishandling
Update of bug #18776 (project freeciv): Status: In Progress = Ready For Test Planned Release: 2.3.2,2.4.0 = 2.3.2,2.4.0,2.5.0 Summary: /remove perhaps faulty = /remove after game start causes crashes due to player vision mishandling ___ Reply to this item at: http://gna.org/bugs/?18776 ___ 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 #19030] gmake of trunk on OpenBSD includes postgresql with wrong path
URL: http://gna.org/bugs/?19030 Summary: gmake of trunk on OpenBSD includes postgresql with wrong path Project: Freeciv Submitted by: akfaew Submitted on: Sat Nov 19 17:47:15 2011 Category: None Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: r20592 Discussion Lock: Any Operating System: *BSD Planned Release: ___ Details: $ ./autogen.sh --disable-nls --disable-client --enable-fcdb=postgres ! nls checks disabled + checking for autoconf = 2.59 ... found 2.60, ok. + checking for autoheader = 2.59 ... found 2.60, ok. + checking for automake = 1.7 ... found 1.9.6, ok. + checking for aclocal = 1.7 ... found 1.9.6, ok. + checking for libtoolize = 1.4.3 ... found 2.4.2, ok. ... checking for pg_config... /usr/local/bin/pg_config checking for PostgreSQL libraries... yes ... ls_postgres.c:23:28: error: pgsql/libpq-fe.h: No such file or directory [18:43:ttyp8][dude@hopek:/usr/local/include:5]$ find . -iname 'libpq-fe.h' ./postgresql/libpq-fe.h $ pg_config BINDIR = /usr/local/bin DOCDIR = /usr/local/share/doc/postgresql HTMLDIR = /usr/local/share/doc/postgresql INCLUDEDIR = /usr/local/include/postgresql PKGINCLUDEDIR = /usr/local/include/postgresql INCLUDEDIR-SERVER = /usr/local/include/postgresql/server LIBDIR = /usr/local/lib PKGLIBDIR = /usr/local/lib/postgresql LOCALEDIR = /usr/local/share/locale MANDIR = /usr/local/man SHAREDIR = /usr/local/share/postgresql SYSCONFDIR = /etc/postgresql PGXS = /usr/local/lib/postgresql/pgxs/src/makefiles/pgxs.mk CONFIGURE = '--disable-rpath' '--with-openssl=/usr' '--with-perl' '--enable-integer-datetimes' '--includedir=/usr/local/include/postgresql' '--datadir=/usr/local/share/postgresql' '--docdir=/usr/local/share/doc/postgresql' '--with-includes=/usr/local/include /usr/include/kerberosV' '--with-libraries=/usr/local/lib' '--with-system-tzdata=/usr/share/zoneinfo' '--with-openssl' '--with-ossp-uuid' '--with-libxml' '--disable-thread-safety' '--with-krb5' '--prefix=/usr/local' '--sysconfdir=/etc' '--mandir=/usr/local/man' '--infodir=/usr/local/info' '--disable-silent-rules' 'CC=cc' 'CFLAGS=-O2 -pipe' CC = cc CPPFLAGS = -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/include -I/usr/include/kerberosV CFLAGS = -O2 -pipe -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasing -fwrapv CFLAGS_SL = -fpic -DPIC LDFLAGS = -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -Wl,-Bdynamic LDFLAGS_EX = LDFLAGS_SL = LIBS = -lpgport -lxml2 -lssl -lcrypto -lcom_err -lssl -lcrypto -lz -lreadline -ltermcap -lm VERSION = PostgreSQL 9.1.1 ___ Reply to this item at: http://gna.org/bugs/?19030 ___ 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 #19029] Trouble saving/loading players' known territory for player indices =40
Follow-up Comment #1, bug #19029 (project freeciv): Please make 'p - l * 32' into 'p % 32', it will be much clearer, and it is equivalent. And this affects games with 33 players, since for p = 32, p - l * 8 maps to 24 and overwrites another players vision. ___ Reply to this item at: http://gna.org/bugs/?19029 ___ 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 #19029] Trouble saving/loading players' known territory for player indices =40
Follow-up Comment #2, bug #19029 (project freeciv): Please make 'p - l * 32' into 'p % 32', it will be much clearer, and it is equivalent. Sure, I wasn't suggested that as the actual fix. More extensive changes are needed here anyway, and there's chances to save time and memory. For instance, lines and hence known[] is bigger than it needs to be, and we could avoid saving half-bytes that have no information. And this affects games with 33 players, since for p = 32, p - l * 8 maps to 24 and overwrites another players vision. If l=1, we're on the next row of known[], so that shouldn't be the case (due to the l * MAP_INDEX_SIZE term)? ___ Reply to this item at: http://gna.org/bugs/?19029 ___ 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 #19031] Creating players from the server, before they connect
URL: http://gna.org/bugs/?19031 Summary: Creating players from the server, before they connect Project: Freeciv Submitted by: akfaew Submitted on: Sat Nov 19 18:16:20 2011 Category: None Severity: 3 - Normal Priority: 5 - Normal Status: None Assigned to: None Originator Email: Open/Closed: Open Release: Discussion Lock: Any Operating System: None Planned Release: ___ Details: Sometimes there is a need to create a bunch of human players and /start the server, without waiting for players to connect. Until now i've been doing that with the autocreate command (attached), it takes as argument a file with a list of player:team:nation:. In hindsight it should take 3 arguments (player, team, nation), not a file. I want to reduce the number of diffs in my tree. Can this be done from LUA? A different approach is: /create playername /team playername 4 /ai playername /take playername playername But here I cannot assign a nation to a player, so if I want to abandon my diff I would need to make at least a /nation command. Can a /create_human command be added, that does the above commands and takes 3 arguments? What do you think? ___ File Attachments: --- Date: Sat Nov 19 18:16:20 2011 Name: autocreate.c Size: 2kB By: akfaew http://gna.org/bugs/download.php?file_id=14588 ___ Reply to this item at: http://gna.org/bugs/?19031 ___ 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 #19031] Creating players from the server, before they connect
Follow-up Comment #1, bug #19031 (project freeciv): The server operator at freeciv.fi creates players this way: lua create_player(playername, find.nation_type(British)) aitoggle playername ___ Reply to this item at: http://gna.org/bugs/?19031 ___ 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 #19007] Player slots miscounted when saving/loading known tiles = crashes and/or players forgetting territory
Follow-up Comment #7, bug #19007 (project freeciv): For me there are odd disconnected spots of known territory This may be what I had and posted some time ago! Then I blamed it on possible sea map trade. ___ Reply to this item at: http://gna.org/bugs/?19007 ___ 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 #19007] Player slots miscounted when saving/loading known tiles = crashes and/or players forgetting territory
Update of bug #19007 (project freeciv): Status: Ready For Test = Fixed Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?19007 ___ 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 #18767] cma: always 1 tax collector
Follow-up Comment #2, bug #18767 (project freeciv): no matter which options i altered, cma always uses one worker as tax collector Do you meant that this happened to one specific city, or does cma always, for all cities, use one worker as tax collector? ___ Reply to this item at: http://gna.org/bugs/?18767 ___ 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 #18767] cma: always 1 tax collector
Follow-up Comment #3, bug #18767 (project freeciv): in various cities, like in this example, cmagents use one worker as tax collector. i do not know why i did not write it down, but today i am pretty sure, that i had cities during that time with two forced tax collectors too. that was my knowledge when i wrote my post. now i think, that the amount of unwanted tax collectors has to do with something, that is getting bigger while a city is growing like the amount of available workers. maybe it is trade or a number in the background, which a player does not get to see. http://img809.imageshack.us/img809/504/13353727.jpg - there are more tax collectors per city in the first column. as you can see, it does not increase steadily with workers (third column) and it does not increase steadily with trade (tenth column). i am curious what it is. i think cma does use workers as tax collectors in all cities based on a specific number - the bigger the city, the more tax collectors. ___ Reply to this item at: http://gna.org/bugs/?18767 ___ Nachricht geschickt von/durch Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] [task #7517] Windows packages for 2.3.1
URL: http://gna.org/task/?7517 Summary: Windows packages for 2.3.1 Project: Freeciv Submitted by: jtn Submitted on: Sat Nov 19 22:04:38 2011 Should Start On: Sat Nov 19 00:00:00 2011 Should be Finished on: Sun Nov 27 00:00:00 2011 Category: None Priority: 5 - Normal Status: None Privacy: Public Percent Complete: 0% Assigned to: cproc Open/Closed: Open Discussion Lock: Any Effort: 0.00 Planned Release: 2.3.1 ___ Details: ___ Reply to this item at: http://gna.org/task/?7517 ___ 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] [task #7518] Mac packages for 2.3.1
URL: http://gna.org/task/?7518 Summary: Mac packages for 2.3.1 Project: Freeciv Submitted by: jtn Submitted on: Sat Nov 19 22:04:41 2011 Should Start On: Sat Nov 19 00:00:00 2011 Should be Finished on: Sun Nov 27 00:00:00 2011 Category: None Priority: 5 - Normal Status: None Privacy: Public Percent Complete: 0% Assigned to: bitaxis Open/Closed: Open Discussion Lock: Any Effort: 0.00 Planned Release: 2.3.1 ___ Details: ___ Reply to this item at: http://gna.org/task/?7518 ___ 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] [task #7426] Mac packages for 2.2.7
Update of task #7426 (project freeciv): Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/task/?7426 ___ 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] [task #7429] Windows packages for 2.3.0
Update of task #7429 (project freeciv): Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/task/?7429 ___ 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] [task #7430] Mac packages for 2.3.0
Update of task #7430 (project freeciv): Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/task/?7430 ___ 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] [task #7228] Tracking release 2.3.0
Update of task #7228 (project freeciv): Status: In Progress = Done ___ Reply to this item at: http://gna.org/task/?7228 ___ 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] [task #7228] Tracking release 2.3.0
Update of task #7228 (project freeciv): Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/task/?7228 ___ 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] [task #7426] Mac packages for 2.2.7
Update of task #7426 (project freeciv): Status:None = Done ___ Reply to this item at: http://gna.org/task/?7426 ___ 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] [task #7430] Mac packages for 2.3.0
Update of task #7430 (project freeciv): Status:None = Done ___ Reply to this item at: http://gna.org/task/?7430 ___ 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] [task #7429] Windows packages for 2.3.0
Update of task #7429 (project freeciv): Status:None = Done ___ Reply to this item at: http://gna.org/task/?7429 ___ 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 #18641] allow remove command for access level = ADMIN in running games
Update of bug #18641 (project freeciv): Open/Closed:Open = Closed Planned Release: 2.4.0,2.3.2 = 2.3.2,2.4.0 ___ Follow-up Comment #16: ...and it's back post-2.3.1, on the assumption that we'll fix the problems before 2.3.2. ___ Reply to this item at: http://gna.org/bugs/?18641 ___ 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 #3055] Configurable road move cost
Update of patch #3055 (project freeciv): Status: Ready For Test = Done Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/patch/?3055 ___ 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 #3057] Rename default ai as classic
Update of patch #3057 (project freeciv): Planned Release: 2.5.0 = 2.4.0, 2.5.0 ___ Follow-up Comment #1: 2.4.0 will be first release with loadable AI modules. We've never released anything that has AI type named default. It makes sense to commit this name changed to S2_4 too to not use name default in the first place, and that way to avoid name change between 2.4 and 2.5. ___ Reply to this item at: http://gna.org/patch/?3057 ___ 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 #19029] Trouble saving/loading players' known territory for player indices =40
Follow-up Comment #3, bug #19029 (project freeciv): Interesting observation: I was testing the fix for bug #19007 with a player with index 125, and it didn't occur to me until later that this bug (#19029) should have been biting me, and wasn't. It turns out that on my platform at least (Linux x86_64), attempting to shift 1u left by x where x32 appears to give the result of shifting by (x%32). As a result, I don't think this bug bites at all on my platform, _provided that_ I save and load on the same platform -- all the bits are there, just in a funny order. It means we've now got platform-dependent savefiles, though, and there probably is some platform where it does discard data. The obvious backwards compatibility plan is to keep the loading code with the platform-dependent behaviour, and we'll have to keep it more or less forever, which will probably cause some compiler to shout at us at some point. Ugh. The attached small C program shows the pattern of bits I get. This is similar to what akfaew posted in bug #18776 comment 24 http://gna.org/bugs/?18776#comment24, but he didn't post his results (which are presumably on Sparc OpenBSD). Here are mine: 0: 1, 1 1: 2, 2 2: 4, 4 3: 8, 8 4: 16, 16 5: 32, 32 6: 64, 64 7: 128, 128 8: 256, 256 9: 512, 512 10:1024,1024 11:2048,2048 12:4096,4096 13:8192,8192 14: 16384, 16384 15: 32768, 32768 16: 65536, 65536 17: 131072, 131072 18: 262144, 262144 19: 524288, 524288 20: 1048576, 1048576 21: 2097152, 2097152 22: 4194304, 4194304 23: 8388608, 8388608 24:16777216,16777216 25:33554432,33554432 26:67108864,67108864 27: 134217728, 134217728 28: 268435456, 268435456 29: 536870912, 536870912 30: 1073741824, 1073741824 31: -2147483648, 2147483648 32:16777216,16777216 33:33554432,33554432 34:67108864,67108864 35: 134217728, 134217728 36: 268435456, 268435456 37: 536870912, 536870912 38: 1073741824, 1073741824 39: -2147483648, 2147483648 40: 1, 1 41: 2, 2 42: 4, 4 43: 8, 8 44: 16, 16 45: 32, 32 46: 64, 64 47: 128, 128 48: 256, 256 49: 512, 512 50:1024,1024 51:2048,2048 52:4096,4096 53:8192,8192 54: 16384, 16384 55: 32768, 32768 56: 65536, 65536 57: 131072, 131072 58: 262144, 262144 59: 524288, 524288 60: 1048576, 1048576 61: 2097152, 2097152 62: 4194304, 4194304 63: 8388608, 8388608 64: 65536, 65536 65: 131072, 131072 66: 262144, 262144 67: 524288, 524288 68: 1048576, 1048576 69: 2097152, 2097152 70: 4194304, 4194304 71: 8388608, 8388608 72:16777216,16777216 73:33554432,33554432 74:67108864,67108864 75: 134217728, 134217728 76: 268435456, 268435456 77: 536870912, 536870912 78: 1073741824, 1073741824 79: -2147483648, 2147483648 80: 1, 1 81: 2, 2 82: 4, 4 83: 8, 8 84: 16, 16 85: 32, 32 86: 64, 64 87: 128, 128 88: 256, 256 89: 512, 512 90:1024,1024 91:2048,2048 92:4096,4096 93:8192,8192 94: 16384, 16384 95: 32768, 32768 96: 256, 256 97: 512, 512 98:1024,1024 99:2048,2048 100:4096,
[Freeciv-Dev] [bug #18767] cma: always 1 tax collector
Follow-up Comment #4, bug #18767 (project freeciv): If i may be permitted to speculate, i'd say that the CMA seems to divert as many workers to tax collectors as it can and still feed the city. Thus, more irrigation and more specials that provide bonus food lead to more taxmen. ___ Reply to this item at: http://gna.org/bugs/?18767 ___ Message sent via/by Gna! http://gna.org/ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
