88 thru motor- not immobilized!

[Pelican Pal]

Just to clarify, if they meant to insert a 99% chance for damage to the engine but by mistake wrote 9.9%, it is a bug, but if they deliberately inserted 9.9% (for whatever reason), it is a "design decision"?

This is a gaming forum, not a computer programming forum, and I for one am OK with people calling flawed design decisions "bugs" even if it might not be completely accurate--especially because unless someone looks at the code, it might not be obvious if something is a "bug" or a "design decision".

Yea, that is more or less correct. Bug is kind of a fuzzy word without a really well defined meaning in colloquial conversation.

IMO the central difference is that a design decision is deliberately chosen by whoever wrote the code while a bug is unintended. Personally I don't care what people call things and harping on about how it is a "design decision" and not a bug doesn't really get us anywhere.

[herr_oberst]

So BF has abstracted the interior damage models into a probability table. Fine.

If that's not your cup of tea, then ask for and lobby for an internal 3d representation of the major component systems of each AFV in the game, the weights, and metal composition of each so the damage engine can accurately calculate the effect and energy loss as the round strikes/penetrates/through-and-throughs each component on its way through. You did want accuracy didn't you?

It's a slippery design slope, and where do you say enough is enough in light of all the other things that would be / could be / should be added to the game engine.

If the transmission has a rounded structure, and it was a glancing impact, then you should do the calculations on the diverted round after it potentially ricochets off the housing.

The WeGo players can afford the couple of extra seconds in resolving a turn, but what about the realtime players?

Hmm, perhaps that could be abstracted to just cubes representing vital systems inside the AFV models -- a compromise of sorts, but the amount of research and data to be collected would still be non-trivial for a relatively marginal return on the investment.

The game and game engine has been getting continuous improvements, which is preferable to postponed perfection. I'd rather be playing RT as it is rather than waiting for just one more feature.

Perhaps when the game engine matures to take advantage of as many cores as the processor has available they could look at spawning threads to do all those detailed calculations. But I suspect that there are other "bigger fish" that BF would like to fry with the resources that would have to be allocated to a damage engine of that level of detail.

In the interest of transparency, I work in the software industry, and based on my 20+ years of experience, BF has the right processes in place. Pick your target, build, test, release, refine.

[womble]

It's a pretty trivial programming problem to add the mechanics of a simple, first iteration internal layout diagram and apply the retained energy and trajectory of a penetrating round to that diagram. It wouldn't have to consider deflections and differences in impacted material to be an improvement on an arbitrary set of damage tables that only take the impacted plate into account for what might get damaged. It's not even computationally intense; there are boardgames out there which had similar approaches that were hand-crunched and still remained playable, and it's not like the engine has to handle more than a handful of such penetrations in any given second.

It's rather more work to come up with vehicle-specific layouts, though it might be tolerable to have only a few generic templates for common ways of building.

Bug or design issue matters because, in BFC's world, bug means it gets fixed for free in a patch. Labelling it as such with no evidence that it is just means you're yammering in the dark.

[JonS]

Bug or design [decision] matters because ...

... if it's a design decision then you're whistling in the wind, regardless of how much you disagree.

Might I also point out that this thread, at 28 posts and counting, it based on n=1, and the veracity of even that 1 is questionable.

[poesel]

Until now I wasn't aware that internal damage is abstracted and I didn't even notice (which says something about the importance ).

But I assumed it would be simulated because it is something that was in DropTeam. DT used spheres to represent the various internal devices.

Maybe BFC could clarify if and why they chose abstraction over simulation for this?

[Thomm]

This T-34 has been penetrated all the way through the hull by an 88, and it is still running and mobile several minutes later. Check the location of the entry and exit hit decals- there's no way the shell could have missed the motor (and transmission).

Since this thread is going nowhere, I filed a bug report.

Please keep the save games; depending on whether it is working as designed or not, they may be needed later.

Thanks for reporting,

Thomm

[Bob Boberson]

Doodes,

I'm like so not sure that proper respect is being paid to the quality of WWII tank engines. Like dig this: one time I was like, hanging in Russia, and like we were in this totally Russian car ripping along through and over all manner of pothole small and large. It was this experience that so like taught me why they are called potholes; as we were like smashing around, man, inside this tin can with doors, I could feel a total bummer of reality imposing itself into my previously cool state of mind. It was like bringing me down, Doodes. It was as though my life support system, which was of Jamaican origin, was being forced out of my system and into the holes in the road. You get my drift, I'm sure.

Anyway, we're flying down the road like a bunch of Mexican jumping beans in a can being shaken by one of those paint can mixing vibrating machines and this Russian guy sitting next to me like turns to me and asks if American-made cars could withstand Russian roads. I laughed and said of course. And I knew I was lying.

Turns out this fellow was a WWII tank engine designer. We ended up, after some Cheech and Chong sized doobies going over some of the design features of these engines. Soviet engine engineers, sometimes referred to as Doodes, knew that people were like so going to be pushing high-velocity metal and explosives through their engines, much like their latter-day auto designers knew that Russian roads are a bit spotty on flat parts.

The most important part of a Soviet tank engine is that they employ pseudo pistons. This isn't to imply that their pistons aren't real, my main Doodes, but it does mean that a piston is not always a piston. If a piston receives severe damage (or rings, cylinder wall, etc.) it has the ability to re-purpose itself and either seal off its own cylinder/head area so that dangerous leakage does not occur. This includes being able to re-route water and oil flow paths as needed.

In early testing, as gasoline version of these technologies was hit with a 150 cm round. Nothing was left but a distributer cap, and though the engine did cough a bit, it continued to run almost as well as new, providing no less than 87% of the original torque to the drives shafts as when new. Bit of a disappointment there, as the spec called for 88%, but like who's counting?

Late in the war all of these feats of engineering, physics, and even some flat out tomfoolery were rendered unnecessary with the development of the Soviet Tank Engine Multiphasic Nowyouseeitnowyoudon't technology. This tech allowed the engine to be 3% out of phase with reality. You can't shoot what ain't there, Doodes. This was made possible by the Multiphasic Reality Couplers which connect the out-of-phase engine with the in-phase tank. Fuel lines, radiator pipes, oil cooler lines, engine mounts, all Multiphasically joined to reality via the 2 dimensional couplers. Hit a coupler and you can so like totally destroy the engine, fer sher. As you know, it's just stupid to think that someone could make a gun round that can shoot 2 dimensional objects, so the engines were now completely safe.

Later improvements included bringing in fuel from transdimensional fuel tanks located in underground bunkers, so Soviet tanks had unlimited range at that point. The same technology was applied to food delivery, waste removal, ammo delivery and brass return/recycling, oil and water delivery/changing, etc.

These tanks could stay out longer than a modern nuclear sub, and cost a heck of a lot less.

So, Doode, I can see why the tank didn't stop.

- Bob

[BigDog944]

Classic post!

[db_zero]

I don't have a dog in this fight. I can live with what we currently have.

If BF didn't implement hit decals this thread probably wouldn't exist.

Maybe the solution is if a tank gets hit from the front then no exit hit decal. Then there wouldn't be the issue of whether the tanks should continue to run or not.

[A co]

Thomm, I will keep the save games.

[Andrew H.]

I absolutely agree, that's why I am surprised that the engine or transmission got away with it - looking at the in/out holes, there's no doubt it would have struck one of those.

This is where the specificity of the "decal" model runs into the abstraction of the damage model.

Specifically, if you look at the picture of the engine, maybe only 10% of the space is taken up by the engine (mostly near the top, but also near the rear) of the engine compartment. So let's say that there is a 5% chance that a large caliber shell goes clean through the engine compartment without immobilizing the vehicle.

BFC sees engine hit, rolls the dice, and gets a "no damage" result. This is fine, completely realistic, and as it should be.

The problem is that the decals show a specific entry and exit point, while the abstraction just relies on the general chances of damage/no damage. So even a statistically correct result will look wrong if the decal shows a hit in a location where there would clearly be damage. (And of course the result would look correct if the decals showed a hit near the very top of the engine compartment, which is probably what the statistical model reflects).

So I don't think that this result shows a bug. It's just a case where there are still some abstractions, and certain graphical representations can't be taken literally.

AFAICT, the decal is accurate for showing precisely which part of the armor was penetrated, and is accurate for showing which compartment of the tank was hit, but it does not accurately model the placement of equipment inside the tank; that is abstracted out to the level of the compartment.

[Amizaur]

Just a case of "We'd really like to have it too." I suspect. The game pushes processors pretty hard for numbers of calculations. The different sets of detail that are intersecting but not producing a meaningless output are all there by design and the level of complexity is running up against the number of calculations. Combinations and permutations get big, fast.

Calculations of that kind - tracking the trajectory of the shell inside a tank and determining what module has been hit - are not especially CPU-consuming, and what is much more important - they are not calculated 50 times per second in every game frame, but are triggered rarely - only when some AP shell penetrates some armored vehicle. Only then a calculation taking 0.01s is needed.

The main problem here is not CPU power, but the fact that new collision-handling code would have to be written and tested, and a database of internal parts (engine, ammo, crewmembers, gearbox, fuel tanks) would have to be created, each one having several parameters (position in tank, size, shape, ect). For each tank. It's lot of work.

The current code is quite universal - it can handle any tank - when adding new one, you only put there a number of crewmembers, list of modules that can be damaged, maybe a coefficient or two (for tank size or something like that) and that's all.

With a shell tracking, adding new tanks would require more work - creating a database of positions of all internal modules.

[poesel]

My guess is that now that decals are in and they have to calculate and display entry and maybe exit point the next step may be a better internal damage simulation.

As Amizaur said it's not much to compute and it has to be done rather seldom. Again I guess creating a simple internal model of the tank (with boxes or spheres) wouldn't be too much work.

BFC may be crazy enough to do it.

[costard]

Calculations of that kind - tracking the trajectory of the shell inside a tank and determining what module has been hit - are not especially CPU-consuming, and what is much more important - they are not calculated 50 times per second in every game frame, but are triggered rarely - only when some AP shell penetrates some armored vehicle. Only then a calculation taking 0.01s is needed.

The main problem here is not CPU power, but the fact that new collision-handling code would have to be written and tested, and a database of internal parts (engine, ammo, crewmembers, gearbox, fuel tanks) would have to be created, each one having several parameters (position in tank, size, shape, ect). For each tank. It's lot of work.

The current code is quite universal - it can handle any tank - when adding new one, you only put there a number of crewmembers, list of modules that can be damaged, maybe a coefficient or two (for tank size or something like that) and that's all.

With a shell tracking, adding new tanks would require more work - creating a database of positions of all internal modules.

Amizaur, thanks - a drive by post where I proclaimed my ignorance of the problem. My understanding of the way the numbers work was working from a probability tree - the program doesn't need to do all the extra calculations, it just needs to recognise when the extra calculations are to be done. I get that he calculations themselves are a fairly trivial workload for the CPU, but I'm saying (not necessarily correctly) that this process comes at the end of a number of others, needs to be 'woven' into the code so as to have a relative reference point from which to work and needs to provide a meaningful result in terms of the game: I'd expect that the 0.01s calculation to have some sort of friction effect through the rest of the code. As herr oberst pointed out, the time constraint that comes with adding another layer of detail and having it intersect with all the others isn't trivial: we're asking the game to keep track of yet another type of granularity in the object map, effectively create another set of LOS calculations for penetrations into the engine space of another unit. The number of non-trivial (meaningful in game terms) paths for an 88mm shell travelling through a 1.5x1.5x1.0m space, relative to an internal complexity inside that space is not small - if you don't want a probability table used (very fast), you have to define them all to see which you can safely ignore (very slow).The game keeps track of bodies, sure, for projectile calculations, but it doesn't tell me if the liver or the lung or the bowel is perforated, it just gives me an end state - dead or wounded (and degree thereof, crikey).

If the shell is coming in from the rear quarter, is it a trivial exercise for the game to give us the ricochet of the shell off the engine block into the crew compartment? How about a powered turret that now has to work on a hand crank? Battlefront, fix or do sumfink. Time constraints still apply, but they're BF's time constraints: I opine that they owe themselves time to do other stuff with their lives.

[LukeFF]

I'm seeing some good arguments here why the CM series could do with some multicore enhancements.

[Amizaur]

costard - there is no additional layer of detail the game has to "track" to be able do track&damage calculations. The knowledge of the "tank internal organs" is needed ONLY when a vehicle is penetrated, which happens very rarely in "game" terms - once in thousands of frames on average. Only then game has to calculate the shell track and check against some table of boxes and spheres - if the shell has hit any of them. If there is no penetration, this is not needed, not called and does not slow down the game at all. It may only increase game RAM memory usage by some additional, small amount (those rarely-used tables has to be kept somwhere).

So adding this "additional layer" does not slow the game at all in all game frames where no penetrations happened on the battlefield. It's not a philosophy, it's coding. Knowing how code works helps to understand which things are CPU-heavy and slow down the game, and which are not.

[Placebo]

As some of the crew are modelled in their tanks, is the chance of them being killed or wounded modelled or also an abstracted percentage chance?

[c3k]

It must be modeled, not abstracted. When the left side of the tank is penetrated, I notice the guys on the left side being wounded/killed far more often than other crewmembers. Similarly for other tank locations.

The modeling may be simplistic. But it is modeled.

[Lt Belenko]

No matter what caliber the weapon i would assume an engine would stop most rounds. So based on the fact it went clean thru I'd figure it missed the engine some how.

[Amizaur]

It's not modelled. When a shell hits the front hull of the T-34, it's random if the driver or the machinegunner are killed. It doesn't depend on where the shell hit. It could hit in MG and kill the driver, it could hit the driver's hatch and kill the MG-er.

[c3k]

Tested, stated by BFC, or anecdotal?

[Amizaur]

Tested. I tested penetration effects and observed the above watching about 200 penetrations. The crewmen that is to be killed is randomly chosed, mainly from occupants of the hit part (hull or turret). I'll try to show some statistics later, but for now - this is what i just observed, without through analysis.

P.S. It is random for hull, for sure. I didn't bother to determine if it's the same for turret, I'm assuming it is.