Irrational Behaviour

[CanuckGamer]

It was my understanding that the patch for Game Engine 4 corrected the issue of units running out in to the open when under fire instead of remaining in their positions and using the terrain they are in for cover.  I am playing a PBEM game of Carentan which has lots of hedgerows as the Germans.  A number of times I have had units hidden behind hedgerows run in to the open toward the enemy when they came under fire.  The unit info does not indicate panic but in some cases it says "tired".  Maybe this still a bug?

[Howler]

A tweak is expected. Meanwhile, for your reading pleasure...

 

[JoMac]

Now, what I want to know...Are Units Running away in due time depending if Green, Vet and in what types of Cover....I think I remember someone saying that 'Green' troops in buildings are too resilient and most of the troops die in place before finally moving out of cover. This could also mean Vet troops will most likely die in place to the last man before leaving said cover ?

I would figure  'Fortifications' in general would give most quality troops a higher resilience factor (fortification bonus if you will), but troops in lesser cover (woods, buildings, etc) would still have them run from cover in short time (a bit longer if Vet, etc). 

Edited June 11, 2019 by JoMc67

[CanuckGamer]

I am the Germans and  had two veteran squads behind hedgerows.  The Yanks who were not behind cover.  After about two minutes of mutual fire,  one squad had one casualty and one wounded.  At that point the squad left their cover and started running in the direction of the Yanks in front of the hedgerow as there was an opening with a fence beside their position.  The other squad did something similar about a minute later.  The end result was that both squads were decimated.

[Wicky]

 

[Michael Emrys]

2 hours ago, CanuckGamer said:

The end result was that both squads were decimated.

'Decimated' or 'annihilated'? People often use one word when the other is intended.

Michael

[CanuckGamer]

About half of each squad was killed.  I was talking to my friend who is playing the Americans and he told me he was using area fire as he couldn't spot me  so that really indicates to me that my squads panicked.  Looks to me like they really need to revisit the fix that was supposed to be in the patch.

[Zardoz01]

This behaviour is definitely still in CMBN 4.01. I saw it last night on two occasions when teams who were pinned, but as safe behind soft terrain as they were ever likely to get, proceeded on the next wego turn to a) run out in front of the cover and b) move *towards* the enemy.  Needless to say they were Mentioned in Dispatches... under the f***wit section...

 

[Heirloom_Tomato]

This issue has been reported and fixed according to the post in this thread from BFCElvis. When the patch to the patch, the patchy patch, comes out, this problem should go away.

[RockinHarry]

If that´s a bug, I hope it gets or got fixed. I always assumed it was sorta (minus) leader decision failure, where the leader judges the enemy threat plainly wrong and send his guys the wrong direction. But the game engines "seek cover" routines always keep puzzling me anyway. It just sort of looks for "better cover" but simply forgets about a "covered" way toward it. While one can always say it´s FUBAR and games fuzzy logic sort of where bad going random events could happen, I remain at the conclusion that it´s all not coded too well simply. Maybe it´s for game resource saving purposes, but I more often than not find it almost "game breaking". The more if BFC rarely explains their decisions for doing this or that. But puzzled customers like me then avoid buying more their games, even if I´d like to. 

[BletchleyGeek]

2 hours ago, RockinHarry said:

But the game engines "seek cover" routines always keep puzzling me anyway. It just sort of looks for "better cover" but simply forgets about a "covered" way toward it.

Leaving value judgements on coding quality aside, you are right that in cmx2 the concept of cover (or more generally, being "safe" from observation or fires) is a static attribute of map tiles, it does not seem to change during the game as units positions, orientation or stance changes. They react to incoming fires on map tiles, though.

In other games we faked situational awareness by keeping, per side, "anti personnel fire power" and "anti armour fire power" layers on the map. This was updated every tick of the simulation, as units spot enemy units and identified their equipment and composition. Of course, this introduces potential instantaneous communication between units, an analogue of borg spotting. Keeping such a layer on a per unit basis is quite ridiculous imho, feasible for games happening on a space the size of a football pitch and not too many guys moving around.

Having said that, on a WW2 or earlier game, I can't see how the nonlocal comms that such a device could enable could be exploited - like to call artillery strikes - as long as it wasn't visible to players and only to the TacAI.

[Zardoz01]

