Volcano

Glad you liked it, come back anytime. 😁

Ah yes, I saw that, but I guess I didn't understand that it fixed the entire issue (I thought some issues still remained with launching the program). OK, good that you figured it out. Will mark this as resolved then.

Certainly you should contribute as much as you are willing to do, it's all voluntary -- anything/everything is appreciated. It's a community effort here. 👍 I guess the main point here is that the "magic resupply" never really worked in all situations, it has issues in how it determines what gets resupplied. It's on the to-do list. 😉

Actually, this should be fixed now. Seems that it was something that was an easy fix, but I looked in the wrong place by mistake. Hopefully it will make it into the coming patch. Let's see.

Right, it should resupply from a truck normally (the vehicles I mean, not the infantry); I meant that in Test mode that "magic resupply" is an issue for those vehicles with the attached guns. It's certainly something we will look into when able, but not as urgent as if it didn't resupply in normal circumstances (from the supply truck for vehicles, or when mounted into a vehicle for infantry), which should work fine.

So a brief explanation here: A few version back completed breaches are no longer allowed to be curved - they must be straight. If there is say, an obstruction in that lane, like a tree, then this is not a good breaching lane and will cause problems. We could just vacuum up the trees in a plowed lane, but then this would look quite bad with the largest trees. It will however (right now) plow through the small trees, so that is good, but otherwise it will cause trouble with the larger ones. I guess in the mean time, just be sure that when plowing that the line looks good straight ahead. Also, you definitely don't want a 1km long breach route that also passes through a forest, like in the example, because that simply just isn't going to work. In the forest situation, its probably best to scope out a straight line, or do manually plowing and manual driving (it's just not the best environment to breach a minefield).

Ah, yes the Mission Editor's "test mode", the right-click resupply has trouble with vehicles that have attached guns, specifically those that can have all sorts of different types of those guns with different types of ammo (ATGM, MG, etc). The ATTV is probably the best example we can use to look further into it, thanks.

This has been fixed now. It might make it into the next patch, we'll see (depending on the timing).

Thanks, yeah it is a known issue at the moment that helicopters will crash into each other, especially in a formation. At the moment they have been made to be immune to such crashes (so they just push each other around). It isn't a great solution, and looks ugly when it happens, but keeps them from dropping like flies. I think in general helicopters are not aware of other "vehicles" for collisions. At some point we will do that, and then (after that works) make them die from such collisions.

IIRC, Dynamic Cache has to do with how much memory is devoted to terrain streaming. The higher the better. If you have a somewhat recent machine (like within the past 5 years?) then there is probably no reason it shouldn't be maxed out. Otherwise just put it at max and lower it only if you see something odd when jumping to different units across the map (when the terrain would be loading/streaming). Not sure what that odd thing would be, but I suppose you would notice something bad and different. 🤔

OK, looks like the usual fix here didn't work (scripting), which implies that something is hard coded there. It seems that for whatever reason this vehicle doesn't treat the external view sounds as the "near external" type, perhaps having something to do with the fact that you can go to the commander's position. So in other words it seems like it is a bug in the behavior, rather than just having the wrong sound file applied. I will pass it along, but obviously it won't be high priority at the moment.

Thanks, I will take a look when I can.

Now I am not sure this is what is your problem is, but I updated my NVidia drivers just this past week and after I did that, several other games I play would not load. I didn't bother to see if it affected Steel Beasts at the time, because I immediately went back to the previous version drivers and then everything worked again. I wonder could it be the same issue here with the latest NVidia drivers? There seems to be a lot of complaining on the Internet about it, so lots of people are having this problem with certain cards. Here is what I did, which you could try it (unless you fixed it already): I went here... https://www.nvidia.com/Download/Find.aspx?lang=en-us# ...and searched for my exact card and downloaded a driver from a month ago where everything worked. Maybe its worth a try? But of course the BSOD is a bit worrying.

Thanks, yeah good point, those options should not be allowed when an RWS is equipped.

First or second one? I didn't save the second one (forgot to). For the first one, I have mine where I joined 15 minutes into it (so its missing that part).

17 MAR 2023: Kymijoki River Crossing 4300_OMU (and, if over early...) Brush Fire-Zebra Nitro-4374 SPECIAL CONSIDERATIONS: Draft? Yes. Random CO selection? Yes. Minimum # players: 6-9 NOTES: Remember to play within the TGIF House Rules and SB.com Community Rules.

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.

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.

Thanks, this should be fixed now. (As to whether it will make it into the coming patch, I am not sure -depending on when the EXE is built and all).

Yeah, good that this was pointed out. It took me quite a long time to wrap my head around what was going on, but hopefully with the new label it makes it more obvious. It will say something like (at least in English): "Detailed driver (gear select & separate throttle/brake)" ...or something to that effect. As to when it would be carried over into other translations, I am not sure.

So just to follow this up (I was unable to revisit this before now)... Actually the check box will remain in Pro PE. It seems the issue is actually that the wording of the checkbox is wrong and totally confusing. When that check box is ON, what it does is, it makes it where the driver must select D, N, R "gear" (forward, stop or reverse). The actual gearing (1st, 2nd, 3rd) is shifted automatically regardless, so its really about drive selection, not so much "automatic transmission" per se. Additionally, when checked on, it splits the throttle from one single axis (+ being forward, - being reverse, 0 being stop) to two separate axis, like a gas pedal and a brake pedal. We can see this if someone presses "Configure Axes" (plural) before and after that check box is selected. When its selected there is a new "Brake" axis present. By default, the brake is probably being fully applied, so when driving around its as if the brake pedal is pressed to the floor at the same time (the solution there would be to remap it to a brake pedal peripheral or some other axis). But certainly the label on that check box must get renamed, and that has been done already to hopefully make it more obvious as to what it does. It seems that it has been like that for several versions now but no one ever tried it out before (apart from the military), so thanks for that. 😎

Actually, slight change of plans. We will play those scenarios next week, and instead will try a new one this week: Brush Fire-Rhino-4377 Being new, it might have some issues, but we will never know until we try it. 😌

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

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.

Not sure I understand, exactly, but maybe this answers the question: The problem that was fixed is that when the tank died, it had a probability to shoot a flame out of the hatches into the sky (the flame-jet ammo cook effect). This was a mistake, so we removed it. The actual description to that fix was rephrased in the release notes, and probably not in the best way. But the point being - it was only a graphical effect that was changed, nothing else.