Re: [Freeciv-Dev] (PR#39558) BUG: science tree not displaying
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39558 On Mon, Aug 13, 2007 at 03:10:57PM -0700, William Allen Simpson wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=39558 The problem was in some assumptions of the patch. Believing my own lying eyes, the code seemed to pass a string in the packet handler that was (nearly) identical to the savegame. Unfortunately, there turned out to be intervening reformatting by the packet handler Rather than change my assumptions, changed the definition to a simple STRING. are you sure? inventions is boolean, so if memory serves [it usually doesn't; I don't have the packet handling code in front of me] BIT_STRING is going to give you a packet which is ~175 bytes smaller... M ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39558) BUG: science tree not displaying
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39558 Michael Kaufman wrote: sorry, yes inventions are technically trinary, but for purposes of passing to the client, they're binary, since update_research() is called upon receiving a player_info packet. Wow, is that wrong! I'll delete that terrible mistake as soon as I can test it. All research and diplomacy and advances are handled and verified in the server. The server version is canonical. It's hard enough to keep things synchronized, without clients recalculating! Not necessarily wrong [or not necessarily terrible]. as I recall update_research() only updates TECH_REACHABLE, which has a rigid definition [and really is only a cached value]: It doesn't matter whether the server tells the client or the client calculates it itself. The server still keeps the master record of inventions. I've heard the bit about premature optimization, but in this case, you're going backward. Actually forward, fixing a horrible implementation flaw. It may not be the final efficient answer, as sending the whole list is useless -- there will never be more than 1 or 2 changes per player per turn. If the list you're talking about is the inventions list, I don't think you get much benefit from say sending the number of changes/the invention indices/and the states or just sending the whole list in a bit array. The correct fix is to split the player_info packet into multiple packets. M ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#39627) [Bug] assert fail when taking player
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39627 On Tue, Aug 28, 2007 at 02:34:02PM -0700, Marko Lindqvist wrote: Patch attached. I'm not aware of any problems caused by not sending ruleset data when /take command is issued, but it doesn't mean there is none... (Remember that in order to /take client already has to be connected to current game and it has received identical rulesets) not off the top of my head, but the dependencies of switching players in the client are [or were] hellish, so the less than ideal solution was a game_free() inside the client to reset it properly, thus requiring the client to need rulesets again. The last time I checked, not doing a client reset on player switch caused bad things to happen, but I can't be more specific than that. M ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] saveturns on public games
I'm fairly sure pubserver set the saveturns value to 1. It might have been changeable with ctrl access at that time however. saveturns was set to 1. I seriously doubt that ctrl access could have changed that value since we needed all games for replays etc. M ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#38354) Autoconnect can't handle password
URL: http://bugs.freeciv.org/Ticket/Display.html?id=38354 On Mon, Jun 23, 2008 at 03:26:49PM -0700, Jason Short wrote: URL: http://bugs.freeciv.org/Ticket/Display.html?id=38354 Any idea if this is present on 2.1/2.2/trunk? How do I set up a server with authentication anyway? (...mostly from memory...) used to be just ./autogen.sh --enable-auth=yes or something like that and then pass -a or --auth to server (there's some new code I don't recognize in auth.c regarding server authentication with configuration from file) unfortunately you currently have to have a mysql server running with the correct set of tables to make it work. attached is my original text database. this was back before user_db.c became auth.c. A little tweaking to the auth.c functions and you can dispense with the mysql dependency. M toy_external_db.tar.gz Description: GNU Zip compressed data ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] [PATCH] Agent calls are never equal if they are to different agents
Just to throw in a couple cents here... I don't fundamentally disagree with what Per is saying here, but I don't think that it's all gloom and doom. Take AI government choice for example. To make the 'correct' choice of a government, a server-side AI can actually change the government, recompute all the cities and check against other choices. A client-side AI can't do that, or at least can't do that in a way which loads down the server (and a client-side AI is what we're talking about here). The CMA on the other hand can load down the server (if I recall; it's been awhile) because the client can keep asking for cma_results from the server to see if they're ok to do. Perhaps throttling these requests is a solution. I wholeheartedly agree that generalized rulesets have made it hard on AI, and doing a lot of the heavy-lifting pregame, after the rulesets have been received by the client, but before the game begins is probably the only way to go without your supercomputer. Despite this, humans can do pretty well with the amount of game state that the server sends their clients, so I expect that client-side AI can do the same with just as much information and more attention to detail. -mike On Wed, Jun 17, 2009 at 06:55:08PM +0200, Per Inge Mathisen wrote: Just to echo what was said earlier - the idea of client side agents is fundamentally a bad one because it requires too much information to be kept and sent to the clients. Only on the server can you access the amount of game state required for such agents without running head first into race conditions and then deadlocks when try to fix that because data has to be distributed over the network link and goes out of sync. It took CMA a very long time and a lot of work to reach its present state of stability. And CMA only does city tile management. I have also changed my mind about the desirability of a computational game AI. The amounts of CPU time required to compute best outcomes increases in such a dramatic fashion when the game rules are generalized, that it is simply not worth it. Good rules of thumb that can be written as AI scripts specifically for each ruleset will be faster, easier to write and maintain, and (therefore) probably even lead to better outcomes. This was not an easy conclusion for me to reach, because I spent a lot of time on the current computational AI. Hindsight is nice. If you want to throw computations at Freeciv AI problems, I recommend writing a program that analyses a ruleset then generating script rules that can be used later for a game AI. That way you can use as many CPU cycles as you want without anyone complaining. - Per ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] [bug #14585] Wish: timeout progress bar
interesting idea, and easily doable. In fact a nice little project for someone wanting to get their feet wet. Add a timing struct for each AI. Each turn for each AI, calculate the time it takes for various major actions (city management, unit management) and store that time. Use number of cities and units and time previous turn took as a predictor. Add all AI times together for interturn prediction. I imagine that the prediction would be pretty good. M What I ment was not the timeout of a turn (which gets counted down) but the time the server needs between turns. I.e. the time from pressing turn-done till one can move again. In large games I have seen it take from 1 to 20 minutes. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
