Strv S1 – Official WG Response

Kandly, Community Coordinator, wrote this on the EU forums here:

„Hi guys!

Some clarifications regarding this: In order to display the information, we’re using the files in the game client, in which we put a number of values that pertain to vehicles.
As you know, in update 9.17 we introduced a new mechanic for some of the Swedish line tanks: Siege Mode. For these tanks, we have created an additional (secondary) file in order to adjust the Siege Mode’s settings. The game client uses a number of settings from that file, which are only connected to the Siege Mode. The client uses all other settings – only from the main file.
With the Strv S1, we have put a number of parameters into the secondary file, bearing arbitrary values from the main one – and because these parameters do not influence anything when in the file, we weren’t able to quickly remove them from it.
These are the parameters we are talking about:
• Ground Resistance
• Braking Power
• Hull Rotation Speed
Because of this, third-party services displayed incorrect parameters of the Strv S1 starting with the release of the vehicle in update 9.17.1, which was caused by the aforementioned arbitrary values in the secondary file. That being said, the game client was nevertheless displaying the correct characteristics.
In update 9.19, we have finally removed the troublesome parameters from the secondary file. As a result, third-party applications started correctly displaying the real values.
To conclude, the above parameters of the Strv S1 haven’t changed since the release of the vehicle. 
For correct comparison of this vehicle: Compare Siege Mode with Siege Mode values, and Travel Mode with Travel Mode values.
Regarding the time of switch from Travel to Siege Mode:
From the release of the vehicle in update 9.17.1, the switch time from Travel to Siege Mode was displayed as 1.25 in the Garage, while you could see a more precise 1.3 while in battle. In update 9.19, we decided to fix this discrepancy, but unfortunately did not inform you about it.
Thanks for being attentive to detail and your prompt feedback! :great:
Cheers ”
My take on it: WG tries to hide game bugs under the carpet, pretending they did not happen and blaming everything on the third party stat reader tools. At least they are trying to fix the issue, so we got that going for us.

6 thoughts on “Strv S1 – Official WG Response

  1. What are you talking about? What bugs would Wargaming “hide under the carpet”? There are no bugs. And Wargaming did not try to “fix the issue”, did you even read your own blog post?

    The problem is on the side of the third party tools/websites, which do not show the correct values, because on the swedish TDs they could not use the same method to calculate them as on the other tanks.

    So the values on those sites where wrong the hole time.

    Thats clearly not the problem of wargaming.

    1. I said that WG tries at least to fix the issue that generated this confusion. They try making the effects of it seem smaller though, which is expected from them.

      1. No, WG’s original implementation is not generating that confusion. In fact it is crystal clear. Those ‘secondary config’ has a _siege postfix. Any programmer with half a brain would have figured out that this is specially used to store parameters for siege mode, not tank mode. But apparently those guys running the 3rd party tools didn’t even bother to notice it.
        Also WG is not obligated to make their vehicle config files human-readable in the first place, let alone provide documents or instructions on how to extract them. You should feel lucky they made it easy to access as it is. It’s entirely up to the 3rd party software authors to make their extractors accurate and reliable.

        1. “Any programmer with half a brain would have figured out that this is specially used to store parameters for siege mode, not tank mode. But apparently those guys running the 3rd party tools didn’t even bother to notice it.”

          Actually I read that slightly different: people actually used the data from the secondary file, but didn’t realize that not all values in that file are actually used by the game (can’t really blame them, it’s not obvious and only way to figure it out would be to double-check all stats manually in-game). As the _siege file had a different traverse rate than the regular file this showed up on Later WG aligned that unused dummy data in the _siege file with the real data of the regular file to avoid this irritation.
          Basically this only became an issue because WG listed _sensible_ dummy values in the _siege file. If they had nulled those values it would have been obvious to reverse engineers that those values cannot be real. But of course WG doesn’t have any obligation to make reverse engineering easy.

          (all assuming WGs description is correct)

Comments are closed.