GJR144

I did a few tests with Kübelwagen VS Snipers and SPW251/1 VS Snipers. To my surprise the KW is absolutely safe. The snipers do not shoot at it. When it reaches close combat range grenades are thrown at it and it is destroyed. The SPW 251/1 are completely different: the snipers open fire very early. If the vehicle is open and as long as the gunner has a covered arc, he is more safe than the driver. Had not a single hit on a gunner during my tests, but several hit drivers. Once the gunner uses the main gun, he is no longer safe and immediately is under fire and easily hit. It doesn't matter if he shoots at the sniper or area fire in front of the SPW. The gun use seems to be the deadly trigger for the gunner.

It's getting ridiculous. The OKH movies were produced not for fun and they did not teach a wrong use of the weapons. There is a bug with HT gunners as soon as they use the weapon and denying the historical use will not solve the bug.

The enemy has been under fire, but the attack is lead with SPWs and they lead the attack and drive THROUGH the enemy positions and cut them off. It is not even mentioned that they should stay back and only support the infantry. And after cutting the enemy off, then the SPWs even are placed IN FRONT of the regained HKL - to protect it. It is also demonstrated that the SPWs are endangered by antitank teams, not by bullets.

Ofcourse. Didn't you know the Wehrmacht used SPWs as trucks because it had too much resources and fuel. Please give me a break from these "experts". There obviously was found a bug. Has this bug been solved in the meanwhile?

You didn't watch the video, did you?

db zero, please watch the video i provided. The SPWs were expected to move through enemy infantry. They obviously are not easily penetrated (a truck would be much cheaper) and the gunner is quite well shielded and a tiny target. Any aiming infantry against the SPW must expose the full head, while the gunner in the HT from the front is only exposed with a small portion of his head. And when the vehicle is moving, it gets even harder to hit the small area. It's only a feeling, but my impression is, that gunners in SPWs are not much more protected than the crew of unarmored and unshielded vehicles like Jeeps. Would be an interesting test.

I also think they are too easily knocked out. Like flies. If this would be correctly modelled the OKW's advice of the correct use of the 251/1 would have not been that way: http://youtu.be/L32rban714c?t=2m07s

You claimed that bunkers were treated as vehicles. Then I tried to explain for complete idiots the concept of OOP and now you bring the LOS map. The LOS map is an abstraction object to reduce CPU demand! The LOS map has nothing to do, how objects are modelled in the game. Again: how LOS is handeled says NOTHING how the objects are modelled within the game. You are making technical conclusions about inner game mechanics you can't do without detailed knowledge about the class structures.

Learn OOP, then you maybe will understand what I'm talking about.

Why not? Each object can have LOS and LOF methods and they do not need to have anything in common at all, or these methods could even be identical. That the enemy LOF is blocked, is almost the proove that the model is represented in 3D for certain demands, while it is only represented as point for other demands. An explanation could be, that as a design decision LOF blocking for enemy units is seen as more necessary than blocking LOF of friendly units. This could mean, if an enemy projectile hits an object a 3D-calculation with data from the 3D-model is used, while friendly fire ignores certain objects and therefore this safes CPU cycles. If you assume a 50:50 friendly:enemy force, this could reduce the CPU cycles for these calculations around 50 percent. This must not necessarily be a CPU issue, but maybe it's just a tiny bug: maybe the method used for vehicles is being reused for bunkers and the label simply has not been renamed yet? Another aspect: Buildings use a more complex LOS calculation. But contrary to vehicles this complex calculation is initiated only, if the action spot is in LOS. This also indicates, that things must be highly optimized and all kind of tricks are used, to keep the processing power down. Maybe they could replace all the optimizations easily with methods dealing all the time with the 3D-models? But then maybe the necessary amount of RAM would become that huge, that it would become unplayable on most machines? It is important to understand that in OOP the object and it's behaviour (methods) are two completely different things. That's the beauty of it. Objects can be completely changed without any impact on the rest of the program, or the behaviour of objects can be completely changed without touching the objects. What we see on screen is only the result of the intentionally used behaviour of the object, but the user does not know, how complex - or how simple - the underlying objects really are. It's like observing shadows. How the real things that create the shadow look like, can't be judged by looking at the shadow.

I only play blind against the AI, otherwise it's no challenge.

