Jump to content

Question about positioning units on ridgelines


Recommended Posts

Hey all, long time player (since CM1)! First time poster.

So I'm playing the third mission of Market Garden, and i have a question about positioning my units. There's a small mound in front of this forest 100 meters away, and I'm trying to position my units so they're covered from fire, but can shoot back.

Because of the 'grid' system, if I split my squad into teams and place them one square behind the ridge, only one guy per team can fire:

ex02_zps4513c4bf.png

However, if I put them on the square on top of the ridge, they can all fire, but they're awfully exposed:

ex01_zpsded91540.png

How should I handle this? Put them all on top? Is there anyway of making all of your team line up on the frontmost edge of the 'tile' so they can stay covered but all shoot? I tried using the 'face' command, but it doesn't seem to do what I'm looking for.

Thanks all!

Link to post
Share on other sites

this last screenshot. only thing i can think of is putting them 1 square behind (ridge) (eastwards in this screenshot) desired location while they are turned to the right (towards mortar icon) and then turning them to the left (where they are facing now)

(they might find middle ground, but unlikely)

i did that kind of thing with AT guns when they tended to be in the bocage and not very near bocage

Link to post
Share on other sites

that looks like it might be a foot path and intended not to have anything on top. That does become a problem in CM with the way units line up on an AS, but a lot of designers are less interested in trying to get the terrain to be conducive to what players would like to do versus leaving it to them to figure out what they can do. Does make for an easier time generating large maps.

There are certain things that are avoided simply because they really do mess with a map and deployment but I think that mostly happens with maps that are in restricted terrain.

Link to post
Share on other sites

I find that if I give a Target order, or the single "up" rifleman spots something to shoot at, the first option usually ends up with more men crawling up to the firing position. In that exact same position, at least the Bren guys moved up to be able to fire, IIRC.

Edit, and yes, the top of the berm is a track, so the scenario designer couldn't plausibly put any vertical cover there.

Link to post
Share on other sites

This is one of the weaknesses of the current engine.. hopefully Battlefront will work something out 'going forward', as Obama says.

Either the solution could be to make the TacAI more aware of ridges, doing a better job to get squads to "snap to ridge", and/or split the maps in more action squares, so finer placement would be possible.

Link to post
Share on other sites
...and/or split the maps in more action squares, so finer placement would be possible.

Well yes, I've wished for that too. But there is a problem you see. If the map were divided into 4m AS, that would require four times as many potential LOS calculations per turn, which would slow play down considerably on existing machines. Maybe in a couple more years the computer owned by the average player could handle it.

But there is another problem. Teams already tend to bunch up on 8m AS with 64^2m area to spread out it. How much worse is that going to be with only 16^2m area? Maybe there are solutions to both these problems, but I have a hunch it might take a lot more work than might be obvious.

Michael

Link to post
Share on other sites
This is one of the weaknesses of the current engine.. hopefully Battlefront will work something out 'going forward', as Obama says.

Either the solution could be to make the TacAI more aware of ridges, doing a better job to get squads to "snap to ridge", and/or split the maps in more action squares, so finer placement would be possible.

Splitting the maps AS as Emrys said is probably not gonna happen (notice I did not exactly say he was right...) That requires geometrically more oomph in computing power.

Changing how they align might be something to hope for, along with how they move and align along trenches and other terrain features. I know Steve has said a couple times how he'd like TAC AI to behave better regarding corners so I don't think it is outside the realm of possibility to see this type of behavior change as well in future releases of the engine.

Link to post
Share on other sites
Well yes, I've wished for that too. But there is a problem you see. If the map were divided into 4m AS, that would require four times as many potential LOS calculations per turn, which would slow play down considerably on existing machines. Maybe in a couple more years the computer owned by the average player could handle it.

But there is another problem. Teams already tend to bunch up on 8m AS with 64^2m area to spread out it. How much worse is that going to be with only 16^2m area? Maybe there are solutions to both these problems, but I have a hunch it might take a lot more work than might be obvious.

Michael

Erm ... I'm no mathematician (and probably about to reveal that to the world ...:)), but each of the three new AS (compared with the one larger old AS) need to have their potential LOS - provided that the initial LOS map doesn't permanently rule it out - checked with the three new AS in every other location ...

so isn't it some sort of ? x ? x ? calculation for the additional LOS calculations, rather than just four times more?

My point - aside from pedantry - being that it is even more of a computer horsepower issue than that makes it seem???

(Or not, if I'm wrong!)

Link to post
Share on other sites
Erm ... I'm no mathematician (and probably about to reveal that to the world ...:)), but each of the three new AS (compared with the one larger old AS) need to have their potential LOS - provided that the initial LOS map doesn't permanently rule it out - checked with the three new AS in every other location ...

so isn't it some sort of ? x ? x ? calculation for the additional LOS calculations, rather than just four times more?

My point - aside from pedantry - being that it is even more of a computer horsepower issue than that makes it seem???

(Or not, if I'm wrong!)

It would make the calculation and size of the "LOS matrix" grow by 16 times, yes. And having smaller ASes would mean teams, crew served weapons and vehicles would more often be in more than one AS, multiplying the actual initial "is it possible" LOS check flitering that would need to be made by 4 or more. It wouldn't multiply the effort needed for the entire process up by that factor, though, as the last bits are point-to-point. You're right that it's probably more than just 4x overall.

Link to post
Share on other sites
Maybe this kind of calculations would be an obvious match for multiple-core computing?

For reasons of their own, BFC have stayed away from multi-core processing. Presumably, if they ever decide to take the plunge, it would increase computational power significantly, which is the whole point of having multi-cores in the first place.

Michael

Link to post
Share on other sites
For reasons of their own, BFC have stayed away from multi-core processing. Presumably, if they ever decide to take the plunge, it would increase computational power significantly, which is the whole point of having multi-cores in the first place.

Michael

whether multi-cores would make up for a massive expansion of computational requirement by going with a smaller increments in AS is extremely doubtful. What it may allow for is better performance with the larger maps we expect may start showing up.

I expect that the whole LOS calculation system is going to be something we will have to deal with until BF moves to whatever CM 3.x would be.

Link to post
Share on other sites
whether multi-cores would make up for a massive expansion of computational requirement by going with a smaller increments in AS is extremely doubtful. What it may allow for is better performance with the larger maps we expect may start showing up.

I expect that the whole LOS calculation system is going to be something we will have to deal with until BF moves to whatever CM 3.x would be.

I think there's some room for "tinkering round the edges" of the LOS system as processors get better, and BFC get better at using the potential of the ones we have. Steve mentioned that the original concept for the LOS matrix had "spotting spots" on the walls and corners of buildings, but that keeping them in had too big a speed hit, so they had to drop out. Perhaps something like that will get shimmed back in as the "BFC least powerful spec" evolves.

Link to post
Share on other sites
multi-cores [...] What it may allow for is better performance with the larger maps we expect may start showing up.

Personally, I would prefer to stay at the same size maps, but with higher fidelity in the simulation. Even the mid-size maps are already plenty big for me. My little brain gets overloaded enough trying to juggle one or two companies. But I know that some prefer the bigger the better.

Link to post
Share on other sites

Personally, I would prefer to stay at the same size maps, but with higher fidelity in the simulation. Even the mid-size maps are already plenty big for me. My little brain gets overloaded enough trying to juggle one or two companies. But I know that some prefer the bigger the better.

I feel the same for WW2. But the modern warfare Combat Missions need REALLY big maps.

Link to post
Share on other sites

LOS checking should be one of the simpler things to multithread, because it is mostly a readonly operation, you don't have to worry too much about writing data all the time. Operations that simply read data are much simpler to do in parallel than those that read and write.

One problem here is RT, real-time play. You can't really stop the running engine updating the action in the 3D view like you could in WEGO.

Also, as all RT games you don't want people with weaker computer get a much worse game experience. All RT games (approximately) simplify and skip steps in computation when they don't have enough CPU available. Obviously you cannot quite do that with LOS checks.

Right now the situation is that casual computer users tend up have about the same per-core speed and better computers are mostly having more cores. In a single-threaded games that means everybody runs closer to each other than you would if you could use all cores. So in the current situation is is easier to give every RT user a comparable experience. Yes there are idle cores but what you gonna do, you can't require computations to be done that the weaker computers don't have the power to execute.

Anyway, I think the solution here is that the situation described in the OP should be considered a bug and that changes to the microAI positioning the individual solders should be made so that the soldiers do not position themselves out of LOS of things that were in LOS for the point the player designated for the squad to go it.

I believe that would be preferable to increasing the number of action spots to the point where it would make this problem disappear, which would be a very large increase, and then you split up single squads over a large number of them. I don't think that is the quickest approach here.

Too bad CMx2 gave up the 1:1 representation we had in CMx1.

Link to post
Share on other sites
Too bad CMx2 gave up the 1:1 representation we had in CMx1.

??? 1:1? With 3 men being displayed to represent a squad of 8-12, and the entire squad being considered to be a point entity? I think you might have a different concept of what 1:1 means.

Link to post
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...