Firing through friendly vehicles

[Fuerte]

I noticed this in CMBO and now in CMBB. My tanks are able to see enemy tanks through my own tanks, and even fire through my own tanks like they were not there. Not very realistic?

I saw in the CMII thread a request for dynamic LOS, maybe this is the same thing, except that not only LOS but also firing should be checked properly.

[Tanaka]

That is an old one, where have you been? :eek:

Anyway, welcome back

[RSColonel_131st]

Its kinda funny...as soon as you blow up a vehicle and it's burning, no more LOS trough it.

Wouldn't that offer itself as a quick fix?

[rune]

No it woild not. As stated a few hundred times, the LOS checks are computer intensive. to track the shell of every unit, would require a super computer. Shell flight was not tracked due to the major hit the processor would take. The reason the burning vehicle stops the LOS is smoke.

Rune

[Other Means]

transparent smoke from all vehicles? with a boolian to say whether to render it?

but i suppose that would make tanks seem as tall as the smoke plume to the AI, which would be more difficult to detect for the average player but would also doubtless result in a "fix the 40m tall tanks or sumfink" thread.

[hardcampa]

Originally posted by rune:

No it woild not. As stated a few hundred times, the LOS checks are computer intensive. to track the shell of every unit, would require a super computer. Shell flight was not tracked due to the major hit the processor would take. The reason the burning vehicle stops the LOS is smoke.

Rune

Eh?

Shells not tracked? Of-course shells are tracked in CMBB/CMBO. Collision checking of vehicle models though, that may not be done. Beats me why though as collision checking on polygon levels are done in many FPS games with lots of objects.

But CM still owns.

[ February 14, 2003, 07:05 AM: Message edited by: hardcampa ]

[rune]

Wrong. The flight path of the shell is NOT tracked. Terrain is checked, but the actual flight track is not followed due to the hit the processor would take. This has been stated several times on the board. Yes, invisible smoke would block the entire height, and personally, I'd rather have the unit fire then be block sue to this invisible smoke.

Rune

[hardcampa]

Originally posted by rune:

Wrong. The flight path of the shell is NOT tracked. Terrain is checked, but the actual flight track is not followed due to the hit the processor would take. This has been stated several times on the board. Yes, invisible smoke would block the entire height, and personally, I'd rather have the unit fire then be block sue to this invisible smoke.

Rune

I stand corrected if that's the case

Still don't see why that would take so much cpu power though as it would be like shooting a ball from the gun towards the target and do the math on that. There must be some other projectile calculations involved that are hard which I fail to see.

[RSColonel_131st]

I'm not talking about tracking every shell, but that smoke thing could be used to block LOS trough other vehicles. Once LOS is blocked we dont have the problem of firing trough them either.

Of course, it could really be a problem when tanks become 40 meters tall. But it would put so much more emphasis on combat formations and tactics.

[Ace Pilot]

Isn’t there a big difference in processing power required for calculating LOS on stationary objects as compared to moving objects? Currently, a smoking vehicle never moves, so you can treat it like any other object that blocks LOS. Putting “transparent, LOS-blocking smoke” on a moving vehicle will require the processor to constantly calculate how that moving object affects LOS. Is that the problem?

[Mies]

Isn't the position of friendly vehicles just as relative as a patch of woods with only a couple of trees and 12 men squads where you only see 3. When I fire through my own vehicles I just imagine that it flies just past it. The whole thing is abstracted, am I right?

Mies

[aka_tom_w]

Originally posted by rune:

Wrong. The flight path of the shell is NOT tracked. Terrain is checked, but the actual flight track is not followed due to the hit the processor would take. This has been stated several times on the board. Yes, invisible smoke would block the entire height, and personally, I'd rather have the unit fire then be block sue to this invisible smoke.

Rune

Rune in correct

THere was a GREAT thread in which Steve Posted about "Method #1 and Method #2"

I cannot find the thread now.

But what Rune said is correct.

can anyone find that old thread in the CMBO archives about Method #1 trajectory calculation vs Method #2 calculations?

Thanks

-tom w

[aka_tom_w]

got it:

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

Here it is..

The MotherLoad with comments by BTS .....

Read the posts closely about Method 1 vs Method 2.

This game was abstracted from ideas and tank battle simulations like in the old Avalon

Hill game Tobruk.

Due to CPU limitations we are told that live AFV's cannot block LOS, this is not news.

Here are the relevant threads:

All new players to this game should read them:

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

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

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

"Big Time

Software

Moderator

posted 04-29-2000 02:17 PM

I see what Lt. Bull is asking. Easily cleared up (I hope )...

There are two ways, in theory, that we could simulate a round leaving a

gun, its eventual path, and where it lands:

