Re: [Freeciv-Dev] (PR#40283) [Patch] Skip base specials in tile_special_type_iterate
http://bugs.freeciv.org/Ticket/Display.html?id=40283 > On 17/06/2008, Madeline Book wrote: > So getting back on topic, is this an acceptable step > for removing S_FORTRESS and S_AIRBASE from specials, > that I may commit to S2_2/trunk so as to be able to > fix the base handling in the editor? Explicit Yes - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40283) [Patch] Skip base specials in tile_special_type_iterate
http://bugs.freeciv.org/Ticket/Display.html?id=40283 > The previous two posts went off on a tangent that is not really important at the moment. So getting back on topic, is this an acceptable step for removing S_FORTRESS and S_AIRBASE from specials, that I may commit to S2_2/trunk so as to be able to fix the base handling in the editor? I will test it myself some more and will take silence (while other stuff is being done) as a 'yes'. ;) -- やってもいいですか。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40184) [editor] Toolbar GUI front-end preliminary work
http://bugs.freeciv.org/Ticket/Display.html?id=40184 > > [book - Wed Jun 11 19:56:11 2008]: > > > [EMAIL PROTECTED] - Wed Jun 11 16:51:03 2008]: > > > > - Add FIXME about the fact that following code is not > > generic enough (gen-movement) > > > > + coastal = is_sailing_unittype(punittype); > > + homecity = find_closest_owned_city(pplayer, ptile, coas... > > This is a direct conversion of the old can_unit_exist_at_tile > to work on unit_type's (needed for example to check if a unit > type can be created at a certain tile). > > I'll add the FIXME here, but generalizing this code really > belongs in another ticket. Sorry, I mistook the code snippet for a different one that looks similar. :( This of course refers to code in handle_edit_unit_create, and has nothing to do with can_unit_exist_at_tile (except that they both use is_sailing_unittype). So my question is: isn't is_sailing_unittype as general as this code can be? Since it calls utype_move_type which calls uclass_move_type, and checks for SEA_MOVING which corresponds to move_type = "Sea" in the unitclass_sea section of the units.ruleset file. How else should I check to make sure that created "boats" are not homed to land-locked cities? -- 教えて下さい！ ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40254) [PATCH] Cancel AI mode when attaching to aifill player.
http://bugs.freeciv.org/Ticket/Display.html?id=40254 > > [EMAIL PROTECTED] - Mon Jun 16 02:05:45 2008]: > > 2008/6/5 Marko Lindqvist: > > 2008/5/30 Madeline Book: > >> > >> When a user connected to a server with some > >> AI players created by aifill, they were attached > >> to an existing AI player but AI mode was not > >> reset. So when the game started the player's > >> units moved on their own. This patch fixes that > >> problem by cancelling AI mode in the attached > >> player if AI mode is on and the server is in > >> the pregame state. > > > > I looked this problem too when I were working with the > > connectdialog problems (still unsure what to do with the > > remaining patch I have) > > Now I can post it here. This requires send_chat_printf() > patch from #40284. This patch (+ the one from 40284) fixes a different problem then what I originally opened this ticket for. It still occurs that if you connect to a server with a positive aifill value you are silently attached to an AI and when the game starts your units move on their own (wierder still is that the 'A' marking automatic orders does not appear until the second turn). Of course with this patch if you do the "Take this player" from the connection list menu in pregame then it aitoggles the player you are attached to into the correct state. But it is not good to expect users to know about and have to do this, especially since this was not the case in previous versions. So I propose that when a new client connection is made, and the server is trying to attach the connection to a new player, the server first removes an AI player created by aifill, and then creates a fresh human player to which is attached the new connection. -- 感謝していますが、私の問題をあまりよく解きません。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40286) Setup -D defines for luaconf.h?
http://bugs.freeciv.org/Ticket/Display.html?id=40286 > A minor issue, but today when compiling S2_2 I got this warning when linking: ../dependencies/lua-5.1/src/liblua.a(loslib.o): In function `os_tmpname': /home/book/src/freeciv/freeciv/git-svn/dependencies/lua-5.1/src/ loslib.c:60: warning: the use of `tmpnam' is dangerous, better use `mkstemp' Looking into the lua-5.1 sources it would appear that the use of mkstemp is controlled by successive macros LUA_USE_MKSTEMP set by LUA_USE_POSIX set by LUA_USE_LINUX in luaconf.h. So would it be possible to use the autoconf tools to somehow make lua compile with the right defines? E.g. with -DLUA_USE_LINUX on my linux system. -- なるほど。でも、よくなるのはできませんか。 ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#40280) [Patch] Renamed player_invention_is_ready
http://bugs.freeciv.org/Ticket/Display.html?id=40280 > > [EMAIL PROTECTED] - Mon Jun 16 01:14:01 2008]: > > 2008/6/15 Madeline Book: > > > > This gave me another idea along the same lines: PREREQS_KNOWN. > > I were worried this would turn out too long, but in the end I'm quite > happy with it. In addition to this change, I moved word "GOAL" before > modifier "PREREQS_KNOWN" or "UNKNOWN" in reqtree parts. Great, this makes the code both clearer and more uniform in its naming. > > It could also apply to player_invention_reachable() making it > > bool player_invention_prereqs_known(player, tech). > > There 'reachable' = 'ever reachable'. Ah yes... I have been confused by the old and new "reachable". ;) -- ご苦労さまでした ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
Re: [Freeciv-Dev] (PR#40282) Re: Patch: CMA fix when loading saved game
http://bugs.freeciv.org/Ticket/Display.html?id=40282 > I'm not surprised you didn't want to use my hack. :-) I tried your patch against 2.1.4. The changes to packhand.c didn't apply cleanly and I had to do them by hand. Then when I tried to load a saved game, I got this when I starting the game: civclient: agents.c:768: wait_for_requests: Assertion `agent->first_outstanding_request_id == 0' failed. Aborted I'll send you a savegame separately (it's about 700K, so I don't want to CC [EMAIL PROTECTED], which looks like a list, with it). Pat On Sun, Jun 15, 2008 at 10:38 AM, Marko Lindqvist <[EMAIL PROTECTED]> wrote: > > 2008/6/10 Patrick Smith: > >> Hi, > >> > >> The attached patch seems to fix some CMA problems when loading a saved > game. > >> The city report still indicates fairly random CMA choices for cities, > but > >> some messages about the governor being confused seem to have > disappeared, > >> and I can now set the governor as I wish after loading a game, which > wasn't > >> always possible before. > > Your patch was a bit too hackish. For example, it handled only first > connection client made. If client reconnects to same or another > server, your fix was not used at all. > Based on your comments about the actual problem and its reasons, I > wrote a bit different patch. It is attached to this email. Can you > test if it fixes the problems. (This version is written against TRUNK, > I don't know if it applies cleanly to other branches) > > > - ML > I'm not surprised you didn't want to use my hack. :-)I tried your patch against 2.1.4. The changes to packhand.c didn't apply cleanly and I had to do them by hand. Then when I tried to load a saved game, I got this when I starting the game: civclient: agents.c:768: wait_for_requests: Assertion `agent->first_outstanding_request_id == 0' failed.AbortedI'll send you a savegame separately (it's about 700K, so I don't want to CC [EMAIL PROTECTED], which looks like a list, with it). PatOn Sun, Jun 15, 2008 at 10:38 AM, Marko Lindqvist <[EMAIL PROTECTED]> wrote: > 2008/6/10 Patrick Smith: >> Hi, >> >> The attached patch seems to fix some CMA problems when loading a saved game. >> The city report still indicates fairly random CMA choices for cities, but >> some messages about the governor being confused seem to have disappeared, >> and I can now set the governor as I wish after loading a game, which wasn't >> always possible before. Your patch was a bit too hackish. For example, it handled only first connection client made. If client reconnects to same or another server, your fix was not used at all. Based on your comments about the actual problem and its reasons, I wrote a bit different patch. It is attached to this email. Can you test if it fixes the problems. (This version is written against TRUNK, I don't know if it applies cleanly to other branches) - ML ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
