c3k

Gents, I've tested (once) ammo use and distribution after resupply and am glad to report that v1.11 seems to have fixed the issue of team ammo distribution. My quick test did show two small oddities though. More on that later. The test was with a 9 man US engineer squad. I split them into teams. 2 teams each had 2 m4's and one m203. The other team had two m249's and one m4. I ran them totally dry by TARGETing some nearby empty ground, WeGo. (Crack, fit, etc.). After they ran dry, I ran a single team back to a Bradley and had them ACQUIRE 2,000 rounds of 5.56. Then they, and the other two teams, reformed into a squad. The squad information panel showed full ammo. I then split the squad back into 3 teams. In v1.10 this is where only the re-ammo'd team would've kept the ammo and the others would've been back to empty. Happily, v1.11 fixes this; all three teams had full ammo bars. Thanks. Now onto the oddity (or two). I was watching the teams burn through their ammo. The two rifle teams used ammo in a linear manner. As they fired, I could see a bar of ammo disappear every now and again. That seems fine. The M249 team did not exhibit that behavior. They kept a full ammo bar for some time. (Fine, they probably have more 5.56 for the M249's.) But, when the ammo bar finally decreased it did so suddenly with no linearity. In fact, it went from full to missing about 5 bars in one second. Then, within the next few seconds about 5 more bars disappeared. Each of these ammo bar usages appeared all at once, not one at a time. "Zap" 5 bars gone. Why is this so? Is this a minor bug, or does it reflect a purposeful decision? Secondly, the teams fired for 2 turns after running dry. For all but the last half of the second turn the rate of fire continued unabated. So, after using the final, red ammo bar, the teams would keep full firepower for about 90 seconds. I fully understand each soldier keeping a few extra last-ditch rounds available, but 90 seconds worth? Regardless of the answers to the above two issues, I'm glad the ammo distribution issue has been fixed. Thanks, Ken

sage2, If you want a CD burned and mailed, I'll do it for you. Either post your APO or email me. Let me know if you want anything else on it (mods, downloads, etc.). Of course, I have no idea how long it'd take to get to you! Regards, Ken

sage2, Go for v1.11. It (and v1.10 before it) makes CMSF a VERY good game. Perfect? Heck no. But very, very good. Besides, what else are you going to do in Mosul while you're waiting for the download? I doubt there's a hot date you'll be missing. Thanks for your service! Stay safe. Regards, Ken

No, you're not weird. The compass is, um, non-intuitive. In a perfect world, the needle would always point north and the compass card would rotate with the camera. Or, better yet, the game would assume that you knew how to read a compass and do away with the compass/needle display and just show the current camera facing as a heading, e.g. "187" when you're looking 7 degrees to the west of south. This falls into an obvious design decision where BF.C has to draw a line between making the user/player perform an action or do they just provide the result of that action. In this case, they decided it would improve the game for you to do the compass interpretation. (Of course, it is more difficult since the compass CARD points north, not the NEEDLE.) Regards, Ken

Yeah, what mikkey said. I'm a Vista64 Ultimate user and I finally got tired of having duplicate folders, only one of which worked. I created a C:\battlefront folder and installed cmsf into that. Now it doesn't have the virtual store duality issue. Regards, Ken

Gents, Thanks for resurrecting this. Apocal - please read the entire thread. There is nothing here (that I have posted) that puts the company or battalion commander in the position of loading ordnance on aircraft. Right now the game assumes certain specific loadouts. It uses those loadouts in a manner which is fully opaque to the player. In a battle YES the company commander would know (through the JTAC) what kind of ordnance would be coming his way. All this thread is trying to do, is bring to BF.C's (and others) attention that a change to the GRAPHIC INTERFACE would do wonders for clarifying the air-to-ground aspect of this game. No changes in loads, no changes in interactions (unless you want to add the run-in axis as an option which would be JUST LIKE a linear artillery request), but, a simple change in the pictures on the user interface. Regards, Ken

Gents, I appreciate the comments you've made. In the situation I described, there were TWO RPG launches before the truck's gunner ID'ed the RPG team and their location. I think the TacAI is well tuned in that regard (spotting RPG teams). Next, the TacAI directed the gunner to fire the .50 at the threat. Excellent! After 5-8 rounds, the threat was no longer ID'ed. The gunner then ignored them. The behavior I think needs tweaking is the gunner ignoring the known location of a deadly threat which has twice tried to kill him and destroy his vehicle. The tweak I'd think could improve the game would be to have the gunner continue to fire on the area in which the RPG team was located. He KNOWS where that area is because the RPG team was identified. Hence, 5-8 rounds of return fire is just a bit too light. ESPECIALLY given that there are no other threats, contacts, or any other fire anywhere elsed. That's all; let the vehicle gunner spray the treeline a bit more in WeGo after the enemy is suppressed. Thanks, Ken

That would be the "open the valves to the oil wells and let the imperialist Americans slip on the oil while we escape the other way" tactic. This shows the inherent realism in all BF.C's games! My real .02 would be to delete mods, update video drivers (after CORRECTLY uninstalling the existing ones), then reinstall the mods you like. Good luck! Ken

Guys, One quick impression and not a positive one. This is one quick datapoint, so take it for what it's worth. In an elite, WeGo, as Blue vs. AI, a USMC MVTR with a manned .50 cal was fired upon with an RPG by a "?". This was the second turn and there were NO other enemy contacts. The next RPG also closely missed, but changed the RPG teams's "?" to an identified rocket icon. The MVTR's .50 slewed to 10 o'clock and fired a 5-8 round burst at the RPG team. The RPG team then became a "?". Immediately the .50 slewed back to 12 o'clock. Now, this doesn't break the game, so let's not get carried away. However, I thought that firing upon enemy who become "?" would continue per the release notes. The release notes may mean that only enemy who are actively TARGETED by the player, and hence gain a red line LOS/LOF, get that treatment. Therefore TacAI targeted enemies do not get fired upon as area fire after they duck. I don't know. I would think, were I to be standing in the turret ring of a truck with a .50 cal., and a couple of RPG's fly out of the woods and go past me, I'd be hosing down the treeline. Nor would I stop for some while, unless, and only unless, I went out of LOS of the treeline or a greater threat became apparent. (Or someone ordered me to ceasefire.) I think this area may need more tweaking... Regards, Ken

Hmm, running as admin, agreeing to UAC didn't work. After a complete CMSF uninstall (and forgetting to save a LOT of created test scenarios), and reinstall, I still had problems. I got the same error message installing my USMC cd. Then I thought about my antivirus. D'OH!!! Yes, that was the problem: kaspersky 2009 antivirus refuses to allow the creation of the folder/file I listed above (USMC performs a similar action). I have no idea why KAV2009 does this without popping up a box that KAV is performing a block. Suspending the antivirus has allowed all installs. Blue Bar goodness is mine.... Thanks, Ken

Gents, This must be what I get for all my previous posts! Anyhow, running Vista64, the USMC patch, I keep getting a runtime error at 1:349 (or so?). The verbiage says it's unable to access a file at users/ken/appdata/local/temp. The file name changes but is always along the line of "is-53FBI.tmp/setup.bmp" or "is-AQBN.tmp/setup.bmp". I know I've mangled the message a bit, but the specific name changes. The alphanumeric after the "is-" and before the ".tmp" is always different. Does anyone have a clue about what this could mean? Or, more importantly, how I can run the patch without an error? Thanks, Ken

Hmm, MY download (USMC) from the BF.C server is showing 129Mb sitting in its cozy new folder in my download file. Although, that's just its resting state; it looks so cute, and my hopes are so high, I haven't had the heart to wake it up and make it go to work yet. Regards, Ken

Steve, You guys care, you really care... <sniff, sniff> Amazing job. I never had a horse in the blue bar race, one way or the other, but I can only applaud your re-examination of this issue and decision to change the game code in such a, ahem, "fundamental" <cough, cough> manner. Because of this one decision, I just may consider buying your next game. Regards, Ken

Ooooooh, that's just EVIL! It sounds like something out of the Beta Tester's Revenge. Ken

Gents, Oh my, v1.11 isn't even out yet, but SOMEONE has to start a thread bemoaning it and crying out for a new patch: this is that thread. :) Enjoy, Ken

Sergei and Steve, Thanks for info on the v1.11 fix for the icons! Err, any chance for a post describing the reasoning behind the name change from "Assault" to "SMAW" based on whether the unit is a SMAW _squad_ or SMAW _team_? Thanks, Ken

Hmmm, maybe looking at this thread http://www.battlefront.com/community/showthread.php?t=83224&highlight=HOLD will shed some light on an approach to this problem. Of course, any solution requires BF.C to take time away from something else and devote it to this issue. Regards, Ken

That partial list of fixes sounds very good. The full list of fixes for v1.11 will be great. Thanks, Ken

marsod, In my case, I am all but convinced this is a manifestation of the common nvlddmkm crash. It is a TDR problem. In XP it would cause a BSD, in vista, the kernel isolates the errant video driver and closes the program using it, but keeps the OS running. A search of nvlddmkm will reveal a LOT! (Those with ATI cards are not immune, they get an ati driver error.) There seem to be many, many, many possible causes of the instabilities which cause this. Sometimes it's a bad video driver, or a PSU which is underpowered on one rail or another, or undervolted RAM, or overclocked CPU/RAM, or overheating somewhere. Regards, Ken

Agreed on the vehicle face. It is a target command, vice a movement command, so only one target command can be active per waypoint. I don't see a fix other than swapping FACE to a movement. (Or, SLOW move the vehicle to the next Action Point in the direction you want it to face. I know, that's rarely possible, and when it is, the new pathfinding in v1.10 may result in self-destructive behavior.) Buy, um, none of this has to do with machineguns. Ken

