Midnight Warrior

First off, let me say a huge, Wow!!!!. Now some questions. 1.I have not seen any graphics for fox holes, only trenches. Will the game support fox holes as well as trenches? 2. It seems that there will be mines. Will engineers be able to clear the mines? If so will they have mine detectors or is that abstratced? Are different types of mines modeled? 3. I have not yet heard any explicit mention of off board artillery. Will that be supported? If so how will it be called in? Will there be special FO's or can any person with a radio do so? 4. Same question for air strikes. How are they called in? Can they hit the wrong target or even friendlies? 5. Can vehicles bog? Apparanetly they can throw tracks? Is this random are is it tied to the crossing of local terrain features like crossing fences or knocking down trees? 6. There is apparantly fighting outside the battle area. If a unit hugs the edge of the playable map can it recieve fire from units outside the playable area are is this fire just cosmetic? Well, that is enough questions for now.

In my opinion the mousewheel has been poorly used in wargames. If it does anything at all it usually controls altitude (e.g. take Command Mannsas) or map scale (COTA) and not used at all in CM! I would propose the following for CMSF. Now it seems to me that the Mosewheel is way too valuable to limit it to control just one thing. I would propose that the mousewheel would normally be made to control one of three things. 1. Map elevation with pull back increased altituide/push down decreases altitude. 2. Left/Right Rotation with pull back rotates view to the right (i.e. pixels move leftward) and push forward rotates view to the left. 3. Forward/Backward with push forward moves forward and pull back moves backward. These three mouewheel control modes would be stepped through by pushing down on the mousewheel (i.e. the mousewheel button). The current control would be displayed soewhere on the control panael at the bottom. Two additional mousewheel controls options would also be selectable by buttons on the control panel. 1. Tilt Up/Tilt Down with the forward mousewheel motion controling tilt down and the backward controlling tilt up. 2. Unit step with each click forward decrements the unit selected (like the - key in CM1) and each click back increments the unit slected (like the + key in CM1). Clicking on the mousewheel button would return the the last of the three above mnetioned normal mousewheel functions selected. It would seem to me that something like this is the best way to put a most under utilized but valuable controller to full use and shouldn't be that hard to program. Anybody agree or disagree?

I agree with eveything you have said with possibly this one exception Even a "yeah, we added some floating point calculations" perhaps on a dialy basis is a waste but on a weekly basis would, IMHO, be nice to hear. But on the other hand it would probably not satisfy.. so maybe you are right after all.

There is also blind speculation 6: They have hauled in a fat government contract and are up to their eyes in alligators trying to get that out the door before they return to servicing us. And if that is the case that might not be all bad for us.

Perhaps a nicer way to say this is.. I might suggest that you try a doing search in that these topics have been discussed previously in some detail.

Also, mines can have a spotted state (both as to whether the minefield itself is spotted or the 1:1 mine is spotted). If a mine is "found" and "marked" (say with a bayonet poked in the ground beside it like in the movies) or has been "stepped by" i.e the follow on men are carefully stepping where the lead man stepped then the probability of a mine being triggered by the dice roll could be reduced. Thus perhaps when a man gets close to the mine the results of the dice roll (adjusted by its spotted state) could be boom, found and marked, marker with footprints, not found. Boom is obvious. Found and Marked means that the mine is somehow marked (like with a bayonet) and all men regardless of whether in the same unit or other units have a greater probablity of spotting the mine. Perhaps the owning unit to the man that spotted the mine might have a higher probability of spotting the mine so that we don't have borg mine spotting. Marked with Footprints would be just like Found and marked except that it would only be applied to the unit inwhich the man that step by the mine was in (i.e only those close to him could follow his footsteps unless perhaps they are preserved in mud or snow in which case that is more like the find and mark results). Also, this result would only be applicable if either the minefild itself is spotted or that perhaps the player might have a special command like watch out for mines. "Unfound" would men that everyone is clueless that they are in a minefield in that the minefiled itself is not spotted (or maybe it is spotted but they are moving too fast to take proper precautions) and hence are not carefully stepping where the lead guy is stepping and thus the mine is not "spotted" by stepping by it. All this mine spotting logic could be adjusted for vehicles, mine clearing vehicles, and leg engineering units as appropriate. edit. fixed a few typos. [ February 18, 2006, 10:32 AM: Message edited by: Midnight Warrior ]

