SenorBeef

<BLOCKQUOTE>quote:</font><HR>Originally posted by ciks: You can't trace LOS through rublle if you are on the same height level the rubble is. If you're higher, then no problem.<HR></BLOCKQUOTE> And naturally, the smoke from burning rubble is harder to see through than simple rubble..

<BLOCKQUOTE>quote:</font><HR>Originally posted by Vanir Ausf B: Actually, you can do this already. Here's how I would have done it: Target the Greyhound as you did, but then give the Hetzer a short Hunt order towards the other enemy vehicles. No delay. Vehicles will turn to target when executing a hunt order. As soon as the Greyhound had died, the Hetzer would have executed the short hunt movement, bringing it to face the M10. [ 05-31-2001: Message edited by: Vanir Ausf B ]<HR></BLOCKQUOTE> Good idea, thanks. It would give it 13 seconds of delay for the greyhound to kill me that target wouldn't... but its better than nothing.

<BLOCKQUOTE>quote:</font><HR>Originally posted by KiwiJoe: Yeah this comes under the whole issue of "micromanagement". Personally I'd like full control... pause delays from 1-59 secs, available both at the beginning AND during other movement orders. But I think you'll find most people are happy witht he way it is and feel its more realistic for this type of game that you under have "some" control over your units orders, and they (the TAC AI), are responsable for the rest. [ 05-31-2001: Message edited by: KiwiJoe ]<HR></BLOCKQUOTE> Actually, this is more a suggested tweak for the TacAI. Currently, if you issue a move order, the TacAI decides "Well, as long as I have a move order, I won't turn to engage any targets".. Its not a micromanagement issue, I'm not asking for a new command to do stuff, I'm asking for an existing command to work with a TacAI flaw. I want the tacAI 'rules' to say that it can turn to engage its designated target while it has a movement order.

You folks generally seem to be pretty knowledgable.. and I just came across an oddity: Hetzer is listed as having a 75mm 792M/S gun, with 141mm penetration at 100 meters, 0 slope. To my knowledge, the hetzer has the 75/L48. The panzer 4 (any variety in the game) also has an l48 to my knowledge, but is listed with a 750M/S MV, and 131 mm of penetration. Marder and jpz4 have 792 also. Stug III has 770 M/S, and 136mm penetration, but to my memory, it called a 75/46, so variations are expected. But the hetzer had the panzer 4 had the same guns, right? Why the differneces in velocity?

Heres the situation: The enemy has a greyhound 120 meters off on the left flank of my hetzer. He also has an m10 and an m4 200 meters in front of the hetzer, but behind a hill so that theres no visibility. I know his plan is to attack with both the greyhound and the tanks/TDs. He'll distract my hetzer by first attacking it from the left with the greyhound, and then, in mid turn, bring the m4 and m10 over the hill to engage the turned-hetzer. Theres no real cover to back into, so my own choice is to engage and destroy the greyhound, then turn to face the m10/m4 when they pop over the hill. Simply ordering the hetzer to target the greyhound would cause it to rotate and engage the greyhound. However, it will still be turned 90 degrees to the left when the m10 and m4 pop over the hill, giving them an easy kill. So, to solve this, I order this: I gave the hetzer a targetting order of the greyhound (in LOS), and also an order to reverse slightly so that it will have to face forward (towards the m4/m10), and give that a pause delay of 28 seconds. So the expected result is that the hetzer will turn, engage the greyhound, and after 28 seconds, back up a bit so its facing 'forward', where it started the turn, again, to engage the m4/m10. Actual result: Hetzer sits forward. Targets nothing. Greyhound pings away at it from the side. Hetzer just sits there.. for 25 seconds. Greyhound pings away at the hetzer front armor (its about 75 degrees to the hetzers left, so it can still hit the front plate, but barely), and after the 4th or 5th shot, the greyhound gets a side shot and kills it. Anyway... I'm assuming the reason this happened is that vehicles won't rotate when given move orders (even when paused). The way that this is set up will completely prevent manuevers like that which I tried to perform.. which don't happen every day, but they're not terribly uncommon. So for CM2, if you could please allow vehicles to move to engage their targets (or specifically ordered/engaged targets only, if you wish), during the time before the actual movement order begins, it'd fix that little dilemma. A small tweak for a small problem.

<BLOCKQUOTE>quote:</font><HR>Originally posted by Bruce Bowes: When I set the Force Size in a QB does that increase my forces as well?<HR></BLOCKQUOTE> Um.. clarify that.

Double post. [ 05-28-2001: Message edited by: SenorBeef ]

Screenshot to demonstrate what I mean. Circled areas are the glitches - all areas of a bocage will 'blink' in and out like that randomly, but at the exact time of the shot, only those particular sections were in the middle of 'blinking' [ 05-28-2001: Message edited by: SenorBeef ]

<BLOCKQUOTE>quote:</font><HR>Originally posted by Freak: This was in a QB against the computer. It was a 700 point high quality units allied attack. I had never seen multiple kills by an MG42 team as high as this before. I may have seen 6 but definitly not more. In this shot you see the mg42 team in the small house. I had a 20mm flak gun in the woods to his right and I bunch of 44 rifle squads supporting it. The mg42 just picked off allied troops as my supporting infantry and flak kept the allied troops from taking cover in the woods. Is this what the germans ment by supporting their machine guns? [ 05-28-2001: Message edited by: Freak ]<HR></BLOCKQUOTE> Thats not too remarkable. The reason you see such low kills, in general, is because you see CONFIRMED kills only. If you stick an mg42 on the reverse slope of open terrain with a flag on your side, you'll see pretty good casualties.

My random idea of the night. Currently, artillery is sort of 'fudged' in punishing you not being in LOS by affecting the dispersion of rounds rather than how far off-center the barrage lands. Historically, as far as I know, incorrect, but it serves a gameplay role. Anyway. Whether you have a hill 5 meters in front of you, and you're firing 1000 meters away, or you're firing 25 meters into a dense woodline (the start of which you can see), both cases are punished by the same degree of disperson. To me, this feels unrealistic. If you can see a treeline, you would be able to simply think "I want to fire 40 meters behind the start of the treeline, and I can see the start of the treeline, so I'll just add 40 meters to that in my calculations." As opposed to being behind a hill and not being able to see see the area at all, and were guessing where you wanted the shells based off a map. So, a proposal I'm making is to have the degree of artillery dispersion based on the ratio of observed and unobserved points in your targetting line. To elaborate, you take wherever your targetting LOS is broken, and break the first and second parts into sections. The section of the line stemming from you is your 'seen' targetting line, and the point past the break is your 'unseen' targetting line. Now, if you're firing into a patch of woods 500 meters away, and you want to fire 40 meters into the woods.. and your LOS is blocked by that last 20 meters of woods, you've now got 520 'visible' firing line, and 20 meters 'invisible' line. In real life, this should provide fairly accurate artillery fire, since you can nearly see your target, just not quite, and you can calculate the difference. However, in a situation where you were behind a hill close to you, firing at the same woodline 500 meters away.. your vision would be cut at the hill, say 100 meters away, leaving 100 'visible' target line, and 440 meters of invisible firing line. So now you're guessing off a map, radio reports, ect, and your fire should be less accurate. I realize, already, that there are holes in this line of thinking. For example, "Whats the difference if a hill blocks you at 10 meters or 100 meters? You still can't see the area you're targetting, why should the dispersion be progressive there?" Thats a perfectly valid concern, and to be honest, I'm not sure how to handle that outside of inflicting a 'maximum' progressive dispersion amount, perhaps from 1-150 meters of 'blocked' firing line, to represent the fact that you're still able to see your target in that case, but beyond that, it becomes less of an issue. Also, if CM starts simulating unspotted fire missions more accurately by affecting the center-point of the barrage, rather than its dispersion, then this above idea would apply to how far a centerpoint is likely to be off from the targetted point. In any case, this is just sort of a random idea I was thinking of, and thought I'd write it down for proposal. I admit its flawed, but it might work into an idea worth something. Mainly, I merely think the current system is a little screwed up in that firing 20 meters into a woodline will provide accurate targetting, but 25 meters is out of LOS and will provide totally scattered artillery rounds. A simply LOS/no LOS switch is overkill in this particular instance, and perhaps a progressive scale might help some, in this case. Your thoughts are welcome, anyone. [ 05-28-2001: Message edited by: SenorBeef ]

<BLOCKQUOTE>quote:</font><HR>Originally posted by aka PanzerLeader: Is a bump in order?<HR></BLOCKQUOTE> Evidently..

<BLOCKQUOTE>quote:</font><HR>Originally posted by Username: Hope this makes sense. Lewis<HR></BLOCKQUOTE> It does, actually. Thanks for the info.

Oddly enough, I ran a fresh install of CM 1.01 (I think), and had the same problem. So its not directly related to CM, and likely a driver problem. Which is odd, given that I've used several different drivers - and it once worked properly, it wasn't ALWAYS blinking. I'm not sure how to go about figuring this out. Is it possible that it results from some physical damage to the video card, perhaps from OCing? (I ran the card at clock when trying to test whether or not I could get rid of the blinking) I also use a utility called "geforce tweak", http://www.guru3d.com/geforcetweakutility/ , and perhaps one of the settings that it played with caused this problem?

This has happened to me countless times. We discuss terms, buy units.. it can be a relatively large battle, and we spend a good 15 or 20 minutes setting everything up. We're almost ready to hit go. Everything is great. -- WOOPS, disconnected. We just wasted a whole half hour. Autosave doesn't kick in until the end of the first full turn. I request that the autosave happy immeadiately after the two clients connect and buy forces - the map data is saved, and the units each side bought is saved. That way, if the connect drops, at least they can go back to the same map with the same units. This also prevents people from 'accidently' getting disconnected to get a new map thats more favorable to them. And, if at all possible, occasional (once every 5 minutes or so) transfer of unit positions from the client to the server. This would help enourmously, because I know I've personally lost alot of time setting things up and getting disconnected by uncontrollable factors, to be really annoyed that the autosave had not yet kicked in. Or, at the very least, set the autosave to save after units are placed, rather than after the first turn, but if at all possible, please implement what I said above.

My leg itches.

What grass and trees are you using?

Bump.. want to see if BTS responds...

<BLOCKQUOTE>quote:</font><HR>Originally posted by Michael emrys: Not exactly. Barrel lengths and propellant charges are designed to be mutually complementary. There is no point in putting more propellant in a round than the barrel can use, therefore merely lengthening the barrel is not likely to help any. The additional friction of the added length is apt to balance the added time for acceleration because the internal pressure within the barrel will have already begun to drop off. Michael<HR></BLOCKQUOTE> Aha, so propellant charges are designed to start 'burning out' in relation to the length of time a round is in the barrel. That makes sense. Edit: Clarity. That is to say, the length of the propellant burn is designed to be as long as the projectile's travel time in the barrel. [ 05-25-2001: Message edited by: SenorBeef ]

<BLOCKQUOTE>quote:</font><HR>Originally posted by Schrullenhaft: Stone wall, hedge and bocage textures are mapped onto a 3D frame, so they aren't sprites (like the the trees "sorta" are). What resolution are you running at ? Have you tried a different resolution ? What is your FSAA set at ? Is it "forced" in all applications ? If you want to, you can send me the screenshots to the email in my profile. I still need to setup a machine with a GeForce in it to check this out myself.<HR></BLOCKQUOTE> FSAA is off. 800x600x32, same as desktop. I emailed the screenshot.

<BLOCKQUOTE>quote:</font><HR>Originally posted by Michael emrys: Mostly it has to do with needing a more massive chamber and breech to contain the pressures of a larger and/or faster burning propellant. Sometimes the barrel needs reinforcement for the same reason. Also the barrel may need special coatings to withstand greater barrel wear associated with higher velocities. Michael<HR></BLOCKQUOTE> Ah.. I thought it was simply a matter of the gas pushing the projectile faster and faster through a barrel, and so a longer barrel gives more acceleration time.

<BLOCKQUOTE>quote:</font><HR>Originally posted by Paul Lakowski: The penetrators are longer and sharper while the charge is much larger...which is why they both penetrate more than the shorter versions of these guns.<HR></BLOCKQUOTE> Whats the reason for this? Why couldn't the pz4 use the round with the larger propellant to get more penetration? Does it relate to needing a lower twist rate in the barrel due to length, or something similar?

<BLOCKQUOTE>quote:</font><HR>Originally posted by YECoyote: Unlike Close Combat, where you rush those Tigers into the front of the line, and have them anhilate EVERYTHING. I played the demo, and tried to rush a StugIII into a team of Infantry. It died a horrible death in less than 10 seconds from a hail a grenades and bazookas. <HR></BLOCKQUOTE> Usually my guys tend to fire rockets at the tanks with bazookas, as just throwing them tends to penetrate less.

<BLOCKQUOTE>quote:</font><HR>Originally posted by Panzer Leader: Whoah there! That idea by Rollsroyce makes the whole idea of a campaign game a possibility. The file that it spits out could be used to set up the NEXT battle, taking into account the victory conditions, losses, etc. Oh man, I am excited now. BTS DO SOMESING!<HR></BLOCKQUOTE> The best part of it is that its no work by them, at all, aside from saying "display victory conditions in this file and on the screen" rather than just "display victory conditions on the screen", which is a minimum of effort. So I hope they'll open the door to any coder who wants to write a program to keep track of things between battles. Additionally, although its extra work, it would be nice if you could import units into scenarios by standardized text files. This way, the front end could keep track of your batallion, or whatever it may be, and automatically send the updated roster, with casualties, experience gains, supply/ammo, ect, directly into the CM scenario editor. To do this, BTS would have to do a little work, but I don't think it would be too hard, but they would be opening the door to their talented fan base to make free programs that increase their game's appeal. I, for one, would welcome such opportunities, and would heavily consider working on a 'strategic' layer sort of program. BTS, your comments please?

<BLOCKQUOTE>quote:</font><HR>Originally posted by Offwhite: I was curious whether higher quality crews' increased chances to hit were actually shown in-game via the LOS/targetting line - turns out it is. I did a quick test involving six Panthers and six MkIVs, one each for every experience level, aiming at a lone Jumbo about 790 meters away. The German tanks were lined up hub to hub so that they were all seeing virtually the same aspect of the Jumbo (front). For both types, Panther and MkIV, Conscript crews showed a 15% chance to hit, and there was an increase of 3-5% for each step up in quality. At experience levels above Conscript, the Panther chance to hit was either equal to or 1-2% greater than the MkIV of the same experience, which is probably the effect of the higher velocity long 75. At the upper end of the scale, the Elite MkIV showed 34% chance to hit, and the Elite Panther showed 36%. So it's only one test, under sterile conditions, but I thought it was interesting anyway.<HR></BLOCKQUOTE> Hmm.. I would think that the difference in velocity (which is the only way CM calculates accuracy - as opposed to using optics, and such) would justify more than a 2% increase.

<BLOCKQUOTE>quote:</font><HR>Originally posted by JMcGuire: That random-battle generator thing could EASILY be altered to spit out some standard file format (e.g. an INI-style thing) that could feed CM on the command-line. Then you could use the e-mailing stuff for the "fair randomness" thing. It would take me maybe 30 minutes to make the changes. Definitely a good idea.<HR></BLOCKQUOTE> Thats an excellent idea also. Allowing a standard file to define the QB settings would allow quick 'standardized' qb settings, easier saving of prefered settings, and, as you said, add the ability to import settings files agreed on mutually. With a front end, either method could work. The front end could either enter the command line directly, or write the file and launch the command line to point to the file. <BLOCKQUOTE>quote:</font><HR>Originally posted by Rollstoy: To take this one step further, Combat Mission could also export the result of the battle as a text file such that the outcome of a battle can be re-imported in the front-end program. This way, a strategic layer could be designed ... Regards, Thomm<HR></BLOCKQUOTE> This is also an excellent idea. It would be a simple matter to put out the AAR data into a text file - and then if someone wished, they could write a front-end to do something with it (I'll consider doing that), otherwise, you just create a harmless text file, which assumably gets written over every new game (like an autosave)