Leaderboard

Just as a heads-up, we're preparing a new version to be released next week - probably on March 1st or 2nd.

Get the release notes and download links here: https://www.esimgames.com/downloads/ Many thanks to the developers and beta testers that put this together!

I've attached the release notes. Enjoy. SBProPE_4-377_RN.pdf

Absolutely. No one wishes for SBProPE to remain stagnant -- visually or aurally -- out of deference to modders. After all, modders, I think, generally aim to offer improvements where they think improvements are warranted. Indeed it seems there is agreement that certain sound improvements were warranted, as from the Release Notes it appears changes are coming that mirror what Ruki has been working on for all these many months. What I was saying, in case there was any miscommunication, was that I empathize with seeing a longterm project rendered moot before it's even shared. I think a lot of us are still interested in what Ruki is doing, so I hope it sees a release anyway -- and users can choose whether they think it enhances their experience or not. Likewise, the prospect of eSim upgrading a model for which I did a vehicle texture isn't going to discourage me from continuing to make vehicle textures I'd like to see in-game. Just hopefully the timing won't jerk the rug out from under me. 😏

Two weeks late with a reply, I know, but I overlooked it... If someone decided to go back to pre-4.377 release (4.363), then by all means do so, that is your prerogative to decide what is best for you. I personally feel without a doubt that, "warts and all" 4.377 is superior to 4.363 because of the improved features and the fixes to the bugs that were in 4.363. Of course I would say that, but that is actually what the question always comes down to: is it better than the previous version? You won't convince me otherwise. One example is the T-72B3 that a lot of people looked forward too, but turned out to have some seriously complex issues that showed itself only in Network Sessions which made it unplayable until the 4.377 update. The comparable issues we have right now are not nearly as severe, but will be addressed in short order. But it’s all subjective and only you can decide what you think is best. That said, stating that you want to go back to 4.363 will never be taken by the development team as some kind of pressure to hurry up and push out a patch because you feel it is required immediately, because on the inside we have a great deal more perspective of course. It would be like rushing a brain surgery procedure -- more harm than good would occur. You can say that 4.377 is a pile of turds to you, but that doesn't affect the urgency of a patch release because it cannot be rushed or else we receive more of the same condemnation. It's a contradiction, actually: on the one hand the accusation is that the update was rushed, but then on the other hand we are rushed to release a patch. It doesn't make any logical sense. What does influence the development process is when people stick with it, try to temporarily "play around" the issues, and keep providing clear and useful feedback that we need to improve the experience. We all get a better simulation when that happens. Just waving the hand and dismissing it, only to find out later in another patch that there is another problem with something that you might have been able to tell us about, is not quite the best approach. But it’s entirely up to you of course and we understand that everyone has different expectations. But speaking clearly about this update -- I can say that it was tested for at least 5 to 6 months, all the way pre-holidays last year, and even before that depending on where the line is drawn. Being that we are human, and that we don't have yet some sort of automated AI test-bot (that would be nice) that could plow through every single feature and report things that it "thinks" are a bug, then all we hope for is to do the best we can and get it to a releasable state. Anyone who thinks that just because bugs are present in a release, even if they might appear to be obvious ones to you, that somehow it means it wasn't tested thoroughly -- then you don't actually understand the nature of software development at all. Things are constantly changing and in a state of flux up until the last minute, bugs being fixed, features being added, and everything is interconnected. You pull one string and something might come apart on the opposite side of the virtual planet, so to speak. One issue is fixed, and this might break several connected things that you aren't aware of. Who knew, for example, that implementing improved reticles would result in some (not all) vehicles not being able to focus their thermal sights near the end of the release? Had it waited another month would it have been caught? Maybe, but it’s not guaranteed, because there are so many items under development, but certainly a longer period means it’s more likely that something will be discovered by accident. So, in the end, we can't just hang onto an update "just because", because we assume that there is something there we haven't seen -- in the end it gets to a releasable state where the dust has mostly settled, and it must be released, and it is always done so in confidence. The probability of finding unknown issues exponentially increases once more eyes are looking at it. Maybe we should call a release a "Beta" more often than we should, as a sort of disclaimer to cover to make everyone feel better? Would that help? Why would it? Then it becomes a crutch. I think in our entire 22+ year history we only had one actual Beta release that I recall, where it was said publicly because it was inherently risky (or maybe it didn't happen, and it was something that I recall being discussed). The fact is, we feel things are in good shape every time a release is made available - we are against public Betas. Anything found after that point is only going to be natural, but we never feel like we haven't tested it enough, no matter what someone on the outside, just picking up the software and just playing it after all the hard work is done, might think. You can of course hold and vocalize these opinions (free speech is a beautiful thing), but it doesn't faze the ones who are working day in and day out on the simulation, or else I guess everyone would quit and go on to something far easier. Luckily though, all those involved play the sim themselves and aren't laboring for the praise or approval of others, nor are they discouraged by what might be sometimes uninformed opinions. Certainly, many opinions and observations are valid, though, and we do take those into account of course. But it would be very easy here to "play it safe" and not push for new features to avoid risks, but we don't want to do that. But if SB was, say, DCS, and we were instead working on a single module for it that featured one very detailed vehicle (as an example), then you can bet all your savings that we would be able to thoroughly test all the buttons and things on that vehicle worked completely. But given that we have 250+ vehicles here, many of which are playable and aren't a generic representation of a "thing with a gunsight", then there simply is no way to test everything, all the time, PERIOD. Therefore, out of necessity, we must do a lot of assuming on our end because of limited manpower. We must assume that if a bug is fixed, then we investigate exactly that described issue and verify that it is fixed, and often assume what wasn't touched still works and functions, mainly because there was no indication that it wouldn't by what changed on the surface. Sure, we often think "I wonder if fixing X somehow broke Y" and we do check those, but often it’s a matter of intuition to find much of the fallout, usually instead being naturally laser-focused on the new features and bug fixes that are changing, checking those things repeatedly until they do function, until they are beaten into submission, so to speak. Anything beyond this is natural software evolution. Some very big and new features were added in this update, and with it comes as a potential Pandora's Box of problems and potential fallout. I am very happy that the fallout was as limited as it was, so this gives you an idea of how the mindset is totally different to what you might think, because we know and see how bad things really are during the pre-release months of testing and development (which is normal in all game development when surgery is being done on the code). We are fully aware that bugs will exist, as I said all we can do is catch most of them as possible and try to be timely with releases of free updates and patches between the paid upgrades. Had the update taken months more to release then I am confident there would instead be complaining about that, but in hindsight now people would say instead "no, it would have been a great idea to wait!" Yeah, OK. So, in the end, we get it to a point we feel confident that any unknown issues will be limited in number, and then we release it. Then after that we take the community's constructive feedback and prioritize and address those issues, as quickly as we possibly can. Why hasn't there been a patch yet? Quite simply because we get to a point where we fix the things that are reported by the community (we have done that already in each case within the priorities), and then we find things that you don't know about that are connected to those issues. So, how it usually happens is -- the community has led us to a point to fix something, and then we arrive at the crime scene, draw the chalk outline, and solve the crime, but then we start investigating the "surrounding area" and find other problems that need to be fixed too. Why did the bug exist in the first place? What caused it? Additionally we often discover other problems that aren't even related to what was reported, in our own games that we play. Then all those fixes must be tested, verified, possibly reopened because the fix isn't effective, fixed again, and so on. Then there is the issue that we always want to log jam as many fixes into a release and "patch" as possible, so up until the very last second we try to get fixes into the release. It's always a matter of "it would be nice (tm) if we could get that fix in the release or patch for the public to have" and this of course carries inherent fallout risks, and so on. Could we be more open? Of course. I try to explain everything thoroughly as often as I can, not just a one-line response. Often it seems that a lengthy detailed explanation hurts more than it helps because it can (intentionally or not) be taken out of context, possibly used as ammunition or, given the nature of text communication, might naturally be just misunderstood and taken the wrong way entirely. I mean we will probably see that very soon after this post is made, but hopefully it sheds light on the process more than it hurts. But the real issue is that it takes time to really put together an intelligent and thoughtful/thorough response to explain things, which doesn't really seem like a great use of limited time when we should be busting our asses working on new features and fixing the bugs. A fine balance can be achieved, but it’s not easy. It is especially not the greatest use of time when often someone may drop a hyperbolic "observation bomb" in the forum, which usually does require a lot of time to explain to help prevent widespread panic from those who are prone to panicking. Sometimes these things are invalid or are dead ends, and time is spent searching, investigating, explaining. So, it really all comes down to how much time is available and has nothing to do with anyone specifically wanting to withhold information. I would bet that we are probably more open with the community than others, especially in an age where game developers are closing their forums. Beyond that, we are grateful for all the feedback we get, and I think if anyone with any sort of honest reflection would agree that despite the bugs you might see, and despite the fact that initial update releases might be rocky, we do NOT ignore the community and we address the issues as it is practical to do so. Why wouldn't we do that? In the end we all get a better sim out of it. We know people get enthusiastic and eager and want it to be perfect (so do we), but at the same time a little understanding of the complexities involved here would go a long way. Even now we are at a crossroads about what to do for a patch release. It could have been last week, but we felt it would have been rushed. It could be this week (tomorrow) but always one more week would be better. But then, there might always be another week, and another week after that. When it comes to developing software, weeks can pass like days, days like minutes. In the end, very tough decisions must be made by those who thankfully aren't prone to panic, and those decisions are never taken lightly. So, the short answer here is, the patch will be ready soon, and it will always come with inherent risks. I guess we will see how that goes - maybe we can get lucky and make everyone happy, occasionally. So even though the thread is old, I just wanted to take some time to give an update to the situation, and hopefully provide some insight into the process. "TLDR" version: The patch is almost ready, soon, and I was hoping it would be ready sooner, but not quite ready yet. The process is complex and tedious at times.

Ben's new map:

For more than a decade it is quite known that Leo 2s produced in batches 1-6(and partially 7) were designed to withstand frontal impacts by 115mm APFSDS at 1km range/125mm APFSDS at 1.5km range, but until recent time it wasn't known what were actual threat munitions. But thanks to declassified information discovered in NL archives we know now, that surrogate round to represent 115mm APFSDS was 105mm XM735. Specified CE protection is 115mm HEAT-T and 116mm ATGM simulated with 105mm M465 HEAT-T and 96mm MILAN warhead respectively. This is about what we have in SB at present time, and for simulation purposes it is way more beneficial to know exact nomenclature of specified threats than some abstract RHA equivalents. In other words at this point armor protection Leo-2A0-A4 is very well documented from overall protection requirements down to armor plates nomenclature.

Calm down everyone. Officially let's just say that if you modify the core files (ie. things outside of the mods folder), then you will get unintended consequences. I guess that was the point that others are trying to make here. It's not an attack on anyone, no need to get defensive Badger, it's a factual statement. As long as you accept that there might be consequences, then that is fine, do what you want. But with a little bit of patience, there will be a patch soon (hopefully this week) as other things are worked out as well (it isn't all about focus, and thermal sky color believe it or not - although fixing the focus is the worst offender, and it's done already). And we got a stuttering fix out of this forum post, so thanks to Apocalypse for bringing that up. Nothing else needs to be said here, though.

It will be at least a full installer. Maybe also a patch installer, depending on whether major artwork resource files have changed. No point building a patch installer if it doesn't conserve a lot of memory/download volume compared to the full installer. Also, we want to avoid the concatenation of patch installers so you don't have to keep a long chain of them that must be applied in exact order.

Leopard 2 Interior Fire & Reload:

Cannot adjust Focus even after remap of Joystick Buttons for my X-56. 2023-03-02 20-39-29.mp4

What happened to my thermals?? I can barely make out targets at 2000m..EVERYTHING is like a deep green fog, day sights are blurred...

outstanding graphics enhancement for daysight optics / reticles 👍

Even with 10x time compression (during which you could do nothing), and assuming that nothing else happens during that period, an infantry platoon would need seven hours to dig 100m of trench line. Watching paint dry is faster.

The basic course of action: In the Mission Editor, go to the Map menu and pick "Replace Map", then pick the same map package, but shift the frame of the selected area accordingly. Two things can happen; the units retain their original place on the map, in which case your job is done. Or they stay in the same place with respect to the Steel Beasts world coordinate system. In that case you'd have to use the marquee tool to mark everything on a party's side (zoom out first), then simply drag and drop the whole selection to the new location. Things to consider/preparatory steps: If I understood you correctly, you want to keep everything in the proper location, but shift the map frame a little. I recommend that you create a crosshair-like map graphic, e.g. a target reference point, exactly on a certain map grid. Copy that TRP to all other parties. Then, if you have to mark everything for the drag & drop action, you just have to focus on that map graphic to move it (and everything else with it) to the previous location; rinse and repeat for the other parties in your scenario.

Right, they shouldn't, at least not right now - because we thought the visual effect was misleading for M1s (flames coming out of the crew hatch), and wanted to wait until we support blowout panel effects. Now obviously, in real life, the ammo could cook off when the loader has the ammo door open, but that too would probably blow off the panels and escape inside the turret as well, and we felt that people would complain about that.

I hope not. Until then, I'll just chalk up black hot as useless.

After this "horrible" scenario with this new version, we had only issues. Re-joining the scearnio was like impossible or at least a few players had problems to re-join. The thermal imiging device "WBG" i still had to calibrate again after i just switch to commander position and then back again. And we would have to re-skript all scenarios again to the New version, bcs there are lots off things they dont work when u dont change some new settings for the 4.37. We will test it on sunday again. Otherwise we (us germans) decide to re-install the older version 4.36 again, bcs this one worked way better than this actual one. I hope you guys can fix it very very soon

Some changes will be made with the next patch. Some of the videos I saw of the T-72B3 thermal imager were, however, rather atrocious. Maybe some are better, suggesting a high variance in factory output, or that the devices are fragile, or tjose videos simply were an exceptional case and don't represent the majority of cases. We would certainly be willing to reconsider in the light of new evidence, as always.

Not here to beat a dead horse but the T-72B3 thermal is awful like that. I am aware that russian military equipment has proven to be less advanced than expected but this is essenially useless isn't it? I appreciated the effort to make the game/simulation realistic but I think this didn't work out as planned. Thermals that don't offer brightness and contrast adjustment aren't very good right now. On the other side with the Leopard 2 it feels like cheating. The CITV can be adjusted to show the entire world, but still make enemy vehicles glow like a christmas tree. Here a comparison between the T-72B3 TIS and the Leopard 2A5 CITV. On one I can see all the of the tress and the terrain AND all targets glow. On the other I can barely see the target, let alone make out what the world looks like.

So just to clarify and explain situation - the video provided here was on a cold day (20-30F), SB's sky is currently the opposite extreme, so we will try to get it in between. It shouldn't be too hard to address. 👍

alright, let me rephrase then: Just need 6 months of not working on all sorts of other shit, and it'll be done. T-72 interior was 600 hours by the by. in that same time period i can make 3-4 exterior models.

I expect the new version to be made available by Thursday (this might mean Friday in Australia); we want to give the web installer a final check before the release (and it needs to be built first). Sean will post the Release Notes as soon as he's ready, possibly ahead of the actual installer.

Just as info: A german tank platoon usually have 4 tanks. 🤓😉 Have fun guys and good shots👍

Don't forget to turn up the volume:

My plan is ready, I am not expecting any big changes in it, so I am posting it here. I will go through it in detail on the briefing. My intent for the first objective (town Imshili) is to split our assault into 2 groups and attack from flanks. Then to cross the river (primary crossing point is NERO, secondary is Iceni - A2 will report if the bridge is useable). I've highlighted some important positions and general scheme of our advance on the eastern bank of river. The exact movement (and waypoint assignment) will be done during the operation based on the situation. I would like to encourage any inexperienced player to take A31 as a Platoon Leader. The scenario looks like a good learning one without too much of troubles (... I hope this claim won't bite me tomorrow ... ). Also, I plan to have A3 in the middle of our advance, so other platoons will be able to assist quickly, should it be needed. See you tomorrow!

