LOS, LOF, units, and you!

[Battlefront.com]

Oh, missed this

There is just an initial check and after the departure of the bullet, it is certain that it will strike the target, even if a moving LOF obstacle ,meets the bullet on the way.

This is going to be rare and the designers feel that this "anomaly" is not going to be present often and players will hardly notice it.

This is the way it is in CMx1 as it is right now. I'm not sure it will be any better in CMx2. Hopefully, but I don't think so. At least we can't do this for small arms and everything else on top of it.

Steve

[aka_tom_w]

no one has discussed wait times for the crunch very much.

Originally posted by Drusus:

Few things:

1. I think that when people are saying that FPS games need to do the checks realtime I think they miss one important point: If CM does the checks in realtime it means that the computing of the turn will take 1 minute. Are you sure that average customer is ready to wait 1 minute? Ofcourse there are a lot of other stuff that fps games do in realtime but also, there are a lot more units to check in CM.

Now, there are 60 units maximum in FPS games. Lets assume that every unit takes 4 units of ram for the LOS checking. Now, the used ram is 60x4= 240 = maximum acceptable ram usage. Now, assume that in CM it takes 1 unit of ram for every unit. Now the amount is 200x1=200 -> OK! But if every check takes 4 units of ram you will use 800 units. This is WAY over the limit. Now you will be badly swapped, and this means unnacceptable performance. I assumed that the amount of checks is doubled if the amount of units is doubled. It is very well possible that this is wrong. But if it is wrong, the amount of checks in CM will be higher, not lower.

2. I don't know much about coding, but there is one point Id like to ask. Smoke cuts LOS in CM. How is this done? Is the LOS map recalculated every time when smoke goes "on" and "off"?

If the game has better collision detection and more high fidelity combat resolution AND better Armour penetration calculations then MOST realtime time games how is it that most turns crunch in under one minute? (if that is true)

If this game happened in Real Time is it true to suggest every one minute turn would crunch for 1 Minute?

I don't think so

