Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2004:
[Freeciv-Dev] (PR#10557) unit with orders being taken over by the AI
Home

[Freeciv-Dev] (PR#10557) unit with orders being taken over by the AI

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: bwexell@xxxxxxxxx
Subject: [Freeciv-Dev] (PR#10557) unit with orders being taken over by the AI
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 17 Oct 2004 21:59:22 -0700
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=10557 >

And the full backtrace:

#3  0x4006f15d in __assert_fail () from /lib/libc.so.6
#4  0x08068ad1 in do_unit_goto (punit=0x8b2ba50, restriction=GOTO_MOVE_ANY,
    trigger_special_ability=false) at gotohand.c:1294
#5  0x080ec18d in ai_unit_goto (punit=0x8b2ba50, ptile=0x401cc358)
    at aitools.c:284
#6  0x080e8032 in aiferry_gobyboat (pplayer=0x81f6494, punit=0x8fa9640,
    dest_tile=0x401cc358) at aiferry.c:520
#7  0x080ec0ab in ai_gothere (pplayer=0x81f6494, punit=0x8fa9640,
    dest_tile=0x401cc358) at aitools.c:233
#8  0x080892bb in auto_settler_findwork (pplayer=0x81f6494, punit=0x8fa9640)
    at settlers.c:1100
#9  0x080899eb in auto_settlers_player (pplayer=0x81f6494) at
settlers.c:1308
#10 0x0804d9d5 in end_phase () at srv_main.c:576
#11 0x0804ee4b in main_loop () at srv_main.c:1544
#12 0x0804efd1 in srv_main () at srv_main.c:1621
#13 0x0804a590 in main (argc=12, argv=0xbffff704) at civserver.c:167

The unit is a Galleon.  It is transporting a unit, and has orders.  Then
the AI takes over, and tries to take over the galleon, but it can't.


Maybe this is too complicated.  So, let's rethink this...

The problem is that even in AI mode, a unit can have (client) orders. 
So what happens when the AI tries to take over a unit with orders?

Solutions:

1. Avoid ever taking AI control of a unit with orders.  This is the
current method, and to enforce it there is an assertion.  However there
are a lot of places where the AI takes control.  In this particular case
the AI just assumes control of any unit that is transporting one of our
units.  Does this mean the AI will control units of other players? 
Probably so.

2. Let the AI think it has control of a unit with orders, but don't let
it actually do anything.  In this case there are only a few checks
needed (I think).  The drawback is that the AI thinks it has control of
these units.  For instance we might pick a ferryboat and tell it to come
pick up our unit, but it will never arrive because it has orders.

3. Let the AI take over units with orders.  The problem with this is
that the user doesn't want this.  In a multi-player game if you get
disconnected for a turn you want your orders to continue.  In a
single-player game if you are watching an AI you want to be able to give
orders and have them respected.  But are either of these really that major?


I think that the ferry code here is buggy and needs to be fixed.  But I
also think that before the final release the assertion here should be
replaced with a check-and-return.  In fact since this is a major bug (it
happens any time you /ai a player who has an occupied transporter with
orders) it should perhaps be fixed immediately.

jason



[Prev in Thread] Current Thread [Next in Thread]