13 hours ago, Heirloom_Tomato said:

This issue has been reported and fixed according to the post in this thread from BFCElvis.

Excellent! 

 

13 hours ago, Heirloom_Tomato said:

When the patch to the patch, the patchy patch

Like that backbone of the internet, the Apache web server, so-called because it is a patchy server... 

http://xahlee.info/UnixResource_dir/open_source_rewrite_history.html

[RockinHarry]

On 6/12/2019 at 11:45 PM, BletchleyGeek said:

Leaving value judgements on coding quality aside, you are right that in cmx2 the concept of cover (or more generally, being "safe" from observation or fires) is a static attribute of map tiles, it does not seem to change during the game as units positions, orientation or stance changes. They react to incoming fires on map tiles, though.

In other games we faked situational awareness by keeping, per side, "anti personnel fire power" and "anti armour fire power" layers on the map. This was updated every tick of the simulation, as units spot enemy units and identified their equipment and composition. Of course, this introduces potential instantaneous communication between units, an analogue of borg spotting. Keeping such a layer on a per unit basis is quite ridiculous imho, feasible for games happening on a space the size of a football pitch and not too many guys moving around.

Having said that, on a WW2 or earlier game, I can't see how the nonlocal comms that such a device could enable could be exploited - like to call artillery strikes - as long as it wasn't visible to players and only to the TacAI.

I´m not a coder and I think I don´t want to be any, particularly for such an advanced simulation for sure. Yet I at least attempt to take a "programmer" possible POV for getting things properly done, also to apply to a limited game time frame which I think is of major importance so that things don´t get asynchronous, more so in the RTS modes. IMO one the points where "bad" TacAI decisions are beeing made is the always use "quick" or "fast" modes to get units from point A to point B. So it possibly happens more times than not that a path to a better cover tile is faster when using a buildings front door (in view of the enemy) than the backside one (slower, but not in view of the enemy). It´s just my observations, but off course only BFC really knows what´s going on under hood. But I slight a bit dislike wasting time on discussing guessworks, when BFC could explain a number of things with a single line of text instead. 

[BletchleyGeek]

I don't like wasting my time either, Harry. I still appreciate coming here and having the odd exchange when I  think I can contribute or learn something. Maybe I was wrong in this instance and it is better that I invested my time elsewhere.

Take care.

[RockinHarry]

19 hours ago, BletchleyGeek said:

I don't like wasting my time either, Harry. I still appreciate coming here and having the odd exchange when I  think I can contribute or learn something. Maybe I was wrong in this instance and it is better that I invested my time elsewhere.

Take care.

same here mate.  Wished I could spend more time actually enjoying the game or keep goin with my mission designs instead of discussing matters that could be answered by BFC easily. The time that I supported BFC just for the sake of it is over. Definitely.  

[CanuckGamer]

On 6/12/2019 at 6:44 AM, Heirloom_Tomato said:

This issue has been reported and fixed according to the post in this thread from BFCElvis. When the patch to the patch, the patchy patch, comes out, this problem should go away.

So, has this "bug" been fixed or is there a patch to fix the patch coming out?  Your first sentence referencing BFCElvis indicates that it has been fixed but then your second sentence contradicts this.  Regardless, I consider it to be a signficant issue.

[Heirloom_Tomato]

1 hour ago, CanuckGamer said:

So, has this "bug" been fixed or is there a patch to fix the patch coming out?  Your first sentence referencing BFCElvis indicates that it has been fixed but then your second sentence contradicts this.  Regardless, I consider it to be a signficant issue.

This issue is one that has been very hard to nail down. While some people have been able to spot it every time they play a battle, the next player never has a problem. I was able to build a test map showing the problem and a fix was made. Since 4.02 came out, the test map I made has seen zero incidents of this bug showing up. So my comment of the issue being fixed was in relation to the 4.02 patch. 

It appears the issue has not been solved in all circumstances. I have loaded the Scottish Corridor campaign and have seen the issue happen once in 5 attempts.

The training scenario Roadblock has also been posted by @Falaise and @domfluffas a battle where the issue shows up. I have loaded this battle and so far have been able to make the men flee into fire, BUT not every time. In my opinion, there is an issue but nailing down the specifics of what causes it to happen will be difficult. 

