Patch V 4.377 only?

[O.Schmidt]

Question: Do I have to completely delete Steel Beast 4.363 and reinstall V 4.377?

[TSe419E]

That’s what it says in the release notes.

[O.Schmidt]

Puh, I only have time for that in 1 weeks! Thanks CavGunner! 

[Ssnake]

Uninstallation takes about a minute on my system, and the Bundle installer will handle it for you once that the automatic download is complete.

[Gladiator(911)]

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

Edited March 4, 2023 by Gladiator(911)

[Abraxas]

I confirm most of Gladiator's statements!

😡

[Ssnake]

11 hours ago, Gladiator(911) said:

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.

...

I hope you guys can fix it very very soon

 

7 minutes ago, Abraxas said:

I confirm most of Gladiator's statements!

😡

If you want to vent frustration, by all means do so.

 

If you want things to change, please provide a detailed description of each issue - ideally combined with a tiny scenario that demonstrates your case.

[Abraxas]

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!

Edited March 4, 2023 by Abraxas

[Ssnake]

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.

[Apocalypse 31]

4 hours ago, Ssnake said:

I don't mind criticism at all. Things didn't go well with this version, obviously

Let's be completely honest....things haven't gone well with patches for years.

 

You can argue that, but I don't think any of the players (not customers) are really even bothered by that - I'm certainly not. It's Software Development 101 and we know eSim isn't a AAA studio with hundreds of employees.

 

What's frustrating is that you guys release patches like this and then we have to wait weeks or months to see a fix. 

 

I also wish there would be more communication about stuff like this....I think expectation management would go a LONG way, but I know that you also disagree with me in that sense.

[Abraxas]

One question regarding Leopard 2s;

The GPS aiming reticle (daylight view) is now illuminated.

Can this be dimmed?

If not, then this should be made possible because it is too bright.

In reality, it can also be dimmed.

Thanks!

[Volcano]

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.

 

[mpow66m]

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

Edited March 17, 2023 by mpow66m

[Abraxas]

Yesterday we drove a scenario with Leo2A4 in version 4.377. And again we had the situation where enemy tanks and APCs had broken in between our positions on the situation map. We tried to clean up this burglary in a hurry. In the end we had to realize that there was no enemy at all. It was misinformation similar to a mirage on the map. The enemy was actually kilometers away! This phenomenon was again in a Leo2A4 scenario at host and guests. It seems to be related to the Leo2A4.

 

Edit:

On March 5th, Gladiator(911) reported the following:

"According to the map, ONE single enemy PzJg (BRDM-2 AT) was indicated almost 200m next to an own tank section. But there was none actually, but rather almost 3 km further away. ..."

 

It was a Leo2A4 scenario! With Leo2A5/6 we never had this misinformaion before.

Edited March 18, 2023 by Abraxas

[BlackIce]

2 hours ago, Abraxas said:

"According to the map, ONE single enemy PzJg (BRDM-2 AT) was indicated almost 200m next to an own tank section. But there was none actually, but rather almost 3 km further away. ..."

I'm tempted to ask my brother to check if that BRDM is still there IRL... he lives a couple hundred meters NW of the minefield...
...come to think of it, maybe I should warn him about that minefield and the bridge being rigged for demolition. It's on his way to work. 😉

[TSe419E]

4 hours ago, Abraxas said:

Yesterday we drove a scenario with Leo2A4 in version 4.377. And again we had the situation where enemy tanks and APCs had broken in between our positions on the situation map. We tried to clean up this burglary in a hurry. In the end we had to realize that there was no enemy at all. It was misinformation similar to a mirage on the map. The enemy was actually kilometers away! This phenomenon was again in a Leo2A4 scenario at host and guests. It seems to be related to the Leo2A4.

 

Edit:

On March 5th, Gladiator(911) reported the following:

"According to the map, ONE single enemy PzJg (BRDM-2 AT) was indicated almost 200m next to an own tank section. But there was none actually, but rather almost 3 km further away. ..."

 

It was a Leo2A4 scenario! With Leo2A5/6 we never had this misinformaion before.

