Jump to content

Lt Bull

Members
  • Posts

    896
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Lt Bull

  1. Yes, and I hope no one is too surprised to see that this actually is the case. It shows at least the manual EVADE waypoint placement mechanics are working as expected/as they should ie. EVADE direction influenced by the scenario defined parameter "Friendly Direction". It should bring some relief to know (not the least Battlefront!) at least this aspect of the game mechanics is working as advertised. Importantly, I have just heard back from the scenario designer of "A Nasty Surprise". He thanked me for pointing it out. It appears that he was oblivious to this scenario setting and had never set it in the first place, so the scenario retained whatever default setting it happened to be (which is Allies west, Axis east). So my casual observations of "odd" behaviour did not deceive me. I do feel somewhat vindicated now for originally even suggesting that "something may not be quite right" with the way the unit in the video behaved when the TacAI made it evade "towards the enemy". Under similar circumstances, I would feel confident that the infantry unit in question would NOT have behaved in the same "suicidal" way had the scenario defined Allied Friendly Direction instead been set to north, rather than west as it was. RockinHarry, in saying this, are you of the belief that the waypoints assigned by the TacAI during "auto-evade" are calculated differently to the waypoints assigned when a player presses the evade button ("manual-evade")? As suggested before, I would think they are essentially one of the same same thing, with the only superficial difference being in whether the evade routine was being initiated by the player directly (by pressing the EVADE order button) or by the TacAI automatically (during RT or mid-WEGO replay action). Do you have any examples that might support your view? Given you had indicated that you had never really considered the Friendly Direction settings with respect to evade direction, it now makes me wonder what the Friendly Direction settings actually were in all the cases you have mentioned (and for that matter, ever other case that has been discussed). I would not be so presumptuous to even think that the determination of the evade waypoint by in CM (under any circumstances) involves what I can only imagine would have to be very complex coding based on battlefield geometry, LOS/LOF interrupt calculations, unit SA/FoW considerations etc even though interrupting LOS/LOF and reducing exposure IS a core objective of the evade behaviour in the first place. If there is an expectation that the game does (or can) explicitly consider LOS/LOF when determining evade waypoints, then I can understand the expectations one may have on HOW they expect a unit to evade. I don't think we really should be expecting too much "intelligence" based on the "local" LOF/LOS, battlefield geometry etc. A simple "calculate evade waypoint" algorithm that works through a list of possible alternatives should be sufficient enough to satisfy in most case our need for a "realistic"/"intelligent" waypoint solution in the majority of circumstances. I would be happy to conceded that perhaps just the relative direction of "known" enemy units may play some part in perhaps tweaking the waypoint determination in secondary way. In thinking about all the possible ways and factors the TacAI coding might consider in it's calculation to determine a suitable "destination" action space for the "evade" behaviour of any given "rattled" infantry unit, I realised that I had never considered one very simple "solution" option: the location of nearby unaffected infantry units. For example, in the instance I highlighted in the video, you can see in the side view screenshots that 20m to the rear left of the infantry unit in question is the 1st Plt HQ/G Co located in a safe position in total defilade. By virtue of the fact that a friendly unit was actually at a location that was: not under fire out of enemy LOS further away from known enemy locations/source of enemy fire/enemy map edge not too far away accessible via a path that would not increase the units current exposure to enemy fire (probably the hardest thing to calculate/code for), by definition this identifies/qualifies that action square as a totally valid/legitimate destination for the infantry unit to 'evade" to. Essentially most (if not all) of the checkboxes boxes for "good choice for an evade destination" are ticked. It certainly is much safer destination to move to than where it actually did move to! So rather than just simply relying on dealing with/modifying existing complex coding algorithms (involving actual analysis considering actual local terrain geometry, LOS/LOF scenarios from various enemy units and all the complexities related to FoW, as well as other factors like other local incoming fire etc) to calculate/determine (from essentially first principles) a suitable "safe" destination for an "evading" rattled TacAI driven infantry unit to move to, perhaps if the algorithm also considered the action squares occupied by nearby unaffected friendly infantry units as valid qualifying destinations, and compared it against other alternatives using a quick "checklist" like the 5 points I listed above, perhaps many of the complex "poorly calculated" outcomes chosen by the game as "a safe destination" (like we are seeing) could be avoided. If such a thing was considered in the case of A Team/1st Sqd/1st Plt/G Co, no one would have an issue with the TacAI choosing the action square of the the nearby 1st Plt HQ/G Co unit as an "evade" move destination. At least we know that the action square was (is) safe. I know this easy, quick and dirty "cheats" way of circumventing complex algorithms to determine a "safe nearby action square" as a possible destination for evading infantry units may not be applicable in all situations, primarily in instances where there are no nearby friendly units, or that it somehow may not even provide "the best" destination in all cases, but I think it would help in a vast majority of the situations where the existing TacAI would instead pick questionable destinations like we are seeing.
  2. FWIW, in my "EVADE testing of random units during orders phase of various turns" in the scenario I am playing (the one where the friendly directions are apparently 90deg out!) I have noticed that units in a particular building will EVADE in a different direction to the units located around the building. All the units around the building will tend to EVADE NW while the units in the building will instead EVADE SW. I haven't really tested this thoroughly with other buildings etc, it's just an initial consistent observation. I am surprised that you considered "friendly map edges" more in terms of potential issues with range and small calibre off-map arty than as a foundation to understand how you would expect units will react when evading/retreating/routing etc, especially in the context of understanding the EVADE mechanics you have been investigating. I can tell you that when I edited the Allied/Axis Friendly Direction setting in the scenario editor and repeated the EVADE order testing on the units I had put on the map, they definitely did start EVADING in the newly set direction. Quite easy to test. Try it out. Was there a reason why you seem to have thought that the Friendly Direction setting may not have had an effect on influencing the EVADE order waypoint? I haven't gone checking a bunch of scenarios myself (yet) but what you are saying certainly is not what I would expect to find (even when I consider all the scenarios I recall playing). I would expect most scenarios to be designed around forces engaging north-south or east-west rather than diagonally across the rectangular map, and as a consequence the Friendly Directions set as N/S or E/W respectively. Can you elaborate more on the reasons you have found to avoid scenarios with N/S and E/W map edge settings/confrontations as opposed to the scenarios based on diagonal set friendly directions? This is most curious. If a scenario has been set up so the main battle lines and deployments are N/S or E/W, I can only imagine that if the Friendly Directions are instead set at NW/SE or NE/SW then it should be expected that it would be more likely to experience "illogical" EVADE and/or retreat behaviour (liek we are discussing) as units would tend to "retreat" diagonally rather than directly away from the N/S or E/W front line.
  3. RockinHarry, Thanks for raising what I am now thinking are very important aspects of the game that might help us understand more about what is happening and why with regards to the "break cover run towards enemy" issue we are seeing (is there a consensus on what we should call this?). In particular I refer to the EVADE command you are mentioning. I certainly knew about and use this command (in WEGO orders phase) but never knew what the command name was called. Thanks for highlighting it. It's worth repeating what the manual says about it. In case folks don't know what I am talking about, it's this button: What I am wondering is whether the game code/algorithm that determines the waypoint of a manually induced EVADE order (either in orders phase of a WEGO game or during a real time game) is the same code/algorithm that determines the waypoint when the TacAI automatically seems to apply this same order to particular "rattled" units under fire during the replay phase of WEGO or in a real time game. Having just discovered where to look in the Scenario Editor for the "friendly map edge" setting assignment, an inspection of the setting for the scenario I am playing (A Nasty Surprise) has actually revealed a nasty surprise! Well, not really nasty, but can a surprise be surprising? Even though the scenario clearly sets up the US forces in a zone along the northern part of the map and the German forces along the southern part of the map forming a natural west-east frontline, the scenario Allied Friendly Direction is actually set as west and the Axis Friendly Direction is set as east! I am awaiting a response from the scenario designer whom I have PMed to confirm with him. What makes this surprise finding even more surprising is that based on the testing I had done myself on the map issuing EVADE commands to my US infantry for the purpose of seeing where the waypoint is placed, it definitely appears that the "default" average direction to EVADE towards was to the north-west, and not the west. I actually was expecting to perhaps find the scenario Allied Friendly Direction set as north-west with the Axis Friendly Direction is set as south-east (hence my double surprise). FWIW, I have even checked the manual and it does say that the friendly direction setting does "set(s) the direction into which .. units would withdraw to join their lines". So to update and revisit the commentary and context of the video I posted: The US infantry unit in the video that seemingly appears to be EVADING in a SW direction "away from the friendly map edge/towards the enemy map edge" technically IS NOT doing that at all based on the scenario settings. . Given the scenario settings state the Allied Friendly direction is west, then south-west could still be considered "in a friendly direction" and not towards "enemy lines". So, perhaps the EVADE example I first reported and in the video is not an example of (or at least not a good example of) the "break cover, run towards enemy lines" issue being reported elsewhere, given the surprising actual scenario settings. A first point of order when investigating these apparent instances of "running towards enemy lines" EVADE behaviour should be to check (and double check) the Allied/Axis Friendly Direction settings of the scenario/campaign or QB map being played using the Scenario Editor.
  4. Hi Ian, Happy to oblige and thanks for looking in to this. I have the .ema files, the scenario is called "A Nasty Surprise", we are using 4.02. I will PM you. Regards Bull
  5. The unit is not under arty attack. There is arty (not major calibre) falling to the units rear right about 150m away, at which range it typically does not affect units. The direct automatic weapon fire (flak gun incl) that it is reacting to is coming in at about 45deg front left. From the side angle view screenshots below of the same action in the video (you can see the incoming tracer fire in each of the BEFORE, DURING and AFTER the unit makes it's move), you can clearly see the terrain directly behind the unit it is more depressed (offering 100% defilade from all direct enemy fire) than the terrain in front of it. The friendly lines (safety good!) are to the left, the enemy lines (danger bad!) are to the right. The infantry unit started the turn targeting some enemy infantry running away from it, but later started shooting at a open sided 20mm or 37mm HT mounted AA vehicle that was moving laterally to the left. It was the return fire from this AA vehicle that "rattled" the infantry unit halfway through the turn. By the time the infantry had reached the wall in front of it, it appears the AA unit had moved out of LOS anyway. Despite any cover afforded by the wall, the infantry unit is still within enemy LOS and is now taking small arms fire from a new more flanking position from the left. How many would disagree that, given the circumstances and threat the infantry unit was reacting to, the safest thing for it to have done was to simply follow what most would consider the most basic instinct to threats: retreat AWAY from the direction of the incoming enemy fire/location of known enemy units/enemy lines (map edge) so as to reduce/diminish, or better, break LOS completely to the enemy and hence gain defilade? This would be immediately achieved if the infantry unit moved back 6m towards it's own lines. Few would have reason to raise a discussion like this if the infantry unit just retreated in the basic vanilla manner described as many would expect. Instead, it seems too frequently for it not to be noticeable in a random game, infantry units under fire are taking what can be described as more questionable "exotic" solutions that are meant to increase their safety that involve running towards the enemy fire/enemy locations across open ground, when a simple basic vanilla "just retreat away from the enemy" reaction would have sufficed. K.I.S.S! Not sure if it was ever brought up in the past (I am sure it was/has) but I remember questions were raised about the TacAI "self preserving" behaviour when infantry took fire typically when moving across open ground from cover to cover. I think people called it the "crawl of death" (may have even been in CMBO/AK). Many of the situations were like the "man who swims 80% distance across the river, then decides the remaining 20% is too far and swims back" kind of logic at play. There were cases where you would expect the infantry unit under fire to either crawl or run to the nearest cover regardless of the relative direction to friendly/enemy lines were and/or in which direction the enemy fire was coming from. Instead, rather than continue a few more metres "to safety", they backtracked across more open ground than they would of if they had just headed towards the closest cover. I understand coding an algorithm that intelligently handles all situations is not easy. I hope a tweak can fix what we are seeing happen too often.
  6. Back again... If the "rattled, break cover, run towards enemey" incident I mentioned earlier (in passing) that occured in this PBEM was not a good example of the very same issue others are reporting, then this one that just happened in the same PBEM is a very good example: https://streamable.com/ils2p Infantry are located behind a hedge on an slightly elevated ridge (the ground gently sloopes down behind them in to an open field in defilade). They are directly facing the enemy map edge, with the friendly map edge behind them. No movement orders were given. The only orders were to target an enemy infantry unit to the front left. Halfway through the infantry unit takes fire from the same front left direction. The immediate reaction of some of the men in the unit is to break cover and run directly forward through the hedgeline, toward. The remianing men initially stay behind the hedge and cower (probably safer), but eventually get up and run through the hedgeline like the original guys did. They are just lucky that not even one of them was hit when they broke cover as they were fully exposed (well there is always next turn) You can see a low stone wall about 15m in front of them but they literaly have to cross open terrain, running through enemy fire to get there. It is not clear if under this situation whether there behaviour was influenced by this "alternate" (more desirable?) nearby cover. To be honest, there are actually two other cases I could show that have happened in this PBEM that share the same fundamental characteristic: "rattled" infantry in cover breaking cover and inexplicably running towards the enemy map edge (with more disasterous results). If the TacAI that kicks in controlling the behaviour of this "rattled" infantry unit is meant to be a "self-preservation" reaction to the enemy fire, perhaps the code is somehow not taking in to consideration the following information: Location, distance and safest route to nearest defilade and/or cover (in this case, defilade about 6 metres behind them, albeit in open terrain ). In the heirachy of possible directions a "rattled" unit can move to "increase it's survivability", you surely would expect the "default"/all things equal/no-brainer go-to direction to be move in would be "away" from the enemy, or towards friendly lines. There would need to be some pretty compeling circumstatnces at play if that "safer" direction/route/path led them closer to the enemy. Maybe the TacAI coding is placing too much emphasis on the percieved cover at "the destination" and not considering the path/route/distance and the danger to the unit in getting there. Regardless this recent new post-upgrade behaviour we are now seeing with infantry "running towards the enemy" appears to be "a thing" not previosly seen or considered a problem prior. I hope it gets addressed.
  7. On all the commentary regarding the "break cover, run across open towards enemy map edge" issue I mentioned (incidentally and in passing really) that just happened to occur to an infantry unit in my PBEM: My understanding (and expectation) of the "flight"/retreat/rout etc. mechanics of units is that all units on a map "know" which direction leads to the "friendly map edge" for their side. The ACTUAL direction they take however may be affected by local factors. I understand that in the instance I explained, if the infantry unit was to simply run a path "towards a friendly map edge" it would mean they would have to literally run towards and through the tank being attacked/destroyed which would be odd in itself. Taking a direction laterally however would seem a more appropriate thing to do in this instance (ie. away from "local known issue", not towards "known" enemy map edge, not away from "friendly map edge", not relocating from covered terrain to open terrain). It did mean in my game the unit got cut down and eliminated as a result of "running across open ground directly towards enemy map edge". I will let other's decide on whether this is related to the pre-existing "break cover, run towards enemy" issue that first started being discussed after the upgrade. The "this just seems wrong" LOS aspect of what I described is that one unit seems to be able to trace a wedge of unobstructed blue line LOS from it's position around 400m back, through a section of wooded terrain (between 40-90m deep), up to a further 400m beyond the woods, whereas other units nearby and closer to the woods itself have no visibility through the woods at all. This "x-ray visioned" unit was also able to spot an enemy unit beyond the trees that other units with clear LOS at much closer range and with only open ground between them and the enemy unit did not spot. I know there is a level of abstraction with modelling LOS through "woods"/trees but just one unit being able to see unobstructed through 40-90m of wooded terrain while other units LOS is totally blocked seems like something unintentional/undesirable is going on in the LOS modelling and this unit for some reason.
  8. I advised my opponent of the issue and this post. I don't want to go in to too much detail in an open forum as our game is still being played and it might disrupt the FoW side of things. I can tell you that the scenario is called "A Nasty Surprise". The sceanrio starts at around 7:15am, weather is clear but I think LOS range is reduced due to the lower dawn light condtions in effect. All the terrain I refer to is essentially flat. I have a unit located in rear part of the map able to trace a LOS 400m across open ground, up to and through wooded terrain about 40m deep, then another 500m across open ground on the other side. All other units near and around the unit in question can not see through the woods at all. And you know how I said I hope that "retreat towards enemy" thing doesn't happen tin our game?... In the very next replay I watch of our game, an infantry unit located at the edge of wooded terrain became "rattled" (apparently caused by the incoming direct AP shell gunfire targetting and destoying a friendly tank about 10m behind it in the woods), then broke cover at edge of woods and started running across open terrain towards towards the enemy side of the map. There was some arty dropping perhaps 75m away.
  9. Hi, I am back playing CM (PBEM) after taking a bit of a break from it. Reasons for the break was a culmination of the gerneral disatisfction and disillousionment with BS "official" responses (or lack of any real response) to several gameplay mechanics issues and suggestions for improvment (spotting, LOS, movement etc) that I either had experienced myself games I had played myself and/or read about in the forums. I was hoping that with all the patches and upgrades that have been released, perhaps the kind and frequency of "this makes no sense, what the hell is going on" kind of moments I saw in games that had worn thin on me and predicatd my need to just walk away from the game would have perhaps be addressed to a point where the likelihood of experiencing those off-putting moments in game had diminished. Well first PBEM back, latest patch, upgrade etc.about 20 turns in but only about 10 moves in from encoutering the enemy, I have had one of those same "something seems wrong with the mechanics" moments that kills/had killed my trust in the game. And no it's not the "retreat towards enemy" issue that many have posted about (hope it wont be an issue in my games). The issue relates to an instance during the last minute of action where the LOS mechanics has been (once again) broght in to question, reinforcing doubts I wish I never had about this aspect of the game. Do I need to bash my head explaining exactly what happened/justifyign my reasons for concern in a forum post here or is there someone at/with BF who can just review the replay file(s) and spare me the effort? I did go to support but they just seem to deal with the general tech issues. Happy to provide PBEM files of course (will ask opponnet as well). Regards Bull
  10. Hi Vanir Aust B, Did you actually report this? Maybe you know why this bug is still with us. Surely it would take no more than an hour or so (if that) of coding to fix this.
  11. Apparently not. We are at v3.11 and I have just checked that this bug still exists for this building. :/
  12. I just finished a PBEM that is much like what you describe: "Evil Be To Him", there were no AT guns however. I thought it was quite an innovative scenario design. Worth at least checking out the design.
  13. I'm actually surprised anyone would think they would even think they would be damaged. I just upgraded to v3.12 and can report the following. The rotation speed of a deployed Pak40 has gone from 43 sec to turn 180 degrees to around 85 sec to turn 180 degress. Basically half the speed it was. Just keep in mind the video shows an undeployed Pak40 on wet grass taking 13 seconds to be rotated 180 degrees, 6.5x faster. Obviously someone at BFC had good reason to change this in the latest patch. What was this reason?
  14. I've got Fraps as well but have only use it for vids, preferring something like Snagit that auto saves screens and opens them up in an editor. Thanks will look in to it.
  15. Thanks for bringing that up, the effect of increasing the "hi detailed textures radius range" is more pronounced as I thought. I was aware that there was a "quality" setting but always assumed thought I had it on max from day 1 in all my CM titles, but that wasn't the case. Looks like I had it in what appears to be the default "Balanced" mid setting. To make this a more educational post, I can say that there are 8 discrete levels that can be set and each does affect this "radius of detail" I am referring to enough so that the setting I am now using is a notably different to what I was using. On a related note, I want to know what peoples experiences are like when they try and take screenshots of CM. Again I think this may be related to the kind of way CM graphics are coded but if I want to take a screenshot of what I currently see in CM, I must, for some unknown reason, first TAB out of CM then just TAB back in THEN take the screenshot in CM. If I do not do this TAB in/out/back in routine and try to take a screenshot, the resulting screenshot will actually be what was on the screen the LAST time I TABed back in to CM...very odd. Further to that, the screenshots that are consequently taken within game aren't always what the actual in game screen looked like. Typically some hig res textures have been instead substituted by those lower res textures. Consequently I can't guarantee that my CM screenshots capture all the detail I actual see. This happens if I use the standard Print Screen button on the keyboard and paste to a graphics program or if I use a third party screenshot program like Snagit. Does anyone have this TAB in/out/in issue and lost detail in screenshots issues with CM? If not, what screenshot program are you using?
  16. Hello I am well aware that the CM graphics engine seems to load hi or low res textures for terrain depending on how far away from the camera they are. This is for all the CM titles. Some terrain types/features which are more 3D (like wheat fields or vineyards) actually look like flat terrain when viewed at ranges beyond this high res texture loading range. Although I understand that this is a way to reduce the graphical load on the PC/gfx card, it doesn't really look too nice when you pan/zoom around the map and you see the high res textures swapping out fro lower res versions. I am wondering whether this seemingly arbitrary "radius from camera" distance can be modified to suit higher specked systems. It does seem odd that this arbitrary "radius" range at which high res textures flip to has (in my experience) has remained fixed from when CM first came out, despite PC systems and graphics cards becoming more capable. Are we stuck with this range or can it be modified? Unless someone can correct me, I am quite sure that because of the (idiosyncratic/unorthodox) way CM graphics have been designed/coded, the game engine does not allow higher performance systems/graphics cards to process the game graphics as well as they would/should. It's like the graphics performance bottleneck is more a function of the game coding than it is of the PC system, which really is a shame. PS: I have also realised that this dynamic transitional low/high res texture change that occurs is most pronounced when the high res/close range textures are not very similar to the distant/low res textures (of course). Would be interesting to hear from terrain modders how/if they ever deal with this issue. Where/what exactly are the low res distant textures anyway? I have seen mod terrain graphics with the word "distant" in them as well as "mini" and I think both are related to the "low res" textures that get loaded.
  17. Hello all, is there or are any plans for anyone to make a gridded version of this terrain mod?
  18. Although I have been focussing on the actual physical movement and rotation speeds of a Pak40, I have not really questioned the deployment and packup times of it and other ATGs, apart from the pointing out the Russian testing that seems to have determined that a 17pdr can go "from march to firing position and back" in 40-60 sec compared to 3.8min deployment and 8min packup times you see in CM. I really am finding it hard visualising what must be going on within the time spans allocated in CM for th deploying and packing up of the various ATGs. A CM Pak40 has a deployment time of 2.2min and a packup time of 4.4min. That really is a quite a lot of time for a 5 crew to do whatever BFC think they need to do before getting off their first shot, more so when you consider packing up. Ammo wise, it's more likely there is less ammo to deal with when packup than when you deployed, so why should it take twice as long? Lets look at an actual Pak40 being fired and see if we we can learn anything from it: Not much here but great to watch! A few degrees rotation in the wheels back then forward again after firing. Now another: Pity you can't see the full length of the trails/shovel ends but based on the seemingly sandy/rocky surface. It doesn't look like there is any evidence of "digging"/displaced earth around the ends of the trails to anchor the ATG to the ground. Putting effort to specifically ground the trails is probably more of an issue if the gun is on an inclined slope, like on a reverse slope. The gun does not seem to recoils on it's wheels as much as it did compared to the first gun. PS: Found some more. This time you can clearly see the ends of the trails and shovels. Looks like hardly any effort was made to anchor the ends to the ground, definitely not minutes of effort! The way those shovel ends are designed is that they are angled in to the ground. They kind of self embed themselves when the gun fires anyway.
  19. Oh I'm looking for other sources don't worry about that, as I hope you are and anyone else who cares about the realistic modelling of ATGs in this game. The only sources I have presented are a shed load more than any other sources anyone else has provided, which is zero. There is nothing obvious about the way BFC have modelled ATG mobility, rather it is actually more exceptional and what should be questioned. Of course I am considering ammo in all this, but really how much of an issue would it have been? Has anyone cared to do the math? No, well let me do that as well. So I open CM, create a QB and drop in a bunch of different Pak40s from the different forces they appear in and check their ammo loadouts. Really? I guess I was not really surprised to find that this statement was either exaggerated and/or misleading. Either way, it is definitely incorrect which is a shame because others contributing information/sources to this thread have spent quite some time making sure what they bring to the table here it is at least accurate, honest and objective. Interestingly, Pak40s in CM from German Army/SS seem to have an ammo layout of 5 HE and 13 AP rounds (total 18) and their 2-man ammo bearer crews carrying 4 HE and 10 AP rounds (total 14). Curiously Luftwaffe Pak40 crews can be seen to have ammo loadouts of 3 HE and 10 AP rounds (total 13) with their 2-man ammo bearer crews 2 HE and 8 AP (total 10). So in summary we have a CM Pak40 ATG 5-man crew and ammo 2-man team carrying no more than 32 rounds of ammo between them, which is between 20% and 36% less than what some posters would otherwise have you believe. Looking at an CM Pak40 ATG crew alone, they carry no more than 18 rounds, which is between 11% and 66% less than what some posters would otherwise have you believe. (BTW, those % are significantly greater if you consider the 13 round Luftwaffe Pak40s). But lets not end the analysis there and consider this comment. Actually I realise a lot more beyond what is being suggested here. Lets look at how much weight we are really are talking about when we consider these Pak40 rounds. Now CM lists Pak40 ammo as being either just AP or HE. Sources I can quote tell me that a typical Pak40 HE round weighed approx 9.15kg while the AP round was either around 9.5kg (PzrGr 40) or 12kg (PzGr 39). I believe the PzGr 39 is the "standard" AP round modelled in CM for the Pak40 so we can go with that (unless someone can correct me). The Pak40 rounds appear to be packed 3 per wooden ammo box. Here is a good representation of what they looked like (actually a scale model): Dimensionally I estimate the box to have been around 1000x380x120mm, weighing about 5-8kg (anyone know what type of wood was typically used for German ammo boxes? Pine, oak, beech, cedar?). A fully loaded ammo box of PzGr 39 would consequently weigh around 41-44 kg. If all the Pak40 ammo was carried in these boxes, then a Pak40 crew at worst would have five or six of these boxes to carry the 13 or 18 rounds depicted in CM. The full ammo loadout of a Pak40 in CM ends up translating in to around 250kg of rounds and boxes. It is ridiculous to think/expect (let alone model in a game) that the 5-man crew would simultaneously move the ATG and carry the 250kg with them under any situation, like some people seem to want to visualise. Moving the gun would have been the primary task, probably undertaken by all the crew, while any relocation of remaining ammo would have been a secondary task undertaken by perhaps one or two of the crew. The implications of "leaving ammo behind while you move the ATG" of course depends on how far the ATG is being moved and the circumstances. In a practical ambush type application (similar to what is described in that WW2 US AT gun doctrine Field Book already referenced) that requires moving the ATG in and out of defilade/firing positions, the need to move any ammunition was probably unnecessary/minor given the ATG would have only be moving perhaps 20m at most from firing position to defilade and back. I think we need to keep in mind that those advocating a review of how ATG mobility in CM is modelled are not really interested or referring to situations where ATGs would be wheeled hundreds of metres all over the map. We are mainly talking about "local" or tactical mobility. Having them move with the same level (or base) of mobility we have seen in the videos within even 50m would be sufficient to meet the majority of situations most of us are considering. Interestingly the ammo boxes I have seen for Pak40 ammo seem to have wooden handles on each end of the box which would allow two crewman to carry one box by grabbing a handle with one hand at each end, each man lifting and carrying equivalent of around 22 kg load, which really is relatively light. A single crewman moving one 44kg box of ammo would probably grab one handle and drag the box along the ground behind them. They could even take the lid off and grab the sidewall of the box and drag it that way if need be. It would be rather awkward (though not impossible) for one crewman to lift and carry an ammo box of that size and weight standing upright in two arms. For those of you unfamiliar with lifting/moving weights at the gym or doing any kind of manual labour moving relatively heavy things around, all these numbers and weights unfortunately probably mean nothing to you. The way CM abstractly models the mobility/movement speed of an ATG is to consider the gun, the crew and the ammo/ammo boxes as one "average" mass. This abstraction however does not translate well in to the practical mobility the weapon would otherwise have. Significantly slowing gown the speed at which the gun can be manhandled (moved/rotated) by magnitudes 4x less than what we have seen in these videos does nothing to realistically and faithfully model the tactical mobility (and hence effectiveness) of ATGs in the game. Not really. ATGs have their place. They are way cheaper and easier to design, fabricate, crew and maintain than a mobile ATG platform. Mobile ATGs have many disadvantages that ATGs don't have. Everything has it's place, hence why they exist in the first place.
  20. An interesting range of responses from those who seem to have read and watched what I have presented (thanks WynnterGreen for returning to this discussion) to those who either haven't or just simply need further explanation. Interesting to keep in mind that none of us even seem to know what data/sources of information BFC referenced on which to base/justify the movement speeds of ATGs (and their deployment/pack-up times) in CM. I have asked for this already but will ask again. Yes which is about 8m/minute, or 8x slower than what you see the re-enactors move the "undeployed" Pak40 int he video. I can't imagine them moving the Pak40 8x slower than what they currently are even if they tried on that surface. (NOTE: 1 AS = 8m). Apart from uphill/downhill modifiers on unit movement, BFC have already modelled in to the game terrain effects on movement speed for both vehicles and infantry and fatigue effects on infantry moving at FAST/QUICK/HUNT/SLOW speeds so it just seems odd and exceptional that this same kind of modelling simply hasn't been transferred to ATGs. I can't see why BFC would treat the movement modelling of ATGS any differently to the movement modelling of infantry already in the game. Anyone know why they don't model terrain effects/fatigue on ATG movement? A general lack of ATG love or abundance of ATG apathy? As I have said, it's not like they haven't done this already for other units in the game. A bizarre comment given the lengths to which people have gone out of their way to explain. Yes they have many times, you probably have not paid attention. Did you read what FOCOL was/is on page 1 and how you can't really execute it in the game? The "mobility" issues with ATGs in the game are not just an issue related to their speed of movement, but to the fact that ATGs can only move in one direction, forward. As far as executing a "text-book" FOCOL based ATG ambush in CM, ATGs would have to possess the ability to move in reverse ie. a REVERSE moment command option, which they don't currently have. In fact, moving an ATG in the reverse direction (pulling it liek they do in the video) might actually be preferred/easier to do than moving it in the forward direction (pushing it). Have been quiet a few people trying to discredit the quality and type of information that can be gleaned by watching "living archaeology" type videos that have been posted here and elsewhere using rather weak reasoning (neatly mown grass!) Kind of disconcerting that some then go to suggest they would place more value in considering an imaginary situation based in their own back-yard with themselves trying to turn some imaginary ATG 180deg, LOL! Please offer more credible alternate data/sources on which to base any understanding on which ATG mobility should be modelled. The closest most of has have probably come to knowing what it is like to manhandle an ATG would come from any experience you might have had from manhandling trailers (and whatever they have been loaded with: furniture, rubbish, motorbikes, boats etc ). When moving/wheeling various trailers of different size and weight in the past, I know it had struck me that it was not too unlike what it would be like manhandling an ATG (same basic shape, form, mass and wheels). In fact, in leui of an actual ATG, I think much could be gleamed from actually using a trailer, loading it up with various masses equivalent to actual ATG masses and getting a team of guys to push/pull it up/down/over various terrain and recording the results. What could be established would be the relative differences between different loading/crew number/terrain scenarios. Even better, contact those re-enactors in the video and ask them to do the tests using he actual ATG (PS: I have decided to do this). Would be good fun doing these tests unless you are more the type who prefers to sit behind a desk and trash the validity of their efforts. Spot on. +1. A great summary of the current situation. Thanks John for your contributions here. Would be interesting to peruse the Merkblatt for the Pak40 (link doesn't work). The report on the 17pdr (listed as weighing 2860kg) is very interesting. Please also note that the tests seem to also have been conducted in snow conditions based on the photos. The reports says "It is not possible to push the gun 500 meters by hand over rough terrain. The 7 man crew can only push the gun 100 meters on flat terrain. Pushing the gun is further complicated by a lack of convenient rails." The lack of convenient rails (basically handles for crew to hold/lift/pull/push the gun) definitely is a huge issue. You can see in the Pak40 re-enactor videos the crew grabbing on to dedicated handles on the ATG trails. Lack of convenient rails might indicate the weapon was never really designed/intended to be manhandled significant distances (though 100m in the snow still seems more than what you would expect any ATG in CM to be moved) which is fair enough for something weighing around 3000kg on 2 wheels. Also please note the report mentions that the time for the 17pdr to go "from march to firing position and back" was only 40-60 sec. Now I am not 100% what that means but it does sound like something related to deployment and packing up. Keep these numbers in perspective when we now consider that BFC have assigned Deployment and Pack-up times for the 17pdr to be 3.8min and 8min respectively. FWIW the 6pdr has been given 1.8min and 3.7min deployment and packup times. Again, where is BFC getting their modelling information from? Why is ATG mobility in CM so undermodelled based on basically all the evidence that has been presented?
  21. CMFB relevant discussion at CMBN forum: http://community.battlefront.com/topic/122944-atgs-again/
  22. Yes I do (only recently though and have yet to try in a game) which definitely was a step in the right direction from how AT-guns were initially modelled (8m/minute speed!). You do realise that the speed at which an AT-gun can execute this move has a large bearing on the practicality of such a move. The longer it takes to execute this move, obviously the more vulnerable and less effective the AT gun will be. Of course I would expect the probability of spotting the ATG to increase "as it's moving in LOS of the enemy", but this is inconsequential to the alternate scenario of having an largely immovable static "ambushing" ATG permanently deployed in LOS of the enemy just waiting unknowingly for something to eventually spot it and kill it before it has a chance to fire. But as I mentioned, moving IN to position is one half of the FOCOL doctrine. Moving OUT of position is the other and without a reverse move available to ATGs, the complementary "life saving" other half of the doctrine can not be practically execute in CM. Also I say FOCOL to anyone who disagrees! LOL
  23. Not surprisingly, I was able to find actual documentation/doctrine that specifically describes the very ambush scenario I considered/hypothesised above when tactically using med-light AT-guns. Found in the document linked to in the other thread on ATGs I mentioned: FM 18-12 Towed Tank Destroyer Gun Platoon (Aprl 1944) that explains AT-gun doctrine and use: http://tankdestroyer.net/images/stories/ManualPDFs/FM18-21%20Tank%20Destroyer%20Towed%20Gun%20Platoon.pdf They actually gave it a name for "FOCOL" and literally sketch it all out plain as day. It is clear that the local mobility of the AT-gun is essential for this doctrine to be executed and is fundamental to how the AT-gun should be used. The L in FOCOL, part (5) L for "Lines (routes) in and out. The text before this also discusses the concepts of Primary Firing, Alternate, Supplementary and Cover positions. When referring to the Alternate position, the document says "routes to it [from the Primary position] also are to be selected", which implies local tactical relocation/redeployment by the crew. In the figure above you can actually see the artist even sketched in the tyre marks on the ground the AT-gun left behind from moving it in and out of defilade. Not surprisingly, the tyre marks on the ground don't seem to indicate that the crew pivot the AT-gun 180deg to move in in and out of the firing position, unlike what needs to happen in CM. I don' think this is coincidental. I think we can be pretty confident AT-Guns were moved both forward to get in position and directly in reveres to get back in defilade. I am sure a similar doctrine would exist and be described in the corresponding German/Russian etc field books. It is a shame CM does not allow this realistic tactical deployment of the light/med AT-guns. Instead we are stuck with a "pick a spot on the map, sit there, pray/hope your don't get spotted, die there" and shutup about AT-guns already kind of mindset. There is no way the actual doctrine described in the Field Book could ever be practically realised in CM without giving AT-guns the ability to be moved both forwards and in reverse. Is even that just simply too much to ask? This one change (to give AT-guns a reverse move capability) alone would go a long ways to at least allow AT-guns to be used in ways they were actually prescribed/designed to be used in, and in doing so improve the general usefulness and survivability of these weapons and moving away from the whole "advance infantry, spot defenceless/unknowing "ambushing" ATG, call in arty, wait, kill ATG, rinse, repeat" whack'a'mole type of gameplay that CM typically degenerates in to.
  24. Hello, I know that there have been some very intense discussions in the past about the modelling of ATGs in CM, primarily related to their concealability, the speed at which they can be manhandled by their crews (including rotation) and their deployment/packup times. One of the more significant discussions can be read in this very well represented thread: http://community.battlefront.com/topic/111333-at-guns-problems-and-how-to-solve-them/ I have had reason to question various aspects of the way CM models AT guns recently. A PBEM opponent of mine in a QB actually recently posted about the "concealability" (or lack of) of four Flak38 88m guns that featured in a QB we recently played. We discussed his post after the battle and we both considered how things might have gone had he in fact used 75mm Pak40 ATGs instead of the Flak 88 guns. The Pak40, based on tests, seem to have a huge advantage over the Flak 88 as far are concealment. We both tended to agree that ATGs in general seem to "have it tough" in CM for some reason and not just in concealment. Movement speed, deploy/packup time. To make matters even more grim for ATGs, the latest CMBN patch 3.12 actually, (for some unknown reason) has reduced the rotation speed of ATGs. Does anyone know why and what the basis of this change in the latest patch anyway? Regardless, I went ahead and just did some investigating and testing myself. First of all, I checked the rotation speeds of a deployed 75mm Pak 40, a Flak 88 and a Flak 37. The results are as follows: To rotate 180deg: Flak 37 = 12sec Flak 88 = 32sec Pak40 = 43sec NOTE: WynnterGreens rotation speed tests conducted in that thread above lists the speed of rotation of a Pak40 in that version of CMBN as being an incredible 114sec to rotate 180deg! BFC must have found reason to increase the rate of rotation of a deployed Pak40 since that thread by about 265%. However as mentioned, as per patch 3.12, they have now seen reason to however reduce the rotation speed of all AT guns (can't check yet as I have yet to install the patch). I am curious to know what reasons they had for that. I haven't found any reference to compare these values against but I have found these videos of a surviving Pak40 being handled by re-enactors on flat ground that is more wet/soft/slippery than it is hard/dry. (I do not think these videos of a Pak40 being handled were ever referenced in the thread I linked above. Similar videos were shown but of a Pak 37mm ATG), Throughout the video they do not seem to be in any haste at all and seem to be going a a rather calm/relaxed pace. I could only imagine that in a combat situation, they would not be so calm/relaxed/unhurried as they are in the videos you will see. starts at 2:05 This video clip shows an undeployed Pak40 being rotated 180deg in about 12 seconds. Compare that to 43 seconds in CM for a deployed Pak40. For what it's worth the Pak40 is not deployed either at the start of it's rotation or at the end of it's rotation whereas the CM Pak40 in the test was. How much does this matter? Hard to say. Curious, I did another CM test this time with an undeployed ATG. It took 37sec, which is still over twice what we see in the video. But it was when I compared the speed at which the undeployed Pak40 was being moved by it's crew of six along the wet (almost muddy) grassed ground (might even be on a slight incline) that I just had to compare this to what we see in CM. It is very easy from the video to get a very accurate/precise estimation of the speed at which the crew are moving the ATG at what appears to be a very average/casual/relaxed speed. This speed turns out to be about 67m/minute. starts at 1:43 If you check the speed at which an undeployed Pak40 in CM can be moved in one minute on even flat dry paved roads, they move no faster than 16m/minute! That's about 24% of the relaxed pace you see in the video (or four times slower). Interesting to note that infantry in CM on dry paved ground walk at about 56m/minute. NOTE: According to tests conducted by WynntrrGreen during the writing of the thread I linked above (basically whatever version CMBN was in Nov 2013), the speed of moving a Pak40 was then 8m/minute which is an astounding 8x slower than what you see in these videos. Since that thread, BFC apparently saw reason to double the speed at which a Pak40 can be manhandled/moved. If this doesn't raise the questions as to the appropriateness/accuracy of the movement speed assigned to at least the Pak40 in the game, then I don't know what else would. The only explanation I have is that in the game, the wheels of the ATGs do not rotate when they are being moved so maybe BFC are actually modelling the speed at which ATGs can be moved/dragged with wheels locked! (OK I am being silly here but if that were the case then the in game movement speed seems realistic enough!) The mass of an AT gun definitely figures in to how "easy" it is to manhandle, but so do the size/width/type of wheels mounted to them (ground pressure), it's geometry and location of centre of mass . To keep things in perspective, here are the masses of key representative AT guns and other heavy things on wheels (albeit 4 wheeled varieties) you may have had to push around at times: Pak36 37mm (light): 327kg "combat" or 450kg "travel" (not sure what "combat" and "travel" weights are...I'm guessing "travel" includes ammo. 327kg sounds precise ie. of gun alone) Morris Mini-Minor: 650kg Pak38 50mm (light-med): 830kg QF 6pdr (med): 1140kg Compact car: 1354kg Pak40 75mm (med): 1425kg Midsize car:1590kg Midsize truck or SUV: 1936kg Large car: 1985kg 3inch Gun M5 (med): 2210kg Large truck or SUV: 2460kg QF 17pdr (heavy): 3050kg Pak43 88mm (heavy): 4380kg We all know many people have chimed in on various threads about the modelling of ATGs in CM in the past. From what I have read, the overiding reason given to explain why ATGs are significantly less "mobile" (at least up to 4 times less in the case of a Pak40) as what you see in videos like this is because "if modelled ATGs were more mobile players would "abuse" them" or some other "game specific" reason/justification not based on actual field data. Significantly under-modelling the mobility of AT-guns across the board in CM has typically caused players to ignore the large variation in actual local mobility amongst the different sizes of these weapons and the significant tactical advantages these differences would otherwise infer to some of the smaller calibre weapons. The under modelled mobility of the lower calibre AT-guns results in all AT-guns being treated as if they are the same thing: A static weapon that once deployed is going nowhere and just waiting to be die in place. I think if the local mobility of a Pak40 or anything lower should be a factor in the units tactical deployment and survivability. I am sure there is data/records/doctrine that would confirm the local mobility of these assets as being part of their tactical deployment. Consider tactical ambushes where you might have a med-light AT-gun in wait out of LOS behind cover (such as a building, crest etc), with it's ammo crew slightly forward spotting enemy, ready to give the signal for the weapon to be quickly pushed only a few metres forward into a deployed ambush firing position perhaps behind a hedge fire a few shots, then perhaps be pulled back out of LOS within a reasonable tactical time frame, to be redeployed elsewhere or to avoid the inevitable "whack a mole routine" of incoming arty that is such a staple of CM gameplay. CM under-modelling of AT-gun mobility simply did (does) not even make this kind of utilisation of these weapon systems possible. It really is a drag knowing that the only way to really use any AT-gun in CM is to just find a spot on the map that has both LOS to potential enemy and has some local concealment/cover, plonk it there, and hope and prey it doesn't get spotted before it has a chance to at least take a shot at an enemy. Being able to tactically deploy it in defilade and quickly move in and out from a firing position would greatly increase the survivability and effectiveness of otherwise "sitting duck" med-light AT-guns. Probably can get this discussion going in the right direction by asking the following question: What core data/source/information/modelling have BFC primarily used to base/assign movement speeds/rotation speeds/deploy/packup speeds of say the Pak40 (and all other ATGs for that matter) on? If it has ever been presented I have yet to see it.
×
×
  • Create New...