Last night I built a new test map, 12 German HMG 42's versus a single green American squad placed at a gap in bocage. I tested with them in and out of C2. NOT once did they break and run into oncoming fire, even when their status was broken. I added some 81mm mortar fire to see if that would do anything to make them flee and they still stayed put or crawled safely to the rear.

I am about to head out to my parents for Father's Day so I won't be doing any further testing until later tonight. If anyone is seeing this issue show up in different scenarios or maps please post them here. If it is a specific combination of elements causing the problem, the more examples available will help to increase the odds of finding the problem.

[CanuckGamer]

I just started up CMBN and my version is 4.01.  I am currently in the middle of a PBEM game.  If I and my opponent install 4.02 I am hoping it will not screw up our game.  Is that correct?  Thanks.

[A Canadian Cat]

It will very likely be totally fine. Follow the official proceedure of watching playback with the old version, saving during command phase, shutting down and installing, then loading the save before completing the turn.

[sburke]

On 6/15/2019 at 12:44 AM, RockinHarry said:

same here mate.  Wished I could spend more time actually enjoying the game or keep goin with my mission designs instead of discussing matters that could be answered by BFC easily. The time that I supported BFC just for the sake of it is over. Definitely.  

I am not sure I understand the logic flow here.   Previously you commented on the fact that the TAC AI in CM is really complicated to the point you surely wouldn’t want to do it.  Then you suggest BF could easily answer questions relative to the TAC AI. Which is it?

what exactly would you have them answer that would change your mindset about “supporting them”?  I can tell you now as a beta tester I submit behavior to BF that “looks” wrong with as much hard data (saves and the like) as I can get.  Charles then looks at it and builds a patch and says have at it.  I do not expect more than that as frankly I wouldn’t understand it. I can only test and see if it seems to have worked. Testing AI is a pain in the butt as you also have to consider unintended consequences which is one reason BF is so slow to address these.  As it is none of this has stopped me from playing and dabbling in design. 

I am honestly pretty tired haranguing folks to stop just harping on behavior to provide saves and not just comment and yet 90% of these threads are completely useless to helping isolate what might be going on.  People point to one item, assume that is it and then assume because they guessed at it presto BF should fix it. 

I am still on the fence on this particular issue simply because something about it seems very specific but it hasn’t been nailed down yet. For example if it turns out it is specific to something baked into a map, which maps? I expect this one is going to be around a bit yet. Nature of software. In a game this complicated if you assume you will get easy fixes and easy answers you are doomed to be disappointed.  Yeah it sucks, but as someone who troubleshoots software issues a lot, it is how it works. (And the software I troubleshoot isn’t even this complicated). 

[sttp]

1 hour ago, sburke said:

I am still on the fence on this particular issue simply because something about it seems very specific but it hasn’t been nailed down yet. For example if it turns out it is specific to something baked into a map, which maps? I expect this one is going to be around a bit yet. Nature of software. In a game this complicated if you assume you will get easy fixes and easy answers you are doomed to be disappointed.

I don't think we should just throw our hands up here and say "oh well, software's complicated, so what are you gonna do?" I feel like that's what happened with the tanks humping bridges bug, primarily because of some of the more vocal forum members here, and all that's gotten us -- the community of players -- is a bug that still exists.

Do we know for certain whether this "fleeing toward the enemy" bug appeared in CMx2 version 3? My understanding is that it did not. Has anyone -- beta testers, Charles, or whoever -- reverted their game to a version prior to 4.0 and then set up situations similar to the save games that have been submitted and confirmed to be broken? It seems like that would be a good thing to know for certain. Only Charles knows the relevant AI code that was touched between versions 3 and 4.

I feel like sufficient evidence of a significant issue has already been presented (via save games, images, etc.) from multiple forum members. Unfortunately though, yes, it's across multiple threads on multiple forums.

And even if the problem relates to something "baked into" only some of the maps, as you say, there is still a solution that exists that can be rectified by modifying the code. (Again, it worked before, right?) There are only 1 or 2 people who have access to the software and debugging tools needed to analyze, isolate and resolve this issue, and to be honest (but hopefully not too harsh), those people should have been all over this, by their own initiative, as soon as the problem was first confirmed.

 

[sburke]

26 minutes ago, sttp said:

