Bug #1564
closed
Correct airlift enabled checking
Added by Alexandr Ignatiev 24 days ago.
Updated 8 days ago.
Description
When considering (with limited knowledge) the possibility of airlifting from/to foreign city, the functions action_hard_reqs_actor in actions.c and test_unit_can_airlift_to in unit.c return uncertain results due to unknown airlift counter even if airlift_from/to_always_enabled is set. This has actually few effect since client allows maybe-possible actions.
Headscratches note: how does it check presence of non-mutual ally units in a foreign city? I tested it in v.3.1 and the unit stays in source city without any note, so some check is performed but idk where, seems like definitely not in do_airlime. EDIT: yes, there is no check in main versoion, the unit lands on heads of non-allied units. I'll look how deep that goes. EDIT 2: yes, it goes back to 3.1 and earlier.
Files
- Description updated (diff)
- Description updated (diff)
- Description updated (diff)
Patch for 3.4, earlier versions need another one
Hmm seems wrong for flagless units. They should be not airliftable neither to ally cities at all nor to own cities with ally units.
Edited into a mostly working function. Now should be propagated to earlier versions.
Ouch, misplaced the ? : branches.
Also, may we allow the clients to try airlift to any unseen city in hope that an ally conquered it (at least if we have a live ally)?
Rewrote things, tested it on a civ1 map, now it should work.
3.3 patch, need to remove flagless lines for 3.1/3.2 one
S3_1 patch uses nullptr:
../../src/common/unit.c: In function ‘test_unit_can_airlift_to’:
../../src/common/unit.c:94:33: error: ‘nullptr’ undeclared (first use in this function); did you mean ‘nullptr_t’?
94 | const struct tile *dst_tile = nullptr;
| ^~~~~
| nullptr_t
hmm happens 3.3 and 3.2 also use it, but they somehow compiled at my installation.
nullptr is being defined even in S3_2, though our CodingStyle was (later) defined to prefer it in S3_3 and later only, and to avoid it in S3_2.
Marko Lindqvist wrote in #note-13:
though our CodingStyle was (later) defined to prefer it in S3_3
Does it mean the patch for main can go for 3.3?
Alexandr Ignatiev wrote in #note-14:
Marko Lindqvist wrote in #note-13:
though our CodingStyle was (later) defined to prefer it in S3_3
Does it mean the patch for main can go for 3.3?
They both should have nullptr instead of NULL, if that's what you are asking.
Well, that's likely the patces' only difference for now. So I correct 3.1,2 only.
- Status changed from New to In Review
- Assignee set to Marko Lindqvist
- Status changed from In Review to Closed
Also available in: Atom
PDF