I don't think that 1:1 mines would be that hard to program nor require that much CPU time. The key is that each mine would be associated with a localalized group of mines as in a minefield and not as individual mines scattered totally at random all over the map. That way only when a unit is in a minefield (which would be typically a small percentage of the time) would the software have to make the additional 1:1 checks. Also, it's not like these checks have to make LOS checks or anything that computationally intense but merely the software has to check if a man/vehicle comes within the fusing radius of the mine. This does not mean that the computations have to be down to the inch but rather if the man gets withing a foot or two the dice is rolled to see if there is a boom. (Also, for trip wire triggered mines this may mean passing between two points rather than one). And once a mine goes boom it is deleted from the minefield. Also artillery rounds that impact in the minefield could be checked to see if they trigger mines in a similar manner.

I was thinking that it would be neat if in CMX2 there would be a way to click on any object in the 3D visual and have it give you its .bmp ID number. That might make modding a bit more straight forward. Thus if you click on the bark of a tree and selected this option it would tell you the .bmp that contains the bark texture for that tree. If you click on a tire on a vehicle it would give you the .bmp number for the tire, etc. Don't know if that would be hard to do. The graphics software obviously has to know where each texture file is so it draws it on the screen. Don't know if reverse navigation from the graphics back to the texture file is easy or not.

Hey, I love it..green on green!

I wonder if you will be able to have a mix of red/blue against red/blue?

Here is a link to a wall penetrating/motion detection radar that uses ultra wide band technology. web page

I am hoping that some of these buttons will be used for configuring the mousewheel and stepping to other units. I like not having to use the keyboard and running things with the mouse (lazy I guess)

Given a UAV has streaming video whateverit sees on its sensor would be intsantly viewable by the operator at the ground control station. This begs the question of how this knowledge gets back to both the ground units and the human player. In CMX1 even though a CAS "pilot" saw something neither the human player nor the on map ground units saw what the pilot saw. In CMX2 will the UAV ground operator be more like the CAS pilot in CMX1 or like another ground unit where the player can see what the round operator can see but the other ground units are subject to the anti borg spotting rules. It wil be interesting to se how this is handled as to whether a UAV is modeled like any other on map unit or will it be abstracted.

Oh, I forgot to mention the punch line which is ... one doesn't need to have a high fidelity 6 DOF flight model (like in a flight simulator) to model UAV's in CM:SF.

