[Freeciv-Dev] (PR#40108) 2.1.2 sdl for osx tiger repetitive crash with hurry production
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40108 Hi, I've experienced repetitive crashes upon choosing hurry production at random intervals. I play on a Mac OSX Tiger 10.4.11 with the Freeciv 2.1.2 sdl. I've also installed darwin 1.5 macport to resolve a previous load problem. Something I noted when doing a system scan were command inconsistencies that have been copied and attached along with the most current save that experienced a crash. I also monitored my video memory to see if a surge of required memory or lack of sufficient memory may have been the cause. However, when the crash did come from a hurry production command it had sufficient memory with only about 60% being in use at the time. In regard to the inconsistencies of programming noticed by the computer, can I allow it to automatically correct those commands without causing fatal communication problem with either the game or the shell? Thanks for your ear and the gaming, LURCH _ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 Hi,I've experienced repetitive crashes upon choosing hurry production at random intervals. I play on a Mac OSX Tiger 10.4.11 with the Freeciv 2.1.2 sdl. I've also installed darwin 1.5 macport to resolve a previous load problem.Something I noted when doing a system scan were command inconsistencies that have been copied and attached along with the most current save that experienced a crash. I also monitored my video memory to see if a surge of required memory or lack of sufficient memory may have been the cause. However, when the crash did come from a "hurry production" command it had sufficient memory with only about 60% being in use at the time.In regard to the inconsistencies of programming noticed by the computer, can I allow it to automatically correct those commands without causing fatal communication problem with either the game or the shell?Thanks for your ear and the gaming,LURCHConnect and share in new ways with Windows Live. Get it now! ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40110) tile_info worked, enum known_type, city_can_work_tile(), and invisible cities
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40110
The first and most obvious part of the patch updates the tile/vision
documentation somewhat, as it was woefully out of date!
Renamed some of the enum known_type to reflect their source, and replaced
the order dependent = = tests.
Moved city_can_work_tile() out of server/citytools into common/city, to be
used in both client and server. This meant changing it somewhat, as it
used some server-only functions.
The upside is a new feature: air and civilian units no longer prevent
working a tile. This better conforms with usual expectations. See new
unit_occupies_tile().
Although the purpose of this series of patches is removal of conflicts
between city_map[] and tile_worked(), there was (at least) one use that
wasn't duplicated:
* seen tiles worked by cities that are not seen by the client!
The city_map[] has them marked TILE_UNAVAILABLE. In the server, the tile
is set, but not in the client.
Now, the city id is passed to the client. So the client has to make some
invisible cities (unknown center tile) to set the worked field.
That makes 2 client uses of NULL == city-tile (the other being the Editor).
The server still expects the tile field is always set.
Also, in borderless games, there's no tile_owner() to use for these
invisible cities, so an out-of-band (but in range) owner is used instead:
MAX_NUM_PLAYERS (in the reserved for barbarian range). The owner is
corrected as soon as the city is seen, or a border expands.
This required some other small modifications, primarily LOG_DEBUG.
Extensively tested on savegames of multiple bug reports. Seems to do what
is expected. I'm sure many more edge cases will be found
Index: doc/HACKING
===
--- doc/HACKING (revision 14420)
+++ doc/HACKING (working copy)
@@ -592,28 +592,29 @@
Unknown tiles and Fog of War
=
-In the tile struct there is a field
+In common/tile.h, there are several fields:
struct tile {
...
- unsigned int known;
+ bv_player tile_known, tile_seen[V_COUNT];
...
};
-On the server the known fields is considered to be a bitvector, one
-bit for each player, 0==tile unknown, 1==tile known.
-On the client this field contains one of the following 3 values:
+While tile_get_known() returns:
+/* network, order dependent */
enum known_type {
- TILE_UNKNOWN, TILE_KNOWN_FOGGED, TILE_KNOWN
+ TILE_UNKNOWN = 0,
+ TILE_KNOWN_UNSEEN = 1,
+ TILE_KNOWN_SEEN = 2,
};
-The values TILE_UNKNOWN, TILE_KNOWN are straightforward. TILE_FOGGED
-is a tile of which the user knows the terrain (inclusive cities, roads,
-etc...).
+The values TILE_UNKNOWN, TILE_KNOWN_SEEN are straightforward.
+TILE_KNOWN_UNSEEN is a tile of which the user knows the terrain,
+but not recent cities, roads, etc.
-TILE_UNKNOWN tiles are (or should be) never sent to the client. In the past
-UNKNOWN tiles that were adjacent to FOGGED or KNOWN ones were sent to make
+TILE_UNKNOWN tiles never are (nor should be) sent to the client. In the
+past, UNKNOWN tiles that were adjacent to UNSEEN or SEEN were sent to make
the drawing process easier, but this has now been removed. This means
exploring new land may sometimes change the appearance of existing land (but
this is not fundamentally different from what might happen when you
@@ -623,9 +624,10 @@
Fog of war is the fact that even when you have seen a tile once you are
not sent updates unless it is inside the sight range of one of your units
or cities.
+
We keep track of fog of war by counting the number of units and cities
[and nifty future things like radar outposts] of each client that can
-see the tile. This requires a number per player, per tile, so each tile
+see the tile. This requires a number per player, per tile, so each player_tile
has a short[]. Every time a unit/city/miscellaneous can observe a tile
1 is added to its player's number at the tile, and when it can't observe
any more (killed/moved/pillaged) 1 is subtracted. In addition to the
Index: server/cityhand.c
===
--- server/cityhand.c (revision 14420)
+++ server/cityhand.c (working copy)
@@ -185,11 +185,11 @@
return;
}
- if (!city_can_work_tile(pcity, ptile)) {
+ if (0 == city_specialists(pcity)) {
return;
}
- if (0 == city_specialists(pcity)) {
+ if (!city_can_work_tile(pcity, ptile)) {
return;
}
Index: server/citytools.c
===
--- server/citytools.c (revision 14420)
+++ server/citytools.c (working copy)
@@ -1979,40 +1979,6 @@
}
/**
- Returns TRUE when a tile is available to be worked, or the city itself is
- currently working the tile (and can continue).
- city_x, city_y is in city map coords.
[Freeciv-Dev] (PR#40110) tile_info worked, enum known_type, city_can_work_tile(), and invisible cities
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40110 [wsimpson - Sat Feb 23 18:08:32 2008]: The upside is a new feature: air and civilian units no longer prevent working a tile. This better conforms with usual expectations. See new unit_occupies_tile(). Please take care not to change gameplay rules without leaving some method of accessing the old behaviour (i.e. a server setting). Players expect this and are generally very annoyed when it changes for no apparent reason (I take a lot of flak even for inadvertently changing shortcuts for warclient). For example with this new behaviour it is not possible to lay seige to a city with fighters (a fairly common strategy, starving it in terms of shields and/or food). And as for appealing to realism (I assume that is what you mean by usual expectations, if not then disregard the following ;)), one could argue just as well that air units scare away the peasantry/farmers (i.e. the city tile workers), and enemy civilian units steal the tile's resources surreptitiously. The rationalization is arbi- trary; the effect on gameplay should generally the only metric by which to judge feature changes and additions. (Cf. my laborious efforts on the longturn forums arguing against using realism justifications for gameplay changes). ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] freeciv as programming game
hi, i recently spent some time on one of those programming games, you know these games in which only ai players compete with each other. anyway at some point i remembered my long time favorite civilization, an i checked freeciv's website to see how things are going. i really would like to write my own client for the game. and i very much would like to do that in my currently favorite scripting language. i guess it would be possible to use SWIG to make the client api written in c available to scripting languages like python, perl or ruby. i admit i haven't done anything with swig, because i'm no c guy, but i worked in a lot of other languages. i sure would help to work on something like this, if there is something i can do. i'm not able to guess how much effort would have to be put in it, though. maybe there already is a project like this out there. surely, i would be glad if it were. let me know what you think. currently i'm not on your dev-list, so i hope this email gets through to you and you'll recieve your replies. best phil ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] freeciv as programming game
On 2/23/08, Philipp Hofmann [EMAIL PROTECTED] wrote: hi, i recently spent some time on one of those programming games, you know these games in which only ai players compete with each other. anyway at some point i remembered my long time favorite civilization, an i checked freeciv's website to see how things are going. i really would like to write my own client for the game. and i very much would like to do that in my currently favorite scripting language. i guess it would be possible to use SWIG to make the client api written in c available to scripting languages like python, perl or ruby. I think your best bet would be expanding the scope of the existing lua bindings (in the server) to the point where AI logic could be implemented completely in lua scripts. This would be really cool and vastly lower the requirements for people wanting to experiment with the AI's playing strategy. i admit i haven't done anything with swig, because i'm no c guy, but i worked in a lot of other languages. i sure would help to work on something like this, if there is something i can do. i'm not able to guess how much effort would have to be put in it, though. You need a very good understand of c in order not to make a mess implementing the bindings (be they in lua or something else). You can't just rely on something like swig to magically do the work for you. Lucky for you that since you say you have worked in other languages it should not be very difficult to learn the nuances of c programming (get yourself some c programming ebooks from the web or p2p or whatever), and that there are some existing lua bindings you could use as example code to build on. But in my opinion it will still require a large amount of time and effort before appreciable results can be seen. maybe there already is a project like this out there. surely, i would be glad if it were. There is no such project as far as I know. Anyway it would really be a great help if the AI could be improved in this way (a very common complaint is that the AI logic is not very good); don't worry that you will be learning (to program in c) as you go along, people will help you out if you run into trouble. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40110) tile_info worked, enum known_type, city_can_work_tile(), and invisible cities
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40110 Madeline Book wrote: And as for appealing to realism (I assume that is what you mean by usual expectations, I meant the actual behavior of civ1/2/3. We only need options for things that change from ruleset to ruleset. Does an air unit bounce a city worker in civ1? Does an air unit bounce a city worker in civ2? Does an air unit bounce a city worker in civ3? My memory is that they do not, but it's been a long time. Likewise diplomats/spies, as that would completely destroy their stealth. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40110) tile_info worked, enum known_type, city_can_work_tile(), and invisible cities
URL: http://bugs.freeciv.org/Ticket/Display.html?id=40110 [wsimpson - Sun Feb 24 02:57:33 2008]: Madeline Book wrote: And as for appealing to realism (I assume that is what you mean by usual expectations, I meant the actual behavior of civ1/2/3. We only need options for things that change from ruleset to ruleset. I don't understand this justification (maybe we have confused each other?). I mean a server setting (in server/settings.c) like savepalace or killcitizen, that would control the effect air and/or civilian units would have on enemy city workers. I don't see why this should be for things (?) that change only from ruleset to ruleset (is this a policy? And can you give me some examples so I better know what you mean?). Does an air unit bounce a city worker in civ1? Does an air unit bounce a city worker in civ2? Does an air unit bounce a city worker in civ3? I don't know the answer to those questions. I also think it is not relevant, unless you view strict emulation of civ1,2,3 more highly than respecting your current user base. Would not a server setting also give you the benefit of the doubt? Perhaps one version of civ has that behaviour, and another does not. I am objecting to a change in a game rule that I know will cause at least minor discomfort to players used to the behaviour before the change. Hence my suggestion that a server setting be added to allow access to the old game rule. If your structural changes to the codebase have made implementing such a setting impossible, well then alright, that's really a shame, and I hope you will be more careful about such things in the future (to avoid irrevocably changing a more important game rule). My memory is that they do not, but it's been a long time. Likewise diplomats/spies, as that would completely destroy their stealth. Spies and diplomats do not have the Partial_Invis flag. As for stealth fighters/bombers, consider that submarines can in fact be detected by their effect on city workers when their controlling player is foolish enough to move them into the field of the enemy city (a common, relied-upon occurence in games). So there is precedent for stealthy units having thier stealth destroyed by affecting enemy city workers. Consider also that an air or civilian unit can be used to bypass ZOC, implying that they do in fact control the tile, and hence should bounce city workers. I hope my advice above, representing the input of the multiplayer freeciv community, has been helpful. If you find that it is tiresome to have me second-guessing you all the time, just say so, or feel free to ignore me. ;) ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
