Other Means

Combat Mission: Wet & Wild

Is it even possible to have a gridded mod? I'll be first in line if it's possible.

Dorosh is an unavoidable feature of WWII I'm afraid.

Webwing - that looks brilliant.

IOW, it looks like one tracer is used by both sides. You can change it - brilliant - but both sides will use it.

Yeah, but you've got to actually get them to PAY for the game.

True, but in addition to tweaking the underlying model. Acquisition, first round accuracy, range effects, I think all the factors that go into creating a firefight need to be tweaked. It's one of those things that are so hard to get right though.

Delete works fine for me.

I'm a simple kinda guy. I thought lots of guys shooting, lots of lines, one squad to be given orders, one target cursor. Look in my ear, you can almost see the cogs moving, very, very slowly. [ December 15, 2007, 02:32 PM: Message edited by: Other Means ]

Ha. I reckon this is one of those complex compound issues, where having a single answer is very difficult; What happens at speed, when the angle is too tight to achieve, when there's obstacles in the preferred path, when the user wants a specific armour facing, when they don't care how they achieve the objective, when any deviation from what's expected will result in serious consequences...many interrelated and contradictory factors. Charles' idea of low speed having different behaviour is a good one (natch ) - the main issue I can see is if someone has a Stryker at top speed, then 2m of "hunt" and a sharp turn, they're going to get pathing errors as now. Still maybe user error like that can't be helped, and at least they will learn a lesson. But really - and I know I bang on about this so please forgive me - it's the mis-match in expectation to "reality*". The approaches of changing the "reality" to conform to what the user wants exposes the solution to all the factors I've listed above, whereas if we front load the expectation by showing the path to be taken we get around them because the user will get the behaviour they expect and can change their orders to match what they want. ...but then, Charles is smarter than me, so lets leave it to him eh? * in game reality.

If the path to be taken due to the waypoints was shown, and if any were invalid the line indicated where, the user would do the best themselves. Sort of like the targeting line except once past the obstacle it would indicate an achievable path again. That way you'd either put in multiple waypoints to get the correct path, slow down or whatever. IMHO it's the ability to plan that's needed, rather than AI to handle it for the player.

I've had one credited with 2 PzIII's, it was in the upper floor and they went by underneath - even so, I'm almost sure it's an error in reporting as it was the last thing to hit them.

As soon as you edit the hotkeys it gets a lot better.

Is it possible to have a LOF line from each squad member? One target point but many LOF lines going towards it.

I'd love a full sound mod. Everything seems a bit anaemic to me now.

...and hell, it's nearly Crimble.

Further. One thing I'd say about any recon elements in CM is don't use them for recon. Infantry is always the best eyes and ears, recon assets are best used late battle as fire brigades when everyone is busy - otherwise they're toast.

I've found a lot of the pathfinding problems I was seeing were actually down to CM1 expectations. Every street in CM1 could have multiple tanks in, and they'd squeeze in as they were all - for me anyway - set to scale + 2. In SF the scale is always "realistic" and Strykers can't turn on the spot - so if they can't get lined up they will spin to find a way down. Still - I'm sure when 1.05 is out there'll be far fewer "game broken" complaints.

I fully support your nomination.

Debating your description of the idea is, of course, pointless. Debating whether it has any merit - well yes, that is also probably pointless, just for different reasons. But then actually stating it is by those reasons also pointless, yet you did, so I debated it, and found it to be less than ideal - in my opinion. This is a forum.

I think a stickied, locked thread where Steve lists things that are noted as problems would help a lot - as long as it's stated there's no commitment to fix.

I think the approach you're positing has some advantages in that it brings some sort of SA to the units, in that they know to avoid exposure to possible enemy positions. No bad thing, but I think there's some issues with it. You can't have a generic "cover" value. If you're getting shot at by and MG, go for the trees, if you're getting shot at by a mortar then go anywhere there's overhead. Therefore it's a different cover map for each type of incoming fire, with an array for each action spot and code to link them all together into what seems reasonable behaviour. This is an awful lot of data, being {cover vs weapon type * action spots in LOS to action spot * number of action spots} = {cover map} – an array of arrays of LOS maps with cover values against each weapon type for each action spot. You have to differentially re-calculate the cover map triggered by events rather than scheduled due to building collapse, AFV cover etc. bringing a large overhead. I think it would be easier to just have an array of {action spot * cover vs weapon type} so it's a single array of cover values (which can be recalculated as needed as this is a much smaller array). The seek-cover routines would then need to be more complex to create a path to good cover. Figuring out the best route against certain weapon types and the position they’re taking fire from. This might be towards possible enemy positions but if they’re not currently taking fire from them what does this matter? So as the use of the cover map: * Has a large data size overhead * Has a large computational overhead – cover map needs to be recalculated even if there’s no unit currently in it * Provides SA – but this SA may be irrelevant as the unit is not currently taking fire from that direction. Not using a cover map but having cover values: * Demands larger cover-seeking behaviour * Would only be done as needed * Does not have a large data size overhead IMHO, the more complex cover seeking behaviour coupled to cover values is the clear winner.

You're talking about a pre-calculated cover map, which I think is a non started because there's so many variables between shooter and shootee that would over-ride the cover map that it's probably just as quick to calculate various cover seeking routines based on those factors. e.g. if you're being hit by a mortar the cover map is opposite to that of an MG (kinda) so do you have a cover map for each type of fire, shooter type, elevation etc? Or do you just have various routines for seeking the closest cover for shooter type.

I think "target" for smoke rounds is needed. Now they're throw in your facing direction, but you often need them throwing perpendicular to your path.

To my mind opening up the map format would allow 3rd parties to - e.g. - create a dynamic map generator. Sounds good to me.