A bit confused about how LOS works sometimes...

[Battlefront.com]

BTW, a correction to earlier posts...

All Action Spots are checked out against each other ahead of time, before the game is played, to see which ones can see each other. These checks are done from each Action Spot center to every other Action Spot center. This information is then stored in RAM in an array so it can be efficiently searched for each individual (not unit) in the game every few seconds. Any math wizards here want to tell me how many checks an 800x800m requires (Action Spots are 8x8m) for the initial map? Anybody want to hazard a guess what 1000 individual spotters require for checks every couple of seconds? Any programmers here want to guess at the RAM footprint of a 1m resolution LOS Map is?

Back to the description...

When a unit is in a particular Action Spot the system already knows what it can theoretically see AND (even more importantly) what can theoretically see it. This cuts down runtime LOS checks by several orders of magnitude. Without this pre-compiled LOS information you'd see a slideshow (in RT) turn compile times that would encourage naps (in WeGo). That's reality and we have to live with it. There's no way around it.

When Friendly Unit A's Action Spot can theoretically see Enemy Unit B in its Action Spot, then the system works to determine if either actually sees the other. This is Spotting and it involves lots of case sensitive checks to see if one or the other actually spots the other. If so, then in theory the one who spots the other can open fire on it.

Assuming weapons capabilities and other factors are favorable, and that the unit wishing to shoot is an infantry Team, each individual Soldier attempts to draw LOF to its intended target. Therefore, even though the two Action Spots can see each other that doesn't mean that the individuals in each, according to their relative positions, can actually shoot at each other.

To do this the soldier's current ELOS (Enhanced LOS) height is used to make the determination. If no LOS is possible at that given height, then the next height up is checked to see if getting higher up will make the difference. If so, and there is no reason to keep from taking the higher stance, the soldier will change his stance. For example, going from prone to Kneeling. If the next higher up stance doesn't work I'm pretty sure it checks the next higher up one from there.

Discussed in the post I linked to is the unique issue of a prone soldier's horizontal center is. For standing and kneeling soldiers the horizontal center is where the head naturally is at that particular height. When the soldier is prone, however, the center is about .5m further forward of the center mass. This presents a bit of a problem because this is the point at which all LOS/LOF checks are determined. If we had prone soldiers' point be their heads then situations would come up when 90% of the body is visually exposed but not targetable because the 10% head portion is out of LOS/LOF. Conversely, the soldier may only have his head exposed and the system will have to assume that the other 90% is equally exposed, therefore having exposure being more than the visual representation.

No system is perfect. CMx1 was so abstract that it didn't have as many visual problems, true enough, but it had so many other problems due to abstractions and low fidelity that the overall level of realism was proportionally lower. Which is why people have to have reasonable standards. Otherwise perpetual dissatisfaction, probably for as long as any of us are alive, is the likely outcome. And at that point I have to say... get another hobby because nobody should choose a hobby that can only offer dissatisfaction.

That's not to say we can't make improvements, because over time we can. But it will never be perfect. Ever. So that is a very, very bad standard to expect from us.

Steve

[SlapHappy]

So there's no easy way to give the prone-on-a-cliff soldier enough LOS "latitude" that he can easily overcome this obvious spotting problem without negating his obvious terrain/posture advantage? At least in 90% or so of the cases illustrated in the screen shots?

The above shots represent soldiers in highly favorable ambush positions. Achieving these positions is a matter of good tactics. While I fully accept it might be unfeasible for the game engine to reasonably correct these problems, I also believe it can highly diminish the quality of the overall simulation if such tactics can't be employed.

That's all I'm saying.

[SlapHappy]

I posted the above before Steve's response, so I believe he's thoroughly answered the question.

[Battlefront.com]

I am pretty sure the problem in the previous screenshots has nothing to do with the guys being prone. I suspect that the Action Spot is not considered capable of drawing LOS to a particular spot because it's center mass is on the wrong side of the crest. Remember that in order for a soldier in an Action Spot to see something it's Action Spot must be "authorized" to see the intended target Action Spot. If it can not, then that ends it right there.

