Dschugaschwili

If you don't find a reasonable use for them, you can also use a couple of them as a makeshift roadblock. Place a couple of them across a road. Any vehicle that drives through them will slow down considerably. And you do have some AT weapons ranged in at the spot, right? Dschugaschwili

I think that tanks using "move" will fire on the move, but continue movement. Also, a rotate at the start of a movement order should behave like the order itself, so your tank shoud stop to engage if you are using "hunt". Can't test it now though, but I'm quite convinced of it. As for the rest of this discussion: I don't think this is a bug. Apparently no tank in CMBB will fire while rotating its hull. As BadgerDog told us from his experience with WWII era tanks, this is realistic because laying the gun on the target is almost impossible while the tank is rotating. So the question is: How do you get your tanks to stop rotating if they spot a target so they can engage? It seems that there are two situations in which CMBB tanks do this automatically: 1. The tank is "hunt"ing. 2. The tank is "rotate"ing (the command, not while trying to follow another movement order) I always thought it was common sense that you should not be using "move" or "fast" if you want to hit anything anyway. Use "hunt" (or "move to contact") instead whenever you expect enemy contact you want to react to. As for "reverse", you will usually want to use it to get out of trouble, and you don't want your tank to stop to engage in these situations. So I can't really see why you wanted to use "reverse" here. Another thing: It is a quite well known CMBB fact that tanks rotate faster while moving. So if you insist on reversing away from an enemy on your flank, you should use two "reverse" orders: the first one a few meters backwards so no rotation is required, the second one in the direction you want to reverse. That way your tank will drive a curve, thus getting the rotation done faster. Dschugaschwili [ February 28, 2003, 05:07 AM: Message edited by: Dschugaschwili ]

Not quite. As Herr Flick already said, a cover arc does not rotate with the vehicle. So if you set a cover arc facing north, it will always face north, no matter how your tank rotates. Dschugaschwili

I'd like to know how you managed to get them to save your day. Commo ranges are too short, meaning your mortars have to be virtually on the front line. Better to just buy a 75mm Infantry gun, than a 81mm mortar. You get over twice the blast effect of an 81mm, for a few more points, and in quickbattles, an Infantry gun has the same indirect fire capability that a mortar has - none. </font>

So you cut out half of the fun from this game? Compared to Lords of the Realm 1, not being able to design your own castles was a great disappointment. I guess the AI couldn't handle it. Dschugaschwili

*cough* HELLCAT *cough* </font>

Ha! I contributed something to the patch. On the other hand, it seems that rarity values for infantry units will still not be shown on the purchasing screen. Was probably too difficult to code properly. Dschugaschwili

Steve: What you wrote pretty much confirms what I already thought. I don't want to say that you should bother Charles again with this topic. And as a programmer I know what can happen when I change something without thinking about the consequences. You used the pre-battle casualties as an example. I think there's an even better one. I still remember very well what happened during the development of the TCP/IP multiplayer mode for CMBO. I don't know exactly how much development time went down the drain when it turned out that different processors were rounding floating point numbers in different ways, so only sending the orders and calculating the movies on both machines locally led to different results, ruining the game. But I remember quite well that it delayed the CMBO 1.1 patch significantly. There are probably a couple of other things that ordinary forum members never were told of. So, I can live with the fact that a faster PBEM system will not be in CMBB. If you promise to include it during the engine rewrite, that's perfectly fine with me. And thanks again for explaining how the game system works. Schoerner: The difference is that you knew exactly what you were looking for when you wrote the anti-censorship loader: basically a couple of strings. But you don't know where you would have to look to find accuracy data for certain guns or something else you need to change to make a cheating executable, so changing the gameplay is much more difficult than changing a few (mostly cosmetic) screen outputs. At any rate, the PBEM system has nothing to do with the difficulty of hacking the executable anyway. Dschugaschwili [ February 08, 2003, 06:39 AM: Message edited by: Dschugaschwili ]

Hehe, good thing I checked back before posting, otherwise I would have missed your editing and posted your correction myself. First, thanks for the explanation how the game works. The system you describe here sounds good and entirely plausible. I know that I'm probably beating a dead horse here, but I guess that somebody else will eventually notice this too, so I can just as well say it myself (and please don't flame me for that): The information you provided here about the game system contains nothing that would make implementing the system I described above impossible, because what I suggested is essentially sending two PBEM files together every second time. So we would effectively still have the same three files per turn, but since two of them are always sent together, we would only need two e-mails. The only necessary change would occur in step 3, because with the faster system the same machine would always be the host (which is actually more similar to how TCP/IP is handled than the current PBEM system). So there must be something else that makes implementing the faster system extremely difficult. Probably something so technical that only Charles knows about it. I do not want to call you a liar, nor even just say that you're wrong, it's just that what you wrote is not sufficient to justify why it can't be done in the proposed simple way. Sorry. Dschugaschwili