I don't think we should just throw our hands up here and say "oh well, software's complicated, so what are you gonna do?" I feel like that's what happened with the tanks humping bridges bug, primarily because of some of the more vocal forum members here, and all that's gotten us -- the community of players -- is a bug that still exists.

Do we know for certain whether this "fleeing toward the enemy" bug appeared in CMx2 version 3? My understanding is that it did not. Has anyone -- beta testers, Charles, or whoever -- reverted their game to a version prior to 4.0 and then set up situations similar to the save games that have been submitted and confirmed to be broken? It seems like that would be a good thing to know for certain. Only Charles knows the relevant AI code that was touched between versions 3 and 4.

I feel like sufficient evidence of a significant issue has already been presented (via save games, images, etc.) from multiple forum members. Unfortunately though, yes, it's across multiple threads on multiple forums.

And even if the problem relates to something "baked into" only some of the maps, as you say, there is still a solution that exists that can be rectified by modifying the code. (Again, it worked before, right?) There are only 1 or 2 people who have access to the software and debugging tools needed to analyze, isolate and resolve this issue, and to be honest (but hopefully not too harsh), those people should have been all over this, by their own initiative, as soon as the problem was first confirmed.

 

I don’t think anywhere  I suggested just throwing one’s hands into the air. I also don’t think anyone has linked it to pre 4.0 if you have a suggestion that is the case then definitely you need to provide a save.  To suggest that the one person who has access to debugging focus on this issue assumes that that is actually their priority and that is frankly not well founded. I personally have not felt this to be game breaking and I am playing across multiple titles including a pbem in CMBN.  I think you are assuming from your own viewpoint what should be BF’s priorities and not looking from their viewpoint. 

As to the baked suggestion, that is just a thought, not anything based in actual testing. It was purely an example that this could be unrelated to what folks have suggested as the issue. 

Software is complicated , which means thorough testing and validation.  I wasn’t suggesting it doesn’t mean fixing, just that the timeline for fixing and the prioritization has to be taken into account. 

Edit. Your point about bridges is a perfect example. BF has addressed that multiple times and yet yes it still exists to the point I still avoid  bridges on my maps.  I don’t think it is so much an issue that BF hasn’t looked at but something really basic in the code simply doesn’t like them. 

Edited June 17, 2019 by sburke

[General Liederkranz]

1 hour ago, sttp said:

Do we know for certain whether this "fleeing toward the enemy" bug appeared in CMx2 version 3?

Just out of curiosity, I loaded the Roadblock scenario to test in 3.12, 4.0, 4.01, and 4.02. In each case, I selected 1st Squad and "Quick" moved it up to the tile to the left of the gap in the hedgerow, as @domfluff suggested to replicate the problem. I did this 6 times in each version. In every case they came under fire (MGs, small arms, and usually off-map mortars) and took casualties. I ran each scenario until the squad evaded, until its members were all casualties, or until the scenario ended. 

3.12: Once they stayed for the entire game. In the other 5 cases they evaded (either Fast or Slow) away from the hedgerow, back into the friendly field.

4.0: Once they stayed put for the entire game. The other 5 times they Fast or Slow moved back from the hedgerow. So exactly the same as in 3.12.

4.01: 4 times they never fled (even with only 2 members left in one case). The other 2 times they evaded forward through the hedgerow gap, and then to the right along the hedgerow to the corner. 

4.02: 5 times they never fled (in one case they were wiped out entirely). The other 1 time they evaded forward through the hedgerow and then right to the corner, like in 4.01. 

This is obviously a small sample size and not nearly as comprehensive as what the beta testers and some others have done. I did it mostly to satisfy my own curiosity and my suspicion that my system is not generating this issue as much as some people's are. It seems for some people, this happens almsot every time in 4.01. For me, it was only 2 out of 6 times. 4.02 helped, but didn't eliminate it (1 out of 6 times). 

It does not seem to happen at all in either 3.12 or 4.0.

But what's really interesting is that in 4.01 and 4.02 the squad NEVER evaded BACKWARD, which would seem like the most logical choice. If they moved, they only moved forward. It was only in 3.12 and 4.0 that they would ever flee backward.

(Random odd fact I noticed: in 3.12, the squad leader's name is always "Lewis." In 4.0 and later, it's always "Melvin.")

Edited June 17, 2019 by General Liederkranz

