[Freeciv-Dev] (PR#39949) Blindspot in the AI's move/attack routines?
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39949 [EMAIL PROTECTED] - Fri Dec 07 16:44:37 2007]: I was playing on a hex tileset. It was early in the game. I had a size 2 city on plains. At the end of one turn, two enemy (AI) chariots moved into one of the outermost tiles of that city (two tiles away from my city center). IIRC, the AI already knew where my city center was. So I assumed that those chariots were headed towards it to capture it. Coincidentally, my city had just finished making a phalanx on that same turn. So, because it was new, that phalanx did not have time to finish fortifying itself before the next turn. My city did *not* have city walls. And I had no other units nearby that could reach my city (to reinforce it) before the chariots could attack it (on the next turn). The future looked bleak for my city and its phalanx. I figured that the phalanx (that was in my city) might survive one attack from a chariot. But it seemed unlikely that that phalanx would survive two chariot attacks on the same turn. And, if that phalanx lost either chariot battle, then my city would fall into enemy hands. Since I couldn't save the city, I decided to save the phalanx. I moved it out of the city center and onto an adjacent mountain tile. That left the city undefended. So, on the next turn, one of the enemy chariots could have just marched into my city and captured it. But that is *not* what happened. Instead, on the next turn, both chariots attacked the phalanx on the mountain. Both chariots lost their battles. So both the city and the phalanx survived. Why did this happen? I believe that it was a combination of two factors: 1) Zone of control (ZOC) exerted by the phalanx restricted the movements of the chariots. 2) The AI could not see the circumvention to that ZOC movement restriction. The following map may help explain this situation: /\ / A \ /\ /\ / D \/ B \ \ /\ /\ \/ E \/ C \ /\ /\ / / H \/ F \/ \ /\ /\ \/ I \/ G \ /\ /\ / / K \/ J \/ \ /\ /\ \/ L \/ \ \ /\ / \/ \/ The city and the phalanx were in tile I. The chariots first became visible to the city when they entered tile B. Tiles C and G were ocean. Tile F was mountain. The rest of the tiles were flat terrain (grassland, plains, etc.). There were no roads on any of these tiles except for I (i.e. the city's center). The phalanx evacuated from the city by moving from I to F. On the next turn, instead of heading towards the city, both chariots attacked from B to F (i.e. they attacked the phalanx on the mountain). And, as I said, both chariots lost that battle. (Why would chariots attack a phalanx on a mountain anyway? Because it was there? :-) But that is a different AI problem.) So apparently the AI did not see the tactic that many human players would see. I.e. first move one chariot from B to A and then move that same chariot from A to E. Then move the second chariot from B to E (which the phalanx's ZOC no longer blocks - because of the chariot now sitting on E) and then from E to I (which the phalanx's ZOC does not block because it is a move *into* a city). If the AI had done that, then I would have been impressed. But it didn't. Too bad. (Maybe Freeciv's AI is smarter now. I don't know because I haven't tested it lately.) It seemed to me that this is an interesting challenge for an AI. So I'm finally posting about it now - in case there is someone out there who might be interested in tackling this problem. A rather detailed analysis, except that you forget that the AI would not have the same information that you do. It could not know that after your phalanx moved to the mountain your city was empty [I assume the AI does not cheat by having access to all the information that the server has], and even if it did, I doubt it would be smart enough to use that particular zoc-bridge (something I would be impressed with even for a human player). Without knowing if your city was empty, it would be very risky to move the chariots like you suggest; if they fail they can be easily picked off in one attack since they are on weak terrain and stacked. That the AI would use its two chariots to attack a phalanx on a mountain is rather sad (this could be easily improved, or may be a bug). It is also possilble that the AI does not understand playing on hex tiles very well. I admit that writing even a decent AI for freeciv is the hardest challenge of this entire project. ___ Freeciv-dev mailing list
Re: [Freeciv-Dev] (PR#39954) Savegames are corrupted Bug...
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39954 Update: Savegames are becomming corrupted if i leave and go back to an earlier save game and then go forward, it is like it is combining the two past and present savegames into one?? For example: If i go a few years, autosave..., autosave..., autosave... then i manual save, then i go back to a previous autosave and go forward, then i go back again and go forward... Some where in there i get corruption and i have to go even further back to recover a working saved game. How do i turn OFF the automatic saving of games as i exit? If i load a save game and make a few moves or even just exit it overwrites a saved game on exit, no warning, no confirmation, no choice, it just does this!! This is very wrong behavior... I will try and see if i can send files that show exactly this corruption in progress, but don't wait for me to fix this bug. Really awesome game folks!!! Thanks!! =) - During game play i left and loaded an auto save game, but i can no longer Meet AI Players to offer or negotiate!? I wonder what or why the savegame corruption? I'm attaching the save game, my system is WinXP + Freeciv-2.1.1-gtk2. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39956) reducing the number of rulesets sent to client (pass 1)
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39956
Implement part of the bug fix proposal in PR#39579.
server/ruleset.c
load_rulesets()
remove redundant send_rulesets(), usually sent later after game_load(),
instead send only after explicit server/stdinhand.c set_rulesetdir()
In addition, this fixes a bug sending rulesets to game.all_connections
instead of the correct game.est_connections (established).
Now, all rulesets are sent only 2 times. Sending once would be better, but
that requires a packet change with significant redesign and restructuring!
server/savegame.c
game_load()
remove redundant send_ruleset_nations(), sent later with send_rulesets()
Now, nation rulesets are sent only 2 times, as above.
server/srv_main.c
start_game()
remove redundant send_server_settings()
Now, server settings are sent only 3 times. The third time is probably
redundant, but various settings are changing without update packets sent!
Therefore, left the remaining redundancy in place (suitably logged).
Generally, send_server_settings() after send_rulesets() for delta
compression of the redundancy and updates.
Also, the server and client had identically named handle_packet_input()
routines, yet were not the generated packet handler names. Renamed to
avoid confusion with each other, and with packets.def handlers.
client/repodlgs_common.c
calloc instead of malloc
Index: server/srv_main.c
===
--- server/srv_main.c (revision 14148)
+++ server/srv_main.c (working copy)
@@ -976,7 +976,6 @@
set_server_state(S_S_GENERATING_WAITING); /* loaded ??? */
force_end_of_sniff = TRUE;
- send_server_settings(NULL);
/* There's no stateful packet set to client until srv_ready(). */
}
@@ -1073,7 +1072,7 @@
Returns 0 if connection should be closed (because the clients was
rejected). Returns 1 else.
**/
-bool handle_packet_input(struct connection *pconn, void *packet, int type)
+bool server_packet_input(struct connection *pconn, void *packet, int type)
{
struct player *pplayer;
@@ -1502,8 +1501,7 @@
send_player_info(pplayer, NULL);
/* Note this is called even if the player has pressed /start once
- * before. This is a good thing given that no other code supports
- * is_started yet. For instance if a player leaves everyone left
+ * before. For instance, when a player leaves everyone remaining
* might have pressed /start already but the start won't happen
* until someone presses it again. Also you can press start more
* than once to remind other people to start (which is a good thing
@@ -1996,10 +1994,17 @@
set_server_state(S_S_RUNNING);
(void) send_server_info_to_metaserver(META_INFO);
+
+ freelog(LOG_VERBOSE, srv_ready() mostly redundant send_server_settings());
send_server_settings(NULL);
if (game.info.is_new_game) {
-/* Before the player map is allocated (and initiailized)! */
+/* If we're starting a new game, reset the max_players to be the
+ * number of players currently in the game.
+ */
+game.info.max_players = game.info.nplayers;
+
+/* Before the player map is allocated (and initialized)! */
game.fogofwar_old = game.info.fogofwar;
players_iterate(pplayer) {
@@ -2034,15 +2039,7 @@
}
} players_iterate_end;
-assert(game.info.is_new_game); { /* FIXME: inexplicable test */
- /* If we're starting a new game, reset the rules.max_players to be the
- * number of players currently in the game. But when loading a game
- * we don't want to change it. */
- game.info.max_players = game.info.nplayers;
-}
-
/* Set up alliances based on team selections */
-assert(game.info.is_new_game); /* FIXME: inexplicable test */
players_iterate(pplayer) {
players_iterate(pdest) {
if (players_on_same_team(pplayer, pdest)
@@ -2054,7 +2051,8 @@
} players_iterate_end;
} players_iterate_end;
}
-
+
+ /* FIXME: can this be moved? */
players_iterate(pplayer) {
ai_data_analyze_rulesets(pplayer);
} players_iterate_end;
Index: server/srv_main.h
===
--- server/srv_main.h (revision 14148)
+++ server/srv_main.h (working copy)
@@ -61,7 +61,7 @@
bool check_for_game_over(void);
-bool handle_packet_input(struct connection *pconn, void *packet, int type);
+bool server_packet_input(struct connection *pconn, void *packet, int type);
void start_game(void);
void save_game(char *orig_filename, const char *save_reason);
void pick_random_player_name(const struct nation_type *pnation,
Index: server/connecthand.c
===
--- server/connecthand.c(revision 14148)
+++ server/connecthand.c(working copy)
@@ -47,7 +47,7 @@
has started. If
Re: [Freeciv-Dev] (PR#39956) reducing the number of rulesets sent to client (pass 1)
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39956 Checked in immediately to avoid conflicts, and to improve performance testing my PR#39578 fixes Committed trunk revision 14149. Committed S2_2 revision 14150. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39954) Savegames are corrupted Bug...
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39954 With the savegame you provided, all the folks are AI, so I'm not sure which of the many players on a vast map Anyway, I tried player0, usually a likely choice, and had no problem meeting with any of the players listed in F3 contact. Could you send an earlier file you think is good, so I can make a quick line by line comparison? My guess is you'll need to Quit from time to time, instead of Leave and Load ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39812) Bug: Cannot Rename Global worklists in FC210
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39812 I think i may have been experiencing keyboard errors or USB errors or driver errors, and this bug report should be closed. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39955) Bug: Can't see FreeCiv's default Theme scroll bar tabs!
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39955 Hi Great Gods of FreeCiv Team, I would humble like to request a change to the FreeCiv default Theme so i may for ever more see, and therefor use, FreeCiv's default Theme scroll bar tabs! Since they're almost everywhere it is troublesome not to see them ever! Jpeg attached. PS If this can't be a fix for all to enjoy, please send me the fix or way to fix this issue. inline: FreeCiv's Invisible Scroll Tabs.jpg___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39954) Savegame got corrupted - Bug? Cannot Meet with nations any longer.
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39954 [wsimpson - Sun Dec 09 22:45:45 2007]: With the savegame you provided, all the folks are AI, so I'm not sure which of the many players on a vast map Anyway, I tried player0, usually a likely choice, and had no problem meeting with any of the players listed in F3 contact. Thanks William! I just downloaded my uploaded save game and as Dutch i cannot Meet with Hellanic (Player Tab F3), maybe this has to do with the .rc file so i will also attach that file. Could you send an earlier file you think is good, so I can make a quick line by line comparison? Since i'm getting all kinds of savegame errors i will be posting a set of files to compare... asap. My guess is you'll need to Quit from time to time, instead of Leave and Load That's either another bug or just a way to work-around bugs... Cheers! Cor'e =) .civclientrc Description: Binary data ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#8737) mapview centering error caused by panel resize
URL: http://bugs.freeciv.org/Ticket/Display.html?id=8737 [wsimpson - Fri Dec 07 10:58:13 2007]: Christian Knoke wrote: A vertical resize could be avoided if you move the minimap to the top. I don't understand this comment. The minimap is already on the top here. True, though that is configurable. It makes sense to split the lines, there is plenty of vertical space. Problem is if the number of lines is not constant then that causes whatever is below to be shifted up or down and that is slow as well. Marko already had some recent code to add an extra line for SDL. That whole function could be re-thought a bit for all clients! Formatting of the text should really be up to the GUI and not enforced by the common code. Although line height is constant and having a fixed number of lines is a reasonable limitation, character width is likely not to be constant and requiring a specific width is not viable. Then again we have one proposed patch which instituted a line wrap...which would again cause the number of lines to vary, creating a vertical resize problem. I stand by my claim that the proper solution is that the widget should auto-resize to be larger but never to be smaller. I find it hard to believe GTK cannot be easily configured for this, though vasco seemed to think that was the case and that intercepting the signal was the only solution. Even if this were done there might still be some translation issues as there is no real upper bound on how long a line might be. An alternative might be to embed this widget into a scrollable frame. Then if it exceeds the size rather than resizing the container it will just add scrollbars. Not perfect but surely better than the current system. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39949) Blindspot in the AI's move/attack routines?
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39949 On 12/9/07, Madeline Book [EMAIL PROTECTED] wrote: A rather detailed analysis, except that you forget that the AI would not have the same information that you do. It could not know that after your phalanx moved to the mountain your city was empty [I assume the AI does not cheat by having access to all the information that the server has] The AIs read the server information directly, and the 'hard' AI is omniscient, while the 'easy' AI has some limitations placed on it. I admit that writing even a decent AI for freeciv is the hardest challenge of this entire project. That is very true. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