I know full well that this topic was already discussed to death. I remember this discussion quite clearly because I started the thread back then. But how should somebody who is not a forum member this long know about it? Judging by his member number, Fuerte could have been around back then. The problem is, the thread with the long discussion of this topic is nowhere to be found. I have searched every Combat Mission related forum for it, it's just not there. So how should a newcomer to this forum know about lengthy discussions? What I did here is repost a summary of parts of this thread from memory. While I was never explicitly mentioned by Steve in his posts in this thread, I'm wondering if this post is also directed at me. If so, let me clarify a few things: 1. I never claimed to be the first one who had this idea. 2. I never said that you guys at BFC don't have a clue what you're talking about. 3. I do not think that Charles is an idiot. Quite the contrary, in fact. If I have accidently created the impression that I was implying one or more of the above, I would like to apologize. Dschugaschwili

Just out of curiosity, why this veto ? Would a computer favour its owner's side or what ? </font>

That's what I mean with quoting out of context. The sentence immediately before that was "If Charles has looked at it and concluded that it is too much work I don't want to question the decision to not implement this". Would it have been better to say "From my perspective I can't see how Charles arrived at his 2-3 months figure"? Keep in mind that English is not my native language, so it's quite possible that some people will read things between the lines that I had never thought of while typing. Dschugaschwili

Agree. I would guess two weeks max. </font>