Your understanding is correct IMO. But being a 3D model, doesn't mean, that every answer this model gives must be a full representation of it's 3D model. For example if I ask you, where you are now, you could tell me the coordinates of the mass centre of your body, or you could give me a full 3D-CAD-model with all coordinates. You obviously would tell me only the coordinates of a point, although you are a 3D object. This means, that bunker objects or vehicles, although they are fully modelled in 3D, could have methods implemented, to allow an efficient calculation without the need to make demanding calculations with their 3D-model. Imagine the bunker-object as being fully defined with all coordinates and all kinds of variables and behaviour. But besides this detailed model, the model also can answer in any way, it is programmed to answer. For example two methods: TellMeYourPosition and TellMeYourPositionQuickly The first method could mean that a 3D-model is returned, with coordinates of all corners, while the second method could be defined as returning only the coordinates of the centre of the action spot, where it is located. We don't know, if the LOS procedure asks the model for a simple and fast answer, or if the model can't give a detailed answer because it is only a vector with an associated graphics model and therefore is returning only a simple answer. Steve has mentioned, that the models are indeed fully 3D. Therefore I'd say, that what we see with the LOS-tool is the result of a quick and simple answer. Not because it was not possible to give a precise answer, but because of technical restrictions which I think are CPU related.

If I wouldn't be able to read the text in briefings or the number of the remaining bullets, I would switch to a lower resolution to be able to read again. But if I would have such bad vision, then I wouldn't need this high resolution anyway. And a lower resolution additionally gives me a higher framerate and better graphics. Three flies with one clap. This doesn't mean that a scaleable interface wouldn't be nice, but there is a difference between necessity and convenience.

An explanation could be, that bunkers like vehicles or infantry can shoot projectiles, while buildings can not. To trace every projectile at every single moment, these objects maybe need to be called extremely often in comparison to buildings and maybe this forbids with a single threaded software, to make a full LOS calculation? Handling the whole 3D-model instead of handling a single spot: we could easily be talking about increasing computations 10fold or 100fold for each object that is able to shoot. Or to say it differently: maybe a single vehicle or a single bunker, in case of full 3D-calcs in stead of being treated as spot, could have a calculation demand equal to maybe 10 - 100 buildings. CPU demand is the only real reason I see, why this restriction is there. Given the quality of BFCs software, I don't think that this is simply an unintended consequence of inadequate classdesign.

CMx1 probably was not strictly object oriented programmed and therefore things at the engine were so extremely complicated to change. CMx2 is much asier to improve, because it obviously is strictly OOP. How LOS or LOF are treated, must not necessarily mean that the bunker class is inherited from vehicles or that both have the same superclass. Maybe the LOS-method is treating these objects simply as spots to save CPU cycles?

Why not reduce the resolution until you can read things again and a good compromise is found?

Tanks as a child class of bunkers (or vice versa) seems very far fetched to me.

Use the 1024 resolution and your eyes will tear with activated MM.

It was a very big disappointment for me, that AA still doesn't work with MM. Low resolutions are THE cure to improve framerates. And then AA becomes very important. It's a shame that Nvidia doesn't allow to create color profiles but I searched the net for color profile software and found two interesting solutions: CPKeeper (Color Profile Keeper) Monitor Calibration Wizard Both should allow to create a suitable color profile and use it while playing CM and afterwards switch back to normal colors.

I also noticed in CMFI:GL that A temple to Mars crashes, if I load it after I had previously loaded another game. CM is not running on Java with a fully automated garbage collector. Do you have the same problem when you load it as first battle after starting CM?

I think too much control takes away what makes CM special. It is the uncertainty. Especially when dealing with the metallic beasts, it is nail biting. The difference with and without such a command would be dramatic: Currently the player has to weigh the pros and cons of a longer pause. 5 more seconds can decide about failure or success. Successful escape or losing the unit. The player can't be sure and that increases the tension. And he must take into consideration the troop quality. How much time will they need to ID the target? Time to aim? With such a special command for easy success the player has nothing to decide anymore, just plot the waypoint. BORING.

The Wehrmacht replacement doctrine was completely different from the western Armies. Contrary to the Communist and Capitalist egalitarian view, that 1+1 people was 2 people, the Wehrmacht respected that 1+1 people being MORE than 2 people. Therefore units that trained together were not torn apart. If possible units even were formed around a common regional heritage.

Imagine CM would have an Iron Man Mode. That would really teach what chaos means.

A simple number for each asset in the roster would be very helpful to manage artillery plans: Currently I'm playing A Temple To Mars. A fantastic map in the mountains and a big battle with impressive amounts of artillery. The problem: the artillery assets have no unique ID. It's cumbersome to count the artillery asset number by hand always from the beginning, to know which asset was called by which observer. For example: a game has 16 artillery assets, 8 on field assets and 8 off map. The off map assets consist of 4 81mm mortars. The 16 assets fill 4 rows (1 row shows 5 assets). Company 1 calls the third 81 mm off field asset. Which in the artillery menu would be somewhere in the third or fourth row. For me it's impossible to keep an overview without an unique identifier for each artillery asset. Was it the second or third 81 mm asset being called by Company 1? A solution would be, to give each field in the roster a number. So the player would only need to write down: Company 1: #13. Then he would automatically find the asset on the roster with the number. No need to switch through the roster and count by hand.

Nvidia GTX560, WinXP