Complete.Org: Mailing Lists: Archives: freeciv-dev: July 2000:
[Freeciv-Dev] Re: conquer city, owner doesn't change (PR#465)
Home

[Freeciv-Dev] Re: conquer city, owner doesn't change (PR#465)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Cc: bugs@xxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: conquer city, owner doesn't change (PR#465)
From: Jeff Mallatt <jjm@xxxxxxxxxxxx>
Date: Sun, 23 Jul 2000 09:39:39 -0400

At 2000/07/23 09:13 , Jeff Mallatt wrote:
>At 2000/07/22 17:01 , Thue wrote:
>>Den fre, 21 jul 2000 skrev jjm@xxxxxxxxxxxx:
>>> Full_Name: Jeff Mallatt
>>> Version: Latest CVS
>>> Distribution: Built from source
>>> Client: Both (or N/A)
>>> OS: Linux (Red Hat 5.0)
>>> Submission from: (NULL) (205.181.148.180)
>>> Submitted by: jjm
>>> 
>>> 
>>> I walked into an empty city, but it remained owned by the enemy!
>>> 
>>> Problem is that move_unit() calls handle_move_consequences() [this is
>>> the only place that handle_move_consequences() is called] which calls
>>> handle_unit_enter_city() [this is the only place that
>>> handle_unit_enter_city() is called].  Okay, move_unit() is commented
>>> as performing "No checks whatsoever!".  However, handle_unit_enter_city()
>>> performs a check!  It checks to see if the attacker is at war with the
>>> target city.  If not, it doesn't do the work to transfer the city.  But,
>>> move_unit() continues to go ahead and move the attacking unit into the
>>> city.
>>
>>Rather, you should not be able to take over the city of an enemy you are
>>not at war with. So the bug would be that the function that allowed you to
>>enter the city didn't check well enough.
>>
>>But note that that check should not be removed! Allies can enter each
>>other's cities without taking them over, which is intentional and
>>documented. You are sure the players were not just allied?
>
>I just thought about what might be the problem.  I had loaded an older
>save-game.  Maybe the bug is "contact states not initialized correctly when
>old save-games loaded.".

Yes, that seems to be it.  As a quick fix, I changed the default diplomatic
state in player_load() to DS_NEUTRAL from DS_NO_CONTACT (see attached
patch), and the bug went away.  This would only apply to old save games.
Is there any reason that this isn't correct enough?  Otherwise, I think
we'd have to do a contact check on every unit of every player.

Attachment: default-diplstate-neutral-0.diff
Description: Text document

jjm

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