Change to the Interface

[yuvuphys]

Originally posted by Battlefront.com:

The problem is there is no mechanism to know which is a tactical decision and which is invoked due to a coordination issue. The reason is there are no explicit simulation of coordination. There is no way to tell if a unit wishes to stop because of a legitimate self determined reason (like suspecting trouble or coming under fire) or if it is "cheating" by allowing events outside of its knowledge to influence its movement decisions. Until we can know the difference there can not be any penalty for tactical decisions like stopping. It would be disasterous to even try. All we can do is assess generalized penalities for starting ations and just live with the fact that they are inherently unrealistically coordinated thanks to the Borg and God issues.

Steve

I'm not sure I understand why there is a problem with creating a delay to stop a unit. In the current incarnation, if I need to stop a unit, I just delete all of his waypoints, and he instantly stops. Why can't there be a delay given to my "stop the movement order I gave you before" command?

[LongLeftFlank]

Originally posted by Battlefront.com:

"1st Squad go left and move around that stand of trees to circle behind that enemy MG position". The Squad determines if it is to stick to the wall or to a ditch that might be there, though it is also just as likely that the Platoon Leader would also have assigned the route if the route was obvious, for example "1st Squad, sneak along that ditch and then circle behind that enemy MG position".

Nice discussion here, and I'm excited at the "ditch" reference (OK, OK, I'm a ditch fetishist)

... with the new 8x8 terrain, whole worlds of trench raids and infiltration attacks (think Japanese or NVA sappers) open up that really couldn't be realistically modeled in CMX1.

I've lost count of the number of times I've seen requests for a "follow the road" command for vehicles, and it seems to me that a solution to this issue might help with the above command issues as well.

Building on the "flags" idea above, would it be possible to embed tags in contiguous terrain features that would be preferentially followed by units in the absence of more specific countervailing orders:

roads, trails, ditches/trenches, gullies/ streambeds, walls and embankments.

So that way you can issue a "strategic" order with a single waypoint: ADVANCE to that farmhouse. However, the unit won't just beeline across open fields when a nice muddy ditch or a wall is available, say within 20 meters of the direct route.

If time is of the essence and you do indeed want them to beeline, well then you tell them to RUN or MOVE (although they may head for the ditch on their own initiative if they think it's safer).

This would mimic natural human behavior -- when it's dark follow the road, get in the ditch when you don't want to get shot, etc. without need for a more complex set of orders and waypoints.

Perhaps also, you could order a unit to ADVANCE, clicking on a wall, at which time a FOLLOW command would become available whose waypoint terminus would lie somewhere along that same wall....

[Peter Cairns]

Steve,

You are talking about changes to the way delays and orders are treated in release two or perhaps three.

Are we talikng about modules or theatres here, and what kind of time scale.

If it's modules then it could be within a year of first release, but if it is actual versions then we could be waiting two or even three years for the definitive system.

Peter.

[Michael Dorosh]

Originally posted by LongLeftFlank:

</font><blockquote>quote:</font><hr />Originally posted by Battlefront.com:

"1st Squad go left and move around that stand of trees to circle behind that enemy MG position". The Squad determines if it is to stick to the wall or to a ditch that might be there, though it is also just as likely that the Platoon Leader would also have assigned the route if the route was obvious, for example "1st Squad, sneak along that ditch and then circle behind that enemy MG position".

Nice discussion here, and I'm excited at the "ditch" reference (OK, OK, I'm a ditch fetishist)

... with the new 8x8 terrain, whole worlds of trench raids and infiltration attacks (think Japanese or NVA sappers) open up that really couldn't be realistically modeled in CMX1.

I've lost count of the number of times I've seen requests for a "follow the road" command for vehicles, and it seems to me that a solution to this issue might help with the above command issues as well.

Building on the "flags" idea above, would it be possible to embed tags in contiguous terrain features that would be preferentially followed by units in the absence of more specific countervailing orders:

roads, trails, ditches/trenches, gullies/ streambeds, walls and embankments.

So that way you can issue a "strategic" order with a single waypoint: ADVANCE to that farmhouse. However, the unit won't just beeline across open fields when a nice muddy ditch or a wall is available, say within 20 meters of the direct route.

If time is of the essence and you do indeed want them to beeline, well then you tell them to RUN or MOVE (although they may head for the ditch on their own initiative if they think it's safer).

This would mimic natural human behavior -- when it's dark follow the road, get in the ditch when you don't want to get shot, etc. without need for a more complex set of orders and waypoints.

Perhaps also, you could order a unit to ADVANCE, clicking on a wall, at which time a FOLLOW command would become available whose waypoint terminus would lie somewhere along that same wall.... </font>

[Bruce70]

It seems to me that the main point of contention is still that a penalty should not be applied for "simple" obstacle avoidance. What is simple obstacle avoidance? Well one definition might be "anything the tacAI can work out" . Which brings us back to the system I and others presented earlier.

Give the player the option to plot a few way points and then (perhaps optionally) have the tacAI calculate a path (which would depend on the nature of the order). If the calculated path is OK, there should probably be no additional penalty. OTOH if the player doesn't like the path, we assume that the waypoints added do not amount to "simple obstacle avoidance" and every waypoint changed would incur a penalty as per the current system (although I would probably argue for a larger penalty in this proposed system).

[LongLeftFlank]

Originally posted by Michael Dorosh:

And when the ditch is found to have been mined?

Well, ditch full of roughly butchered meat I suppose...

But if you're referring to units being induced by the Tac AI to enter "preferred" terrain even when they know it's been mined, you'd presumably need another set of "tags" for mines that override the terrain tags (i.e. telling the unit to avoid known mines the same way it would reroute a command to cross an unfordable water obstacle)?

In reference to the "who's in charge here anyway" issue raised earlier, you might introduce the following protocols that tell the AI whether to obey the player literally or use its best judgement:

RUN or ASSAULT commands mean a beeline along the exact path the player has chosen (so long as terrain is passable and morale holds).

MOVE/MTCONTACT means get to the waypoint using whatever route offers fastest movement within the 20-30 meter band... i.e. you aren't expecting fire, so follow the road.

ADVANCE means get to the waypoint by following (not wallowing in, as in your hedge example) whatever terrain types offer the best cover and concealment within the 20-30 meter band.

[yuvuphys]

Originally posted by yuvuphys:

I'm not sure I understand why there is a problem with creating a delay to stop a unit. In the current incarnation, if I need to stop a unit, I just delete all of his waypoints, and he instantly stops. Why can't there be a delay given to my "stop the movement order I gave you before" command?

Thought I'd tack on a few more thoughts...tell me to can it whenever you want, Steve

So, one of the main issues seems to be coordination, and the incorporations of lower-level planning into the game, and their relation to command delays, etc. One way to incorporate this would be, during the setup phase to allow the player to place several (3?) checkpoints at any point on the map, along with movement orders associated with that checkpoint. During the game, units can go to those checkpoints, and will automatically and immediatly execute those movement orders when the player chooses to shoot a signal flare associated with that checkpoint. If one so desired, checkpoints could also be created where the orders would automatically be executed at a given time if the unit were at that checkpoint at that time. This would allow coordination of movement, even if command delays were to increase significantly, and/or units out of command. Coupled with a delay upon the issuance of a "halt" command , this could make for some daring and quite interesting decisions.

Of course, that would force you to write some new chunks of AI, but I think that something like that has to be the next expansion under the current waypoint system.

[Battlefront.com]

yuvuphys

I'm not sure I understand why there is a problem with creating a delay to stop a unit. In the current incarnation, if I need to stop a unit, I just delete all of his waypoints, and he instantly stops. Why can't there be a delay given to my "stop the movement order I gave you before" command?

Because a tactical unit does not have to radio into HQ to ask or permission to stop for a minute or two. That is a decision that is left up to the tactical unit itself, though it might feel constrained to do otherwise. So a delay, of any sort, to stop would be unrealistic as well as disastrous for gameplay. Features that don't mimic realistic behavior are non-starters from a design standpoint.

So, one of the main issues seems to be coordination, and the incorporations of lower-level planning into the game, and their relation to command delays, etc.

Yes, coordination is the central issue. Coordination of the soldiers within a unit, coordination with units of the immediate organization, and then coordination with higher echelons. Each has its own implications on tactical decisions. Unfortunately, all too often these things are at cross purposes with each other. For example, any half decently trained unit can do within a second or two if it senses a need to do so, but if something happens on the other side of the map then the unit shouldn't be able to stop at all for any reason related to that event. Sticking a delay on stopping, therefore, satisfies neither situation and only frustrates the more common reason to stop (i.e. something directly associated with the unit).

One way to incorporate this would be, during the setup phase to allow the player to place several (3?) checkpoints at any point on the map, along with movement orders associated with that checkpoint. During the game, units can go to those checkpoints, and will automatically and immediatly execute those movement orders when the player chooses to shoot a signal flare associated with that checkpoint.

Correct, that is one form of the obvious solution. But as I have already stated, and you seem to appreciate, this is an entirely new thing for the game system. It is no small undertaking to support it, which is why it won't be in the first release. Which brings me to Peter's question:

Are we talikng about modules or theatres here, and what kind of time scale.

When I say "release" I do not mean a Module, I mean Title. Modules will never introduce major new features, instead designed to extend the setting already established by a Title. In a crude form this means Titles give you a setting and features, Modules give you more units and terrain for that setting and no (significant) new features. Modules are due to be released in months (which is why no major features can be included) and Titles every year or so. It will not be 2-3 years in between Titles. That's the whole point of the CMx2 engine

Bruce,

Give the player the option to plot a few way points and then (perhaps optionally) have the tacAI calculate a path (which would depend on the nature of the order). If the calculated path is OK, there should probably be no additional penalty. OTOH if the player doesn't like the path, we assume that the waypoints added do not amount to "simple obstacle avoidance" and every waypoint changed would incur a penalty as per the current system (although I would probably argue for a larger penalty in this proposed system).

This would then mean the TacAI no longer favors the player's orders but instead favors something else (quickest path is what you're asking for, but there are other options). Not saying that is a bad thing, but it might turn out to be more annoying than you might think. It all comes down to how frequently the path you want to take is not optimized for speed (i.e. direct path) vs. how often you want it to be the quickest path. And that might change dramatically depending on the makeup of a scenario.

