Hit on moving vehicel out of LOS

[Scipio]

Just something I noticed today - a Sherman fires on a moving tank and hits it - altought the target has moved out of LOS in the time between the shot and the hit. I assume this is a known bug and will be corrected in CM:BB?

[Schrullenhaft]

Known bug.

Being corrected in CMBB... I'm not sure. I believe that there will be some steps to minimize this occurance, but I don't think that it can be completely corrected with the current engine.

From what little I can recall of previous conversations about it the engine determines LOS at the beginning of the turn (assuming that the shot is to take place within seconds of the turn starting) for shots that are going to take place within a few seconds into the turn. If the object wasn't moving at the time of the calculations, then I guess it is considered to remain in LOS. If an object starts to move out of LOS after the shot calcs are done (during the shot) then it may still get hit, though it may be out of LOS when it does get hit.

I'd guess this issue has something to do with the 'granularity' of the engine's calculations for each second of the turn. It would have to plot the 'potential' movement of each unit and then recalc LOS for each second of the turn - something I assume isn't actually happening with the current engine.

I'm only guessing at what is going on and what limitations may be in place to prevent a full fix of this issue (though Charles may come up with something anyway). I remember that aka_tom_w started a lengthy thread in the past about this subject (last summer ?). So you may want to search the 2001 archive for some more definitive answers.

[aka_tom_w]

Originally posted by Schrullenhaft:

Known bug.

Being corrected in CMBB... I'm not sure. I believe that there will be some steps to minimize this occurance, but I don't think that it can be completely corrected with the current engine.

From what little I can recall of previous conversations about it the engine determines LOS at the beginning of the turn (assuming that the shot is to take place within seconds of the turn starting) for shots that are going to take place within a few seconds into the turn. If the object wasn't moving at the time of the calculations, then I guess it is considered to remain in LOS. If an object starts to move out of LOS after the shot calcs are done (during the shot) then it may still get hit, though it may be out of LOS when it does get hit.

I'd guess this issue has something to do with the 'granularity' of the engine's calculations for each second of the turn. It would have to plot the 'potential' movement of each unit and then recalc LOS for each second of the turn - something I assume isn't actually happening with the current engine.

I'm only guessing at what is going on and what limitations may be in place to prevent a full fix of this issue (though Charles may come up with something anyway). I remember that aka_tom_w started a lengthy thread in the past about this subject (last summer ?). So you may want to search the 2001 archive for some more definitive answers.

Good memory there Schrullenhaft!

I suspect the thread you are refering to is this one:

http://www.battlefront.com/discuss/Forum1/HTML/013403.html

BUT that thread I started was about tanks shooting through houses and NOT moving.

The other thread that is more relevant to the original post here is this thread:

http://www.battlefront.com/cgi-bin/bbs/ultimatebb.cgi?ubb=get_topic;f=16;t=017277

In this thread Steve quotes specifically about this very issue and the explanation is quite detailed!

Steve's quote appears on this page:

Steve's quote on hitting targets moving out of LOS

(it is easier to read on that page then here the way it was cut and pasted into this thread sorry)

Here is Steve's Quote from that Thread:

Big Time Software

Administrator

Member # 42

posted March 14, 2001 03:53 PM

Subvet wrote:

quote:

It would be nice if BTS would respond, even if it was a "yeah it's a bug, and you'll have to live with it because we aren't

going to fix it."

We have said this a few times before. There are inherent limitations in the game engine that we can't practically fix. it is NOT a

bug, rather a design limitation. We have answered this many times before, but for some reason our repeated explanations don't

seem to be understood by everybody. The problem with this thread is that people are mashing things all up, which is only

confusing people more. All sorts of different visual outcomes are being attributed to DIFFERENT possible causes, when in fact it is

the same thing causing all of them. It is really simple so I don't understand why some people are having such a hard time

grasping this...

In the real world a round leaves its gun and travels until it impacts upon SOMETHING. That SOMETHING can be the target, a

building next to it, or anything that happens to be directly in the flight path. With me so far?

Now, Combat Mission has two different limitations that kick in to the above. The first is that when a unit is shot at NO FLIGHT

PATH IS CALCULATED. Instead, probability of a hit is calculated using a vast number of factors relevant at that particular

millisecond.

If the a "hit" is scored then the round is graphically shown to fly and whack the target. If the target and/or the shooter are

moving, there is a graphical chance that it might be behind something at the time it is hit.

