Jump to content

OlafP

Members
  • Posts

    20
  • Joined

  • Last visited

Posts posted by OlafP

  1. 1 hour ago, 37mm said:

    I would've agreed with your conclusions except for one issue... I cannot recreate the effect.

    I can recreate the "frame rate fluctuations that stabilize into an equilibrium" effect easily enough because, as you suggest, that's happening pretty much all the time.

    However the fluctuations I have (no matter the settings I used... AA on or off, Best/Balanced 3d model quality, high or low tree details) are only a few fps here or there... even on the edge of a forested map.

    Obviously, the fluctuations are greater when I pan & move the camera... however 10-20 fps is the usual level of fluctuation not hundreds of fps like you're getting.

    I can't seem to recreate these wild fluctuations.

    I'd suggest that you have some kind of driver issue?

    What happens when you have vsync on Fast & recreate that scene?

    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. 10 hours ago, General Jack Ripper said:

    I don't usually explain myself to people who call me a liar, so consider yourself educated

    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.

    9 hours ago, Xorg_Xalargsky said:

    I ran a similar test, but had the JTAC team face a trio of insurgents instead of a taxi.

    Upon taking fire (enemy not spotted yet), they stop and execute the Hide command. However, some seconds later they start opening fire in self-defence (as the enemy was rather close), but resume hiding after taking a few shots (and the cycle continues).

    Yes, there is always the case of AI overriding the standard behaviour. This seems to confuse people a lot.

  5. 8 hours ago, Ultradave said:

    Thanks for this. This helps a lot. I ran your saved game using my FB 2.0 installation and saw the same behavior you did, just slightly different end results but pretty much the team running around panicked.

    Then I loaded it in the patched beta version of FB and the behavior was markedly improved. In fact, I'd say, exactly what you would want. The team stopped at that row of bushes (not really a hedgerow), either kneeling or prone, took a couple shots at an enemy soldier in the stone courtyard in front of them, who then appeared to run off, then took a couple rifle shots at a Sherman that suddenly appeared far off through the trees - presumably to make it button up. Then they hunkered down. All four guys in the same place, no running in circles, screaming and shouting. Proper behavior.

    That should cut through the remainder of the above discussion.

    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. 1 minute ago, Bulletpoint said:

    I always believed the suppression meter showed an indication of the objective amount of incoming fire a team is taking. And I believe veterancy just makes the meter empty quicker, as well as possibly making return fire more accurate despite suppression. But it's possible I could be wrong here.

    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. 3 minutes ago, Bulletpoint said:

    Your video doesn't show the suppression meter, but it does show your troops are green, nervous and under bad leadership. That means they will drop down much faster under suppression. I still believe it's the suppression caused by the incoming fire that makes them react - not because the way the hunt command works.

    If we assume that the hunt command makes troops stop and drop on receiving fire, then well led, highly motivated veteran infantry should do the same.

    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. 17 minutes ago, Bulletpoint said:

    The team does notice taking incoming fire - this is shown by the suppression meter rising. When the meter becomes full, any movement order is cancelled and the team drops down. This happens both on hunt and on the other movement modes, so it's a different discussion.

    And if the team also takes a casualty, the suppression meter very quickly goes to max. I believe this is what you're seeing in the case of the unspotted marksman.

    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. 15 minutes ago, Bulletpoint said:

    Straight walls always run through the centre of the action spots, dividing them in two, so I believe that pixeltrooper intended to stay in the same square, but had to run around the wall to reposition on the other side...

    No, they don't. In this case the centre of the action spot was the corner of the building.

  10. 25 minutes ago, Bulletpoint said:

    I think you're supposed to face them more away from the building. You're clicking basically on the building itself - try to use the facing option and click on the small shed to the right instead. Does that help?

    That being said, I also have many problems making the corner-peeking mechanic work consistently, depending on what kind/size/angle of building it is.

    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. 1 minute ago, Bulletpoint said:

    I've seen scout teams take repeated MG42 bursts and still hunt on until one of them got killed or their suppression metre filled up, whatever came first.

    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. 17 hours ago, Bulletpoint said:

    The manual is wrong here. The unit only stops when actively spotting an enemy.

    (or when taking enough fire to fill the suppression bar, which generally cancels any move order)

    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.

    17 hours ago, 37mm said:

    You are confusing 'hunt' with the (in my opinion) superior "move to contact" order of CMx1.

    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.

    16 hours ago, IICptMillerII said:

    In this video it appears that the TacAI is performing the new "cornering" mechanic added in v4. That is, the team was given a face command outward along the building they are behind, which tells them to peak around the corner. The one soldier who moved to the other side of the building was doing this as well, he just had to run around a wall to get there. Personally, I do not see a problem with behavior in this second video.

    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.

    Quote

    The scenario in the first video you posted is a lot more complex. First off, do you have a save file of the replay of this turn to share?

    Yes: https://ufile.io/tx7n7

    Quote

    I've watched the clip a few times and I can't really figure it out. At first, I thought the team had taken fire first, causing the team to displace. However, it appears that this is not the case. The team spots one enemy team, and without taking fire appear to displace, which is when they run into the open and get gunned down. If I were to guess, it appears that when your team spotted the enemy, it triggered the TacAI to displace. This is odd, as normally that behavior is only triggered after taking fire. It's possible that a combination of the 4.0 TacAI, along with the specific move command you used (Hunt) and the nature of the immediate terrain all conspired against you to produce the result you recorded. 

    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.

    Quote

    I understand that this is frustrating. No one likes losing units, especially when it appears that they were killed by a glitch/bug. My advice would be to first, send/post the save file of the replay (if you have it) here so that beta testers and those curious can load it up and see for themselves what happened. Second, right now it is best to wait for the upcoming engine patches to be released. I know for a fact that the patches will be addressing a number of TacAI behaviors in 4.0 and fixing them. It is very possible that the behavior you saw in the first video will be mitigated/eliminated from happening again after the patches are released. 

    No worries, thanks for acknowledging the issue. I will hold back further reports until I have tested the new patch.

    Quote

    In the meantime I would recommend replacing the 'Hunt' command with the 'Slow' command in situations like your first video. Added with a 'Hide' command, this would have caused your team to crawl up to that hedge and remain prone. Then, the following turn you could turn off the 'Hide' command to allow the team to sit up and look out over the yard to their front. Also, a liberal application of the 'Pause' command helps to mitigate the current 4.0 behavior.

    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.

    10 hours ago, MikeyD said:

    You place the units in a no-win situation in a maze-like environment where movement choices are restricted then are surprised when there's a negative result. Its like claiming a car is defective if it doesn't stop you from deliberately driving off the road into a ditch.

    You can't be serious?

  13. 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.

  14. 18 hours ago, General Jack Ripper said:

    Actually it is.

    You are not very familiar with how the 'Hunt' command works.

    The team spotted enemy troops, which causes the string of orders attached to the Hunt command to self-cancel.

    Which means the team won't hide or face, so they open fire instead.

    Hunt is used as a "move until you see something" command. It's not a "move slowly this way then hide" command. Attaching other commands to a "Hunt" order only works properly if they don't see anything.

    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.

    18 hours ago, 37mm said:

    I suspect Ripper has it right... I've always found the "Hunt" command to be a bit of a risk in a potential CQB situation.

    Try the experiment again with a short quick dash (or a crawl).

    Also run the experiment at night/thick fog (so that the subjects cannot spot anything & cancel the Hunt/facing commands).

    I reckon you'll see much improved behaviour but it'd be interesting to know.

    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.

  15. Bulletpoint: Did you replicate the facing order? I've run some more tests, and that seems to be crucial here. I can induce what I think is the intended behaviour (stopping at the wall corner, hiding, one soldier peeking, no fire) by changing the facing. 

    I don't think it's a small bug when they just run out into the open like that. I have several examples of similar odd behaviour and most of the seem to be related to corners/peeking. I don't think I'm going to bother recording them until the patch is released. Maybe this is just one issue expressing itself in multiple different cases.

  16. 7 minutes ago, Bulletpoint said:

    I see a team moving up to cover, then deciding to run out of cover the moment they spot nearby enemies.

    Was your team broken?

    Because in that case, it could be that the broken team spotted enemies, decided to run away, but they decided to run to a spot on the other side of the wall. Then they took the shortest path to that point, which was straight through the enemy line of fire.

    No, they were in perfectly fine condition. No nervous or rattled or anything. Suppression bar at zero.

    I've never had troops run away simply from spotting the enemy before. I don't think they can even do that, although that would have been a nice feature.

  17. What I think it shows? Isn't that obvious? I order them to hunt to and hide at the corner of the wall, and instead they move past the corner, then sprint out into the open through the hedge while opening fire at the enemy.

    The order given is not the order executed.

    JoMc67: The sprinting out in the open occurs before any gunfire, and my team is the one actually opening fire.

  18. 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?

×
×
  • Create New...