Jump to content

Lt Bull

Members
  • Content Count

    837
  • Joined

  • Last visited

About Lt Bull

  • Rank
    Senior Member

Converted

  • Location
    Australia

Recent Profile Visitors

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

  1. Hello I have tried to log in to the HelpDesk so that I can open a ticket to see if I can solve a PBEM file problem. The PBEM has been going on for over 2.5 years, we are up to the last few turns, file #178. When I load this file the game crashes around 90% loaded. Even though I can load in to my BFC account on the main battlefront.com page, I seem to need ANOTHER log in to log in to the HelpDesk to "view existing tickets". There seems no option however to "create a new account" just for HelpDesk purposes. I have nevertheless just submitted a ticket after logging in with a Google account. Is there something wrong with the HelpDesk? I need BFC to check out the PBEM file. Ticket has been successfully logged. Still don't know why I wasn't able to just log in and raise a ticket under the same account as my BFC account :/.
  2. 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.
  3. Apparently not. We are at v3.11 and I have just checked that this bug still exists for this building. :/
  4. 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.
  5. 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?
  6. 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.
  7. 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?
  8. 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.
  9. Hello all, is there or are any plans for anyone to make a gridded version of this terrain mod?
  10. 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.
  11. 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.
  12. 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?
  13. Thanks all...should have posted earlier...problem solved after opponent remade turn and orig file deleted from Incoming folder, not just Dropbox folder (using CM Helper)...can delete this thread
  14. CMFB relevant discussion at CMBN forum: http://community.battlefront.com/topic/122944-atgs-again/
×
×
  • Create New...