Eventually that's going to happen, but my firm prediction is that it's going to be a near-useless feature for the Personal Edition because of the amount of time that it takes to dig in.

Right NOW!!!

Isn't it in the end mission creators choice whether to or not use Complicated items / features. Those who want it easy... Will use it easy those who want the burden of a feature... Probably have audience of those who are interested of it. That is btw major reason why I love Steelbeast. You can have a lot. But you don't need to use or know everything as it works with AI just as well. ❤️

I'm not convinced that this actually happened. At least one of the Leopard 2s had the hull split open exactly where the hull ammo bunker is (forward left corner), with a full quarter of the whole hull disintegrated: That one clearly is a result of a deflagration of the hull stowage, and it should surprise exactly nobody. Steel Beasts predicted that this would happen some 20 years earlier (well, the turret separation part). In this example, it's the turret bustle rack, which seems to have worked as designed, at least initially: This example reminds more of the first, except that the ammunition deflagration either involved fewer rounds, or was staggered enough to lift the turret out of the hull, but was not so severe as to rip open the hull: Absent in all cases, craters from aircraft bombs.

When tanks cook off ammo apart froma fireworks display nothing else happens (No shrapnel / overpressure) As a temp fix a hard wired IED device using remaining ammo? AS a way of teachin softskin and inf to not hang around Tanks. We had a Kanium game where @Major duck's tank blew up from a AT-11/AT-14 hit and my teeny tiny recce jeep was just like "Meh" parked about 50 meters away. Think a 60 tonne tank going boom might at minimum rattle some heads? @Lumituisku's image