Fuerte: What you wrote here is about the same as what I wrote in the (now sadly missing) thread where I also proposed the faster PBEM system. To everyone: For those who had problems understanding Fuerte's explanation above, I'll try to explain what I would do to implement the faster but still secure system (Steve, please correct me if I make any wrong assumptions ): When the movie file for a certain turn is viewed for the first time (so the player does not give new orders after viewing), no calculations are made when the player presses "done". So the file must already contain all the information about what happened during this turn. This means that the state of the battlefield at the end of the current turn is already known to the program. This is the same state as at the beginning of the next turn. Let's suppose that as soon as the player hits "done", the second movie file is written to disk. (That's basically what happens now). As stated above, the game already knows the state of the battlefield at the beginning of the next turn although the other player has not yet seen the movie. If this state is known, the game could allow the player to give new orders. These would currently be stored in an "orders only" file (the small one of the three). This file could also be written to disk. Now we have two files. We could append the second one to the first one (perhaps seperated by something that let's the game see where the first file ends; a modified "PBEM data begins/ends here" line would probably do) and send the resulting file. Now, switch the view to the other player. To view the current turn, the game would only need to load the first part of the file. After hitting "done", the next turn's orders phase follows (note: this is exactly what is happening now). When the orders are given and "GO" is pressed, the game would now write a PBEM file containing only the orders. Instead of doing this, the game could now load the second part of the file (containing the other player's orders) and immediately calculate the movie file. So, where are potential problems with this? I can think of two: 1. Obviously the order in which the different file types are created and used is different. This will require some recoding. Depending on how the current engine is implemented, this can be very little or a substantial amount of work. 2. Some of the information about the troops of the player who does not currently view the movie file first may be encrypted in a way to only be accessable with the right password. On the other hand, the game engine must have all information about both players' troops to be able to do the calculations, so I doubt that this is the case. And now, before someone starts bashing me for this, note that I'm only about a month away from my master of computer science, so don't tell me I have no idea about programming. Dschugaschwili PS: And don't get me wrong, I don't want to rant at BFC. If Charles has looked at it and concluded that it is too much work I don't want to question the decision to not implement this. Although I must admit that 2-3 months seems a little high to me. :confused: [ February 06, 2003, 04:32 AM: Message edited by: Dschugaschwili ]

One important thing to note is the fact that units using movement orders that include running (run, advance, assault) slow down when they get to tired state. Over dry open ground even the assaulting squads will keep up with the moving ones until they are tired. Only from this point on will they fall back. Dschugaschwili

Don't get me wrong, I'm strongly in favor of keeping and improving the PBEM system. That's why I suggested a two e-mails per turn system when I realized it could be done without sacrificing security. The only possible security risk associated with the new system would be that all turns are calculated on the same machine. On the other hand, if somebody can hack the calculation or do something else to alter the outcome of the calculation, being able to do so every second turn (read: under the current system) should be more than enough to secure a win... Dschugaschwili

Yes, there were threads on this topic, but the one I was looking for is nowhere to be found. And I know what I'm looking for because I started it back in the CMBO days. I effectively proposed the same two e-mails per turn system as Fuerte and explained why this can be implemented securely and without increasing the amount of data that has to be sent. I remember that Steve said that while this system could indeed work, it would require changing the PBEM file format (no surprise here) and changing a working system for CMBB was not particularly high on the priority list (not really a big surprise either). Since then high bandwidth internet connections have become even more common, so I doubt that we will see any more improvements in the PBEM part of CM. Dschugaschwili

The only times I have noticed this "firing into the ground" behaviour were situations where I was trying to fire at infantry units that showed 0% exposure without being behind a wall. Can somebody who also has encountered this problem confirm or deny this? Dschugaschwili

I never claimed that the front turret was a perfect cylinder, but from looking at the photos/drawings on page 3 I don't think that it would perform much better than a cylinder, and certainly not better than a sphere. Probably somewhere in between. The calculations I did were done mostly to invalidate JasonC's first proposed impact angle distribution model. Dschugaschwili

1. Vehicles purchased independantly are always in C&C. Subordinate vehicles in a platoon are not always in C&C. Command ranges are a couple hundred meters regardless of LOS for radio equiped vehicles. For radioless vehicles HQ and subordinate vehicle must be close together, have LOS, and none of them may be buttoned. 2. Don't know right now. I have never got any of those. 3. This was already in CMBO. One star means damaged (damage > 50%), two stars means heavily damaged (damage > 75%). 4. The rarity modifiers are added to the base price of the unit. This is already reflected in the prices you see on the purchasing screen. Dschugaschwili

- Per-weapon ammo tracking for infantry squads. - Add the ability to stop projectiles in flight to get rid of the over-time at the end of turns. - Collision detection for all projectiles, even those that are supposed to hit. (To make killing moving tanks through a hill impossible) Just be careful when lining up your tanks behind each other. - Better modeling of night visibility. - And what about a chance for gun shells to hit a tree and explode when passing through scattered trees/woods/tall pines, creating a treeburst. That should make you think twice about firing through some scattered trees occupied by your own troops with your Hummel. Dschugaschwili

JasonC: How did you measure the turret area "pixel by pixel"? I imagine that it would be very difficult to get the impact angle by looking at a picture. I would prefer to model the surface of the turret front using some mathematical equation (like I did for the cylinder and sphere examples) and calculate the probabilities for hits at different angles from the equation. And where did you get the mean angle of 30° for CM from? Some more tests would be needed, but it looks like CM may use the cylinder model internally. At least the test results so far don't show results that are statistically significantly different. Dschugaschwili

Finally a post that sounds useful. A few mathematical calculations: When shooting at a cylinder (2D-curving), assuming that the hits are equally distributed (so hits in the center are not more likely than hits farther out), the probabilities to hit the surface at different angles are: Ang. Prob. Diff. 10°: 17.4% 17.4% 20°: 34.2% 16.8% 30°: 50.0% 15.8% 40°: 64.3% 14.3% 50°: 76.6% 12.3% 60°: 86.6% 10.0% 70°: 94.0% 7.4% 80°: 98.5% 4.5% 90°: 100.% 1.5% The Prob. column shows the probability of hitting at an angle of less than Ang. The Diff. column shows the probability of hitting at an angle between the Ang-10° and Ang. We see that half of the hits hit at an angle of 30° or less. The same calculations done for a sphere (3d-curving) instead of a cylinder yield the following results: Ang. Prob. Diff. 10°: 3.02% 3.0% 20°: 11.7% 8.7% 30°: 25.0% 13.3% 40°: 41.3% 16.3% 50°: 58.7% 17.4% 60°: 75.0% 16.3% 70°: 88.3% 13.3% 80°: 97.0% 8.7% 90°: 100.% 3.0% Here only a quarter of the hits hit at less than 30°. But that's still much more than JasonC's proposed round armor model on page 2 would allow. Obviously he hasn't thought his model through properly. Dschugaschwili [edited for spelling mistakes] [ February 03, 2003, 05:53 AM: Message edited by: Dschugaschwili ]

I'm quite sure that this is already in CM since CMBO. The problem is that most ricochets go upwards, so they only come down a couple of kilometers behind the map where they hit nothing. Dschugaschwili

Not always. I have had gun damaged tanks fire their coaxial MG. I could even target them manually. There seem to be different kinds of gun damages. Some of them leave the coax intact, some take it out too. Dschugaschwili