Personally, I don't understand what all the fuss is. I've never, ever worried about the C&C delays when I plot. I just issue the best waypoints for the task I want the unit to perform and accept that it takes that long to do it. I tend to plot fairly short hops and when I command crappy units I make them as braindead simple as I can. Like I said about 1000 times already, since the time is generously low I don't feel there is anything to gripe about from a realism standpoint.

Steve

[aka_tom_w]

Personally, I don't understand what all the fuss is. I've never, ever worried about the C&C delays when I plot. I just issue the best waypoints for the task I want the unit to perform and accept that it takes that long to do it. I tend to plot fairly short hops and when I command crappy units I make them as braindead simple as I can. Like I said about 1000 times already, since the time is generously low I don't feel there is anything to gripe about from a realism standpoint.

Steve

And by "generously low" you mean the delays over all are unrealistically short and the game moves forward at a slightly unrealistically fast pace, "so quit your moaning" .

I would agree the command delays are unrealistic in that in real life it takes any group of people of any size a lot longer to get moving to do something together in any form or co-ordinated fashion. Now supposedly training and military "conditions" encourage speed or swiftness and following orders and all that stuff, but it might still take longer that 30 -45 seconds to get any group of 8-12 soldiers moving with a common goal in a combat setting. IMHO

Lets see what they do about this in CMx2.

I would like to see a small %10 - %20 random delay factor added or subtracted (+/ -) to any command delay so that the delay would not be "robot like" predictable as it is now.

-tom w

[Ted]

Just to keep beating the subject…

First, I have no problem with way points either. I just try and not have so many it takes more than twenty or thirty seconds to get going. I may delay other forces around them so everyone starts at the same time.

For something different would it be possible to just plot two points, a start and a finish, with a line connecting the two just like we have now only being able to pull and push the line using the cursor to create a desired path?

This would create only one time delay even if you wanted to skirt around an obstacle to get to an objective.

Just thinking out loud…. you could add varying time delays for every pull or push depending on the distance from the center line. Or have a formula that calculates the overall deviation from the center line and adds that to the start time.

[Wicky]

Presently in CM you can adjust the waypoint in direction and distance by clicking on the previously plotted waypoint and dragging it. The reponsiveness of dragging steps up between cons, grn & reg, with a marked jump in effectiveness with vet, crk & elt.