cabal23, Time for breaching walls and buildings should be the same. (I'd think - no testing to verify.) Perhaps it is 15 seconds from the time the sappers assume the breaching position (atbp). However, when will they atbp? They moved into position ((that caused an unknowable delay); there was enemy fire nearby which could've caused suppression (that was another possible unknowable delay); then they switched from their quick move to their BLAST move (that caused another unknowable delay as they quicked to that waypoint); then they BLAST moved to the wall (that move caused another unknowable delay)); they then atbp (what is the countdown there? does enemy fire cause a delay?). So, the above sequence is a micro-examination of all the possible delays and time sinks when moving a sapper unit into position. The BLAST command includes a movement portion; that portion changes based on distance and enemy interaction and terrain. That, plus any preparatory movements prior to the BLAST command (and the concommitant terrain, distance and enemy fire interactions) causes the demo charge's detonation time to be unknowable to the player. In real life, the two elements, breach and assault, would be much better coordinated. The two man SMAW breach team is too small and too valuable to actually assault INTO a possible enemy position, which is what happens with the BLAST command. (The movement INTO the obstacle following the blast.) My attempt was to beef up assault element through the BLASTed building wall. Regards, Ken

Hmmm, that is what I'd LIKE to see happen but it doesn't. (Although I'm more than happy to be told what I'm doing wrong, I've been playing this game since it came out so I've got a little bit of experience.) As I stated, it was a building, not a wall, that I was breaching. The coordination was important to prevent the assault from going into an available door. I'd set waypoints so that the closest entry would be the breached building side. I'd set a 30 or 45 second delay to ensure the breach would've been created by the time the assault reached the building side. The breach had NOT occurred by the time I'd been confident it would've. So, it's a timing issue. How do I know how long it will take to breach an obstacle? Right now it's a bit of hit or miss. How long will it take the breachers to reach the set-point? Once they reach it, how long until the begin the breaching process? Once they start the process, how long until the charge is detonated? Once they start, will incoming fire slow down, halt, or abort the process? Thanks, Ken

