Jump to content

Ssnake

Members
  • Content Count

    20,438
  • Joined

  • Last visited

Everything posted by Ssnake

  1. Can someone please help this gentleman? Thread at SimHQ.
  2. Correct, version 4.0 and 4.1 are still pretty close to each other as far as the render engine are concerned. But even at eSim Games, the days of DirectX 9 are numbered.
  3. The program installation itself will not grow substantially. Sure, it's bigger - new artwork comes with new textures, so there's a bit there. Version 2.656: 0.99 GByte Version 3.027: 2.37 GByte Version 4.023: 2.45 GByte Current 4.1 beta: 2.77 GByte This can be approximately doubled as far as the disk space requirement after installation is concerned. Map data, on the other hand, will come separately, and can be installed in any other directory (including different disk drives). This is one of the major deviations from traditional file path conventions (which was largely dictated by Microsoft recommendations for Windows application in multi-user environments; we try to stick to the rules). Instead, Steel Beasts 4.1 will store the path to the map files in a registry key so that subsequent installations will still recognize the directory even after a complete reinstallation. So, if your C drive is pressed for disk space, that's the way out for you.
  4. For one of these, the answer is Yes. Others are still on the list.
  5. Make no mistake, "polishing the legacy" is pretty painful for the team as well. If we didn't have a customer base to maintain, starting from scratch would make a lot of things a lot easier. The problem is, when you start developing an entirely new product category for a market that doesn't exist yet, you can't know where you'll eventually end up, so you can't know which mistakes to avoid. In a way that's a luxury problem in that you have to be successful in the first place to face the consequences of a legacy design that isn't so easy to adapt as if you had implemented a more flexible, easier to maintain code base from the start. But what's easy to maintain is something that you usually identify only in hindsight. And if you create "the perfect software architecture" first, you may run out of money before you have a marketable product, or you might come too late. Luxury problem or not, it's still a problem, even if it beats the alternative.
  6. I don't have a percentage for you. What I can tell is that we would never release something that would invalidate maps and scenarios. Even a completely new engine would at least have to be able to import legacy scenarios and maps, and save them in the new format. You created all that content. We won't throw away what's not ours. We have, indeed, discussed whether we should better start from scratch, or make a more "gradual transition". I think we have now a better understanding of the implications of a gradual transition. But even then, from scratch is a high risk development strategy. Say, we'd need two years to create some prototype that could then begun to be tested, and then another three years to add all the content and functionality that's in SB Pro as we know it. Five years later we end with a product that may be easier to maintain, but it's representative of the state of Steel Beasts five years before, just with new bugs that are, allegedly, easier and faster to fix. Where's the benefit for the customer? Why should anyone pay for this? You already have a version that works, and our promise would be to charge full price for something that is defined as "all new, and just as good" with, probably, the sole additional benefit of higher frame rates. That doesn't make sense, even if the most devoted Steel Beasts fans might actually be willing to pay, just to support our work. Thanks for that, but we also need to convince the average user. The reality is, Steel Beasts isn't one computer game among many others that you play. If you want to master it, it's an entire hobby. Which is probably the hardest sell. And with a decision for development from scratch we'd just have doubled the price, and added five years of product stagnation. I may not be the world's greatest entrepreneur, but this doesn't sound exactly like a winning strategy to me. Maybe I'm just lacking the vision.
  7. A lot of the changes that we had to work on were really hard to do. That invoked a lot of uncertainty about projected release dates. But I am now confident that we have a near release-ready product by now. I admit that I had my doubts around end of 2017/mid 2018 whether things would work out, but the latest version that we have demonstrates much improved frame rates (that is, better than in 4.0). This required a myriad of optimizations - including a complete replacement of all vegetation artwork to allow for the instancing of trees, and ground clutter. And the biggest effect was to be seen only relatively late in the process (like, a week ago). It's one thing to know that such a change is coming, and another to experience the effect first hand. 4.1 will bring much improved AI in select demonstration cases, for both vehicles and infantry, especially when navigating obstacles such as "parked cars" on the road side, "blocked" bridges by one immobilized vehicle, dealing with water, and wadi edges, infantry formations moving in urban terrain. Again, these improvements required massive changes to much of the underlying legacy code. Which, in turn, created a few hundred bug reports that had to be identified, reported, supplemented with a test case, then solved (and be tested again and again in daily automated test procedures). Finally, 4.1 will also come with an entirely new model of high explosive and fragmentation effects. We couldn't finish that work, but we have reached an intermediary stage that will already bring a lot of pretty cool improvements. But replacing the legacy code was, again, a tough nut to crack for the same reasons as outlined in the "AI" section above. The changes in the file structure for the map files caused a massive cascade of other changes since we wanted to retain user flexibility and some degree of convenience for multiplayer sessions; like the ability to pull a missing map from a server simply by copying a unique identifier code and pasting it into a dialog in SB Pro (and then to be able to define more than one server from which to query your files ... so every community can set up their own server, if so desired, for their own set of map files). Again, all that needs to be tested. You all cannot thank the beta testers enough. They really had it rough. More than any of you, we want this to be over! So you can believe me, we will not delay the release a minute longer than absolutely necessary. We're mere humans here at eSim Games. I cannot divine the future. I understand that you as customers want to know what's ahead, and I admit that we made a serious mistake in April 2016 when I released videos of the new engine in the mistaken belief that we would be ready a few months later when the beta testers told me that we were not. In April 2019 I'm telling you that we will be ready in a few months with more confidence because I've learned to listen more closely to the beta testers, and the beta testers have learned to voice their objections more bluntly.
  8. eSim Games certainly has to thank you guys for your support. Without you, nothing would have happened. I hope that Kanium will find new players this way (and that the whole multiplayer community will benefit from that).
  9. Ssnake

    Tactical FPS

    Neither, nor. We have yet to identify a specific training case where VR would offer a unique advantage. So far, it only offers better immersion (which is no small feat), but the effort to make it work with a stable rate of 90 fps, the redesign work of the 3D models to support full 6 DOF of camera movement, is in marked contrast to the gains that it offers. So, not a priority at the moment.
  10. One-day or two-day event insurances can be had for maybe 300...400 EUR, I'd expect.
  11. It's pretty simple. If you're confident that you're going to use that bridge later, don't demolish. If you're confident that you can defend a bridge without demolishing it, you don't. If however you can't defend everywhere (usually you can't), you demolish where you have insufficient resources for defense. German cold war defense plans were aimed at denying access to infrastructure rather than its destruction. Like steel or concrete barriers that would hyraulically move out of the ground, and then lock in place. Or flooding terrain adjacent to sections of a canal (such as the one bypassing Hannover to the north which connects the Rhine with Weser and Elbe (and ultimately connects all the way to Berlin)) by "pulling a plug" rather than blowing it up. Or powerplants that would be shut down, then have identical key components removed everywhere. But of course there were also locations for demolition charges part of all major bridge constructions; the explosives would be stored no farther than maybe a kilometer away from a bridge, so you only had to get the charges, open manhole covers, insert the charges and wire them, so the bridges could be prepared for demolition by a sapper platoon in under two hours or so. This is, of course, all history. The demolition charges are no longer stored "in the wild".
  12. First line reads "Video Hardware Error". That suggests that the graphics card needs replacement (IOW, a driver update won't help).
  13. Wasn't it more of a maneuver exercise than a competition?
  14. So, the banner print came out allright? (if compared with the prize posters)
  15. Looked like a CO2 extinguisher to me, they tend to have a fair bit of a cooling effect too.
  16. I'm not familiar enough with the Challenger 2 to say if it has two LRFs; in the Leopard 2, you don't, and I'm not sure about the M1A2 SEP either. So it's at least quite conceivable that with a damaged main sight you would also lose the rangefinder even if the commander still has his independent sight. Periscopes for the commanders are not primarily intended for system redundancy but to allow tho independent observations of the battlefield with a smooth handover, or target identification (and permission to fire) by the commander. The redundancy in this context would be more of a welcome fringe benefit. But, you may just as well have found a bug.
  17. My experience was, the "toys" usually don't break, it's the mechanical parts. And of course my remarks were a bit tongue in cheek to the extent that I was also lumping in regular maintenance and minor issues. At the end of the day I suppose we can agree that tanks are maintenance intensive. If the crew isn't lazy and takes good care of its tank, it will usually be combat ready. That doesn't mean that there aren't a few parts that need replacement (such as the proverbial lightbulb on the braking lamp). But even good maintenance can't fully prevent that you might develop a leak in an idler wheel axle and suddenly you have a tank on fire:
  18. If simulation parameters are based on manufacturer claims... Let's be honest here. We try. We try to get all the relevant information to get the most reliable simulation outcome that we're capable of simulating within the constraints of the application (=real-time, decent framerate, ...) and our business model (it is, after all, commercial software development (= the least amount of effort you can get away with)). But there are always unknowns. Reliability of subsystems for example is a big issue. In the Steel Beasts world, all components work at peak efficiency until or unless they are destroyed. We wouldn't know the MTBF rate and failure distribution for even one of all the different components for even one of our 250+ vehicles. Even if we did, there would be no publicly available data for all the other components, for all the other vehicles. And even if they existed (they don't), they would probably be derived with different methodologies, so the statistical parameters wouldn't be directly comparable. What I can say is that the natural state of a tank is that it's broken. The moment a tank leaves the factory, something in it probably fails. It could be something trivial such as a blinker on the rear fender (irrelevant in combat, but in peacetime the tank may not drive on public roads, period). Or it could be a brake failure (oh, sh!t), or insufficient or too much gas pressure in the recoil dampener (another Oh, sh!t moment if you find out in the wrong moment). Does that mean we shouldn't have brakes or recoil dampeners? Of course not. But since we can't really say how likely it is that such a component breaks, there's basically two options - ignore it in the simulation (doesn't mean it can't happen in real life), or make shit up, like "how often should a player experience this malfunction in one exercise, or in ten exercises". So the training goals dictate that components fail more often than they do in real life because you don't want to experience those 500,000 operating hours MTBF in real-time to teach a student that, Yes, that component there can fail too! So, the purpose of the "simulation" plays a role as well. Realism of outcomes is nice, but sometimes you don't want realism because your time budget is limited.
  19. Once that we calculated the impulse transfer, we no longer felt it to be justifiable. That appraisal has, however, changed again, but it's still in the stage of a filed "enhancement" report in the bug tracking database. Eventually, though...
  20. I'm glad that you're so easy to please. The answer's still No.
  21. Not sure if he'd accept a laser rangefinder, thermal imager, a ballistic computer, or sight stabilization. Because "it can all fail". Yes, it can. And still I wouldn't want to miss any of these because when they work - and usually these aren't the things that will fail -, they give an enormous advantage. In combat, I don't want a level field. I want as many advantages on my side as possible.
  22. As long as the implementation there is shit, no.
×
×
  • Create New...