I'm having the testers present a couple of scenarios to Charles to see if there is anything more he can do to help out the crest situation for those Action Spots which offer a place for soldiers to observe the other side of a crest but whose centers are not able to do so.

Steve

[noxnoctum]

So are you saying that, this problem is not fixable, period? Not in CM:N, not even in CMx2:Ostfront?

[ChrisND]

So are you saying that, this problem is not fixable, period? Not in CM:N, not even in CMx2:Ostfront?

No, he is not saying that.

[Flanker15]

Have you considered giving a special property to action spots in these positions? Say let them los through the closest action spot or itself?

[noxnoctum]

And Steve, obviously I know you're a tiny team, but this would rank as a "must have" for me. Maybe even more so than the "clear room" command I'm always ranting about. Is there any way you could just have it be more abstracted in these particular situations? Maybe have the game engine revert to something more primitive when it detects this kind of situation?

[vincere]

Is there any way you could just have it be more abstracted in these particular situations? Maybe have the game engine revert to something more primitive when it detects this kind of situation?

If I read right the problem is in the pre game tile-to-tile check. So maybe less abstracted for a small number of tiles.

[Lanzfeld]

I'm having the testers present a couple of scenarios to Charles to see if there is anything more he can do to help out the crest situation for those Action Spots which offer a place for soldiers to observe the other side of a crest but whose centers are not able to do so.

Steve

This is all we can hope for. Thanks for giving it a second look. Maybe there is an answer in there somewhere.

[sfhand]

Looking at if from a different perspective, the problem isn't because LOS is calculated from the center of the Action Spot but, in the screenshot example, because of the height it is calculated at. I wonder if the initial Action Spot line of sight check could happen from preset heights dependent on an adjacent Action Spot slope variable, i.e. when the adjacent Action Spot is nearly the same height as the current the current LOS height would be used, and when the Adjacent LOS is many meters lower a higher LOS height (depending on how many meters lower) would be used. Assuming that the Action Spots are square, this variable height should only come into play when calculating the variable height in the direction of large height differential. The other directions should remain at the default height.

Those are the ramblings of this madman...

[c3k]

Steve,

Thanks for letting us know you're looking at this. I hope Charles can come up with a workable solution.

Regarding the SEPARATE issue, prone LOS checks: you state that the ELOS system checks LOS from over the center dot, approximately .5m back from the visual representation of the head. When LOS is drawn along a level surface, that works well. In the case where there is an elevation difference, the LOS can be blocked due to the ELOS system check. You say that the system then checks the next higher ELOS spot and, if LOS is valid, will raise the soldier's posture to match. Now this is somewhat special, but would it be possible to simply put the soldier's HEAD at the center of the action spot whenever they're prone?

[Battlefront.com]

This is all we can hope for. Thanks for giving it a second look. Maybe there is an answer in there somewhere.

There is an answer in there somewhere, for sure. The twin questions are... how hard is it to code around and how much will it hit the hardware. Both have to be acceptable or no fix is possible.

Getting back to something Normal Dude said on the previous page, we do know the problem crops up fairly regularly. Too regularly in the opinion of most, including myself. The unfortunate situation we find ourselves in is that if a player happens to setup on one of these exception Action Spots, then the problem isn't a theoretical one but a real one. And we do understand that in those situations it doesn't mater if 99% of the time everything works fine because we're no longer talking about the other 99% of the time. Kinda like finding out that a rare cancer strikes only 1 in 100,000,000 million people each year. If you are the unlucky 1, you still would want a cure despite the fact that 99,999,999 don't need one.

Looking at if from a different perspective, the problem isn't because LOS is calculated from the center of the Action Spot but, in the screenshot example, because of the height it is calculated at. I wonder if the initial Action Spot line of sight check could happen from preset heights dependent on an adjacent Action Spot slope variable, i.e. when the adjacent Action Spot is nearly the same height as the current the current LOS height would be used, and when the Adjacent LOS is many meters lower a higher LOS height (depending on how many meters lower) would be used. Assuming that the Action Spots are square, this variable height should only come into play when calculating the variable height in the direction of large height differential. The other directions should remain at the default height.