Gents, I'm always having fun trying to coordinate my men while playing WeGo. Sometimes it's very hard. Other times it's harder. I just tried using a SMAW team's demo charge to BLAST the side of a building so an assault element could gain entry without resorting to the building's doors. The enemy had units in other locations which were covering the approaches to the doors. The side I was trying to BLAST was out of LOS of any enemy. Pretty smart of me, huh? It didn't work the way I wanted. My SMAWmen got next to the building with their BLAST command. There they sat, doing whatever demo things needed doing. I'd assumed it'd take them a bit of time, say 30-45 seconds. So, my separate assault element left their cover after a suitable delay (PAUSE of 30 seconds). They had an ASSAULT order into the target building. The demo did not go off in time, so my assault element continued to the doorway closest to them to enter the building. After the first team was in (and got fired at by the doorway), THEN the demo went off. Errr. Is there any way to add a countdown over a BLAST unit which shows WHEN it will go boom? I'd love to see it just like the PAUSE countdown, but with the word "BLAST" added to it. Of couse, a little stopwatch would look cooler. Or, allow an optional SET OFF AT :xx command. This would have the demo team prep the charge and then standby to set it off at the specified point in the next turn. Such as SET OFF AT :45. Then, I'd know that 45 seconds after the beginning of the turn (NOT 45 seconds after the team gets to the location) the demo will go off. Thoughts? Regards, Ken

Apocal, I've tested your thesis regarding 0351's moving up or down: the game does not reflect this. In all cases, the 4 man squad shows the SMAW gunners as the first man in each team. When broken down into the 2 man teams, the SMAW gunner is still the first man. I assume the first man indicates the primary weapon user. If it's a SMAW, well, it's a SMAW. So, no manpower change in the user interface. Still, always having a proper SMAW silhouette would make it MUCH easier to find these guys (whether or not they're going to use the demo charge or SMAW). Thanks, Ken

Apocal, Thanks for the insight on the 0351's. I have not noticed a change in manpower distribution in the squad/team split. Regards, Ken