Sorry, but someone on the Internet claiming that certain sources are subjective, is also entirely subjective. The very nature of all this *is* subjective, from the sources, to those that have opinions that disagree with those sources. But the fact is that no one source was used in the revision; it was a multitude of sources, and discussions between at least four knowledgeable individuals until a consensus was reached after several days of review. We had the late version of the Leo 2A4 represented, because back in 1998-1999 there were two tanks in SB, the M1A1(HA) and the Leo 2A4, so we made both comparable, giving the latter the protection level of the late variant. Now we have the Leo 2A5 present, and so after consideration, we felt that it makes far more sense to model the earlier Cold War version of the Leo 2A4 instead, since: that is what the model visually represents there were so few of that specific improved variant of the 2A4 (<100 tanks) scenario designers were using a late period Leopard 2A4 in Cold War scenarios, putting them out of the time period by about >5 years as mentioned, now we have the Leo 2A5 modeled for the 1990s, being more of the M1A1(HA)'s contemporary - a better representation for that time period In other words, from a scenario design point of view, the way it was before was far too limited in what we could do. We essentially had a "diet Leo 2A5" of the early 1990s, to use for 1985-1989 scenarios, which meant that it was a terrible representation for that. It made little sense after we thought about it. Instead, what you have now is what we strongly feel is a better representation for Cold War scenarios. Obviously we knew that would cause controversy and grumbling, but we are pretty confident in what we did or otherwise we would not have went through the process. Speaking of the other Leo 2s, as mentioned, in the mid-1990s the Leopard 2A5 should be used instead, which we feel is pretty good in its representation (any revision of the later Leo 2s would be minor adjustments, not necessarily all negative either). And of course we want to make different versions of the Leo 2A4 -- the heavier armored one that we think was represented before, and even possibly a Leo 2A2/2A3 for early 1980s (where at least they can only have up to the DM23, for example, and some visual differences - the all green texture, etc.), and maybe even an earlier mid-80s Marder one day. So its not like we are taking an hammer to all the Leo tanks, so please try to remain open minded about it. 😎 Edit: Does this mean that some Leo 2A4 scenarios will have to be rebalanced? Most likely, but not always. If needed, then it would be adjustments like this: Leo 2A4 vs. M1A1 scenarios? Give the Leo 2A4 DM33 now (we used to give them the older DM23 vs. M829 on the M1A1 to compensate for the better protection on the Leo 2A4. Now its not needed). Leo 2A4 vs. 1990s threat scenarios? Change to a Leo 2A5. Leo 2A4 vs. Cold War 1985-1989 scenarios? Consider, if anything at all here, giving Soviets the ammo of the previous available round in some scenarios (we often give Soviets ammo that would be extremely rare for them to field in large numbers, when they often had very few of the latest arounds available), or give a few more Leo 2A4s to the NATO side. (I say "if anything at all", because we have played plenty of 1985-1987 Cold War scenarios with cutting edge Soviet ammo versus M1, M1(IP) and M1A1, all of which were still in US service, and its tough but not impossible).