If a "miss" is determined, the engine semi-randomly assigns the round an impact location (think of it as a "hit" defined above) and

the shell graphically hits that location. Just like with a "hit", the impact location can be in a place that doesn't graphically make

sense. However, a "miss" will check out intermediate blocking terrain because it can not be assumed that there is LOS/LOF to the

miss impact location, unlike with a "hit".

The other problem is that the flight path of the round is not looking for random elements that might be in its way. This means

vehicles or units in general. It even includes knocked out vehicles. It does, however, take into consideration static terrain like

buildings and ground (slopes). Set up your own test ranges and you will see rounds impacting on these things all the time.

Basically, if the shot was determined to be a "hit", it is a "hit" regardless. Since LOS/LOF is requires when the shot is taken, there

is no need to check intermediate terrain at all since by definition LOS/LOF rules out intermediate terrain blockage. At least at the

second the shot is fired.

Zahl appears to understand this fairly well. Here is what he had to say above:

quote:

The most logical explanation is that CM determines hitting and missing at the instant of firing, based on the conditions

that applied at that very moment. If it was a kill, whatever the target might be able to do during the following seconds

can't save it. It might drive behind a hill, behind buildings or woods, but the shell travels mercilessly through any

obstacles and kills the target, because this was predetermined.

This is no LOS issue. The shooter needs to have LOS at the moment of firing, but after that it is irrelevant.

Correct.

quote:

Apparently projectile collision detection is already implemented since they can unintentionally hit buildings when you

are trying to shoot something else.

True for misses, since hits require LOS/LOF which by definition means no blockage. But it really is just a LOS/LOF check and

where the blockage happens the round hits instead of the intended targeted area.

quote:

Possibly the only way to fix this would be to calculate trajectories dynamically when the shell is in flight.

Correct, but only part of the solution. There would also need to be a huge amount of TacAI work to simulate compensating for

leading, wind, dropage, etc. Not only does the coding for this require a lot of time, but the CPU cycles necessary to carry it out as

well. Too much to ask of us or the computer at this time.

quote:

If I remember, this was suggested before and BTS replied that it would make a difference only in exceedingly rare

cases. Like when Tank A is firing at a distant B and some third vehicle intersects the trajectory just at the most

inappropriate time.

This is correct. However, you can of course have situations where this is far more likely to happen than in others. For example, a

dozen vehicles all mixed up on a level plane in close proximity to each other. But this is not something that comes up very often,

so again the real chance of this being a factor in a game is low. It will happen, but the cure to fix the problem would kill the game.

Shooting through building corners is also related to this topic. We had to put some "play" into it because we do not track the

exact location of the gun barrel. So once again, graphical portrayal is not 100% exact. And again, the limitation is on CPU

calculations necessary for a host of game aspects (notably the TacAI once again).

Now to answer a couple of individual questions:

Jeff Dunquette wrote:

quote:

I think modeling Real WorldTM exterior ballistics and Real WorldTM LOS could go along way toward addressing some

of these game quirks.

As I stated above, partially correct. However, reducing the abstraction of this one element has a cascading impact on the rest of

the game. This means we would also have to be a refinement of all sorts of other game aspects in order for this to all work.

Unfortunately, the coding and CPU load are too much. So to get CM that last 2% realistic we would have to drop everything and

work on nothing but this issue for weeks, if not months, along with upping the minimum system requirements. Just not worth it.

quote:

Trajectory can be modeled with a function, so I don't get why this is such a big processor deal. Tank sims ala Steel

Beasts already model Real WorldTM.

Trajectory is modeled in CM, but not on the fly for every shot. I have no idea what Al did with Steel Beasts, but the two games

are different enough that it is a comparison of apples and oranges. For example, I think a game like Quake III looks to have exact

trajectories done on the fly, but there are reasons why that is possible for Quake and still not for CM. Each environment is asking

different things of the hardware, and therefore it is not possible to just say "this has it so why doesn't that".

Subvet wrote:

quote:

That's all fine and good, but then they post this: There is a basic rule in CM -> "Nothing can shoot through houses".

Put another way, in no way shape or form may any unit, regardless of what it is, shoot through house. Never. Not

even in the strangest circumstances. LOS will not be calculated through a house.

So which is it? The two statements completely contradict each other. Also remember, we are talking LOS as well as

LOF. It is one thing to talk about a round penetrating a wall, but it's another to talk about x-ray vision. I'm just trying

to get a straight answer one way or another on this; with poor results unfortunately.