I have seen this happen before.  I suspect its cause was a very serious case of a player de syncing from the host.  In this case the player Falcon (not his fault, it just happens sometimes).  Following my suspicions I believe the “ghost” units are the host receiving bad position reports from the player, which he can see and which he did engage, which are reported by the host and show up on the map.  The corresponding ghost units are either already destroyed, according to the host, or are somewhere else in relation to the host and all of the players still in sync with the host.

 

l don’t know if it has anything to do with the Leo 2A4, but I am positive that in this case the primary cause was the player being de synced.

[Abraxas]

Could be! Nevertheless we've only this since 4.377.

[Sean]

9 hours ago, Abraxas said:

Yesterday we drove a scenario with Leo2A4 in version 4.377. And again we had the situation where enemy tanks and APCs had broken in between our positions on the situation map. We tried to clean up this burglary in a hurry. In the end we had to realize that there was no enemy at all. It was misinformation similar to a mirage on the map. The enemy was actually kilometers away! This phenomenon was again in a Leo2A4 scenario at host and guests. It seems to be related to the Leo2A4.

 

Edit:

On March 5th, Gladiator(911) reported the following:

"According to the map, ONE single enemy PzJg (BRDM-2 AT) was indicated almost 200m next to an own tank section. But there was none actually, but rather almost 3 km further away. ..."

 

It was a Leo2A4 scenario! With Leo2A5/6 we never had this misinformaion before.

 

Can you attach the scenario?  Does it happen every time? 

[TSe419E]

Here is my copy of it.

GELBER KYRASS.sce

[Ssnake]

The relevant question is, do the host's and client's machines' debugLog.txt files of that session show that the network bandwidth was exceeded/packet loss occurred.

[Arch]

Not going to defend the devs as I am very new so it is not my place anyway, and I am someone who regularly releases half-finished products then has to patch them multiple times for fixes which makes me worse than them by definition, BUT-

 

Please don't make threads like "omg last update so shit guys", just try to reproduce the issue, post a thread and an example and roll back to the previous patch if you really need to. The sure-fire way to get a dev to roll their eyes and think you're a fucking idiot is to vent without providing a concrete example of the issue.

[Abraxas]

For better understanding:

Both scenarios/sessions had different hosts and guests. Due to the number of participants, we always used the SBProPeServer4_377.

The March 3rd scenario (report from March 5th) was from Gladiator(911), the March 17th scenario was from me.

Unfortunately, the last video and files on Gladiator's PC now have been irretrievably lost due to drive failure, sorry!

[Lumituisku]

6 hours ago, Ssnake said:

The relevant question is, do the host's and client's machines' debugLog.txt files of that session show that the network bandwidth was exceeded/packet loss occurred.

 Hey Ssnake would you please be so kind and explain in detail what does it mean in this context if there was network bandwidth / packed loss? 

 

I am asking because I have hosted Kanium game two times now and I have observed atleast one person to have severe network problems momentarily. His PC like froze and he told us that he might have dropped. But after like 5 minutes his client suddenly catched up.  I think i observed it happening twice. 

 

I also host lot of multicrew games and i have seen that message pop up quite a bit on those.  So what does that message mean and should we be really concerned about it whenever we see it happens? Or when should we be concerned at low packed loss or after some limit? 

 

Is there Any way of getting everyone synched up if problems happen?   Save in progress / restart session? Or maybe it's just enough that guy with problems drops out and we do pause and re-join to minimize problems? Then again...  These suggestions have at times caused problems of their own too. 

 

*Wonders*

 

 

[Lumituisku]