Originally posted by Ted:

For something different would it be possible to just plot two points, a start and a finish, with a line connecting the two just like we have now only being able to pull and push the line using the cursor to create a desired path?

This would create only one time delay even if you wanted to skirt around an obstacle to get to an objective.

Just thinking out loud…. you could add varying time delays for every pull or push depending on the distance from the center line. Or have a formula that calculates the overall deviation from the center line and adds that to the start time.

[Dook]

Originally posted by Wicky:

[QB] Presently in CM you can adjust the waypoint in direction and distance by clicking on the previously plotted waypoint and dragging it. The reponsiveness of dragging steps up between cons, grn & reg, with a marked jump in effectiveness with vet, crk & elt.

Note too that the HQ's command rating has a significant effect on the responsiveness of waypoints to change. You can make fairly dramatic changes if the unit is in command of an HQ with a +2 command rating.

[Ted]

I realize you can adjust way points after starting movement but still it’s a straight line between waypoints. Also there is a fixed time delay every time you add a waypoint no matter the distance.

Perhaps I didn’t make my self clear (I’m good at that). When I said pulling and pushing I meant that it would create a curve. For example if you wanted to move around a patch of woods to a place on the other side you would click on where you want to finish your move creating a straight line through the woods. You would then “grab” part of the line going through the woods and “pull” the line so it curves around the woods.

Something like being able to stretch and bend the lines.

[aka_tom_w]

OK!

Now we are talking

Ted wants Bezier Curves (say: "bezEEay" curve)

Notes from this web site if you want more info...

bezier curve infor web page

"A Bezier curve in its most common form is a simple cubic equation that can be used in any number of useful ways. Originally developed by Pierre Bézier in the 1970's for CAD/CAM operations, it became the underpinnings of the entire Adobe PostScript drawing model. If you're a regular user of Adobe Illustrator, Macromedia Freehand or Fontographer, any number of spline-based 3D programs, etc., you've probably used Bézier curves.

It can also be used for animation. These pages are a simple introduction to how to implement Béziers for motion control: how to choose curves and control points, and how to calculate movement along the curve. I've provided a sample Shockwave movie you can try out, download, and grub around in the code of."

NOW....

Do we need this in the game?

Sure it would be COOL and it could have an impact as Ted says in how command delays are calculated...

BUT I would say it might not be entirely "natural" to have units running all over the map in perfect curve patterns. I could be wrong but I guess I always figured most moves of most units were in small straight line segments (like in between way points in the game) from one place in a straight line to the next place...

But what do I know? :confused:

If you are new to the concept or just want to see how a Bezier curve works just try this page:

Bezier curve page where you can play with curves and sliders and curve handles to make the curve in on a web page thanks to Shockwave code. THe small blue and green dots at the end of the "handle" arms are what you move to change the curve then you can see the red ball move along the curve. In other places in the diagram the red balls just moves along a fixed curve or line.

and yes this might be VERY difficult to put into the game for EVERY path for every unit.....

-tom w

[ October 03, 2005, 12:57 PM: Message edited by: aka_tom_w ]

[J Ruddy]

Originally posted by aka_tom_w:

BUT I would say it might not be entirely "natural" to have units running all over the map in perfect curve patterns. I could be wrong but I guess I always figured most moves of most units were in small straight line segments (like in between way points in the game) from one place in a straight line to the next place...

It all depends how much shorter the right leg is when compared to the left leg.

I guess we need to have leg lengths modelled precisely in CMX2. Does anyone have historical data that shows the average deviation between leg lengths of point men or section commanders between 1939 and 1945 (assuming WWII is the genre for the game)

Space Lobsters, on the other hand, prefer to move in French curves. (much sexier than plain old Bezier curves) It has something to do with the delinearization of their quantum eye stalks and the jet-like streams of hot gas expelled from their nether regions after eating Finlanders.

[Dirtweasle]

Originally posted by Ted:

...Perhaps I didn’t make my self clear (I’m good at that). When I said pulling and pushing I meant that it would create a curve. For example if you wanted to move around a patch of woods to a place on the other side you would click on where you want to finish your move creating a straight line through the woods. You would then “grab” part of the line going through the woods and “pull” the line so it curves around the woods.

