Ssnake

Also, it very much depends on which position you're planning to spend most of the time. I'm not a CH stick user so I'm not sure what to recommend. But you can export all hotkeys to a single HTML file as your reference about them. Granted, we use more key bindings than your joystick will have buttons. So I suppose you'd want to apply functions that you use particularly often - change of ammo (or indexing it, or commanding its change if vehicle commander - it's all the same keys), change of the field of view/zoom, possibly the WASDX driving commands, Hold fire/Fire at Will would come to my mind. Also, I found two profiles in our Downloads area, this page, if you scroll close to the bottom. The files are relatively old. They may require modification/updates.

This is a wishlist thread. No need to ridicule each other.

Actually, make that two, I just noticed.

Can someone please help this gentleman? Thread at SimHQ.

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.

...?

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.

For one of these, the answer is Yes. Others are still on the list.

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.

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.

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.

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).

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.

One-day or two-day event insurances can be had for maybe 300...400 EUR, I'd expect.

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".