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: Major bug and what to do about it (long)


>>>If the action check failed because the unit view doesn't not
>>>correspond to an actual unit at the given position, then the task
>>>logic should make a callback to the AI or UI to remove the unit
>>>view, IMO. This would break the cycle.
>>
>>
>> Yes, I thought about that. However, since failed tasks do not consume acps,
>> this would provide a cost-free way to probe the terrain for real vs. bogus
>> enemy units.
>
>No. Tasks don't consume ACP or anything else. Actions do. And, I don't
>see a problem if a failed action consumes ACP or materials. If an attack
>or a fire misses an actual unit, ACP is consumed in spite of the fact
>that it was a miss. How is attacking a ghost unit any different than a miss?

Because we are dealing with a failed task here, not a failed action. We
never get to the point where we attack the ghost unit. That is the core of
the problem. If we did attack the ghost unit, we would certainly consume
acps, even if we failed. But the only way to get that far is to use
fire_into_action so that the action is not aborted before it happens (or
even before it can be scheduled to happen, as in this specific case).

>I don't think that tasks should consume ACP or anything else. They are
>too high level. We should restrict consumption to actions (as I beleive
>the case is now).

OK, then we agree on that point. That does, however, rule out the acp
penalizing scheme as a possible solution.

>>but
>> it would go against how Xconq works in all other situations. For example,
>> if you click where your unit cannot move, you don't spend any acps.
>
>In the case of movement this makes sense. But, consider that a melee
>attack actually does imply movement (as we agreed upon in an earlier
>thread), and thus, even if the attack is unsuccessful, the unit should
>be penalized for the implied movement (preferably through the normal
>attack costs).

If a unit does carry out an attack which is unsuccessful, yes. But if it
only gets as far as contemplating an attack (task execution) which never
happens, I don't think it should be penalized. Thinking about doing
something is not the same thing as doing it.

Hans

P.S. I think the real problem here is that real units instead of unit views
are being checked at a point (task execution), where only unit views should
be checked, since that is all the AI or the human player should ever know
about. References to real units should be strictly limited to the action
code where things do happen. Anything before that is AI code (or interface
code), and should be treated accordingly.

By firing into or attacking cells instead of units, we can avoid the need
to mess with real units already at the task execution stage. That's the
gist of my argument.




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