Something like being able to stretch and bend the lines.

I thought I posted something simaler pages ago too. It's such a simple idea, (the concept that is), there has to be a reason it's not used. ...and there might be the answer; Easy to think of, but damned hard to put in the game.

[Battlefront.com]

It's such a simple idea, (the concept that is), there has to be a reason it's not used.

Just didn't think of it as being necessary It is still something I don't think is a big problem, at least with road behavior fixed, so I'm not sure we'll go ahead and do it for CMx2. However, personally I would like to see if we could. Charles' fear is that this would make the command process noticably slow on the lower end machines. A toggle on/off would fix that.

We'll see!

Of course, this doesn't have any bearing on the issue of command delays

Steve

[yuvuphys]

Correct, that is one form of the obvious solution. But as I have already stated, and you seem to appreciate, this is an entirely new thing for the game system. It is no small undertaking to support it, which is why it won't be in the first release.

Steve

Heh, I appreciate all too well. So, if you're not going to incorporate this type of coordination immediately, what areas are you specifically focusing on for the first release?

I still don't agree with you on the stopping delay...at least as I understand your argument so far. I'll give an explicit example, then I'll let it drop I have two squads advancing 50 meters apart from each other in dense woods. They've been instructed to advance 150 meters into the woods. The squad A (on the left) comes under fire 75 meters into the woods, and is on the verge of being routed due to a blistering counter-attack. I need squad B (on the right) to rush to the aid of squad A and help beat back the counter attack. My question is what happens next in CMX2. Does squad B continue to advance 75 more meters into the woods? Does it stop when it hears the gunfight? Or does it stop and move towards the sound of the fight on it's own accord?

Now, if the answer is squad B continues to advance into the woods, I as company commander want to tell them to bust their butts over to the fight. So, I send a runner into the woods to tell'em to help squad A. Meanwhile, squad B will continue to advance into the woods until the runner stops them, and tells them their new orders. In CMX1, the instant I give them the new orders, they stop advancing, wait a while, then run towards the fight, reducing the distance they have to travel to get to the fight.

So, depending on the answer to the question of squad B's reaction to the sound of the firefight, this sort of ties in with coordination in a more dynamic way than we've talked about before, and maybe that's what you're getting at and I'm missing?

[Battlefront.com]

Heh, I appreciate all too well. So, if you're not going to incorporate this type of coordination immediately, what areas are you specifically focusing on for the first release?

Tons of other things But if I had to say any one thing, it would be the basic structure. Remember, we chucked out all the CMx1 code and started fresh. There's a lot that needs to be designed and built just to get a unit displayed on the screen and moving around. We therefore can only do so much with each release or we'll be back to 2-3 years for each one. That sucks for everybody.

I still don't agree with you on the stopping delay...at least as I understand your argument so far. I'll give an explicit example, then I'll let it drop

Note that your example is one where coordination is the central issue. That is the critical thing I have kept pointing out. In the absence of a method of simulating coordination, one can not impose coordination restrictions and yield realistic results. Period.

I have two squads advancing 50 meters apart from each other in dense woods. They've been instructed to advance 150 meters into the woods. The squad A (on the left) comes under fire 75 meters into the woods, and is on the verge of being routed due to a blistering counter-attack. I need squad B (on the right) to rush to the aid of squad A and help beat back the counter attack. My question is what happens next in CMX2. Does squad B continue to advance 75 more meters into the woods? Does it stop when it hears the gunfight? Or does it stop and move towards the sound of the fight on it's own accord?

No, of course it doesn't stop and do something on its own accord. That would require the unit to pass over to AI control, and that is simply not something we're going to touch with a 10' pole If Squad B can see the enemy unit firing at Squad A, then perhaps it will stop and exchange fire (depends on the order). If Squad B can't see the enemy, then it will continue on its merry way until the player has a chance to tell it to do otherwise. Just like in CMx1.

Now, if the answer is squad B continues to advance into the woods, I as company commander want to tell them to bust their butts over to the fight. So, I send a runner into the woods to tell'em to help squad A. Meanwhile, squad B will continue to advance into the woods until the runner stops them, and tells them their new orders. In CMX1, the instant I give them the new orders, they stop advancing, wait a while, then run towards the fight, reducing the distance they have to travel to get to the fight.