It would seem that UAV's in many ways coud be handled as any other unit (paricular small UAV's like a Raven). They could be given waypoints which would traverse much ike a ground unit. They could spot units much like a ground unit. They could be shot at much like a ground unit. Of coarse there also are differencies between UAV's and ground units that would have to be accounted for. The UAV waypoints would also have to have a specified altitude of either AGL (altitude above ground level) or ASL (altitude above sea level. They would also have climb and dive limits (these could be specified as a maximum climb angle (say 10-20 degrees) and a maximum dive angle (say 30-40 degrees). However, in general UAV are not dogfighting or flying fancy 3D maneuvers but typically would be flying wings level flight bewtten waypoints with a small amount of climb and dive and a medium banked turn at each waypoint. The command altitudues for each waypoint could be limited by these maximum climb/dive angles. The pitch and roll rates would be sufficiently high that the vehicles could be assumed to intstantaneously pitch and roll attitude. The UAV's would have a mimimum turn radius (just as a ground vehicle does)but it would be governed by R=V^2/A where R is the turn radius, V is the speed and A the hoizontal acceleration in making the turn. Say for a coordinated turn (i.e. a turn where the vehicle does not loose any altitude because t maintains a 1 G vertical component)where the bank angle is 45 degrees A (acceletation) would be 1 G (or 32.2 ft/secs. For a slow moving UAV's like a Raven this would be a pretty tight turn radius (for an aircraft that is). For a speed say of 50 knots this would be a turn radius of about 214ft. If waypoints are limited to be greater than this turn radius then the UAV should be able to follow the routes OK. The rules for spotting enemy units could be similar to a ground vehicle except that it would be limited to the FOV (field of view) of the imaging sensor on the UAV. The imaging sensor could be pointed at a spot on the ground (i.e ground stabalized) or it could be in a push broom/snow plow mode where is stares at a fixed angle in respect to the vehicle. The new command structure looks like it could easily accomodate these new command options such as command altitude. The vehilce can be drawn graphically just like a regular ground vehicle. Thus there would be some special coding for modeling small UAV's but not perhaps as much as one might think. Finally, targets seen by the UAV (or by any unit for that matter) could be data linked to other units given that they are on the same comm net and given suiable delays. Finally, the ground control station could also be modeled but it typically would likely be off the map for most situations. edit: corrected a few typos. [ November 05, 2005, 07:09 PM: Message edited by: Midnight Warrior ]

Just imagine how these types studies would have rated WWII vehicles The Sherman is under gunned and torches up too easily and does not have good flotation The Tiger is too heavy, too expensive, too slow, the turrent rotation is too slow and it breaks down too easily US Tank destroyers too lightly armored to stand up to heavy German armor US Halftracks are too under armored Has there ever been a perfect military vehicle?

Perhaps to maximize code reuse a near term SF game could be develped that has aliens attack NATO in 2007 where Strkers and M-1's et al fight alien technology. This would reverse the technology imbalance in CM:SF where NATO would be the underdogs. The scenario might be aliens intercede in behalf of the Syrians (why not?) after NATO attacks Syria... or maybe a it could be another war of the worlds variant (less Tom Cruise) with alien vehicles on walking tripod legs that can shoot down LOSATs in flight with their ray guns...or something like that.

You know, a 3D, WEGO, computer version of AH's Starship Trooper wouldn't be at all half bad! ..You know, I could never quite bring myself to see the movie in dread of what a hatchet job they probably did with the book.

How 'bout CM:PA Combat Mission: Prelude to Armageddon ..that ought to jazz up sales! edit: or maybe better CM:RA Road to Armageddon

I am hopeing this means that we will have both Strykers and M-113's in CM:SF so that we as players can make our own (humble) conclusions by employing either vehicle type and seeing how it plays out in the game for various situations.

I am thinking (or at least hoping) that with the 1:1 modeling, units, per se, don't take hits but rather the fire is directed against individuals. Thus if a mortar round goes of next to a leader then it is the leader that takes the hit. And for direct fire perhaps the shooters are not just aiming at a unit but at a specific person (or group) within that unit. BTW (as per earlier post) this doesn't mean that a LOS calculation is made on a per person basis but I am hoping that fire resolution is. Edit: fixed some typoes

Wow! 200m x 400m area of assured destruction! Of all those nasties this seems by far the nastiest! edit: added link [ October 23, 2005, 07:40 PM: Message edited by: Midnight Warrior ]

Perhaps one of the reasons Israel and Russia employ heavy APC's because they don't have to deploy them globally.

Interesting links. I wonder if CM:SF will include M-113A2's and A3's? Also, I wonder if it will model the Stryker's turning radius and the limitations it has in negotiating 90 dgeree turns on narrow streets for MOUT?

Here is an interesting article that might shed some light on what would make a credible background story. Apparantly (according to the article) there is some connection between Syria and Iran. Perhaps the Iranians starts something and the fire spread to Syria. Perhaps NATO gets involved becuase the situation becomes too threatening to Europes oil lifeline. Perhaps there is a wider war with Iran and Syria is just one part of a bigger war just as in Iraq and Afganistan. article BTW, by cited this article I am not endorsing any or all of what it says rather this is just FYI