Eventually, we might add a 2A4 variabt with the then latest armor package. At least some of the 2A4s that are still in use received the upgrade.

Updated this one to improve replayability and add trenches. I've kept the old version 1.0.0 available for anyone who wants the very predictable OPFOR.

well, the previous estimate for the challenger 2 turret was basically done by taking our estimate of the abrams armour closest to the challenger 2, estimating the thickness of the challenger 2 front turret, and the result was our previous estimate. all of it publicly sourced. if we used a bunch of top secret military material for our work, there's not a lot of military customers who would allow pro PE to be released.

Seems like it got fixed.

Yep, I have plans for more sound improvements (similar to the new bullet impact sounds in 3rd person now in the update, which I thought was most important to do first). Let's see what happens. 👍

I don't mind criticism at all. Things didn't go well with this version, obviously. There's just two points, -- Generic statements like "lots of things don't work" help nobody because there's no actionable information in it -- There's competing expectations between the speed of feature development and the quantity of bugfixes, the amount of testing/quality control to be administered with each software iteration, and the amount of money that everybody is willing to pay for it. Of the software development triad "fast, good, cheap" one may only pick two, or must be willing to compromise. eSim Games is largely in the "good & cheap" camp, but as one can imagine from the current geopolitical situation, there's immense pressure to also deliver certain things faster. On top of all that, the old CodeMeter runtime version 4.50, if combined with Windows 11, resulted in the irrecoverable loss of CodeMeter containers with the associated loss of license for a good number of users. That's clearly unacceptable, so we had to release an update with the new runtime version at the earliest possible moment, to help those who lost their licenses. More features have been worked on (and were intensively tested, too) - but since they didn't reach full maturity, they were not included in this version, and therefore it may appear as if no other work has happened and the amount of test coverage was less than you're used to. In other words, your perception is biased towards what's contained in this update, not to everything that happened since version 4.363 Anyway. If you can provide us with good examples of what went wrong in your old scenarios, we'll try and see if we can fix some of these things. The more vague your statements are, the more it takes to test each area in the hope that we might find what you were talking about; the consequence of that is that in a given amount of time, fewer things can be repaired.