Again, you are talking about something which is not simulated. How do you know that Squads A and B weren't told to watch out for each other? So when Squad B hears that Squad A is under fire there would be no need for a runner since the Squad would do what it was already instructed to do. Plus, in reality the Company Commander wouldn't be involved at all in this situation. If anybody, it would be the Platoon Leader. If he was instructed to move on without any delays he might order Squads B and C to keep on going and just hope that A makes it out of the fight alive. Or he might be instructed to eliminate any enemy resistance found in the woods, in which case all assets under the Platoon Leader's control would be brought to bare on the enemy.

So why should Squad B have to wait around to know when to stop? Because you are assuming it is instructed to not act on its own initiative or the initiative of the Platoon Leader? That is a pretty bad assumption.

And you keep ignoring the important thing... the inherent ability for a unit to determine its own course of action. Here is an example for you...

A Squad is in the woods. Nobody else is with it because it is on patrol. It is moving along a 200m plotted path. It comes to a small clearing and is half way through when it spots an enemy unit or gets a sound contact. Please explain why it must continue moving without being able to stop whenever and wherever it pleases? In CMx1 you can delete/move waypoints to allow the unit to continue on for a little bit more, or you can stop it cold. The choice is up to the "unit", which in this case is the player. You can not outline any other realistic constraint on the unit's ability to stop on a dime because no such conditions exist.

Another example, the same Squad is moving in the same conditions and comes to a road that it was not originally planning on moving down. At the time it reaches there the Squad Leader thinks that perhaps they should take the road instead because it has been slower and rougher going through the woods than he thought. So he wants to immediately stop the Squad and redirect it down the road. Why can't he do this? Or are you saying that in real life he'd have to check with someone before he could alter his path to the same objective?

I really hope you can see that you are making a singular assumption in order to push forward the notion of a penalty for stopping. But for every one situation you can come up with, I can come up with several that counter it. But more importantly, I can come up with examples that you can not counter, while you can come up with none that I can't. That clearly demonstrates that no stopping penalty is the more realistic design choice. Once we simulate higher level planning and ramifications, in detail, then we can do all sorts of things that aren't possible to do now.

Steve

[yuvuphys]

Originally posted by Battlefront.com:

</font><blockquote>quote:</font><hr />Heh, I appreciate all too well. So, if you're not going to incorporate this type of coordination immediately, what areas are you specifically focusing on for the first release?

Tons of other things But if I had to say any one thing, it would be the basic structure. Remember, we chucked out all the CMx1 code and started fresh. There's a lot that needs to be designed and built just to get a unit displayed on the screen and moving around. We therefore can only do so much with each release or we'll be back to 2-3 years for each one. That sucks for everybody.

I still don't agree with you on the stopping delay...at least as I understand your argument so far. I'll give an explicit example, then I'll let it drop

Note that your example is one where coordination is the central issue. That is the critical thing I have kept pointing out. In the absence of a method of simulating coordination, one can not impose coordination restrictions and yield realistic results. Period.

I have two squads advancing 50 meters apart from each other in dense woods. They've been instructed to advance 150 meters into the woods. The squad A (on the left) comes under fire 75 meters into the woods, and is on the verge of being routed due to a blistering counter-attack. I need squad B (on the right) to rush to the aid of squad A and help beat back the counter attack. My question is what happens next in CMX2. Does squad B continue to advance 75 more meters into the woods? Does it stop when it hears the gunfight? Or does it stop and move towards the sound of the fight on it's own accord?

No, of course it doesn't stop and do something on its own accord. That would require the unit to pass over to AI control, and that is simply not something we're going to touch with a 10' pole If Squad B can see the enemy unit firing at Squad A, then perhaps it will stop and exchange fire (depends on the order). If Squad B can't see the enemy, then it will continue on its merry way until the player has a chance to tell it to do otherwise. Just like in CMx1.

Now, if the answer is squad B continues to advance into the woods, I as company commander want to tell them to bust their butts over to the fight. So, I send a runner into the woods to tell'em to help squad A. Meanwhile, squad B will continue to advance into the woods until the runner stops them, and tells them their new orders. In CMX1, the instant I give them the new orders, they stop advancing, wait a while, then run towards the fight, reducing the distance they have to travel to get to the fight.

