[Freeciv-Dev] [bug #13702] [Bugfix] City lost to enemy seen as owned
Update of bug #13702 (project freeciv): Category:None = general Status:None = Fixed Assigned to:None = cazfi Open/Closed:Open = Closed ___ Reply to this item at: http://gna.org/bugs/?13702 ___ 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 #13706] [Bugfix] Homecity field accessed from already freed unit
URL: http://gna.org/bugs/?13706 Summary: [Bugfix] Homecity field accessed from already freed unit Project: Freeciv Submitted by: cazfi Submitted on: Wednesday 06/17/2009 at 00:04 Category: general Severity: 3 - Normal Priority: 1 - Later Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: wipe_unit() uses punit-homecity after unit is already removed. Fix attached. ___ File Attachments: --- Date: Wednesday 06/17/2009 at 00:04 Name: HomecityId.diff Size: 806B By: cazfi http://gna.org/bugs/download.php?file_id=5983 ___ Reply to this item at: http://gna.org/bugs/?13706 ___ 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 #13707] [Patch] Free memory allocated by init_nls()
URL: http://gna.org/bugs/?13707 Summary: [Patch] Free memory allocated by init_nls() Project: Freeciv Submitted by: cazfi Submitted on: Wednesday 06/17/2009 at 00:49 Category: None Severity: 3 - Normal Priority: 1 - Later Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: Free memory allocated by init_nls() when program quits in order. Makes valgrind reports a bit cleaner at least. ___ File Attachments: --- Date: Wednesday 06/17/2009 at 00:49 Name: NlsMemLeakFix.diff Size: 2kB By: cazfi http://gna.org/bugs/download.php?file_id=5984 ___ Reply to this item at: http://gna.org/bugs/?13707 ___ 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 #13708] [Patch] Fix memory leak in sea barbarian creation
URL: http://gna.org/bugs/?13708 Summary: [Patch] Fix memory leak in sea barbarian creation Project: Freeciv Submitted by: cazfi Submitted on: Wednesday 06/17/2009 at 01:44 Category: None Severity: 3 - Normal Priority: 1 - Later Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: Creation of barbarian boat causes call to ai_data_get() after ai_data_phase_done() is called for the turn. ai_data_get() has side-effect of sometimes calling ai_data_phase_done() and ai_data_phase_init(). There is memory leak when there is no ai_data_phase_done() between two ai_data_phase_init() calls. Attached patch fixes this memory leak by wrapping sea barbarian creation between separate ai_data_phase_init() and ai_data_phase_done() calls. We can't extend turn's main ai_data_phase_init() and ai_data_phase_done() there. ___ File Attachments: --- Date: Wednesday 06/17/2009 at 01:44 Name: CreateBarbDataPhase.diff Size: 591B By: cazfi http://gna.org/bugs/download.php?file_id=5985 ___ Reply to this item at: http://gna.org/bugs/?13708 ___ 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 #13709] Switch from toluaxx to tolua-5.1b
URL: http://gna.org/bugs/?13709 Summary: Switch from toluaxx to tolua-5.1b Project: Freeciv Submitted by: cazfi Submitted on: Wednesday 06/17/2009 at 02:33 Category: None Severity: 3 - Normal Priority: 1 - Later Status: None Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Release: Operating System: None ___ Details: First some history: When we updated lua to 5.1 there was no lua-5.1 compatible version of tolua. We had to switch from tolua to toluaxx. Quality of toluaxx has been somewhat shaky and it seems that it's dead project. Nowadays there is lua-5.1 compatible version of tolua, tolua-5.1b. I think it's time to switch from toluaxx back to tolua. Consider this notification as patch to add tolua-5.1b directory under dependencies; if nobody objects within 24h I'll add it. ___ Reply to this item at: http://gna.org/bugs/?13709 ___ Message sent via/by Gna! http://gna.org/ ___ 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
On 15/06/2009, Bernd Jendrissek bernd.jendris...@gmail.com wrote: On Tue, Jun 9, 2009 at 3:44 AM, Madeline Bookmadeline.b...@gmail.com wrote: You should know that the agents framework suffers from a number of design problems and has not been actively maintained by anyone in a long time, the original author no longer begin involved in freeciv development and nobody else really interested in learning how it should work or how to fix it and make use of it. Could you elaborate please? I haven't been subscribed in a few years so I'm not up-to-date with current memes. You don't need to do my homework for me; I'm just looking for *what* to look for. Design problems worries me, if I'm going to be depending on agent callbacks. For cma in particular: it is slow (no CPU computation should take longer than a second; the algorithm does not scale), inefficient (too much client-server communication making it unwieldy in online games), does not adapt well to non-default game rules (the ugly cross-dependence of common/ files and untested behavior for other rulesets), and fails to accomodate even basic game situations that occur again and again (no way to prevent greedy tile grabbing, no way to fix tile usage, recomputation right at the very moment when client needs to be responsive, etc., etc.). (I mention in passing that the entire attribute system should be removed, and probably would have been long ago, were it not for the single annoying dependence of the cma on it.) Every potential agent implementation must consider whether it fails in the above mentioned respects at least. In general there is also the question whether client side automation afforded by agents is even desirable for freeciv, as then it may degenerate in to battle of computer programs rather than players. For example in the case of the city worker twiddling problem that cma tries to alleviate (player does not have to micro-manage citizens, in theory), one should also consider fixing the design of the game itself. That is, instead of throwing AI at the game problem, consider finding and proposing better game mechanics that would not suffer the same player annoyances. Then there is the current problem of agent implementations almost always requiring to keep track of some form of state between activations, but the design of freeciv packets makes this quite cumbersome at best (cf. the request id hacks used by cma). In brief, there is poor support for stateful client side programming (other parts of freeciv suffer from this too, and I have a solution in mind, but have not yet had time to make a test implementation). Finally I would just like to mention lua as a much better candidate for work than the agents framework. Extending and implementing all non-resource intensive code in a lua engine would do wonders for AI programming, both on the server and the client side. At least so my dream goes, assuming that the lua integration is done right. ;) All that said, if you are some programming wizard and have already made some significant improvements to the agents system and implemented some useful features, feel free to post your patches for possible inclusion in the development version; at least we would have something more fruitful and concrete to discuss rather than past mistakes and vague generalities. 何かがモニターのピクセルを一つずつ食べてしまう。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
