Leaderboard

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.

When in the 3D view it is under the "System" tab in the upper left-hand corner as well.

Make a back up your SB executable and put it somewhere other than your SB folder. Reason: If you make and save control key changes while in a SB Multiplayer via internet network connection, (aka Network session) as soon as you hit "Save" your antivirus will identify SB as malicious software (because you made a configuration change while connected to the internet) and nuke your SB executable from orbit.

First I'd like the option to fire AT weapons and rifles...

Alt+C

Just FYI: A pretty significant network bug was fixed today that took about a week to track down and eliminate and it was one of the main issues holding things up on a patch release. The bug caused network sessions to get spammed with messages which would cause the network to because overloaded, and eventually crash the HOST. This was caused by the M60A3 (either version), and it came from the fix to Bug 11295 (in the release notes). This is not something specifically reported in the community as far as I know, but is something we discovered (from both of last week's TGIF scenarios). In the mean time, please avoid playing Network Session scenarios with an M60A3 (TTS or otherwise) for now (single player is fine). We should now be at a point where a patch can be released soon with that wrapped up, but it will probably be next week to be able to do some final checks (and we want to get that T-55 binocular fix in there too). But let's see if all things go smoothly. In any case, if you play a network session scenario without the M60A3 until the patch, then it should run fine.

Good job w the update even Babe Ruth whiffed once or twice.Im sure itll be fixed ASAP.Im enjoyiing it warts and all.

My method: 1) make an L shaped line graphic with line width zero and a bright color exactly on a grid square edge 2) copy it to all parties 3) select the new map area 4) drag to select all units on blue (including the graphic) 5) zoom in to the graphic and drag it exactly on to the original grid sqaure 6) repeat for each party 7) never make the map area mistake again!

I only reported this against the Abrams cause I know the Abrams Drive System and how it should act IRL. Now after finding out what the option real purpose and why it is being used then I guess it could be related to others. But I’m sure as they have different Gears and other Drive options than the Abrams or closely related. Either way Esims have identified their use for it and are making the changes. Thanks again 👍

does have very good mobility on any terrain, MTLBv can cross open swamp and snow means nothing. But this time the ice broke in such way that rear part of tank dropped in pond, so tracks did not get traction to pull itself out. We solved it by attaching spikes (soviet hardened steel spikes that are bolted straight to tracks) and the tank got out using its own power. I remembered that I have picture of this, hopefully it uploads.

Heating C-rations in the field by either putting them in the exhaust stream of the personnel heater, the hot air vent in the turret, or burning the box while the can was inside. Hot breakfasts brought out by the 1st Sargents. That glorious hot shower provided for us by the unionized Dutch Army (on a weekend) after being in the field for 30 days. Being the gunner during gunnery. Hitting a 2000+ meter target with the first round while on the move. Pulling three 88s and two M60A1s out of the frozen muck at Hohenfels. Etc, etc, etc...

POS? But being a MTLB crewman is comfy, tank has literal leather couches at the back for sleeping. Of cource tank is tiny and made in soviet union, so ergonomics are not good at all. And transmission is unsyncronized, so driver has to know what he is doing. And maintainance is pain, for prevously mentioned reasons. Transmission adjustments especially.

You're welcome Gladiator. It was a lot of work but I tried really hard to make sure it was reasonable for appearance and performance. I'm taking notes from anyone that messages me if you find a problem. I'll probably plan on doing an update to it some time next years and release it at the end of the summer like this one. If you run across a problem please let me know.