This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pathfinding refueling


>> Yes. But we must still check the treasury in order to decide what materials
>> should at all be considered as fuel.
>
>I am planning on testing all materials for all materials, once at the
>start. If any materials are consumed and required per turn or per move,
>then it is a fuel. If any fuels have a receive-from distance of zero,
>then it is a controlled fuel. The controlled fuel giving the shortest
>range is the one that is controlled in the path-finding. But all
>refueling points must be able to replenish all fuels required, otherwise
>it is ignored as a refueling point. I am not planning to do a global
>treasury check. Actually I am not completely sure what you mean, which
>is why i am reiterating the proposed algorithm, hopefully it covers what
>you mean.

After looking at the code, I can understand if you were puzzled by my
comment. The way the treasury is supposed to work, a unit will take the
difference between the material it needs for any type of action and its own
supply from the treasury. However, this is not implemented for move
actions: consume_move_supplies only uses the unit's supply. This is clearly
a bug, which I will fix.

In any case, a material that is consumed per turn or per move and has a
receive-from distance of zero can still have a treasury. So once the bug
has been fixed, the algorithm would have to check the treasury. Or to be
more specific: check if a treasury exists for m and if
um_takes_from_treasury is greater than zero. In that case, m should
probably not be considered a controlled fuel.

I say probably, because it is possible to have some units give material to
the treasury and some hoard it (depending on um_gives_to_treasury). If the
units who produce m also hoard it, then we a situation resembling the
normal case. I don't think any games use this possibility now, however, so
we can perhaps worry about this complication later.

Hans



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]