[RockinHarry]

6 hours ago, sburke said:

I am not sure I understand the logic flow here.   Previously you commented on the fact that the TAC AI in CM is really complicated to the point you surely wouldn’t want to do it.  Then you suggest BF could easily answer questions relative to the TAC AI. Which is it?

what exactly would you have them answer that would change your mindset about “supporting them”?  I can tell you now as a beta tester I submit behavior to BF that “looks” wrong with as much hard data (saves and the like) as I can get.  Charles then looks at it and builds a patch and says have at it.  I do not expect more than that as frankly I wouldn’t understand it. I can only test and see if it seems to have worked. Testing AI is a pain in the butt as you also have to consider unintended consequences which is one reason BF is so slow to address these.  As it is none of this has stopped me from playing and dabbling in design. 

I am honestly pretty tired haranguing folks to stop just harping on behavior to provide saves and not just comment and yet 90% of these threads are completely useless to helping isolate what might be going on.  People point to one item, assume that is it and then assume because they guessed at it presto BF should fix it. 

I am still on the fence on this particular issue simply because something about it seems very specific but it hasn’t been nailed down yet. For example if it turns out it is specific to something baked into a map, which maps? I expect this one is going to be around a bit yet. Nature of software. In a game this complicated if you assume you will get easy fixes and easy answers you are doomed to be disappointed.  Yeah it sucks, but as someone who troubleshoots software issues a lot, it is how it works. (And the software I troubleshoot isn’t even this complicated). 

sburke, most what I´d state here is based on my own observations and related conclusions, no matter if they´re actually true from a coding and game engine POV (how could I know for sure anyway) . While it´s nice to see issues transported back and forth between beta testers to BFC and back again to public, I´d rather prefer "unfiltered" direct responses from developers themselves. Just for clarity! To me it oftenly seems you beta testers aren´t told certain necessary datails as well, so many your public responses more often than not, leave many questions still open. At least to me. I was beta tester for a number of wargame companies as well, so I know that you need to apply to NDS (non disclosure agreements). Maybe it´s just cause of that?

With regard to "support".... well I´d reported a number of issues the past couple of years, but more often than not (again) I feeled a bit....not taken serious maybe. That "feel" still prevails ATM. So if it´s just me reporting a particular issue and only response I see is "oh...we don´t see any...so no need to tell BFC", how much serious and beeing supported as customer do I feel then in consequence?

Have a look at (and take serious) this and we´ll see further.  If it´s not worth to spend an hour looking into it, why then should I keep working tens of hours on missions that are broken from exactly this issue? Even if no actual "bug" is to be found, it still helps me figuring out what´s probably wrong with my OS or hardware maybe. (see my sig for details). ATM my finger is very very close to the "delete all BFC stuff from HD" button to free space for more usefull things. So here again (3rd or 4th time) my latest and most serious issue ATM. Thanks!

 

 

[Howler]

10 hours ago, sburke said:

I am honestly pretty tired haranguing folks to stop just harping on behavior to provide saves and not just comment and yet 90% of these threads are completely useless to helping isolate what might be going on.  People point to one item, assume that is it and then assume because they guessed at it presto BF should fix it. 

I was fortunate to have @IanL arrange an email exchange for a savegame illustrating the issue. Yes, in this day and age - I don't have a dropbox or whatever else is used by folks these days for moving files. Most people would think a save isn't a priority given that there is no formal way to provide one to this vendor.

If saves are so important - could some official means of providing them be established by BFC? We all have accounts on this board and care enough to report which would seem to me that some secure mechanism could be setup to allow it. It could always be shutdown if it becomes abused.

There is no sticky anywhere on this board detailing how users should provide these saves.

I'm tired of people telling me that saves are required but not telling me how this can be done.

6 hours ago, General Liederkranz said:

But what's really interesting is that in 4.01 and 4.02 the squad NEVER evaded BACKWARD, which would seem like the most logical choice. If they moved, they only moved forward. It was only in 3.12 and 4.0 that they would ever flee backward.

Now, that is interesting. I'm my case, the one save sent to @IanL involving the CW 18 Platoon scenario, is fixed. It was always broken (rush forward and back) and is now never forward, sometimes stay in place, or otherwise backwards. So, 4.02 is an improvement.