Scipio

Of cause it is very difficult for us 'outsiders' to comprehend the natur of the problem. What, of course, doesn't keep me away to search a solution . Unfortunatly I have to catch a train in an hour, so I can't write out my brilliant theory... Huntarr, I have no idea why you can't recreate the problem on your machine. Obviously I'm not alone with my experiences. Maybe it has even something to do with the CPU and small differences in a floating point-calculation caused by this. (I have an AMD dual core CPU) Anyway, something I always wanted to ask and that is related to infantry movement: we spend some time in my military service (German Bundeswehr, early 1990') to train formations, such basic things like 'line' and 'column'. It doesn't looks to me like we have something like this in CMSF. Isn't this 'up to date' anymore - and would it have a positiv influence on the movement question?

Huntarr, nice pics, but your approach seems different from mine. The teams on your pics start the movement in a trench, while mine start in open terraine and (shall) enter a trench. It seems to me that the starting point of the movement has some importance. On the last image it looks a little bit like the team leaves the trench because another team is blocking the way. But thats pure assumtion, I could be wrong with this.

This is unfortunatly not correct. I made a few tests with a simple trench. A six men engineer squad (organized in two teams of 3 men each) was ordered to enter a trench, follow it to it's end and then turn around an move to the other end. What happend: one half of the squad entered the trench and followed it, the other half runs to the trench, crosses it and moves on paralell to the trench in some distance. I assume that the path for both teams - of the unsplitted! squad - is calculated seperatly, and maybe both teams are not allowed to share the same tile, or take the same path at the same time, or something like that.

What I have seen so far makes me believe that pathfinding and unit placement is based on an underlying grid. IIRC Steve said something like that in a very old post. That would explain why so funny things happen frequently. Or why soldiers are not able to follow a trench without leaving it - as long as the squad or team is within the right grid tile, everything is okay for the program. Cover seems to be secondary. It's the same thing like ordering area fire - the target marker ussually jumps some meters, I assume to the center of the next map tile. With all respect to Charles, who makes a great job, especially if we keep in mind that he makes all the programming alone - but maybe the basic system has already a flaw.

I've found at Global Security some stats about the Syrian Army, that it as French-German 'Milan' ATGM available, at least as much as AT-4. Just wonder why they are not in the game and if they will be added? Okay, not the most important thing to do, but anyway [ April 20, 2008, 08:51 AM: Message edited by: Scipio ]

I had this in v1.08 yesterday, too. I send a turnfile to dima who said he is in the beta team.

Seen today in a PBEM turn file. My infantry squad is in building A, I order it to quick move to building B. The building A has doors to the front and rear. Since I know an enemy platoon in a building in the upper right corner, I set a waypoint to the rear door (yellow line). What happend (red line): the squad leaves the house to the rear and splits up at the waypoint - the half squad runs to left as ordered, the other half runs to a building to the right and directly into enemy fire, causing 4 casualties and uncovered my movement. I made a test scenario with the map and units to figure out what went wrong! If I would have moved the waypoint a bit more to the road and to the left, that the movement would have been exectuted well, because parts of my squad wouldn't have moved that far to the right. But if I set the waypoint to the reardoor of Building B, my squad splits up again - one part leaves building A to the rear, the other half to the front door. More funny, the team that leaves to the frontdoor tries to get around Building B on it's LEFT side and regroup with the other team that waits at the rear door of building B. Since this is not possible within the timeframe of the 'regroup phase', they then went back and enter building B through the front door!!! The problem seems to be partely caused by the regroup an maintain phase at each waypoint(as written in the manual on page 54). My conclusion: it is very difficult to make a prediction about the execution of movement orders. Since I don't know where exactly I would have to set the waypoint(s) to achieve the result I want to see. My stupid question/idea of the topic: is the regrouping phase at the waypoints necessary? Would it help to remove it?

Seen today in v1.08, turn-based mode: I've ordered a two-men HQ team to disembark and enter a building. One men followed the orders, the other started to stereotypical cross a wall and back for the rest of the turn, likely even for the rest of the battle. Giving new orders doesn't seem to solve the problem. Dima, I've send you a save game file! [ April 19, 2008, 11:01 PM: Message edited by: Scipio ]

John, if you enjoy the 'Combat Reform' website as a whole and have really no idea what's wrong with it, then you shouldn't waste any further thoughts about other people's opinion. Don't bother yourself with colliding worlds The articel about riflegrenades has, BTW, some very interesting informations. :cool: [ April 19, 2008, 12:54 AM: Message edited by: Scipio ]

*giggle* I though 'Mishga' is a boy, too. What a strange world where women are interested into wargaming...

You pretty much described CMx1 Operations with the addition of being able to real select forces. And so down the slippery slope into oblivion we would go ... Steve </font>

Well then... we take a large campaign map where parts of it will be revealed depending on the progress of the campaign. Both sides start with a basic force on-map preset by the campaign designer and a large pool of possible reinforcement units. Between the single campaign battles, the player can select his reinforcement units and (ammo) resupply on his own, limited by some factors - transport capacity for example - which can mostly be abstracted by designer presetings and dice rolls. The time between the single battles depends on the ordered supply/reinforcements. The player can also preset simply a 'rest & rally time' for his frontline units. It's very likely that different orders for the things to happen between the battles will be given, but a relative simple system of calculation and dice roll can decide when the action starts again and how much progress with resupply etc etc has been made for both sides til then. This would add some dynamic and a pinch of operational level to the CMx2 campaign, without really adding an additional layer to the tactical level. Just a pitty that it's likely not that easy to realize as to contrive while lying in the bathtub .

Received and answered!

Yes and no! May I remind on the CMx1 style of campaigns, where the single campaign-battles were fought on sections of one large campaign map!? I guess something could be developed on the basic idea, and 'carried damage' would make some sense then.

YES ME!!! Please send me a PM or email for the details! [ April 17, 2008, 05:53 AM: Message edited by: Scipio ]

I could be wrong with this, but didn't took the SEALs high casualties in Panama, because they had NOT been used in a stealth role? Please correct me if I'm wrong. BTW, what is the role of the US Rangers today? I didn't even knew that they are part of the special forces!?

To bad, my danish is a little bit rusty

To make a break from the mega-tile issue and mention a detail for the scenario editor: I noticed that it's still impossible to remove the Headquarter Teams from the OOB. Is there a special reason for it, or could this be changed? To go one step further, why ain't it be possible to create a complete OOB from scratch down to teamlevel? This could make sense in several situations - unconventional forces, cut off or scattered troops ralied by a local commander - just to name two.

I'm not so much into scenario design, but I also think that more option are better, and I also think that the CM2 system to calculate the result is better as the CM1 system for several reasons. But if I try to see the AAR-screen from a scenario designers point of view, I would wish more than ever more details about the result. Just as an example, I set 'Enemy casualties of 60%' as objective. I playtest the scenario, the battle went well and as expected, but the objective wasn't completed anyway. Now I have a problem - how close to 60% am I? Which threshold do I have to set?

Oh, I see. Silly me Another question, also from the 'Ambush in Al Fubar': When I checked the scenario in the editor, I noticed that the blues side can achieve a total of 500 points when they complete all objectives, while the red side can win only a total of 400 points (if I shouldn't have missed something). Wouldn't it make more sense if the total points for both sides are equal?

I didn't meant that there is a real need for it. My thinking was more something like 'A cease fire switch makes only sense when playing H2H'. Has a computer player ever offered you to cease fire? I guess not, because fire is usually ceased when both players have the feeling that nothing important will happen anymore. Anyway, not an important thing.

I agree, many of the problems I mentioned are partely caused by scenario designers who give only very abstract or even missleading informations in the briefing about the 'goals'.

BTW, something I have noticed in the 'Ambush in Al Fubar' scenario today when I played it as red side: the terrain objectives for the blue side are shown, even when I play as red side. It seems to me that I shouldn't have this information available, and beside that it's very confusing, too, since the red side doesn't have any terrain objectives at all in this scenario! Look like a little bug, doesn't it?

Why not such a cease fire lock for human vs computer at all? IMO a cease fire requires a kind of decission that's beyond the abilities a computer.

Today I played 'Ambush in Al Fubar' again in Version 1.08! BTW, I played CMSF very rarely before because I'm not a fan of RT, and the turn-based-mode had so many problems. But I'm very pleased about it now!!! Anyway, after the battle I was confronted once again with an After Action screen that told me nearly nothing. Okay, I can see that I have won the battle as well as the casualties stats. Very important informations of course. But now to the objectives . GROUND (blue side): Secured Objective #1 - 500 points Objective #2 - 300 points Okay, that's easy to understand, but could be much better. How about showing the objective name (if the scenario designer has entered one)? It would also be nice if the kind of the objective would be shown (Occupy, Preserve...) TARGETS (red side): Failed Objective #1 - 3 points Seriously, I first had to read the manual about scenario design to find out that a 'Target Objective' is an enemy unit that must be destroyed. As with the terrain objectives, it would be better if the AAR shows which unit is meant with 'Objective #1'. As player I have no idea about this without opening the scenario in the scenario editor, especially if the scenario designer shouldn't have pointed this out in the briefing. PARAMETER (red side): Failed Enemy casualties - 0 Once again - the player has no idea about the numbers he has reached or should have reached. Wouldn't it be better if the stats says something like 'Enemy casualties 10% (30% necessary) - 100 points'. BTW - I'm not sure about this - is a partial result possible for Parameter & Target objectives?