Also another thing i am wondering is... Is there easy simple method people could use to help us out to find what are problems with low performance / frames or such? Could shift + F12 = screenshotting be a viable method? When such is observed, like when person observes that darn i have low frames simply to take screenshot and later it could be possible seen what guy was doing looking at or from mission time stamp (if it's visible on screenshot.. i dont remember) location and movements be backtracked a bit from AAR?  Would that for example be viable method to help sourcing when /. What might be causing low frames?

 

(Ofc there may be external factors too that might cause that) 

 

Asking since low frames seem to be a thing that pops up in discussions with friends / buddies here and there. 

[Ssnake]

2 hours ago, Lumituisku said:

would you please be so kind and explain in detail what does it mean in this context if there was network bandwidth / packed loss?

Well, a network game is a flood of constant update messages between host and connected clients. Like most other real-time oriented network applications, data are transmitted with the UDP protocol. TCP/IP has a lengthy handshake procedure to ensure completeness and authenticity of all data transmissions. UDP basically says, "fuck that, fast delivery or bust!" and doesn't check with the other end if the message was actually received. It just sends one data package after the other and hopes for the best. And in 99.99% of all cases the data packages do arrive.

So, the question is how important are the remaining .01% of packages that get lost (or garbled) during transmission. Most of the time  - because those are the messages that are sent most frequently - it's a position/vector update of a certain unit under a certain client's control, so if a package is lost the dead reckoning on all conntect machines is a bit off and you see a tank sliding a little bit across the landscape every now and then as one or several missed updates are eventually followed by a package that does send a new (and unexpected) location. So, maybe 50% of those .01% are rather benign packet losses.

Then there are messages that send a status flip, but not the status itself. Like, the human gunner closes the ballistic shield doors on the primary sight. The connected client machine with a human player in the commander's seat must know this, so the doors get closed in his simulation as well, and the system state is consistent on both machines. If that package is lost, the commander might see "his" primary sight fully functional while the gunner sees the ballistic covers closed.

 

So, these are cases where it's still somewhat harmless, but might irritate human operators, so we'd rather not have that happening. There are mitigation strategies, like sending absolute status updates rather than state change messages maybe once every 20,000 milliseconds to recover from such state discrepancies ("Just a general reminder, the shield doors are supposed to be closed!").

That's probably another 40% of those 0.01% of lost packages where it's sorta-annoying but may not be noticed often (e.g. if there's no human CDR in the same tank, he can't notice the discrepancy in the system state; even if he's there, he'd have to know that the gunner has just closed the shield doors, and he'd need to look at a replication of the primary sight to actually notice that something is wrong, and even then, on average, a second later it gets fixed with the reminder message).

That leaves maybe 0.001% of lost packages were truly bad stuff can happen. And it's rather unpredictable what could possibly go wrong. Of course we'd like every packet loss to be recoverable, but the reality is, nobody knows if there might not be a unique combination of three or four packages of a certain information that, if dropped all together, might not cause some really strange effect.

 

This happens rarely when humans are present to observe it (if there's no human player around and something weird happens with a civilian car of the Purple party somewhere up in the northeast, it might be the most astounding or frightening event, but we will never know). Which makes us believe that these things don't happen at all when maybe we're just blissfully ignorant. And then we happen to run across a freak event right after we updated a software, and to our brain it's absolutely clear that "the upgrade done it". And in all fairness, there is an elevated chance. But the trouble with rare freak events is that there's no economically feasible way to test for them.

 

You test as much as you can. If nothing happens, maybe it's because the code is safe. Maybe you just didn't come across the conditions that will reveal it. As a reminder, Steel Beasts is commercial grade software. It gets tested as much as we can afford it, so we don't feel like total frauds charging money for it. But every version of Steel Beasts released since about 2013 came with about 2,000 known bugs. Some of which you know, and even fewer about which you care. Every day we add a bug or two, and we fix a bug or three. Then, after releasing a version, we learn about the 5...20 bugs that we didn't know about, and we fix 4...15 of them in a subsequent patch, and the counter of known bugs jumps from 1997 to somewhere between 1998 and 2002 again.

 

 

Coming back to the packet loss thing, if packet loss occurs, all bets are off what might happen. If the debugLog file contains a warning about package loss around the time when you observed an anomaly, chances are that the package loss made it happen. Needless to say, this should be checked immediately after the game session, so you know the approximate time stamp when it happened. Days of weeks later, it's near-hopeless to figure this out.

On the other hand, if it happens more than once or twice, it might not be packet loss. But a bug that manifests in 30% of all cases after 2.5 hours into a game with between five and twenty participants and 100...200 combat vehicles is effectively unkillable, unless you kill it by accident when fixing something else.