Jump to content

OlafP

Members
  • Posts

    20
  • Joined

  • Last visited

Profile Information

  • Location:
    Norway

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

OlafP's Achievements

Junior Member

Junior Member (1/3)

7

Reputation

  1. The issue is not the fluctuation itself, although that is pretty annoying too. The issue is that you end up with terrible fps whenever the fluctuations stabilize. The fluctuations would be a lot less wild on a less powerful graphics card, since the system would not be able to take the fps so high. That could possibly explain why you are not seeing them. V-sync doesn't make any difference.
  2. 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).
  3. Btw., some people seem to think that Hide commands attached to a waypoint only apply after that waypoint has been reached, but this is not true. Look at this example. The team on the left is given a zig-zag move order with a Hide command at the end while the team on the right is given a similar order except the Hide part: The team on the left seems to be much more cautious, sometimes going prone and even hiding at each waypoint, while the team on the right never hides and always uses a kneeling posture.
  4. 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.
  5. That's great to hear. I would still like to lobby against infantry opening fire on tanks with rifles, though, but I guess that's a whole different can of worms to open.
  6. Well, it could be tested by changing that scenario to only have Elite troops. I think you'll find the exact same behaviour, but it might be more difficult to find a case, since Elite troops are much more likely to spot the unit first.
  7. 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.
  8. 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.
  9. No, they don't. In this case the centre of the action spot was the corner of the building.
  10. No, that just made them stay away from both corners. It's very finicky. Sometimes they corner post without any input, sometimes you have to spend several turns to find the right angle, and sometimes they don't seem to be able to do it at all.
  11. Yeah, I've seen that as well. But I think it's just the game going a bit too far in modelling the difference between actual incoming fire and perceived incoming fire. Usually spotting occurs before the unit perceives incoming fire, which is a bit strange. In cases where spotting is hard but incoming fire is easy to perceive (such as a sniper far away), they do stop when taking sufficient incoming fire. The saved game I provided can actually be used to test this easily. On the right side, I have a platoon hunkering down in the open because they took several casualties from an unspotted marksman.
  12. Yes, here it is: https://ufile.io/tx7n7
  13. 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?
  14. Here is another video of a team suddenly changing to an entirely different action spot when there is a junction and a Face command involved: This seems to be related to repositioning and junctions. The AI seemingly gets confused when there is a junction involved and sends all or part of the team to the wrong action spot. Another reason why I don't think TacAI self-preservation is involved, is because TacAI self-preservation always issues either a Fast- or Slow-command, but the team in my example seem to be entirely orderless.
  15. Uh, no this is nonsense. The hunt command certainly is not supposed to cause soldiers to Fast into incoming fire and it does not cancel the Hide-command when contact is reached. This is one of the most useful command-combos in CM, in fact, because it allows you to move to contact, stop and hold fire as soon as contact is reached. In other words, you can recon without engaging in a firefight. It has been a mechanism in CM since Barbarossa to Berlin. That is 17 years almost. Okay, do you really think this is not a bug and simply me being bad at the game, or are you trolling? From the manual: "Infantry - this command maximizes the unit’s awareness for possible enemy contact. Soldiers advance slowly, weapons ready. Upon seeing an enemy unit, or when fired upon (even if the enemy is not seen) the unit stops immediately. This is a good command to use when enemy contact is imminent." They are not supposed to run forward. Later in that paragraph, the devs even recommend to use this command in CQB: "Example - Hunt is very useful for cleaning out houses which are suspected to have enemy hiding inside, or as a “move to contact” order for tank". I don't think either of those commands you suggest are appropriate in this situation, but that is rather irrelevant to the topic of this thread.
×
×
  • Create New...