sect: Fix revert to deity and "no civilians" corner cases
We maintain a few sector invariants in sct_prewrite(). Since the update bypasses sct_prewrite(), it needs to maintain them itself. The two should be consistent. When a deserted sector reverts to the deity, sct_prewrite() clears owner and mobility. It neglects to clear the old owner, unlike populace(). Harmless, but fix it anyway for consistency. Visible in tests/navi-march/final.xdump. Work percentage, loyalty and old owner apply to civilians. When there are none, sct_prewrite() sets work percentage to 100 and old owner to owner. It neglects to clear loyalty, unlike populace(). Loyalty persists until populace() clears it. Most of the time, this doesn't matter, as moving civilians into a sector without civilians ignores the sector's loyalty. However, airlifted and unloaded civilians adopt the sector's loyalty (bug#49 and bug#255). Fix sct_prewrite() to clear loyalty for consistency, and to mitigate these bugs. Note that populace() may not always clear loyalty right away. This will be fixed in the next commit. Signed-off-by: Markus Armbruster <armbru@pond.sub.org>
This commit is contained in:
parent
0bdcb5ee19
commit
5e54219606
2 changed files with 3 additions and 1 deletions
|
@ -80,6 +80,7 @@ sct_prewrite(int id, void *old, void *new)
|
|||
|
||||
if (!civs) {
|
||||
sp->sct_work = 100;
|
||||
sp->sct_loyal = 0;
|
||||
sp->sct_oldown = own;
|
||||
}
|
||||
|
||||
|
@ -90,6 +91,7 @@ sct_prewrite(int id, void *old, void *new)
|
|||
if (own && !civs && !mil && !has_units(sp->sct_x, sp->sct_y, own)
|
||||
&& !(sp->sct_flags & MOVE_IN_PROGRESS)) {
|
||||
own = sp->sct_own = 0;
|
||||
sp->sct_oldown = 0;
|
||||
sp->sct_mobil = 0;
|
||||
if (sp->sct_type == SCT_CAPIT || sp->sct_type == SCT_MOUNT)
|
||||
caploss(sp, prev_own, "");
|
||||
|
|
|
@ -101,7 +101,7 @@ owner xloc yloc des effic mobil off loyal terr0 terr1 terr2 terr3 dterr xdist yd
|
|||
3 -6 6 10 100 0 0 0 0 0 0 0 0 -6 6 0 0 100 0 10 0 0 0 0 0 3 100 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 healthy 0 0 0 0 0 0 0 0
|
||||
2 -4 6 10 100 0 0 0 0 0 0 0 0 -4 6 0 0 100 0 10 0 0 0 0 0 2 100 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 healthy 0 0 0 0 0 0 0 0
|
||||
2 -2 6 10 100 0 0 0 0 0 0 0 0 -2 6 0 0 100 0 10 0 0 0 0 0 2 100 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 healthy 0 0 0 0 0 0 0 0
|
||||
0 1 7 10 100 0 0 0 0 0 0 0 0 1 7 0 0 100 1 10 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 healthy 0 0 0 0 0 0 0 0
|
||||
0 1 7 10 100 0 0 0 0 0 0 0 0 1 7 0 0 100 1 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 healthy 0 0 0 0 0 0 0 0
|
||||
1 3 7 10 100 0 0 0 0 0 0 0 0 3 7 0 0 100 1 10 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 healthy 0 0 0 0 0 0 0 0
|
||||
1 5 7 10 100 0 0 0 0 0 0 0 0 5 7 0 0 100 1 10 0 0 0 0 0 1 100 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 healthy 0 0 0 0 0 0 0 0
|
||||
1 7 7 10 100 0 0 0 0 0 0 0 0 7 7 0 0 100 1 10 0 0 0 0 0 1 100 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 healthy 0 0 0 0 0 0 0 0
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue