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)


>> The exploits are an interface problem. By eliminating the cause of the
>> problem (the ability to attempt bogus actions) you fix all possible
>> exploits in one stroke.
>
>I don't think that killing the patient is a good way to cure the
>diesease. Can we please just keep existing functionality while
>fixing the problems with it, instead of ripping out functionality
>as a way of fixing the problems?

I don't consider the ability to attempt bogus actions a functionality but a
bug, and I think we both agree on that. What I am suggesting is a solution
that will fix these problems forever. Just like putting wrapx on the
accessor macros fixed all the wrapping bugs.

>Properly dealing with bogus actions does not (or should not)
>entail removing two actions.

I am not suggesting that. I am suggesting that a fire-at action without a
valid target should be converted into (default into) a fire-into action.
See point 3 on my agenda.

>Hans, I think a lot of our disagreement stems from which working
>definition of 'fire-into' we are using. By 'fire-into' do you mean
>fire and hit the first unit in the stack or a randomly (possibly
>weighted by size) chosen unit from the stack? Or, do you mean that
>there is a real possibility that nothing is hit even if there is a
>stack of units in the cell? I have been arguing thinking that you
>are working from the former definition, but have been urging that
>we adopt the latter one.

As I stated previously (point 4 in my agenda), I would like to change how
fire-into works. I don't like the current situation where you get a free
shot at all units in the stack for just one acp. What I would like to have
is an action where you fire at the cell, one unit is picked as the target,
and you either hit or miss that unit. The logic behind this would be that
the shell has to land somewhere in the cell, and only one unit can sit
where it lands. So yes, it would certainly be possible to do a fire-into
action and not hit a single unit.

I don't think that this a necessary preconditon for fixing the other bugs,
though. I favour a step-by-step procedure.

Hans



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