aka_tom_w

I think that is about right especially this part: "Flak guns are cheap nasty building and light armour wreckers that are exploited in gamey hoardes by ruthless axis players." that is too true! -tom w

"Squad leader is to Combat Mission, as Strategic Command is to...___________." I'm sorry to admit I do not know the answer to this question Can anyone give me a hint? Is it an SSI game? Avalon Hill Game? World in Flames? What else is there in board games of that scope? -tom w

Hi Tom, I could not tell if that was pure sarcasm or not. Me being on a mac and all, I am definitly in the minority. BTS, is there a mac version in the works for Strategic Command? The game looks great guys!</font>

Let me guess??? There is NO Mac version in the works! :mad: !1 -tom w

Very creative! nice way to retro engineer DooDad into a snappy explanation of an acronym. -tom w

OK I posted about this very issue sometime ago also objecting to the phrase "doodad" if we go with this: "non-interactive, visual terrain enhancement graphics" JUST make it an acronym = NIV-TEGs Thats what they are now..... they are NIV-TEGs !! forget Doodads we now have NIV-TEGs (I think it sounds sort of military like don't you?) -tom w [ May 16, 2002, 03:40 PM: Message edited by: aka_tom_w ]

would that be JasonC: "JasonC Member Member # 5490 posted May 15, 2002 08:51 PM The variation from salvo to salvo is much higher with rockets than with other types of arty, and highest for the weaker 150mm rounds than for the big 210 and 300 ones. "

got it thanks the trick here is tbe be very careful transfering and copying the graphics 3 and graphics 11 files in the data folder. I installed the game fresh and then copied in all the other graphics except graphics 3 and 11 and I'm not sure I want to mess with those files at all. I have the game now modded 'mostly' the way I like it, but that graphics 3 file with the interface and text files is very finicky or flakey or unstable or problematic (whatever, pick one ) anyway thanks for the response. I hope this will help other folks with new macs -tom w

Did anyone fis this problem I'm working on a NEW iMac 800 mHz with the nvidia GeForce2 MX card right now and have the same problems is there a solution? I'm running 9.2.2 do I need a new nvidia driver? any thoughts on this one? is the issue fixed or solved? I'm trying to get in touch with Hoopenfaust to see what mod files messed him up. I have the same problem here. -tom [ May 15, 2002, 02:31 PM: Message edited by: aka_tom_w ]

where's that wheat MOD?? -tom w

my gues would be they are actually TOO busy making CMBB to be standing around promoting it OR it they are taking a wel deserved rest after its release and they don't need to promote it because we are all going to buy it AND promote the hell out of it anyway -tom w

just a bump [ May 15, 2002, 01:16 PM: Message edited by: aka_tom_w ]

Where are we at with that snow and that Wheat Mod? is it up and posted? Where sorry I'll edit this if those questions were answered -tom w

The way that I understand it (and it could be completely wrong, so take this with your preferred amount of salt), the program looks at the target at the moment of shooting and one of the things it assesses is the target's speed. I would imagine the degree of speed affects the shot, but the direction does not, since it is being considered only at the instant the gunner pulls the trigger. So a fast-moving target is a fast-moving target, no matter what direction he's going. The numbers are crunched, the program decides whether a hit or a miss has occurred, and then we see it in the movie. Of course, that's only for AP shots. Guns firing HE do not lead their targets, as others have said.</font>

I agree. I hope we can also place AFV hulks on the field in the scenario designer as well; to simulate an area that has already been fought over at least once before. I always disliked how CMBO's battlefields looked almost new when you start a new scenario.</font>

here's the motherload: http://www.battlefront.com/cgi-bin/bbs/ultimatebb.cgi?ubb=get_topic;f=1;t=024726 I think this just about covers it : I suspect the thread you are refering to is this one: http://www.battlefront.com/discuss/Forum1/HTML/013403.html The other thread that is more relevant to the original post here is this thread: http://www.battlefront.com/cgi-bin/bbs/ultimatebb.cgi?ubb=get_topic;f=16;t=017277 In this thread Steve quotes specifically about this very issue and the explanation is quite detailed! Steve's quote appears on this page: Steve's quote on hitting targets moving out of LOS (it is easier to read on that page then here the way it was cut and pasted into this thread sorry) Here is Steve's Quote from that Thread: Big Time Software Administrator Member # 42 posted March 14, 2001 03:53 PM Subvet wrote: quote: It would be nice if BTS would respond, even if it was a "yeah it's a bug, and you'll have to live with it because we aren't going to fix it." We have said this a few times before. There are inherent limitations in the game engine that we can't practically fix. it is NOT a bug, rather a design limitation. We have answered this many times before, but for some reason our repeated explanations don't seem to be understood by everybody. The problem with this thread is that people are mashing things all up, which is only confusing people more. All sorts of different visual outcomes are being attributed to DIFFERENT possible causes, when in fact it is the same thing causing all of them. It is really simple so I don't understand why some people are having such a hard time grasping this... In the real world a round leaves its gun and travels until it impacts upon SOMETHING. That SOMETHING can be the target, a building next to it, or anything that happens to be directly in the flight path. With me so far? Now, Combat Mission has two different limitations that kick in to the above. The first is that when a unit is shot at NO FLIGHT PATH IS CALCULATED. Instead, probability of a hit is calculated using a vast number of factors relevant at that particular millisecond. If the a "hit" is scored then the round is graphically shown to fly and whack the target. If the target and/or the shooter are moving, there is a graphical chance that it might be behind something at the time it is hit. If a "miss" is determined, the engine semi-randomly assigns the round an impact location (think of it as a "hit" defined above) and the shell graphically hits that location. Just like with a "hit", the impact location can be in a place that doesn't graphically make sense. However, a "miss" will check out intermediate blocking terrain because it can not be assumed that there is LOS/LOF to the miss impact location, unlike with a "hit". The other problem is that the flight path of the round is not looking for random elements that might be in its way. This means vehicles or units in general. It even includes knocked out vehicles. It does, however, take into consideration static terrain like buildings and ground (slopes). Set up your own test ranges and you will see rounds impacting on these things all the time. Basically, if the shot was determined to be a "hit", it is a "hit" regardless. Since LOS/LOF is requires when the shot is taken, there is no need to check intermediate terrain at all since by definition LOS/LOF rules out intermediate terrain blockage. At least at the second the shot is fired. Zahl appears to understand this fairly well. Here is what he had to say above: quote: The most logical explanation is that CM determines hitting and missing at the instant of firing, based on the conditions that applied at that very moment. If it was a kill, whatever the target might be able to do during the following seconds can't save it. It might drive behind a hill, behind buildings or woods, but the shell travels mercilessly through any obstacles and kills the target, because this was predetermined. This is no LOS issue. The shooter needs to have LOS at the moment of firing, but after that it is irrelevant. Correct. quote: Apparently projectile collision detection is already implemented since they can unintentionally hit buildings when you are trying to shoot something else. True for misses, since hits require LOS/LOF which by definition means no blockage. But it really is just a LOS/LOF check and where the blockage happens the round hits instead of the intended targeted area. quote: Possibly the only way to fix this would be to calculate trajectories dynamically when the shell is in flight. Correct, but only part of the solution. There would also need to be a huge amount of TacAI work to simulate compensating for leading, wind, dropage, etc. Not only does the coding for this require a lot of time, but the CPU cycles necessary to carry it out as well. Too much to ask of us or the computer at this time. quote: If I remember, this was suggested before and BTS replied that it would make a difference only in exceedingly rare cases. Like when Tank A is firing at a distant B and some third vehicle intersects the trajectory just at the most inappropriate time. This is correct. However, you can of course have situations where this is far more likely to happen than in others. For example, a dozen vehicles all mixed up on a level plane in close proximity to each other. But this is not something that comes up very often, so again the real chance of this being a factor in a game is low. It will happen, but the cure to fix the problem would kill the game. Shooting through building corners is also related to this topic. We had to put some "play" into it because we do not track the exact location of the gun barrel. So once again, graphical portrayal is not 100% exact. And again, the limitation is on CPU calculations necessary for a host of game aspects (notably the TacAI once again). Now to answer a couple of individual questions: Jeff Dunquette wrote: quote: I think modeling Real WorldTM exterior ballistics and Real WorldTM LOS could go along way toward addressing some of these game quirks. As I stated above, partially correct. However, reducing the abstraction of this one element has a cascading impact on the rest of the game. This means we would also have to be a refinement of all sorts of other game aspects in order for this to all work. Unfortunately, the coding and CPU load are too much. So to get CM that last 2% realistic we would have to drop everything and work on nothing but this issue for weeks, if not months, along with upping the minimum system requirements. Just not worth it. quote: Trajectory can be modeled with a function, so I don't get why this is such a big processor deal. Tank sims ala Steel Beasts already model Real WorldTM. Trajectory is modeled in CM, but not on the fly for every shot. I have no idea what Al did with Steel Beasts, but the two games are different enough that it is a comparison of apples and oranges. For example, I think a game like Quake III looks to have exact trajectories done on the fly, but there are reasons why that is possible for Quake and still not for CM. Each environment is asking different things of the hardware, and therefore it is not possible to just say "this has it so why doesn't that". Subvet wrote: quote: That's all fine and good, but then they post this: There is a basic rule in CM -> "Nothing can shoot through houses". Put another way, in no way shape or form may any unit, regardless of what it is, shoot through house. Never. Not even in the strangest circumstances. LOS will not be calculated through a house. So which is it? The two statements completely contradict each other. Also remember, we are talking LOS as well as LOF. It is one thing to talk about a round penetrating a wall, but it's another to talk about x-ray vision. I'm just trying to get a straight answer one way or another on this; with poor results unfortunately. You are seeing conflict between my statement and the manual only because you are not looking at the context of each seperately. I said nothing can shoot through houses in the context of the discussion about LOS/LOF in regards to moving vehicles, the limitations of when hits/misses are determined, and then how they are resolved. My statement was not meant to have anything to do with rounds going through buildings, which as Tom W pointed out is specifically mentioned in the manual. Also, "through" a house was, in the context of the initial discussion, defined as LOS/LOF being established through two or more walls of a building. So there is NO conflict between my statement and the manual. Now... the only INTERESTING thing I see in this thread is the picture posted by Tom W. A vehicle should NOT be able to do that. Judging by the location of the vehicle the proximity to the house is the reason. In other words, flush up against the side of the house. So I tried to reproduce this in the Editor. I set up a test scenario and had very, very hard time reproducing it, but did in fact manage to put a vehicle in a spot where it could look straight through a house. It is obviously some sort of "sweet spot" as I couldn't get other vehicles to do it no matter how many times I repositioned them. I am having Charles take a look into it as this should not happen. Note that this probable bug appears to be limited to the exact placement of a vehicle flush up against a house, and therefore is not relevant to the rest of this thread. I hope this clears up the questions that are (still) lingering about this LOS/LOF issue. Steve [This message has been edited by Big Time Software (edited 03-14- 2001).] and from this page: http://www.battlefront.com/cgi-bin/bbs/ultimatebb.cgi?ubb=get_topic;f=16;t=017277;p=4 Big Time Software Administrator Member # 42 posted March 16, 2001 02:44 PM Philistine wrote: quote: Rather than checking the shell in flight for intervening objects, would it be possible (easier) to have a 2nd LOS check on the target after an amount of time equal to the shell flight-time has passed? If there is no longer a LOS (target is behind cover) it is treated as a miss. Otherwise the normal hit procedure is followed. Well... I didn't mention that we thought of this about a month ago and it is on The List for possible inclusion in CM2. The reason I didn't mention it is because we aren't sure if it can be done using a reasonable amount of time and coding. I mention it now because it looks bad if we don't respond to a good idea that we (me... ) already came up with a while ago Kudos to Philistine for thinking of it though! IF we can do it, most problems will go away. But NOT all. The only way to ensure that firing results are 100% accurate is to trace the flight path of a smartly aimed shot (i.e. simulating gunnery and results to the nth degree). There is no computer in any player's posession that could hack that, not to mention the coding time it would take. So the 100% option is completely out of the question. But this second check idea might get us to 100% accurate results 98% of the time. Dunno how much it will improve things, really, but it potentially should definitely get rid of the most obvious inaccuracies currently allowed for. Overall, we still don't see this as a HUGE problem. Again, check out how many shots you disagree with over a long period of time and using a great variety of maps. It simply is not common, and therefore doesn't register as a HUGE problem. It is a significant one, though, and if we can do something somewhat painlessly we will certainly do so. The future engine rewrite will be a much better system for sure, so things will be improved at some point. I also agree with Joe Private that although Tom tries to use this tactic as often as possible, I for one don't think he is automatically getting some sort of one-sided bonus regullarly enough to make this a viable "cheating" tactic. Hunting the way Tom describes and hunting in general work the same way. Does he get an edge sometimes? Maybe, but probably no more than if he was using hunt in some other situation. And there are drawbacks to getting up close and personal to a building. For example, in my tests I found that you can only look STRAIGHT through the building, and of course only if you drive right up to it. If something were to flank the vehicle in question it would be at a disadvantage compared to if it had been a few meters back and toward the edge of the building. Just one example of why this tactic of Tom's isn't necessarily as great as it might look. Still, we are looking into how we might be able to fix this problem since it shouldn't be allowed at all. Steve [This message has been edited by Big Time Software (edited 03-16-2001).]

Thanks for the update -tom w

Good Question enquiring minds want to know..... -tom w [ May 13, 2002, 05:49 AM: Message edited by: aka_tom_w ]

See, there's this little thing called 'scenarios'... and in these 'scenarios', you can't buy your units.</font>

Good memory there Schrullenhaft! I suspect the thread you are refering to is this one: http://www.battlefront.com/discuss/Forum1/HTML/013403.html BUT that thread I started was about tanks shooting through houses and NOT moving. The other thread that is more relevant to the original post here is this thread: http://www.battlefront.com/cgi-bin/bbs/ultimatebb.cgi?ubb=get_topic;f=16;t=017277 In this thread Steve quotes specifically about this very issue and the explanation is quite detailed! Steve's quote appears on this page: Steve's quote on hitting targets moving out of LOS (it is easier to read on that page then here the way it was cut and pasted into this thread sorry) Here is Steve's Quote from that Thread: Big Time Software Administrator Member # 42 posted March 14, 2001 03:53 PM Subvet wrote: quote: It would be nice if BTS would respond, even if it was a "yeah it's a bug, and you'll have to live with it because we aren't going to fix it." We have said this a few times before. There are inherent limitations in the game engine that we can't practically fix. it is NOT a bug, rather a design limitation. We have answered this many times before, but for some reason our repeated explanations don't seem to be understood by everybody. The problem with this thread is that people are mashing things all up, which is only confusing people more. All sorts of different visual outcomes are being attributed to DIFFERENT possible causes, when in fact it is the same thing causing all of them. It is really simple so I don't understand why some people are having such a hard time grasping this... In the real world a round leaves its gun and travels until it impacts upon SOMETHING. That SOMETHING can be the target, a building next to it, or anything that happens to be directly in the flight path. With me so far? Now, Combat Mission has two different limitations that kick in to the above. The first is that when a unit is shot at NO FLIGHT PATH IS CALCULATED. Instead, probability of a hit is calculated using a vast number of factors relevant at that particular millisecond. If the a "hit" is scored then the round is graphically shown to fly and whack the target. If the target and/or the shooter are moving, there is a graphical chance that it might be behind something at the time it is hit. If a "miss" is determined, the engine semi-randomly assigns the round an impact location (think of it as a "hit" defined above) and the shell graphically hits that location. Just like with a "hit", the impact location can be in a place that doesn't graphically make sense. However, a "miss" will check out intermediate blocking terrain because it can not be assumed that there is LOS/LOF to the miss impact location, unlike with a "hit". The other problem is that the flight path of the round is not looking for random elements that might be in its way. This means vehicles or units in general. It even includes knocked out vehicles. It does, however, take into consideration static terrain like buildings and ground (slopes). Set up your own test ranges and you will see rounds impacting on these things all the time. Basically, if the shot was determined to be a "hit", it is a "hit" regardless. Since LOS/LOF is requires when the shot is taken, there is no need to check intermediate terrain at all since by definition LOS/LOF rules out intermediate terrain blockage. At least at the second the shot is fired. Zahl appears to understand this fairly well. Here is what he had to say above: quote: The most logical explanation is that CM determines hitting and missing at the instant of firing, based on the conditions that applied at that very moment. If it was a kill, whatever the target might be able to do during the following seconds can't save it. It might drive behind a hill, behind buildings or woods, but the shell travels mercilessly through any obstacles and kills the target, because this was predetermined. This is no LOS issue. The shooter needs to have LOS at the moment of firing, but after that it is irrelevant. Correct. quote: Apparently projectile collision detection is already implemented since they can unintentionally hit buildings when you are trying to shoot something else. True for misses, since hits require LOS/LOF which by definition means no blockage. But it really is just a LOS/LOF check and where the blockage happens the round hits instead of the intended targeted area. quote: Possibly the only way to fix this would be to calculate trajectories dynamically when the shell is in flight. Correct, but only part of the solution. There would also need to be a huge amount of TacAI work to simulate compensating for leading, wind, dropage, etc. Not only does the coding for this require a lot of time, but the CPU cycles necessary to carry it out as well. Too much to ask of us or the computer at this time. quote: If I remember, this was suggested before and BTS replied that it would make a difference only in exceedingly rare cases. Like when Tank A is firing at a distant B and some third vehicle intersects the trajectory just at the most inappropriate time. This is correct. However, you can of course have situations where this is far more likely to happen than in others. For example, a dozen vehicles all mixed up on a level plane in close proximity to each other. But this is not something that comes up very often, so again the real chance of this being a factor in a game is low. It will happen, but the cure to fix the problem would kill the game. Shooting through building corners is also related to this topic. We had to put some "play" into it because we do not track the exact location of the gun barrel. So once again, graphical portrayal is not 100% exact. And again, the limitation is on CPU calculations necessary for a host of game aspects (notably the TacAI once again). Now to answer a couple of individual questions: Jeff Dunquette wrote: quote: I think modeling Real WorldTM exterior ballistics and Real WorldTM LOS could go along way toward addressing some of these game quirks. As I stated above, partially correct. However, reducing the abstraction of this one element has a cascading impact on the rest of the game. This means we would also have to be a refinement of all sorts of other game aspects in order for this to all work. Unfortunately, the coding and CPU load are too much. So to get CM that last 2% realistic we would have to drop everything and work on nothing but this issue for weeks, if not months, along with upping the minimum system requirements. Just not worth it. quote: Trajectory can be modeled with a function, so I don't get why this is such a big processor deal. Tank sims ala Steel Beasts already model Real WorldTM. Trajectory is modeled in CM, but not on the fly for every shot. I have no idea what Al did with Steel Beasts, but the two games are different enough that it is a comparison of apples and oranges. For example, I think a game like Quake III looks to have exact trajectories done on the fly, but there are reasons why that is possible for Quake and still not for CM. Each environment is asking different things of the hardware, and therefore it is not possible to just say "this has it so why doesn't that". Subvet wrote: quote: That's all fine and good, but then they post this: There is a basic rule in CM -> "Nothing can shoot through houses". Put another way, in no way shape or form may any unit, regardless of what it is, shoot through house. Never. Not even in the strangest circumstances. LOS will not be calculated through a house. So which is it? The two statements completely contradict each other. Also remember, we are talking LOS as well as LOF. It is one thing to talk about a round penetrating a wall, but it's another to talk about x-ray vision. I'm just trying to get a straight answer one way or another on this; with poor results unfortunately. You are seeing conflict between my statement and the manual only because you are not looking at the context of each seperately. I said nothing can shoot through houses in the context of the discussion about LOS/LOF in regards to moving vehicles, the limitations of when hits/misses are determined, and then how they are resolved. My statement was not meant to have anything to do with rounds going through buildings, which as Tom W pointed out is specifically mentioned in the manual. Also, "through" a house was, in the context of the initial discussion, defined as LOS/LOF being established through two or more walls of a building. So there is NO conflict between my statement and the manual. Now... the only INTERESTING thing I see in this thread is the picture posted by Tom W. A vehicle should NOT be able to do that. Judging by the location of the vehicle the proximity to the house is the reason. In other words, flush up against the side of the house. So I tried to reproduce this in the Editor. I set up a test scenario and had very, very hard time reproducing it, but did in fact manage to put a vehicle in a spot where it could look straight through a house. It is obviously some sort of "sweet spot" as I couldn't get other vehicles to do it no matter how many times I repositioned them. I am having Charles take a look into it as this should not happen. Note that this probable bug appears to be limited to the exact placement of a vehicle flush up against a house, and therefore is not relevant to the rest of this thread. I hope this clears up the questions that are (still) lingering about this LOS/LOF issue. Steve [This message has been edited by Big Time Software (edited 03-14- 2001).] and from this page: http://www.battlefront.com/cgi-bin/bbs/ultimatebb.cgi?ubb=get_topic;f=16;t=017277;p=4 Big Time Software Administrator Member # 42 posted March 16, 2001 02:44 PM Philistine wrote: quote: Rather than checking the shell in flight for intervening objects, would it be possible (easier) to have a 2nd LOS check on the target after an amount of time equal to the shell flight-time has passed? If there is no longer a LOS (target is behind cover) it is treated as a miss. Otherwise the normal hit procedure is followed. Well... I didn't mention that we thought of this about a month ago and it is on The List for possible inclusion in CM2. The reason I didn't mention it is because we aren't sure if it can be done using a reasonable amount of time and coding. I mention it now because it looks bad if we don't respond to a good idea that we (me... ) already came up with a while ago Kudos to Philistine for thinking of it though! IF we can do it, most problems will go away. But NOT all. The only way to ensure that firing results are 100% accurate is to trace the flight path of a smartly aimed shot (i.e. simulating gunnery and results to the nth degree). There is no computer in any player's posession that could hack that, not to mention the coding time it would take. So the 100% option is completely out of the question. But this second check idea might get us to 100% accurate results 98% of the time. Dunno how much it will improve things, really, but it potentially should definitely get rid of the most obvious inaccuracies currently allowed for. Overall, we still don't see this as a HUGE problem. Again, check out how many shots you disagree with over a long period of time and using a great variety of maps. It simply is not common, and therefore doesn't register as a HUGE problem. It is a significant one, though, and if we can do something somewhat painlessly we will certainly do so. The future engine rewrite will be a much better system for sure, so things will be improved at some point. I also agree with Joe Private that although Tom tries to use this tactic as often as possible, I for one don't think he is automatically getting some sort of one-sided bonus regullarly enough to make this a viable "cheating" tactic. Hunting the way Tom describes and hunting in general work the same way. Does he get an edge sometimes? Maybe, but probably no more than if he was using hunt in some other situation. And there are drawbacks to getting up close and personal to a building. For example, in my tests I found that you can only look STRAIGHT through the building, and of course only if you drive right up to it. If something were to flank the vehicle in question it would be at a disadvantage compared to if it had been a few meters back and toward the edge of the building. Just one example of why this tactic of Tom's isn't necessarily as great as it might look. Still, we are looking into how we might be able to fix this problem since it shouldn't be allowed at all. Steve [This message has been edited by Big Time Software (edited 03-16-2001).] -tom w [ May 10, 2002, 11:05 PM: Message edited by: aka_tom_w ]

I don't think it's as bad as that. As is, the first player starts setup on the 2nd file transferred, under the proposed new system he would start on the 4th. That is only 1 extra cycle (each player sends 1 more file than currently). If doing it in 3 steps takes 24 hours I don't see why doing it in 5 would take 5 days. Think of it this way: you are playing a guy for the first time who you don't know. You are using VR. 10 turns into the game you see he has a Jadgtiger. What goes through your head? For me, and I'm sure a lot of people, a logical question to ask one's self would be "Is statistically more likely that he lucked out and got one 1 in 1000 games where he could afford it, or is it more likely I just ran into one of those rare people who would cheat to get it?" If I ever did luck out and get an affordable Jagdtiger, I would probably pass on it just so my opponent would not be suspicious of me. Eliminating any possibility of that suspicion is worth 2 extra files per game IMO.</font>

Dan, if I read this right, you're saying that there is no extra turn to send to prevent people from continuously restarting 'til they get the rare unit they want? I would welcome an extra turn if it would alleviate any possibility of trying to cherry pick by re-starting. It wouldn't be much of a burden on the players since the file would be a once-a-game send, and would be very small. It would eliminate any suspicion of tinkering with the game. The variable rarity system sounds very nice; I can't wait to try it out. And I do know to try to play trusted opponents, but this one extra turn would help immensly, IMO. Thanks. - Chris</font>

Wow, Thanks for the very prompt and informative reply Steve. that should make folks think twice. I am not really a fan of the whole "buy/purchase" of units in the "ever popular" ME QB so this is not a big deal for me. It seems sort of odd or interesting that if you knock out someones "rare" AFV (say that Ferdinand/Elephant Dan paid %60 extra for) that they paid extra for then as the killer of that particular AFV you have sort of hit the jackpot (in victory points) but you might not actually know it at the time, OR will you see the estimated Victory point number/value spike up dramatically after you "hit the jackpot "and nail that expensive Elephant?? Just curious? -tom w [ May 09, 2002, 08:08 PM: Message edited by: aka_tom_w ]

Has anyone given any thought to how victory points will be tallied??? Seriously, now in CMBB with both Fixed and vairable rarity, units have differing values depending on how and when you buy them. So now what happens in the game when you kill them or destroy them? in CMBO you know/knew a tank was worth a set and fixed value and knocking it out was a big deal you then earned those victory points. "OK, so you get that Tiger at only +30%, but those Halftracks you want are now +10%. So you redo the setup. Now the Tiger is +80 and the HTs are +5%. Redo. Tiger is now +40% and the HTs are -5%. See what I mean? It isn't like the Tiger is going to be +250% one time and then -5% another. The system is purposefully set up to NOT have mood swings like this. The Fixed Rarity system is used as a benchmark for change, with the range of possible changes being fixed to these hardcoded numbers. Or more basically, the people most likely to do something underhanded like this probably want a Jagdtiger. Well, hate to break it to that player... that thing ain't NEVER going to be cheap " OK so in the example above if the Tiger is worth +30% +40% or +80 does that make it worth that much MORE to my opponent when he knocks it out??? :confused: So how do victory points work in CMBB now?? (please excuse me if this has been covered somewhere else ) -tom w [ May 09, 2002, 09:28 AM: Message edited by: aka_tom_w ]

there's always a work around try this: If you want your turret of a turreted AFV facing in a specific direction, use the area target command, but when the game asks you if you want to use main weapon say NO this will fire the co-ax MG in the turret in the direction of the area target and keep your turret and your guys looking for the next big threat in the direction of your choice and all it "costs" is a few rounds of co-ax MG fire. try it in the scenario of your choice as far as I can tell this is the only reason I can think of for that question "Use Main Weapon"? Yes/No so just say NO ! and area target with the co-ax mg. -tom w [ May 08, 2002, 10:26 PM: Message edited by: aka_tom_w ]