Your last line hints at the problem with having exceptional heights... they need to be vector based. I suspect this wouldn't work from a code standpoint, but that's just a guess. For something like this it is best to just identify the problem and let Charles figure out what he can do about it. Otherwise we go round and round with tempest in teapot suggestions since none of us know how the code works or could work.

Regarding the SEPARATE issue, prone LOS checks: you state that the ELOS system checks LOS from over the center dot, approximately .5m back from the visual representation of the head. When LOS is drawn along a level surface, that works well. In the case where there is an elevation difference, the LOS can be blocked due to the ELOS system check.

This was the case long ago during initial testing. So Charles put a bit of "slop" into the equations which appears to have address the problem.

You say that the system then checks the next higher ELOS spot and, if LOS is valid, will raise the soldier's posture to match. Now this is somewhat special, but would it be possible to simply put the soldier's HEAD at the center of the action spot whenever they're prone?

No, because Soldiers are placed individually within an Action Spot and their relative positions within that Action Spot are used for LOS and LOF checks.

Remember, the problem here (as seen in the two screenshots) seems to have nothing to do with the soldiers being prone. Rather, it is that the soldiers are not even doing LOS/LOF checks to the valley below because they aren't in an Action Spot which is (in a sense) authorized to see those locations.

Steve

[costard]

I wonder if the problem has something to do with the vertex of adjoining tiles being, effectively, not modelled: the ELOS/LOS takes place from the action spot, the vertex (i.e. the ridge/cliff edge behind which most of the infantryman's body lies) lies between action spots. If so, a possible workaround might be to have a specific "edge condition" tile - a bit like having building wall/roof junctions handled by a specific tile. More work for the map builders (and code builder, granted), but they can place ambush points and suchlike, so it isn't all bad.

(It could also be that I have misunderstood this completely.)

[Martin Krejcirik]

This information is then stored in RAM in an array so it can be efficiently searched for each individual (not unit) in the game every few seconds. Any math wizards here want to tell me how many checks an 800x800m requires (Action Spots are 8x8m) for the initial map? Anybody want to hazard a guess what 1000 individual spotters require for checks every couple of seconds? Any programmers here want to guess at the RAM footprint of a 1m resolution LOS Map is?

Why guess, tell us ;-) I think 2D AS to AS map could be 12,5 MB if stored as a bitmap for each AS (10000*10000/8). If there are 6 height levels, than it could be 450 MB. I'm surly completely wrong though :-)

[akd]

On the flip side of this, is there a penalty to concealment if the unit on the crest is "sky-lined" (on a crest with only sky behind) vis-à-vis the unit at the lower elevation? Avoiding that situation plays heavily in much small unit doctrine.

[Battlefront.com]

I wonder if the problem has something to do with the vertex of adjoining tiles being, effectively, not modelled

Certainly, that is part of the problem. An Action Spot can bend in many different directions in many different places. In theory each fold or intersection with an adjoining Action Spot could present a unique "micro LOS" situation that would be quite different than the center spot. To effectively counter this we would have to have spotting done on the fly from pretty much any point. That is technically not possible to do.

Note that individuals *DO* use the "micro LOS" when they check to see if they can spot or shoot at something. But they are only allowed to check when the Action Spot has been approved. Narrowly refining an already refined choice is not all that bad for the hardware to handle. Which is why we can have 1:1 LOS/LOF within an Action Spot to any point within another Action Spot, but not from any point on the map to another random point on the map.

Why guess, tell us ;-)

I'm not a programmer so I can't guess This is also not something worth bothering Charles about.

Steve

[Battlefront.com]

On the flip side of this, is there a penalty to concealment if the unit on the crest is "sky-lined" (on a crest with only sky behind) vis-à-vis the unit at the lower elevation? Avoiding that situation plays heavily in much small unit doctrine.

Skylining is not explicitly simulated. Skylining happens when a unit is, basically, on a completely bare peak where the other side's angle means that sighting through the target intersects with nothing except the target and blue sky. It was considered too cost prohibitive (computation, coding) for the likely utility of it.