Is 1 minute really too long to wait for the crunch? (I don't think so)

(no one has really answered that here.)

For those of us seeking a more high fidelity collision detection model the wait time for the crunch would have to be longer.

BUT how much longer?

still wondering

-tom w

[ September 08, 2005, 04:45 PM: Message edited by: aka_tom_w ]

[aka_tom_w]

The post that started this thread off is very interesting and I have read it over more than a few times, but no where in that post does Steve address the variable of "Time to Crunch the turn". No comment on length of time to crunch.

If my understanding is correct better collision detection "could" be had at the cost of longer wait times for the crunch, but so far there has been no real discussion of the possibility or option in this thread.

Perhaps I am mistaken. (longer crunch times will NOT in fact yield a more high fidelity collision detection model.)

-tom w

Originally posted by Battlefront.com:

This is a general explanation of the differences between LOS and LOF, both from the player's perspective and from the code's. The reason for this post is to clue you guys in to why there can be support of one but not the other.

snip

One thing someone will ask about... the effects of deformed terrain on LOS. Well, from what I understand the periodic updating of already known data structures, simply to change their LOS related properties, is doable. That means you can reduce a building and now have LOS through it when before you did not. Even CMx1 supported this, though with a lot less terrain to be considered. I am pretty sure that Charles can allow deformable terrain to have an effect on CMx2's LOS/LOF. At least I assume so since I haven't asked him directly in a long time.

Steve

[ September 08, 2005, 05:20 PM: Message edited by: aka_tom_w ]

[Michael Dorosh]

[ September 08, 2005, 10:12 PM: Message edited by: Michael Dorosh ]

[pamak1970]

Which basically amounts to the way we have it in CMBB/AK... rapid target switching and "collateral" effects.

Either i was misunderstood or i have not understood the response

I understand this limitation and i do not propose any change in this method of simulating grazing fire(collateral damage through rapid target switch).

My focus is not in simulation of trajectory.

It is more narrow .

It is about the way AI chooses now targets to switch fire for "collateral" effects and simulate grazing fire.

From what i read in the current state the AI does make multiple LOS and LOF calculations and switch fire rapidly from one target to another in order to simulate grazing fire.

So, regarding this aspect of LOS and LOF calculation for multiple targets,we already have the technical ability to do so.

What i point ,is that this choice of targets should be altered a little bit in order to follow a "geometric pattern".

This "geometric pattern" of the choice of targets will give the "feeling"- "illussion" of a "psuedo-trajectory" effect.

For example,

Imagine a line formation of two squads- (two squads beside each other) ,with each squad seperated from the other by 50 meters attack a MG directly in front.

In CMMB or CMAK, AI might simulate grazing fire by switching fire between these two squads .

This is a problem cause in reality these targets deployed in such a manner can not be affected by grazing fire effect.

On the other hand, if a column formation of two squads seperated again by 50 meters (one squad behind the other) attacks the same position,then the MG can produce grazing fire effect .

So the way i see it, the choice of the targets should be more restricted.

The MG and all affected targets should be approximately along the same geometric line in order for the former to switch fire and apply collateral damage to the latter,as a bonus of grazing fire effect.

So the additional calculation in my case,is not about LOF determination or LOS.

These things are calculated in the same way it happens now.

The additional calculation is about the determination of the additional requirement i expressed earlier.

That is, the MG and all targets should be along the same geometric line (or better if the determination is about if they are all inside a very narrow "firing arc") .

If they are, then grazing fire is executed in the same way it happens now and both targets are affected, if they are not then there is no grazing fire and only one target is affected.

Under these conditions, it will make a big difference in the game if a MG fires oblique or flanking fire towards the approaching line formations.

In the above example of two squads side by side ,the best position for a MG is to be and fire from the flank.

Only during that case , the requirement of having MG and both squads along the same geometric line, can be fulfilled.

The most common situation would be to have squads side by side ,but still they will not be at the exact same level.

So even oblique fire can satisfy the geometric requirement, while frontal fire will not be able to do so.

Under these conditions ,players will have an advantage in deploying MG in a more realistic manner.

So we will see MGs of the right sector aiming diagonally towards the left and Mgs of the left sector aiming towards the right , creating crossfire immdediatelly in front of the defence position.

So, the question i see ,is if it is intense for the engine to calculate in addition of what is does now ,that 3 or 4 for example different points on the map belong to the same geometric line.

[ September 09, 2005, 10:28 AM: Message edited by: pamak1970 ]

[Battlefront.com]

The problem is that the system doesn't understand the concept of "all targets should be along the same geometric line". In order to do that we have to do a LOF vector trace each time the MG fires. That means every single meter inbetween the MG and wherever LOF ends (terrain or range dependent) needs to be checked. This isn't impossible to do (though I think Charles will say impractical), it's just computationally expensive.

If we were just talking about team based MGs at least that would keep the number of possible units needing this horsepower down to a few per side in most cases. But vehicle mounted MGs are quite common and have a limited ability to do grazing fire (limited because of where the MGs are positioned). LMGs, a part of almost all Squads and sometimes Teams (i.e. 2 per Squad), should also have a limited ability to do grazing fire. Not as good as a tripod mounted M/HMG, but not as limited as a vehicle MG.

The thing I said earlier about the "fan" effect is the practical implication of what Grazing fire means for a tripod mounted MG covering an open area. Unlike CMBO the MG behavior in CMBB/AK means rapid target switching happens when there are multiple targets. This means the MG has to pick out a target, LOF trace along a line, fire, switch targets, LOF trace, fire, switch targets, LOF trace, fire, etc. Check out a MG in action in CMBB/AK and see how quickly something like a HMG42 fires in a given 1 minute turn when it has adequate targets.

Anyway... I'll say it again... I am not saying we aren't going to do anything more with grazing fire, I am just not sure that it is practical. If it can be done, obviously it will be. So I don't think there is much more to add to this topic than that.

Steve

[aka_tom_w]

that's good enough for me

Just as long as MG fire causes LOTS of supression that should be close enough to keep most folks happy

the MG model in CMAK and CMBB was Much improved over CMBO

I figure CMx2 will show some more improvement again.

I would say the CMBB and CMAK model for MG supression seemed fairly realistic and well modeled in the first place.

LOF and LOS and collision detection for the heavy stuff is what I am far more concerned about. (Tank and anti tank rounds).

But thats just me, the lover of GREAT tank battles!

-tom w

[ September 09, 2005, 04:56 PM: Message edited by: aka_tom_w ]

[pamak1970]

Thank you for the effort to explain the situation.

The second response made things more clear to me.

[YankeeDog]

Great info, Steve. Thanks.

I do think the CMBB/CMAK MG modeling is a vast improvement, and on the whole works very well. While my knowledge of computer coding is admittedly limited, I can see two areas where improvements might be able to be made without incurring a massive increase in computations required:

1. Both the "Rapid Target Switch Area" and the "Supression Zone" for MGs seems to be basically circular right now -- this appears to be the case with both hard targetting, and Area Fire orders. As I'm sure you know, IRL the oft-discussed "beaten zone" is dependent on ballistics, and changes dynamically with range. I'm sure any actual calculation of a beaten zone would be a big strain to actually calculate. As a rough, one-size fits all approximation, though, I think an oval (wide axis along the range vector) would be better than the current circle. It would be even cooler if the oval got gradually more circular (shallower in range, wider in bearing) as the range got longer, but that's a bonus I can live without.

2. At short to mid ranges, the "rapid target switching" behavior you mention was a great addition to CMX1, and does IMHO realistically improve an MG's ability to deal with multiple targets, but it also greatly increases ammo consumption. While ammo usage certainly should go up do a degree (more targets = more shots fired), I think it may go a bit too far right now -- rounds fired at one target are going to be effective at other targets in the same vicinity, giving the MG(s) a degree of "ammo efficiency".

I see this as mostly a problem with lower ammo load, MG heavy units like 2xLMG-42 squads. To a degree, this is realistic -- MG42s certainly could burn through ammo. But having them burn through their entire ammo allotment in 2 minutes (which I see happen pretty often, and not even in "mad minute" situations) seems a bit excessive to me. Hopefully, with more detailed ammo and suppression modeling in the new engine, there will be some way of tweaking this a bit.

A related aspect of this with plunging vs. grazing fire, but that's another debate. . .

Cheers,

YD

[PSYOPBrian]

Originally posted by Battlefront.com:

This is a general explanation of the differences between LOS and LOF, both from the player's perspective and from the code's. The reason for this post is to clue you guys in to why there can be support of one but not the other. You can see an example of this here:

Steve

What I would like to see in the next generation game concerning LOS is this: In the setup screen, being able to be in a LOS mode where whatever terrain point is left clicked, you see 360 degrees lines extending in yellow showing LOS. In the defensive, one could then put TRPs in these dead zones for artillery. In addition, it would be nice to add claymore mines to cover these dead spaces, that can be activated during the opponent's turn. The LOS would not affect gameplay as I am only talking about the setup screen (although it would be nice during the gameplay as well).

[Zalgiris 1410]

Origionally posted by c3k

There are plenty of INDIRECT fire weapons which utilize a highly elevated trajectory specifically to fire against targets with which there is no LOS. And I'm not talking about on-call assets.

Some examples: light & medium mortars; rifle grenades; PIATs; short-barrelled infantry cannons (German & Russian 75mm IGs and German 150mm IGs) are in this category.

This category of weapons is NOT displaced far away from the firing line. They are right up front, and they can be told or estimate where they want to hit, yet they don't have to see their target. "Sergeant, drop HE directly behind that house!" You can see the house; you saw a target move BEHIND the house; you have a weapon which can arch rounds OVER the house; you have NO LOS there, yet, you CAN fire at it.

Will CMx2 support fire by units where the is NO LOS?

[Olle Petersson]

Regarding crunch times; I played CMBO with crunch times well above five minutes, if gun fire was heavy. (P2/300MHz/64MB RAM)

A one minute cruch time for a medium size battle computed on a state of the art computer seems playable, with crunch times doubled or quadrupled on lesser hardware. (Anything less than five minutes is fine with me.)

/Olle

[aka_tom_w]

Just a note on State of the art Collision detection and physics game code....

from:

AGEIA hardware for game code physics interview

Note:

"The PhysX chip utilizes the NovodeX SDK. What the chip can do essentially, is handle mass amounts of physics operations.. much more than a normal CPU can. In fact, according to AGEIA, a current CPU can handle around 1,000 active bodies, while the PhysX chip can handle 32,000 with relative ease. With future software updates, that number could get even higher."

By Rob Williams July 27, 2005

Editor: Rob Williams

AGEIA is a company with huge ideas. They plan to make our gaming experiences much more immersive with their PhysX add-in card. We sit down and chat with Andy Keane to answer some burning questions.

Back in May, around E3 time, AGEIA was responsible for a lot of buzz in the hardware industry. The world was talking about their promise to make our gaming experiences much more rich. This would come in the form of a Physics Processing Unit (PPU), called PhysX. For those who have not heard of AGEIA or PhysX before, I'll delve a little into what you can expect to see more of in the future.

Basically, AGEIA (Stands for America, Germany, Egypt, India, America) created a PhysX PPU chip, which resides on a PCB board, which will be used in your PCI slot. The PhysX chip utilizes the NovodeX SDK. What the chip can do essentially, is handle mass amounts of physics operations.. much more than a normal CPU can. In fact, according to AGEIA, a current CPU can handle around 1,000 active bodies, while the PhysX chip can handle 32,000 with relative ease. With future software updates, that number could get even higher.

Most of us who have played through games like Half-Life 2, realize how much good physics can add to the experience. If we rewind back to last year and had the AGEIA on hand then, we can imagine what the chip could have done to add to the experience even more.

There are a lot of skeptics out there though, and I for one, am one of them. What AGEIA promises to do, is quite extraordinary, and if they get the right support, which seems great so far, then this could be an add-in card that hardcore gamers cannot do without.

In gist, the PhysX card will allow for a much more rich gaming experience, due to the much larger physics capabilities. Hopefully down the road, more and more developers will pick up on this and make use of the NovodeX SDK. Currently, such companies as Shiny, Ritual, Cryptic, NC Soft and Epic have jumped on the bandwagon and plan to use the PhysX technology in their games. Even announced recently, the Sony Playstation 3 will be taking advantage of the NovodeX SDK as well.

What we know about the card specifications up to now is, that it will have 125,000,000 transistors, and a 182mm^2 die size. It uses a respectable 0.13µ process, and uses approx. 28 watts of power. Lastly, it will be equipped with 128MB or GDDR3 memory. In the picture to the right, you can see the overview of the card. You'll notice that it's dual sided for PCI-E and PCI. This will not be in the final card, but is only available in the developers version.

With all the information about the PhysX chip already, there were still some burning questions. We had the opportunity to chat with VP of Marketing, Andy Keane, to clear up these questions. I should also note, that all the images you see in the article can be clicked on for their original size.

Techgage: Greater physics capability sounds exciting, but since most gamers will likely be swayed away from the $249 - $299 price tag, do you have any specific plans to help really grab their attention, and gain an interest to buy?

Andy Keane: Content is king, and what will sell the hardware is the games. We've lined up a great deal of content, see enclosed presentation. Also, keep in mind, that consumer prices for graphics cards, and SLI are upwards of $400.

Originally posted by Battlefront.com:

All things are a balance. If we wanted to make a game which emphasized collision detection... we sure could! No problem. There is no technical reason preventing it. But what happens when we start adding other stuff into the design? Whoops... where did all that extra CPU power and RAM go?

Think about an FPS game. Forgetting the massive multiplayer games, which use distributed computing as one of their tricks, what does a modern FPS game lack that CMx2 has to do? Spotting. That's the big CPU and RAM sucker right there. Ok, what next? Well... how about 100 or more units moving around in an environment that can be a complete mixmosh of terrain, weather, and other very detailed factors? Oh... and how about the fact that at any given time there might be 20 or 30 units slugging it out? And how about distances? What is the average engagement range in a FPS compared to CMx2? Well... that's at least the bulk of it, probably. Much of the rest of the stuff the FPS games and CMx2 have in common.

What this means is that CMx2 does all the basic stuff that a FPS game does, and a whole lot more. At least overall. How is CM able to do this? By clever programming that uses CPU cycles and memory better than people like John Carmak? No, by emphasizing different things and sacrificing some things for the good of others. Just like FPS games do. For us we have to cut back on LOF, for FPS they cut back on units, distances, other stuff, and most importantly spotting. So their games are geared towards shooting stuff in a small space, ours are geared toward battlefield tactics. Same hardware, but maxed out to produce different results.

Steve

[hoolaman]

I don't think anyone has mentioned the implications for firing through friendly formations.

It seems like LOF/Grazing fire would be worth including from a friendly unit point of view. It's a pretty big realism issue to be able to fire through your own formations at an enemy as in CMx1.

And if it is done so you can't fire through your own men without cutting them down, it is the other side of the same coin to make offensive grazing fire possible.

So I think the benefits from including calculations along the LOF are worthy of inclusion, especially for small arms/automatic weapons. I hope everyones favourite disembodied brain can come up with a shortcut to get it in there.

[Michael Emrys]

I've been asking for this for ages, Hoolaman. I join with you in hoping it will get in there some time some how.

Michael

[aka_tom_w]

again the discussion could come back to wait time for the crunch.

Steve and Charles have not officially commented BUT if the game does ALL the LOF caluclations for MG's the crunch time will be longer.

I completely disagree with any suggestion that LOF calculations for MG fire cannot be done. The game code "could" be written to do LOF fire for ALL MG's BUT the cost in wait time on the crunch would likely be considerable.

If LOF calculations where an optional setting like FOW settings that would likely please everyone except Steve and Charles as they might need to take ANOTHER 3 - 6 months at least, (just a guess :confused: ) to release the game.

In fact, according to AGEIA, a current CPU can handle around 1,000 active bodies, while the PhysX chip can handle 32,000 with relative ease. With future software updates, that number could get even higher.

My post above gives an indication of what is needed to for physics and computationally intensive (LOF and LOS checks) game code to run quick or at "acceptable" speed. Their answer is the PPU which is yet ANOTHER piece of NEW hardware the gamer would need to buy. The card is a Physics Processing Unit (PPU), called PhysX.

My guess is Steve and Charles would NEVER go for this.

WHAT???

:eek:

You want to play CMx2??

FIRST you need a ton of VRAM (more than you have now likely)

AND

and you will need a Physics Processing Unit (PPU), called PhysX for about US $300.

OK!

Woo HOO! Now you are set, and all your LOS, LOF, FOW wet dreams can come true in a relatively short wait time for the crunch so you can play and have fun, IF you have a FAST computer!

(How does that sound??)

Like Steve has already said the whole game code development process is a GREAT big balancing act, PBEM has already been quoted as a factor for possible NON-inclusion. LOS and LOF requests for MG fire (While I support that request) are sure to mean some other negative side effect, either longer time to release the game or a longer time to crunch the turn (wait time) or BOTH!

I don't think we will see much improvement...

-tom w

[ September 14, 2005, 11:16 AM: Message edited by: aka_tom_w ]

[aka_tom_w]

good point

" I don't think anyone has mentioned the implications for firing through friendly formations.

It seems like LOF/Grazing fire would be worth including from a friendly unit point of view. It's a pretty big realism issue to be able to fire through your own formations at an enemy as in CMx1."

-tom w

Originally posted by Hoolaman:

I don't think anyone has mentioned the implications for firing through friendly formations.

It seems like LOF/Grazing fire would be worth including from a friendly unit point of view. It's a pretty big realism issue to be able to fire through your own formations at an enemy as in CMx1.

And if it is done so you can't fire through your own men without cutting them down, it is the other side of the same coin to make offensive grazing fire possible.

So I think the benefits from including calculations along the LOF are worthy of inclusion, especially for small arms/automatic weapons. I hope everyones favourite disembodied brain can come up with a shortcut to get it in there.

[tar]

I agree with the Reindeer Cavalry. I think that a major missing tactical element is the need to consider keeping lines of fire clear. That's why the height of tactical brilliance is the "L-shaped" ambush and not the "U-shaped" ambush.

In CMx1, a U-shaped ambush works much better than an L-shaped one. In the real life it doesn't. Ideally in CMx1 you would actually completely surround a unit and fire into the center, a military formation which is usually described as an <insert offensive ethnic reference> firing squad.

One should have to keep the line of fire clear. For purposes of this check, I think there are a number of algorithmic shortcuts that can be used. Given the relative speed of projectiles versus unit movement, there does not need to be a check on the millisecond level. It should be possible to establish a 3D rectangle-shaped "danger zone" and just consider possible effects for the generally very limited number of units in that zone. A full LOF check would only be needed against that small number of units.

Besides, if this feature is actually present, then there will be even fewer occasions when it would be needed, because the players will avoid situations where the LOF crosses friendly units. (Of course that may be offset by the attempt to setup such situations with respect to enemy units.)

In any case, I think the tactical ramifications of firing down a line or column of enemy units, as well as the need to keep the lines of fire clear will be a great advance in simulation fidelity which will affect the in-game tactics.

[aka_tom_w]

Originally posted by tar:

I agree with the Reindeer Cavalry. I think that a major missing tactical element is the need to consider keeping lines of fire clear. That's why the height of tactical brilliance is the "L-shaped" ambush and not the "U-shaped" ambush.

It sure would be GREAT if they could find a way to realistically simulate this in CMx2.

Steve says:

Battlefront.com

Administrator

Member # 42

posted September 05, 2005 09:48 PM

All things are a balance. If we wanted to make a game which emphasized collision detection... we sure could! No problem. There is no technical reason preventing it. But what happens when we start adding other stuff into the design? Whoops... where did all that extra CPU power and RAM go?

but I think we might not be seeing anything like that in CMx2

-tom w

[ September 16, 2005, 09:14 AM: Message edited by: aka_tom_w ]

[tar]

I'm beginning to wonder if Steve is making some of the problem a bit too difficult, although that may depend on the particulars of how the LOS computation is made and, more importantly, represented.

As it stands now, an LOS computation will be made to determine whether things are in sight or not. Now if this LOS check, if unblocked were recorded in such a manner that it was easy to find all LOS vectors close to the one chosen to shoot along (say by maintaining azimuth and elevation from spotter?), then the potential targets for the danger zone would also be identified.

(OK, there is a cover vs concealment issue hiding in here, but I'll skip that for now.)

It seems to me that the information required to check for danger in the line-of-fire is largely already present in the game computations. I guess the only caveat (which could be a killer, BTW) is that this requires also doing LOS checks against friendly units and not just against enemy units. And since that is an N-squared phenomenon, it would require 4 times a long.

But with some cleverness, this could be reduced. Operating under the assumption that most lines of fire would, in fact, be clear, one could have the TacAI make a provisional fire decision and then doing a more limited check along the line of fire That would greatly reduce the number of friendly units to check. If too many (any?) friendly units are in the danger zone, then consider abandoning it and substituting the second most favored target.

[Battlefront.com]

As it stands now, an LOS computation will be made to determine whether things are in sight or not. Now if this LOS check, if unblocked were recorded in such a manner that it was easy to find all LOS vectors close to the one chosen to shoot along (say by maintaining azimuth and elevation from spotter?), then the potential targets for the danger zone would also be identified.

True. This is how MGs are simulated in CMx1. The problem is, there is no line being traced from the source to any of the other affected targets. Therefore, we aren't simulating the side targets actually getting shot at. Just having a suppression effect from MG fire coming in their geneal direction. To start hitting these neighboring units we would have to do direct LOF checks because how pissed would you be if you were losing guys who were adjacent to the targeted unit but themselves were not in LOF with the shooter?

Friendly units does indeed make for a whole nother problem.

Operating under the assumption that most lines of fire would, in fact, be clear

We can make no such assumption. The system must assume that these lanes are clogged with enemy and/or friendly units. It must also assume there needs to be a unique lane from the source of fire to the ultimate destination of it.

It's a real hardware killer situation no matter how you slice it.

Steve

[tar]

On the first issue, doesn't relative spotting mean that you've already done a LOS computation on those neighboring units? I would think that having an LOS would imply that an LOF exists (discounting some truly limited circumstances where the divergence between LOS and LOF comes into play. I would think this could be safely ignored.) On the other hand, LOF may exist when LOS doesn't. Hiding in tall grass or behind smoke, for example. That does pose a potential problem with not being able to have LOS do double duty as LOF, although one could potentially compute both by continuing the computation once if only concealment was encountered and not actual cover. This would be a sub-linear increase in computation and thus should scale reasonably well.

Steve, I think there was a miscommunication about the assumption of the LOF being clear. I meant that in most cases that come up, the LOF will not have the blockage, so having a cheap test to confirm this would mean there would be no need to do a detailed test. The idea is that for any given LOF there would only be a small subset of units, friendly or enemy, which would even need to be considered as being potentially in danger.

The friendly units issue is, IMO, the real killer.

[Battlefront.com]

The problem is that LOS checks are not done as frequently as needed for LOF. LOF must assume that the target is in motion and therefore not necessarily in LOF. Even a few split seconds can make a difference there. So LOS can not substitute for LOF.

More importantly, LOS really only means that you know where the unit is, not necessarily that you saw it yourself. With Absolute Spotting most units were spotted by someone else. With Realtive Spotting it isn't that different from the assumption standpoint, just more likely the enemy unit is known through direct LOS.

Steve

[London Calling]

Apologies if some might consider this slightly *off* topic, but how will the new engine handle large calibre rounds that are fired DF (AP shot/shell/HE) that miss their target? As I understand it at the moment, shots that miss their target fall in a arbitrary random position *somewhere* around the target; will the new engine take into account line of flight considerations to determine where a shell lands?

[hoolaman]

Originally posted by tar:

The friendly units issue is, IMO, the real killer.

I don't really understand the implications of what Steve is saying, (is it me or is last post extremely confusing?)

Anyway I agree with the above quote, and I hope that friendly LOF considerations can be implemented. I think it is not really an "icing on the cake" issue but one fundamental to a good war sim game engine, especially, as someone said, if the engine is expanded into ranked combat.

Originally posted by tar:

The Ideally in CMx1 you would actually completely surround a unit and fire into the center, a military formation which is usually described as an [insert offensive ethnic reference] firing squad.

I think this quote sums up what shouldn't be in the new game!

[ September 21, 2005, 04:36 PM: Message edited by: Hoolaman ]