1. Use a whole bunch of variables (like weapon accuracy, guner

training, suppression, etc) to determine a trajectory to the target. The

trajectory would then be "traced" and wherever the shell hit damage

would be done. If the hit whacked a vehicle then CM would go through

all the armor pentration stuff to figure out what the impact did.

2. The trajectory itself is only a binary LOS calculation. Either the

shooter can, in theory, get a round from the gun to the target or it

can't. A whole bunch of constant and situationally unique variables (like

LOS quality, weapon accuracy, guner training, suppression, etc) to

determine the chance of the target being hit. If it is a hit then various

equations determine where and HOW (angles) the shell strikes its

target. Then damage is calculated based on the physics for the

particular situation (HE blast near infantry, AP shot hitting sloped

armor, etc). If the round is a miss there are equations to determine

how badly the shooter missed based on several variables (i.e. a bad

unit will miss by a LOT greater margin than a good one). Then the shell

trajectory is calculated to the predetermined location (either the hit or

miss one). Colateral damage is calculated based on the detonation of

the round where it hits. Terrain is checked along a "miss" vector to see

if it strikes something along the way. Hits don't need to check because

they have already been calculated to be hits based on a clear line of

fire.

WOOOOO!! That took a little longer to explain than I thought

OK, now what are the real world difference between the two...

Method 1 -> as real as you can get! Unfortunately, it is also a CPU

cruncher from Hell. If we had one or two vehicles shooting in more

sterile conditions it wouldn't be a problem. But when you have letterally

dozens of shots being made on a somewhat average turn, this

becomes a HUGE problem.

Method 2 -> On average will come up with the same results as Method

1, but only spews out a realistic number of calculations on the CPU to

crunch. What you lose is the ability for the shell to accidentally strike

something between A and B other than terrain. As the link Iggi gave

will explain a bit more. Thankfully, the cases where this matters are few

and far inbetween.

So there you have it Method 1 and 2 yield pretty much the same

results, with the exception of variable blockage (i.e. vehicles). Oh, well,

the other difference is that Method 1 would make CM tedious to play

and Method 2 works just fine.

(tom w opines: I interpret this to mean that Steve is saying that CM was designed to use

Method 2 to save time to process or "crunch" the result of the round being fired, hence it

does not, and cannot account for live or dead vehicles which are not smoking and burning

in between the shooter and the target. It should also be noted that Pillboxes and bunkers

are treated as vehicles and do not offer any form of cover and do not block LOS or LOF).

When you get CM take a dozen vehicles for each side, plop them on

opposite sides of a level battlefield and see how slow the turns

calculate. Now do that until one side is wiped out and you will notice

how much faster each turn becomes with the elimination of each

vehicle. Then remember that this is using Method 2 in sterile conditions

with no blocking terrain or vehicles (especially not ones in motion!!) to

bog down the LOS calculations.

Steve

P.S. Grazing fire for MGs is in fact simulated. Charles found that the

math to simulate just this one feature wasn't too horrible for the CPU

to deal with.

[This message has been edited by Big Time Software (edited

04-29-2000).]

[rune]

Thanks for reposting that Tom.

Reward, a evil Rune scenario will be heading your way. You may begin screaming...

Rune

[Fuerte]

Originally posted by Ace Pilot:

Isn’t there a big difference in processing power required for calculating LOS on stationary objects as compared to moving objects? Currently, a smoking vehicle never moves, so you can treat it like any other object that blocks LOS. Putting “transparent, LOS-blocking smoke” on a moving vehicle will require the processor to constantly calculate how that moving object affects LOS. Is that the problem?

Currently the turn calculation takes under 10 seconds on a 1 GHz CPU (of course depends on the scenario), this seems very quick to me, and I wouldn't mind a 20 second calculation if it did this dynamic LOS. Or 30 second. Should do the building LOS correctly as well. But this affects the plotting response as well, it jumps even now, it would be much worse I guess.

[aka_tom_w]

Originally posted by Fuerte:

</font><blockquote>quote:</font><hr />Originally posted by Ace Pilot:

Isn’t there a big difference in processing power required for calculating LOS on stationary objects as compared to moving objects? Currently, a smoking vehicle never moves, so you can treat it like any other object that blocks LOS. Putting “transparent, LOS-blocking smoke” on a moving vehicle will require the processor to constantly calculate how that moving object affects LOS. Is that the problem?

Currently the turn calculation takes under 10 seconds on a 1 GHz CPU (of course depends on the scenario), this seems very quick to me, and I wouldn't mind a 20 second calculation if it did this dynamic LOS. Or 30 second. Should do the building LOS correctly as well. But this affects the plotting response as well, it jumps even now, it would be much worse I guess. </font>