Having said that, units which are on a ridge to try to keep as low as possible in order to minimize exposure. So in practice units do try to minimize skylining. It's also a bad idea to march along a ridge because you'll be easier to spot simply because there isn't as much terrain around to obscure movement. And if there is, then skylining probably isn't possible in that circumstance anyway.

Steve

[dan/california]

It probably is not worth Charles' and Phil's time, but the skylining computation could mostly be folded into the initial computation of the LOS table and spit out as a precalculated modifier. It would reduce the CPU hit a lot to fold it in that way.

[c3k]

Thanks for the feedback. Any chance the solution to this crest issue could result in a solution to the issue of the inability to target the edge (or other non-center part) of a building?

[Battlefront.com]

Dan,

Sure, there are a bunch of things that could be done that aren't being done. But all come with some sort of pricetag attached if they are even possible. Having a variable accuracy bonus for a skylined target doesn't seem to be worth the cost.

C3K,

No, two entirely different things. To get more fidelity in Area Fire of buildings on extreme oblique angles (which is the only case where there's a significant issue) buildings would have to be sub-divided into many smaller Action Spots. This could be done, and I assume at some point will be done, but for now we don't think it's a wise idea from a computing resource standpoint. A built up urban area, with many multi-floor buildings would punch up the system requirements. Think about it.

A 4 story building section is basically 5 Action Spots (roofs are considered a story). If we divided each one up into 4 Action Spots then we now have 20 Action Spots instead of 5. Think of what this would mean to a map like this:

Thanks to LongLeftFlank for making show us what the game engine is capable of Details of his Ramadi map can be found HERE

Steve

[c3k]

Steve,

Thanks for the reply. As to LLF's Ramadi map, that's a work of art! I don't even want to begin to think what kind of spousal cost was involved in its creation! (Image of man hunched over computer keyboard with wife standing behind, hands on hips, made up to go out to dinner, scowling at him..."I've just got to get the market district laid out, then I'll be ready to go.")

Ken

[TheVulture]

Certainly, that is part of the problem. An Action Spot can bend in many different directions in many different places. In theory each fold or intersection with an adjoining Action Spot could present a unique "micro LOS" situation that would be quite different than the center spot. To effectively counter this we would have to have spotting done on the fly from pretty much any point. That is technically not possible to do.

Note that individuals *DO* use the "micro LOS" when they check to see if they can spot or shoot at something. But they are only allowed to check when the Action Spot has been approved. Narrowly refining an already refined choice is not all that bad for the hardware to handle. Which is why we can have 1:1 LOS/LOF within an Action Spot to any point within another Action Spot, but not from any point on the map to another random point on the map.

It seems to me that a plausbile algorithm to solve many of these cases would be to pre-calculate LoS from the corners of a terrain tile to all action spots too, and if any of the corners of tile A have LoS to the action spot of tile B, then flag LoS as possible between the two tiles. It costs you no more than a factor of 2 in precalculation time (I'm assuming that is a relatively small part of the setup time) and no extra memory (the only difference is that some extra tiles are flagged as having LoS). In game it would cause units within tile A to do their individual detailed LoS checks to B and therefore behave correctly in those cases; the only cost would be the extra LoS checks when there were actually units in tile A and B, and the extra computational cost of that would be pretty minor.

The same could apply to buildings, potentially; check from the corners of a building floor to a given action spot and if any of them are clear, allow detailed LoS checks.

The issue is that in some cases LoS should be possible between two action spots (thus triggering the detailed individual LoS checks) when it currently isn't since the action spot centers don't have LoS. I'd personally be happy to live with longer load/precalculation times to avoid some of the LoS anomolies, since I can guarantee that at least once or twice per mission they will annoy me.

[Thomm]

Of course this is a great idea (for it will give you peeking around corners capability), but you must also take into account that re-calculations become necessary when, e.g., a wall or a building are destroyed. Perhaps it becomes too much then.

Best regards,

Thomm

[noxnoctum]

Just wanted to bump this and see if BFC cares to comment... will any of these LOS issues be improved in CMBN right off the bat or should we expect to wait longer, possibly a patch, or even another module or something?

thanks