SenorBeef

<BLOCKQUOTE>quote:</font><HR>Originally posted by Wolfe: Hey! Do you still have a copy of that thread? If so, could you send it my way? Thanks. - Chris chare@erols.com<HR></BLOCKQUOTE> No, sorry, just my post. I edited my post with wordpad rather than on the web page for ease.. so I ended up saving it.

<BLOCKQUOTE>quote:</font><HR>Originally posted by Gyrene: I've recently discover the joys of Panther killing with Fireflies in CM and also have started to develop a great admiration for the later model Churchill's thick hide, now my question is: Why wasn't the great 17 pounder gun placed in Churchills? Turret ring too small? Tank considered too slow? That combo would make a tank that would cause Big Cat commanders to lose sleep. Gyrene<HR></BLOCKQUOTE> Churchills weren't used operationally like they are in CM, generally. If you've got an enemy armor company attacking someone in your division, are you going to want your only capable AT guns mounted on a quick, reliable sherman, or a sluggish churchill? Sure, when you're actually there, in the battle, churchill with 17 pdr sounds great.. but when you've only got so many guns to go around, do you really want to mount them on the tanks that can't go anywhere?

<BLOCKQUOTE>quote:</font><HR>Originally posted by Mr. Johnson-<THC>-: Or just try not playing me on the defense Senor Beef. It was a little sad to see them all die so quickly.<HR></BLOCKQUOTE> Ahem... the death of that platoon was avenged.. by lots and lots of boom boom.

<BLOCKQUOTE>quote:</font><HR>Originally posted by KwazyDog: SenorBeef, if your playing the scenario I think you are playing, you will probably find that it is actually a German plane your guys were shooting at Dan<HR></BLOCKQUOTE> Oh yeah? I thought the briefing said it was an american one. I assumed it was mistaken identity. Well, another plane came along, and blew up another building... ergh.

<BLOCKQUOTE>quote:</font><HR>Originally posted by Panzer Leader: Oh I see now. I thought you were some dodgy old DOS guy at first, but the idea of being able to have a front end is intriguing. It could do all sorts of stuff, like set up random QBs and even handle PBEMs. This idea has some merit. Of course, part of the draw is that I am alwaysa wanting ANYTHING that gets our grubby hands deeper into this game and its mechanics! Still, I like the idea.<HR></BLOCKQUOTE> I am one of those dodgy old dos guys - but thats irrelevant And I don't think it would take much effort on their part to set it up, but I think my front-end would help speed up and increase ease of communication when setting up QBs.. and the presets would be especially valuable if you like single player QBs. This could also be done as an OLE link of some sort rather than through a command line, but I think that would unnecesarily complicate things. Also, pbems could be kept track of, automatically run, emailed, ect.

I was playing a cc2->cm scenario of schindel road. My air support arrives entirely too late, but I'd won the battle anyway by this time. So the aircraft targets my stuart.. simple misidentification, fine. But something odd happens: Firstly, my units fire at the plane. My m3 halftracks, (and I think a sherman a3) all let off a burst at the plane. Thats odd enough because I didn't think m3 had AA capability, but I could be wrong. Secondly, they never actually targetted the plane, there was no target line, just a bunch of tracer rounds into the air. Third, they expended an ammo point to do this.. but some units lost the ammo point a few seconds before firing (they weren't firing at anything else.. they just lost an ammo point, and 3 or 4 seconds later, some tracers went into the air) Anyway, just a few oddities. I've never seen friendly ground forces target their own planes.. and I've never seen tracers fired off without a targetting line. (Oh, and he missed the stuart he was firing at, and hit a building with both bombs. Smashed the thing instantly, and took the remnants of a platoon with it. Cool screenshots.

I have a shot but nowhere to host it right now. Want me to email it?

On second inspection, they don't actually completely dissapear, they just go half-transparent and sort of blur. I'll see if I can catch it in a screenshot.

<BLOCKQUOTE>quote:</font><HR>Originally posted by Schrullenhaft: What OS are you running ? Do the textures still blink out on a clean, un-moded install of CM (1.12) ? What version of DirectX do you have installed ? When the textures blink out are you moving around the map or do they blink out while you remain still ?<HR></BLOCKQUOTE> Win ME and Win2k Adv server. Problems exist on both. ME uses dx8, 2k adv server uses whatever comes as the default. And, they blink constantly, whether I'm moving or not. I'm wondering what the connection is... How exactly are brush/ect drawn? Are they sprites? Maybe thats the problem, sprite blinking rather than texture blinking?

<BLOCKQUOTE>quote:</font><HR>Originally posted by Abbott: I am interested in different tactics used by players for employing their Axis armor. What have you found that works for you? If an experienced player or three would be interested in writing an article or two on the subject I would be interested in speaking with them. sos@kscable.com <HR></BLOCKQUOTE> HIDE! Those damn 17 pdrs and 76es with oodles of tungsten are everywhere.

My stone wall, hedge, and bocage textures, and only those textures 'blink' in and out of existance, constantly. They'll look perfectly fine for about a quarter second, then they'll go transparent for just the tiniest bit of time, 2 or 3 times. Its incredibly annoying, because those particular textures are constantly blinking in and out of existance. This didn't start when I first started playing CM, and since then, I formatted/reinstalled everything (cm, drivers, ect), but for some odd reason, the problem still appears (maybe it appeared in a patch? I can't remember, honestly). I copied over the scenarios and mods and stuff from the old install, but didn't really install them or anything, so theres no connection there. I have a gf2 mx, currently running detonator 12.10 drivers (I think), but the problem appears both with detonator 6.33 and 6.5 too. I have a t-bird 800 running on a kt7-raid.. any help would be useful, thanks.

