Follow-up Comment #4, bug #13218 (project wesnoth):
1) Ok, I'll add code to handle ai::move_unit (unit.loc, unit.loc) case.
are there any other special situations I should be aware of ?
(apart from normal move, failed move, and ambush)
IMHO, that underlying problem is that return value of ai::move_unit is
overloaded - it is used in two ways:
- to tell where the unit ended up after move.
- to tell whether the move was successful.
2) regarding the recruitment.fai
I think that the problem lies in:
--
if( my_leader.movement_left > 0,
move( my_leader.loc, nearest_keep( my_leader.loc ) ),
fallback()
)
it is there to move the leader to closest keep at the start of the turn, for
him to be able to reinfose
--
there are many possible actions to take (depending on the circumstances -
such as 'is other keep available which can be reached with one move?','is the
keep occupied by friend or an enemy?', 'do I have the money?', 'is the keep
dangerous for leader?', etc):
Let me think of a simplest way that could possibly work without major
glitches.
leader should check, in that order
a) Empty keep available within reach of a leader:
move leader to it. [this solves my case]
b) Keep available within reach of a leader but is occupied by an own
soldier:
- if possible, move own soldier out of the way
- if keep becomes empty move leader to keep
c) Keep available within reach of a leader but is occupied by a enemy:
attack the keep with the leader
d) Nearest Keep not within reach
- move towards nearest keep.
e) Keep available within reach of a leader but is occupied by an ally
- do nothing special with leader.
Of course, this is clearly not the best way, but works without glitches in
most cases.
What do you think? Should I try to implement such logic in place of current
code ?
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?13218>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs
