Jump to content

Ssnake

Members
  • Posts

    25,854
  • Joined

  • Last visited

  • Days Won

    293

Everything posted by Ssnake

  1. It's difficult to isolate the discussion of an ongoing war from the reasons why the war is fought; nevertheless, let this be a call to order to maintain the communication discipline as established by the forum rules of conduct. Neither Bradley nor T-90 are invincible machines. A duel between the two will have a lot of advantages on the side of the T-90. But the nature of tactical engagements incurs an element of chance as anyone who has played a number of non-trivial scenarios in Steel Beasts will have experienced first-hand. It should also be mentioned that Steel Beasts does not invoke reaction modifiers for psychological conditions (although they most certainly will play a role whenever humans are involved), just as it doesn't involve at least one other element of this engagement, armed FOV drones. Specifically, the T-90 might have easily prevailed had it been in the company of dismounted infantry or at least one or two other combat vehicles. As it was, it found itself isolated inside an urban area, which most certainly diminishes its combat value. One might argue that these are one of the few constellations when a Bradley has a survival chance at all in a duel situation (and it still took two Bradleys and an FPV to bring the T-90 into a situation where the crew decided to bail). If the video shows one thing, it is that it's not "easy" for a Bradley to defeat a T-90 (but the chance is greater than zero).
  2. In all fairness, side hulls of Leo 2 and M1 are rather thin. They are no wonder weapons. And Russian tank designs aren't quite as bad as many people would have you think in the mid 1990s. The question is maybe not so much whether the numbers they are working with are very different, but what the model is when a perforation occurs.
  3. I'd love to add the Wisel 20mm MK; sadly, we never found the time for it. Also, doctrinally it was a bit harder to justify as long as SB Pro was a vehicle-centric ground simulation since the Wisel platform is designated as a "weapons carrier" to provide mobile fire support for light infantry (paratroopers, mostly). So, you wouldn't normally see it fighting other IFVs, but rather in the fire support role for a type of combat that Steel Beasts currently does not simulate in an optimal way. The Milan on Marder ... it's complicated. I decided that we'd postpone that development until we have a code base that's more flexible. The SB V1 ...V4 code architecture was devised when we had little idea in which direction Steel Beasts would develop, and for how long. After we made the decision to enter the military training market (2002) I had always hoped for a 25+ year future, but it was very uncertain. Now that we can be relatively certain about the market in which we're operating, we are developing a new code architecture that will ensure that this software can be developed for decades to come, giving us more flexibility and ease of code maintenance at the same time, and certain performance bonuses. Hopefully, that will then also free up the time for small side jobs such as adding a dismountable missile launcher half of the vehicles in a platoon - which currently would be a big side job.
  4. Don't know why I didn't think of this before, but I think I just had an idea.
  5. What I was trying to say, if you or any other reader of this thread has a good idea under which circumstances one of our existing movement tactics could be used for passage of line ("keep your turret opposite to your travel vector"), I'll be happy to assign the job to one of the programmers. I have thought about the subject on several occasions in the last twenty years, but haven't yet had an epiphany.
  6. At the moment of detonation, the round has come to rest (and spread itself into a pancake shape). The AAR doesn't show the muzzle velocity, but the velocity at the moment of impact (or detonation).
  7. To me the question is, can we handle this by repurposing an existing movement tactic by putting it into a different context, or would we need to define an entirely new movement tactic to exhibit this behavior. Further complicating the user interface is something I have become more and more reluctant to agree with.
  8. To answer your question, our philosophy is that graphics are what psychologists call a "hygiene factor". You don't want your product to look ugly. But it doesn't have to look world-class either. Creating AAA graphics still requires disproportional allocation of scarce resources to artwork, and artwork alone. Dollars spent on artwork development can't be spent on better AI, or whatnot. As long as you have a limited budget - eSim definitely does, though it has become much better over the past fifteen years - you must prioritize. We chose to emphasize tactical depth and fidelity of simulation outcomes in our development efforts. So we have three times as many programmers as we have artists. Usually the ratio in game development is five artists to one programmer. I disagree that better lighting effects result in better simulation fidelity. They may certainly improve immersion, they may increase the fun factor - all that is undisputed. But the decision whether a certain vehicle gets destroyed by a certain round and at a certain angle and distance does not depend on the quality of the smoke that it will emit afterwards. I would tolerate the argument with respect to our high-resolution terrain engine. It certainly looks better, but its undeniable contribution to better simulation results is what's far more important; it offers more opportunity for combatants to seek cover, hence lifts survivability of units in battle to more realistic levels. I will admit that we chose to work on the high resolution terrain for the wrong reasons - better looks. I'm grateful that it was a benign error that reaped unexpected benefits. But the new terrain engine was far more than just some shader effect or other visual sleigh of hand.
  9. That's hardly translatable outside of the flight sim sector. Flight sims are immensely more popular. Note that even then MS did abandon its flight sim for several years before coming back with their latest version.
  10. Oh great, let's develop two A.I.s to toggle between. What could possibly go wrong?
  11. Visual and simulation fidelity are orthogonal to each other. That's the takeaway.
  12. What happens after armor perforation it anyone's guess. There simply are no good data available; the best being the early 1960s Conqueror trials which have been declassified a few years ago. I think it's a safe assumption that the basic principles still apply. At the same time engineers learned a lot how to protect crews even after penetration (e.g. the introduction of spall liners, which were completely unknown at the time of the Conqueror trials - as well as insensitive munitions, flame-retardant paints and clothing, quick-reaction fire suppression systems, and probably more). In SB Pro we have a high spatial resolution as far as component location is concerned. We have some idea how resistant some components are to spall/fragmentation damage. But can anyone say with certainty that in case of an armor perforation in a certain part of the hull or turret the radio will be damaged with a 5% likelihood? 6%? 4%? 15%? 30%? At some point you'll go with whatever you find "plausible" - which is a function of one's expectations (IOW, a bias), and then you try to set up consistent rules between vehicles of a similar class or design era, and simply roll with it. In the end, our damage model serves certain purposes that are subordinate to the purpose of the simulation as a tool for crew training and education. We probably overestimate component failures at least in vehicles that have crew positions, simply because our customers want their crews to correctly diagnose their faulty systems and apply corrective measures. We may slightly underestimate the lethality of armor perforations (by how much is anyone's guess) simply because you don't learn much from a "you're dead" end screen. And overall, our software shall still give a realistic impression (not a prediction!) about combat outcomes in a given scenario where crew training is not the focus. Someone working in a classified facility explained to me once why he purchased SB Pro for his work. Yes, they have "better tools" and better data to predict the result of specific armor/ammunition interactions. These are, to use a photography analogy, a macro lens to take pictures of pieces of flowers, like pollen sticking to the legs of a bee. As awesome as these tools are, they do not give you an impression of what a garden is. SB Pro, to him, is the impressionistic painting of a garden. It's fuzzy in the details, but it gives a unique perspective of the bigger picture. And then there's constructive simulation tools that are the equivalent of an aerial picture of a garden colony or a suburb. Lots of gardens, but you can't make out the individual flowers anymore. Other armor games might not be an impressionistic painting of a garden. But maybe they still count as paintings in a different art style, if you want to take the picture analogy to an extreme. The real danger lies in mistaking image quality of a render engine as a proxy for simulation accuracy. Even people who should know better make that mistake all the time. "Beauty is truth, and Truth is beauty"
  13. That distinction line appears somewhat blurry to me. Since I don't know anything about that AW title, I can't really comment on it. But I assume that both their developers and we are working from similar, unclassified sources. I always felt compelled to demonstrate to the public our methodology (at least up to the limit where it might start hurting our business). That way, people can make up their minds whether they find our assumptions reasonable or not - unlike completely closed source software where the developers basically demand blind trust. You can make a game focus on entertainment, and still do a decent job with the underlying models and parameters. Our focus is on crew procedures, tactical education, and of course we'd like to take pride in good correlation between our simulation results and reality when it comes to damage mode, AI behavior, etc. At the end of the day, claiming to be "the most realistic" combat simulation (without further qualifications) is first and foremost clamoring from the marketing department. Being a mouse warrior has little in common with actual combat, certain aspect can't be adequately modeled. Some epistemiological humility would become, well, the entire internet, I guess.
  14. Generally, we don't comment on other products (mostly because I don't have the time to test them extensively, partly because we know very well what we want to do, so we don't have to imitate others, partly because it's just bad style). We let the documentation of our work and the simulation results speak for itself. A lot of people choose to believe whatever causes the least cognitive dissonance to them. We try to eliminate biases from our estimations as much as we're aware of them. But of course, estimates remain estimates, and nobody should use our figures as an authoritative source. Knowledge is classified. Those who know can't talk, those who talk might occasionally know a thing or two, but with overwhelming likelihood they don't possess the full picture. And then there's that class of particular idiots that publish classified material just to assure their Alpha Nerd status. I never envied that position.
  15. There'll be a patch/minor update later this year, maybe late spring. There'll be at least one major V4 upgrade, probably 2025-ish.
  16. MAYBE they should open fire the moment that, in the video, the M1 turns around first the hull, then also the turret. Zapping a few into the buste rack would take away most of the ammo, and I suppose shooting the rear would also immobilize the M1. So, in that sense I agree that there's something fishy. We had a bug where AI units would always use the frontal armor values of a target for their shoot/no shoot decisions. But that was supposedly fixed a few years ago. I suppose we'll look into the matter.
  17. Those crazy ideas are version 5 concepts. 😉
  18. I think we disabled towing burning messes because it's a. hazardous, and b. useless; if it's burns, it's a write-off, and it might even explode or emit hazardous substances. So, I guess we simply didn't want to promote this particular practice for being reckless and pointless (unlike going to war for minimum wage, which is also kinda reckless and considered pointless by some, but then again, sometimes it's necessary). But you need to be able to tow unmanned vehicles either as a recovery activity for them to be repaired, or to clear them being an obstacle for others. Other than obstacle removal, it won't have any practical effects. But you might still make it a goal for one player to collect all immobilized or otherwise damaged vehicles in some designated region.
  19. We'll look into the matter. Beyond that, I promise nothing.
  20. Not sure if that's possible, since Alt, Shift, and Ctrl are function modifiers in the Map Editor.
  21. There's a good number of TrackIR related threads here in the support forum. Please try the search function in the top right corner.
  22. F8 toggles between the bird's eye view and the regular external observer's position, if the bird's eye view has been enabled by the mission designer (in other words, not every scenario has this).
  23. There can be reasons other than "embargo", like temporary maintenance. If in doubt, please send an email to Shipping (@eSim) with date and time of your attempt to visit the store, so we can check server logs.
×
×
  • Create New...