<BLOCKQUOTE>quote:</font><HR>Originally posted by Michael emrys: While I don't think that your suggestion is entirely without merit, SenorBeef, there is one point that needs to be held in mind. And that is that the movement orders given in CM are usually somewhat more complex than the ones that would be given by a real life platoon leader in the same situation. That is because the TacAI is not yet sufficiently sophisticated to duplicate the initiative of an experienced squad in using terrain in its movement. Therefore, a little more micromanagement on the player's part is called for and should not be unduly taxed. For the moment though, something on the order of one extra second per waypoint doesn't strike me as excessive. Michael<HR></BLOCKQUOTE> This is a good observation, and I agree to it to an extent. I don't see this as a critical flaw or anything like that, in CM, its perfectly workable. I think it just might add another layer by worrying about coordinating your units, those with complex orders, and those with simple supporting orders. It would just add an extra layer of realism and consideration. Nothing major, but I was just offering this as food for thought.

<BLOCKQUOTE>quote:</font><HR>Originally posted by Maximus: So how is that different than to going to the graphical user interface and selecting all that from pull-down menus? With command line variables, you still have to type all that out.<HR></BLOCKQUOTE> Erm, I don't think either of you read my post. I said the primary reason for this would to be allow for the programming of QB and PBEM front-ends. This means a program that presents you with whatever options it wants to, and has the ability to execute the CM game of your choice. For example, say you like playing german attack, 1500 points, in jan 1945, heavy trees, rural, moderate hills. Or something else entirely.. whatever it may be.. a front-end program could allow you to set pre-sets that would allow you to set all of your favorite game parameters in one click. Now, the front end program would then, itself, not you, enter the cm command line that brings up the appropriate QB. This allows you to generate completely random QBs, to save your favorite QB parameters and execute them with one mouseclick, and also the program could put a text string into your pace buffer that listed all of your parameters, so you would merely have to hit paste to get "Allied attack, 1500 points, combined arms..." ect, ect. It makes it much easier to get that info to your opponent, rather than having to type it all out, forgetting to add some stuff, ect. Anyway, I've already offered to design the front-end myself, I just want them to implement a command line system so that a QB could be directly executed from the front-end.

I forgot to add that a PBEM command line set would help that part of the game along too quite nicely.

<BLOCKQUOTE>quote:</font><HR>Originally posted by JasonC: So, I wouldn't want to see the added cost go too high. The total delay from a typical order ought to be some fraction of a 60 second turn. But generally less than half of it. The first 3-5 waypoints should probably be "included" in the present cost, not just the first, if something like this were done. And the added cost per waypoint or action should not be high - 1 sec, not 5.<HR></BLOCKQUOTE> Well, the 13-second day (or whatever it might be) is an abstraction for being a middling time from which both quick and complex orders are simulated. Its not (I assume) the low-end number representing the minimum time an order will take to implement. Meaning, orders don't NEED to have a 'base' of 13 seconds (regular infantry) or whatever it may be. That time can actually be cut in regards to simple orders. A quick order to move 20 meters ahead to the end of the tree line might only take 6 or 7 seconds to implement, for example. So it wouldn't be only a time delay penalty, but it could be a reward for simpler orders. EDIT: Btw, Lewis, I think the system already does work like that, with higher quality units being more 'flexible'. [ 05-24-2001: Message edited by: SenorBeef ]

I would like to suggest creating a command line set for QBs in CM2. One of the current lacking features is the time it takes to set up a qb with someone, tell them exactly what you mean, see what they want to change, go back, change it, come back out, see what else they want to change.. ect. Its not a huge workload, but it can be annoying. You also can't really get a really random QB in CM. Proposal: Create a command line function for QB generation so that front-ends can be written for CM2. I'll write one myself, if you implement such a system. This way, someone can save certain QB 'presets' they like to play with, and play them at the click of a button, rather than modifying 10 qb parameters.. you could also generate a randomize function that would effectively randomize some or all QB variables. Additionally, and perhaps most useful, the front end would be able to generate a paste-able text string describing the settings of the QB, so you don't have to spend all your time listing everything to your opponent. A simple system, such as cm /QB /WEATHER:CLEAR /DATE:AUG42, ect. It would be unwieldy for someone to manually enter all that data, but it would facilitate the use of a front end program that could simplify and add QB functionality, especially, but not limited to, multiplayer. Thanks for your consideration.

My third topic of the evening, but what else am I going to do at 4:30am? Here goes, a proposal for CM2. I've been thinking that having orders, regardless of their complexity, take the exact same amount of time to start implementing isn't realistic. Whether its worth it or not to implement a system to remove some of the abstraction for its perceived gameplay value is completely up to debate. The current system is good, just could be worked on. Anyway, the meat of it is.. Whether you issue an order to move, 10 meters, to the edge of a treeline, or whether you move up to the road, then left for 100 feet, then forward for another 200, then crawl to the right for a few hundred feet, ect, both orders take the same amount of time to get moving. Clearly, an order of "Sargeant, get your men to the end of that woodline" or "sargeant, go here, then there, then here, then crawl here.." would take different amounts of time to implement. So perhaps a system could be implemented by which command delay is based on the complexity of the order. This could be as simple as adding an extra second or two for every waypoint on a trip, or more nebulous, taking into account amount of distance moved, whether they can see their destination ect. Anyway, this is just a suggestion for a rather minor abstraction, and so it is in no way very important to CM2.. but it could add a little something. Comments are welcome.

This got lost in, I think, the ammo thread that was going before the BB crashed, and anyone could respond to it, so I'm reposting it here. <BLOCKQUOTE>quote:</font><HR>Originally posted by Big Time Software: Panzer Leader, this makes some sense but it would mean that as soon as the unit rotated the extra cover would be lost. And since that happens all the time, I'm not sure this would have any real effect on the game. We would also have to program in some sort of "don't move around" order as well as give units some "memory" about how long they have been sitting there. This is quite a bit of work for something that probably will have only a minimal impact on realism or combat results. Steve[/QB]<HR></BLOCKQUOTE> Steve, Jason brought this issue up a while back with greater depth. (Of course, he always does.) One of the great unrealistic advantages of the attackers in CM is their ability to instantly take maximum cover of the terrain the instant they step into it. A unit (not in a foxhole) that has been sitting in heavy woods for 2 minutes has no cover advantage over a unit who just ran into another patch of heavy woods 100 meters away. I believe this to be clearly unrealistic. The defenders (those that have been static for longer) have had a chance to find the perfect firing spots, at least as much is allowable in 2 minutes. However, the unit entering the woods does not share that advantage. They can hide behind a tree, or hit the ground, but their positions are taken hastily, not sought after moments to decide their best positioning, until they have been long enough to shift themselves to benefit from the specific cover provided. This gives the attacker an obvious benefit that he would not have in the real world, and serves to harm the balance between attacker and defender. I do not believe this to have a minor effect on the game. Additionally, in regards to losing cover benefits after rotating, I don't believe that to be true. Rotating, as I understand it, is an abstraction of some men getting into different firing positions to attack a different target. Unless a radical change in facing were to occur, most men in a squad would likely be able to shoot at their new target without even moving, simply by aiming a different way. Those troops that couldn't, perhaps 1 or 2 of them, would then move to a position that allows them to fire at the new target. This would depend on specific terrain and angle, but in general, an entire squad isn't keyholed so much as to have all of them need to move to shoot elsewhere. This could be represented by the unit losing partial cover during rotation, rather than full. It can be as simple as saying 'For every 20 degrees rotated, one man needs to move in order to reach the next target, although probably a bit more complex in execution. So in the case of a new target 40 degrees to the left, the squad would lose a percentage of cover equal to: (2/Squad size)(Time_in_cover_benefit) to represent only 2 men, of say 10, actually having to lose their added cover to attack their new target, rather than all 10. They would still be provided the 'base' cover of the terrain, but some cover would be subtracted from their 'added' cover benefit from time of occupation, equal to the portion of the squad moving. No reason for members that aren't actually moving to lose cover. So if the base cover of a terrain type is 40%, and after a minute, a squad gets an extra 20% of cover from finding better specific cover. Upon switching targets, 2 men must move. So they lose (2/10)(20%), 4% of cover, until the rotated men could regain that cover. Specific numbers are off the top of my head, for demonstration purposes, real values would be different, of course. As a whole, I think this would provide a more accurate war game, and give back some of the historical advantage of the defender. It will not be a drastic change, but I believe it to be a useful one, and would add value to gameplay.

I noticed this in a recent game. Heres the situation: I have arty coming down in 20 seconds, and I want to rush his gun. However, I don't want to rush out until the gun is under artillery fire for suppression. Its a big gun (150mm), so I don't want my troops firing at it.. I don't want the gun to see them. So I hide them. All is cheery. So I enter my movement order, and pause for 40some seconds. Everything is great... Until I hit go. The units which were ordered to hide all 3 got up and fired at the 150mm gun. The 150mm then quickly raped the platoon before it could launch its attack. "Hide" state is lost immeadiately upon a movement order being given, rather than a movement order being implemented. This, I think, is clearly a flaw (if a minor one), and I would like if you would consider fixing it for CM2. EDIT: I really need to start proofreading more. [ 05-24-2001: Message edited by: SenorBeef ]

<BLOCKQUOTE>quote:</font><HR>Originally posted by Mike721: The two things that drive me nuts are having a tank become immobilized in mud and losing one in a duel because my gunner can't hit the other guy in 4 rounds. I know that having a crew that are "veteran" status improves gunnery and the ability to free a vehicle, but is it enough of an improvement to warrant the extra cost?<HR></BLOCKQUOTE> In my personal experience, its better to save the money on the veteran vehicles for veteran infantry.

<BLOCKQUOTE>quote:</font><HR>Originally posted by Furiously Babra: I keep getting a "Hack Attempt Logged" message when I try to use the Babra nick. I know I'm a hack, but sheesh... <HR></BLOCKQUOTE> Ow, my colon. HTH.

<BLOCKQUOTE>quote:</font><HR>Originally posted by caralampio: Hi, Does friendly fire (aside from mistaken air attacks) cause casualties to your own troops? I mean like smallarms if friendlies are in the line of fire. Does having height advantage give any cover? How about infantry behind a crest, in a gully, etc. where only the upper half of their bodies is visible to the enemy?<HR></BLOCKQUOTE> Maybe, no and no. For the first one, friendly MG grazing fire might have an effect, but regular squad firepower doesn't, as far as I've ever noticed. There was a big discussion a while back (search for "Are hill crests cover?") about height advantages and such. They're simply not modelled. The only advantage to height is observation. This has nothing to do with the fact that the graphic representation of the soldiers is variable (as was stated above), but simply that they don't have the extra code to account for it. Squads ARE abstracted, but they could still be modelled to get abstract cover bonuses from crests and such. But to your answer your question, they don't.

<BLOCKQUOTE>quote:</font><HR>Originally posted by Gen-x87: Remember in the early parts of the war the armor was not that thick on either side. So some crude weapons like the 88 flak and some lighter AT weapons will probably do the trick. The thing that will be interesting once they get to the early part of the war is the German players like myself will have to use tactics to kill Allied armor with our PZIIs and PZIIIs No more just standing off and picking off Allied armor with Panthers! Gen<HR></BLOCKQUOTE> Yeah, that damn crude flak 88mm. Give me a bundle of grenades any day.

<BLOCKQUOTE>quote:</font><HR>Originally posted by AFLC: Might it be possible with the actual code? I don't see why not. Not only it would be interesting to watch a learn, it would also be nice to command a platoon/batallion and have the computer command another. Alexandre Carneiro<HR></BLOCKQUOTE> AI vs AI shouldn't be a huge stretch of code, I wouldn't imagine, but partial AI partial human control would require a decent bit of development.

<BLOCKQUOTE>quote:</font><HR>Originally posted by Sirocco: This is how I'd design rarity. I apologise in advance if I've misunderstood the plans BTS has for it, and intends to implement a similar system, but from the previous rarity post, lost today, I think theirs is a different idea. I would give each unit a base value. That would be defined on the basis of the area of combat - for example Army Group North, Centre and South - and the month. The value would be lower if the unit was common, and higher if it was rare, combined with the perceived value of the unit, of course. And some units wouldn't be available at all due to their extreme rarity. A rarity value would be defined, and it would work thus: Tiger I : base value 177, rarity value 50% The first time a player chose a Tiger I, it would cost 177 points. Then it's price would increase to 265 points. Players could still choose rare units, but couldn't choose them in larger numbers that would be unhistorical. Feel free to shoot my idea down in flames. <HR></BLOCKQUOTE> This is more or less the system they're using, except that it doesn't account for regions like that. Simply put, more rare, more points. Or pick the dynamic version, and you'll hopefully get a lucky roll of the dice.