Scipio Posted May 10, 2002 Share Posted May 10, 2002 Just something I noticed today - a Sherman fires on a moving tank and hits it - altought the target has moved out of LOS in the time between the shot and the hit. I assume this is a known bug and will be corrected in CM:BB? Link to comment Share on other sites More sharing options...
Schrullenhaft Posted May 10, 2002 Share Posted May 10, 2002 Known bug. Being corrected in CMBB... I'm not sure. I believe that there will be some steps to minimize this occurance, but I don't think that it can be completely corrected with the current engine. From what little I can recall of previous conversations about it the engine determines LOS at the beginning of the turn (assuming that the shot is to take place within seconds of the turn starting) for shots that are going to take place within a few seconds into the turn. If the object wasn't moving at the time of the calculations, then I guess it is considered to remain in LOS. If an object starts to move out of LOS after the shot calcs are done (during the shot) then it may still get hit, though it may be out of LOS when it does get hit. I'd guess this issue has something to do with the 'granularity' of the engine's calculations for each second of the turn. It would have to plot the 'potential' movement of each unit and then recalc LOS for each second of the turn - something I assume isn't actually happening with the current engine. I'm only guessing at what is going on and what limitations may be in place to prevent a full fix of this issue (though Charles may come up with something anyway). I remember that aka_tom_w started a lengthy thread in the past about this subject (last summer ?). So you may want to search the 2001 archive for some more definitive answers. Link to comment Share on other sites More sharing options...
aka_tom_w Posted May 11, 2002 Share Posted May 11, 2002 Originally posted by Schrullenhaft: Known bug. Being corrected in CMBB... I'm not sure. I believe that there will be some steps to minimize this occurance, but I don't think that it can be completely corrected with the current engine. From what little I can recall of previous conversations about it the engine determines LOS at the beginning of the turn (assuming that the shot is to take place within seconds of the turn starting) for shots that are going to take place within a few seconds into the turn. If the object wasn't moving at the time of the calculations, then I guess it is considered to remain in LOS. If an object starts to move out of LOS after the shot calcs are done (during the shot) then it may still get hit, though it may be out of LOS when it does get hit. I'd guess this issue has something to do with the 'granularity' of the engine's calculations for each second of the turn. It would have to plot the 'potential' movement of each unit and then recalc LOS for each second of the turn - something I assume isn't actually happening with the current engine. I'm only guessing at what is going on and what limitations may be in place to prevent a full fix of this issue (though Charles may come up with something anyway). I remember that aka_tom_w started a lengthy thread in the past about this subject (last summer ?). So you may want to search the 2001 archive for some more definitive answers.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 ] Link to comment Share on other sites More sharing options...
Scipio Posted May 11, 2002 Author Share Posted May 11, 2002 Aha, thanks. I must confess, I have noticed this for the first time within 19 month, so I can agree that it is a rare incident. There are surely more important issues - like the ability to hit on the move, what is - for a WWII tank - extremly difficult in reality, with or without gyros. Modern battle tanks can do this, but they have very complicated and extremly expensive fire guiding systems. The price of the fire guiding techiques makes up to 40% of the price for the complete tank LeopardIIA6, for example! Link to comment Share on other sites More sharing options...
Recommended Posts