You are seeing conflict between my statement and the manual only because you are not looking at the context of each

seperately. I said nothing can shoot through houses in the context of the discussion about LOS/LOF in regards to moving

vehicles, the limitations of when hits/misses are determined, and then how they are resolved. My statement was not meant to

have anything to do with rounds going through buildings, which as Tom W pointed out is specifically mentioned in the manual.

Also, "through" a house was, in the context of the initial discussion, defined as LOS/LOF being established through two or more

walls of a building. So there is NO conflict between my statement and the manual.

Now... the only INTERESTING thing I see in this thread is the picture posted by Tom W. A vehicle should NOT be able to do that.

Judging by the location of the vehicle the proximity to the house is the reason. In other words, flush up against the side of the

house. So I tried to reproduce this in the Editor. I set up a test scenario and had very, very hard time reproducing it, but did in

fact manage to put a vehicle in a spot where it could look straight through a house. It is obviously some sort of "sweet spot" as I

couldn't get other vehicles to do it no matter how many times I repositioned them. I am having Charles take a look into it as this

should not happen. Note that this probable bug appears to be limited to the exact placement of a vehicle flush up against a

house, and therefore is not relevant to the rest of this thread.

I hope this clears up the questions that are (still) lingering about this LOS/LOF issue.

Steve

[This message has been edited by Big Time Software (edited 03-14-

2001).]

and

from this page:

http://www.battlefront.com/cgi-bin/bbs/ultimatebb.cgi?ubb=get_topic;f=16;t=017277;p=4

Big Time Software

Administrator

Member # 42

posted March 16, 2001 02:44 PM

Philistine wrote:

quote:

Rather than checking the shell in flight for intervening objects, would it be possible

(easier) to have a 2nd LOS check on the target after an amount of time equal to the shell

flight-time has passed? If there is no longer a LOS (target is behind cover) it is treated as

a miss. Otherwise the normal hit procedure is followed.

Well... I didn't mention that we thought of this about a month ago and it is on The List for possible

inclusion in CM2. The reason I didn't mention it is because we aren't sure if it can be done using a

reasonable amount of time and coding. I mention it now because it looks bad if we don't respond to a

good idea that we (me... ) already came up with a while ago Kudos to Philistine for thinking of it

though!

IF we can do it, most problems will go away. But NOT all. The only way to ensure that firing results

are 100% accurate is to trace the flight path of a smartly aimed shot (i.e. simulating gunnery and

results to the nth degree). There is no computer in any player's posession that could hack that, not

to mention the coding time it would take. So the 100% option is completely out of the question. But

this second check idea might get us to 100% accurate results 98% of the time. Dunno how much it

will improve things, really, but it potentially should definitely get rid of the most obvious inaccuracies

currently allowed for.

Overall, we still don't see this as a HUGE problem. Again, check out how many shots you disagree

with over a long period of time and using a great variety of maps. It simply is not common, and

therefore doesn't register as a HUGE problem. It is a significant one, though, and if we can do

something somewhat painlessly we will certainly do so. The future engine rewrite will be a much better

system for sure, so things will be improved at some point.

I also agree with Joe Private that although Tom tries to use this tactic as often as possible, I for one

don't think he is automatically getting some sort of one-sided bonus regullarly enough to make this a

viable "cheating" tactic. Hunting the way Tom describes and hunting in general work the same way.

Does he get an edge sometimes? Maybe, but probably no more than if he was using hunt in some

other situation. And there are drawbacks to getting up close and personal to a building.

For example, in my tests I found that you can only look STRAIGHT through the building, and of

course only if you drive right up to it. If something were to flank the vehicle in question it would be at

a disadvantage compared to if it had been a few meters back and toward the edge of the building.

Just one example of why this tactic of Tom's isn't necessarily as great as it might look. Still, we are

looking into how we might be able to fix this problem since it shouldn't be allowed at all.

Steve

[This message has been edited by Big Time Software (edited 03-16-2001).]

-tom w

[ May 10, 2002, 11:05 PM: Message edited by: aka_tom_w ]

[Scipio]

Aha, thanks.

I must confess, I have noticed this for the first time within 19 month, so I can agree that it is a rare incident.

There are surely more important issues - like the ability to hit on the move, what is - for a WWII tank - extremly difficult in reality, with or without gyros.

Modern battle tanks can do this, but they have very complicated and extremly expensive fire guiding systems. The price of the fire guiding techiques makes up to 40% of the price for the complete tank LeopardIIA6, for example!