Ssnake & eSim Games, We are not frustrated but disappointed. An update should be tested intensively beforehand. The thermal image is absolutely useless and in no way corresponds to reality. Its operation should be more stable and easier, and the settings should not change when changing positions. Nevertheless we find the ammunition positive, even if some scenarios now have to be revised. We will test 4.377 again and report back!we are not frustrated but disappointed. An update should be tested intensively beforehand. The thermal image is absolutely useless and in no way corresponds to reality. Its operation should be more stable and easier, and the settings should not change when changing positions. We find the ammunition positive, even if some scenarios now have to be revised. We will test 4.377 again and report back. Please don't take it personally if criticism is expressed! Thanks!

Good to hear that. I don’t doubt that the T-72B3 doesn’t use the best thermal sight but I must assume it’s better than this. And this is certainly true for the M1A2 which has a rather unrealistically bad CITV and TIS right now. But again, I appreciate the effort you guys make.

I am not sure I explained it correctly... I am saying that the temperature is NOT dynamic right now. Its a sort of generic situation where the sky is hot. So, like vehicles that do not get brighter or darker with their activity, we have a sort of generic one size fits all temperature for everything. The military essentially complained about this with the sky being too dark/cold, so given that we are representing things in a non-dynamic way right now, we probably made the sky too hot (too far the other way). The solution would be something in between to get it "OK" in both hot and cold situations, until we can do something that is actually dynamic. So, in other words, I am not disagreeing with you here; we will look into it. But I am trying to make it clear that its about making it look "better", and less washed out, while at the same time giving some temperature to the sky too rather than pitch black, in an attempt to find a middle ground between too hot and too cold. It will take a few tweaks to get there, I am sure, but that is the nature of big changes like this. Hopefully that makes more sense.

Changed the thread title, we've settled for a version number. I'd call it an update, not a mere patch. Of course, bugfixing dominates. Most importantly, we'll get rid of a critical issus that resulted in the loss of a number of time-based licenses under Windows 11 in the last months. If you were affected by it, please contact me. Release notes will go up later today.

Cessna 414, cool. I'll take a look at it. I'm flying the Kodiak 100 at the moment. Pretty good study aircraft and I always had a penchant for bush flying. Am I the only one who has never really attempted to learn an airliner? I've always stuck to GA in all the flightsims.

Nice battle. Our only loss today...you can see the "oh shit" moment in his face 🤣

Update: So far we have 186 sounds modded. I focus first on german vehicles because my BIAS demands it.