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)


On Thu, 19 Aug 2004, Hans Ronne wrote:

> OK. So your scheme doesn't distinguish between visible and invisible units.

It doesn't need to. 'fire-into' doesn't need to distinguish 
between visible and invisible units.

> That makes your whole argument about units "u1" and "u2", which was based
> on one of them being visible and the other invisible, irrelevant to the
> issue at hand (how to best model hits against stacked units).

Bullshit. And you know it. The argument about units "u1" and "u2" 
pertained to _your_ scheme and not mine. Please stop twisting 
things; it is starting to get a wee bit annoying. I am not asking 
to admit your argument was wrong; if you're too proud to admit a 
mistake, that's fine by me. But don't sit there and take what I 
say out of context and attempt to distort it. I will not let you 
win an argument that way.

Only visible units can be targeted by 'fire-at'. The only way to 
have a chance to hit an invisible unit should be by using 
'fire-into', and the chance of hitting an unit (visible or 
invisible) with 'fire-into' (unaimed fire) should not be the same 
as with 'fire-at' (aimed fire).

> The problem with visible and invisible units having the same hit-chance is
> something that we will have to fix regardless of what model we use for the
> fire-into action. It could all be handled by tables, as already discussed.

Right.

> We should not make things more complicated than they have to be by
> introducing other units and their sizes into the hit-chance calculations
> for a given unit.

Without the introduction of an additional table or property, it is 
highly unlikely you will find an acceptable solution to the 
problem.

> Good. Let's forget about bringing the sizes of other units into the
> hit-chance calculations, then.

If by sizes, you mean the target area suggestion that I had, then 
maybe you should think a little bit more closely about it. It is, 
in fact, equivalent to introducing an 'indirect-fire-hit-chance' 
table or whatever the f___ you want to call it.


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