OlafP

OpenGL might be bad, but it's not going to hold back your fps like that in a game that has very simplistic graphics. And game calculations are not the culprit, because when you move the camera off map, and frustum culling kicks in, the fps skyrockets. When you move the camera on map again, the fps is back to its low rate. Hence, the poor performance is caused by the rendered geometry, not game calculations. It wouldn't make any sense to do game calculations in the orders phase anyway, because those calculations would be dependent on orders that aren't yet given.
When you position the camera with only a slight portion of the map exposed, something interesting happens:
This is on a GTX 1080, I have nothing running in the background and there is no input from me. The game engine is choking that graphics card while producing nothing but a few trees and a small patch of ground!
Notice three things:
- The framerate fluctuates from very low (around 7 fps) to very high (approaching 300 fps). 
- The framerate eventually stabilizes at a constant fps that is relatively low (43 at the beginning of the video, 54 at the end).
- When the trees and ground are rendered in high detail, the framerate is high, while it is low or lower when they are rendered in low detail. The only exception to this is when the framerate is stable at either 43 or 54.
So from the last point, we can deduce that for that given perspective, I should be able to have very high fps AND high detail at the same time. 
What I think is going on here is that the game engine is constantly trying to reduce or increase the level of detail based on current performance and current level of detail. It does this by going into a negative feedback loop which eventually stabilizes at an equilibrium based on the given graphics setting (fast; faster; balanced etc.). The only problem is that this mechanism itself seems to be taking up a lot more GPU power than whatever small amount is required for the rendering. The consequent reduction in performance, caused by the LOD simplifier, is then fed back into the feedback loop as input, causing the whole system to run the game at an fps rating and detail that has nothing to do with available system performance.
I used to play this game, or engine, on an old laptop back in 2012. The game performed comparable to what it does on my GTX 1080 today. Clearly, this doesn't make any sense. What seems to be going on is a self-defeating system that holds back performance on modern computers (but might possibly function properly on laptops or low-end systems). 

OpenGL might be bad, but it's not going to hold back your fps like that in a game that has very simplistic graphics. And game calculations are not the culprit, because when you move the camera off map, and frustum culling kicks in, the fps skyrockets. When you move the camera on map again, the fps is back to its low rate. Hence, the poor performance is caused by the rendered geometry, not game calculations. It wouldn't make any sense to do game calculations in the orders phase anyway, because those calculations would be dependent on orders that aren't yet given.
When you position the camera with only a slight portion of the map exposed, something interesting happens:
This is on a GTX 1080, I have nothing running in the background and there is no input from me. The game engine is choking that graphics card while producing nothing but a few trees and a small patch of ground!
Notice three things:
- The framerate fluctuates from very low (around 7 fps) to very high (approaching 300 fps). 
- The framerate eventually stabilizes at a constant fps that is relatively low (43 at the beginning of the video, 54 at the end).
- When the trees and ground are rendered in high detail, the framerate is high, while it is low or lower when they are rendered in low detail. The only exception to this is when the framerate is stable at either 43 or 54.
So from the last point, we can deduce that for that given perspective, I should be able to have very high fps AND high detail at the same time. 
What I think is going on here is that the game engine is constantly trying to reduce or increase the level of detail based on current performance and current level of detail. It does this by going into a negative feedback loop which eventually stabilizes at an equilibrium based on the given graphics setting (fast; faster; balanced etc.). The only problem is that this mechanism itself seems to be taking up a lot more GPU power than whatever small amount is required for the rendering. The consequent reduction in performance, caused by the LOD simplifier, is then fed back into the feedback loop as input, causing the whole system to run the game at an fps rating and detail that has nothing to do with available system performance.
I used to play this game, or engine, on an old laptop back in 2012. The game performed comparable to what it does on my GTX 1080 today. Clearly, this doesn't make any sense. What seems to be going on is a self-defeating system that holds back performance on modern computers (but might possibly function properly on laptops or low-end systems). 

Oh, they stop and hunker down when they take incoming fire. I think you might be confused by the fact that squads sometimes do not realize that they are taking fire in CM, even though sound and graphical effects indicate to you as a viewer that they are.
No, I'm not confusing anything. Look, test this out, it's very simple. CM has had this feature since BtB. It behaves exactly as it did back then.
Yes, the cornering mechanic, but they're supposed to position at the corner indicated by the face command, not the corner which the face command points away from. From the manual: "If you only wish to man one corner and not the other, give the team or squad a facing command angled slightly towards the corner you want, and away from the one you don't.". That's not really the issue I had in mind though. The problem is that they are repositioning to an action spot on the other side of the wall. It didn't have any bad consequences in this example, but in the first one it did. I do suspect that there might be some overlap of issues here.
Yes: https://ufile.io/tx7n7
Well, like I said, the Hunt command normally does not behave like that and is not supposed to behave like that. They're supposed to hide, not open fire. Hunker down, not reposition. I don't think they're displaced in the sense of self-preservation. They are reevaluating cover based on either the face command being reached at the end of the command chain or new information popping up. Or both. That causes the unit to erroneously think that it needs to move to the other side of the wall, just as in the second example I gave.
No worries, thanks for acknowledging the issue. I will hold back further reports until I have tested the new patch.
Well, according to the manual Crawling soldiers tend to pause and return fire at nearby/ exposed enemy troops often, then resume moving. That's not really what I wanted here, especially since there are tanks in the background and infantry often open fire on tanks. I've found that a crawling soldier is often a soon-to-be dead soldier in this game. I rarely use it. I guess what I could have done was to issue a Target Arc command, but it seems that if they ignore the Hide command, they will ignore the Target Arc command as well.
You can't be serious?

You are obviously a very ignorant and arrogant asshole, but nowhere did I call you, or imply that you were, a liar. I didn't even explicitly call you those two things.
Yes, there is always the case of AI overriding the standard behaviour. This seems to confuse people a lot.

Obviously, when the unit notices incoming fire, the suppression bar is going to change. So saying that the suppression bar is changing and that the unit notices incoming fire is the same thing. What seems to be your point is that the suppression bar needs to be at MAX in order for units with the Hunt command to stop moving, and therefore that there is no difference between the Hunt command and other commands in this regard. This is wrong. Here is an example I just recorded from my savegame:
The interface got cut off for some reason, but you can see that the suppression bar is not at max. In fact, it is only slightly elevated, and there are no spotted units, only sound contacts.

No, the suppression meter is a reflection of subjective suppression, in other words suppression relative to the current variables of the unit (experience, moral etc.). It is not a measure of objective, actual incoming fire. That's why you see the suppression meter going bananas when Green troops take fire, while it changes only slightly with Veterans in the same situation.

The tacAI seems to be very dysfunctional when it comes to infantry moving around corners of buildings, walls, and the like. In fact, entirely broken in some cases, I would say. I've found various bugs related to pathfinding in particular. Don't know if there is any point in posting this now, since I understand that there is a patch underway, but here is a typical example:
Btw. is this the proper place to post bugs?