Again, you are talking about something which is not simulated. How do you know that Squads A and B weren't told to watch out for each other? So when Squad B hears that Squad A is under fire there would be no need for a runner since the Squad would do what it was already instructed to do. Plus, in reality the Company Commander wouldn't be involved at all in this situation. If anybody, it would be the Platoon Leader. If he was instructed to move on without any delays he might order Squads B and C to keep on going and just hope that A makes it out of the fight alive. Or he might be instructed to eliminate any enemy resistance found in the woods, in which case all assets under the Platoon Leader's control would be brought to bare on the enemy.

So why should Squad B have to wait around to know when to stop? Because you are assuming it is instructed to not act on its own initiative or the initiative of the Platoon Leader? That is a pretty bad assumption.

And you keep ignoring the important thing... the inherent ability for a unit to determine its own course of action. Here is an example for you...

A Squad is in the woods. Nobody else is with it because it is on patrol. It is moving along a 200m plotted path. It comes to a small clearing and is half way through when it spots an enemy unit or gets a sound contact. Please explain why it must continue moving without being able to stop whenever and wherever it pleases? In CMx1 you can delete/move waypoints to allow the unit to continue on for a little bit more, or you can stop it cold. The choice is up to the "unit", which in this case is the player. You can not outline any other realistic constraint on the unit's ability to stop on a dime because no such conditions exist.

Another example, the same Squad is moving in the same conditions and comes to a road that it was not originally planning on moving down. At the time it reaches there the Squad Leader thinks that perhaps they should take the road instead because it has been slower and rougher going through the woods than he thought. So he wants to immediately stop the Squad and redirect it down the road. Why can't he do this? Or are you saying that in real life he'd have to check with someone before he could alter his path to the same objective?

I really hope you can see that you are making a singular assumption in order to push forward the notion of a penalty for stopping. But for every one situation you can come up with, I can come up with several that counter it. But more importantly, I can come up with examples that you can not counter, while you can come up with none that I can't. That clearly demonstrates that no stopping penalty is the more realistic design choice. Once we simulate higher level planning and ramifications, in detail, then we can do all sorts of things that aren't possible to do now.

Steve </font>

[Peter Cairns]

Having read most of the arguements here at least once, I think Steve and the boys are pretty much on the right track.

What people seem to be wanting is an unrealistic control of units so that they have a method of precise control over how units react to unknown terrain, without having to put some thought in to avoiding it.

Occasionally units do do daft and frustraiting things, but as Steve pointed out, thats as much to do with the orders they are given as the AI or way point system.

My rule of thumb is K.I.S.S.

Keep It Simple Stupid.

If you don't go giving units, long term intricate orders that send them long distances by complex routes, you won't really have problems. If you do insist on doing it then you get what you deserve.

Going back twenty odd years to when I played board wargames there were two types of players, those who moved units took the rough with the smooth and had a good time, and those who agonised over every hex, challenged every line of sight and criticised every rule.

The "Go with the flow guys", like me had fun, the moaners were never happy.

As it is the system they are outlining will have a balance between orders given and how units below Co level interpret them, which will improve on an already pretty decent system.

In the past when my units have stalled on on Flank because of hedges or the like, I've not turned my wrath on the waypoint system or the AI, I've said, "Well, Pete, you made a complete mess of that didn't you".

Peter.

[melb_will]

I'll put this in here and hope it doesn't get lost.

Could I have a distance tool where i click on one point and click on another point and get told the distance between the two points. Like the LOS tool it wouldn't make any lines appear it would just be a player aid. As this info is already available in a more cumbersone nature by using the los tool it shouldn't be gamey etc.

Also because it is an interface question i'll repeat a request to be able to draw plans on the game screen it would make setups so much quicker. it would also speed up the making of turns a little bit because if you have drawn a circle around a hull down postion you want to get to you don't have to keep going back to view 1 to find it.

cheers

Will

[Webs]

Originally posted by Michael Dorosh:

Where can I DL your grass mod?

[Michael Dorosh]

Originally posted by Webs:

</font><blockquote>quote:</font><hr />Originally posted by Michael Dorosh:

Where can I DL your grass mod? </font>

[Wicky]

Wheatfield Mod