Destroyer fire rate not working as advertised

[Miscommunication_dept]

Time to bump this topic again as two WOWS CCs have been talking about this, Gaishu and Biison.

Also, with Forrest Sherman release. its reload will be hugely effected.

 

 

The problem is that we only have certain reload numbers due to a server tickrate of 0.2857

 

This means reload can be multiples of this number so for example

1.143

1.429

1.714

 

Clearly this has little effect on most ships but destroyers and particularly fast reloading destroyers are hit hard by this bug

 

Smalland with reload mod, and bft has the same reload in game as  a Smalland with reload mod, bft, active fearless brawler and AR (1.43) until it reaches about 40% health. Then suddenly it becomes 1.143.

 

 

 

There is no benefit in between these figures.

 

@MrConway @YabbaCoe @Crysantos

 

Could someone address this issue?

 

Thank you.

[Miscommunication_dept]

This topic has a lot of background on this:

 

https://forum.worldofwarships.eu/topic/146627-småland-fire-rate-testing-dd-skills-dont-work-as-advertised/

[Panocek]

21 minutes ago, gopher31 said:

Could someone address this issue?

Its not really fixable unless WG overhauls server backend, probably both hardware and software to accommodate for increased server tick/refresh rate.

And that is one REEEwork they probably aren't interested in pulling off, as it would cost a lot of time and resources only to affect tiny portion of the ships and then only fraction of owners of these ships would be able to tell the difference... oh wait, I think I've seen this before?

[Hirohito]

5 hours ago, gopher31 said:

Time to bump this topic again as two WOWS CCs have been talking about this, Gaishu and Biison.

Also, with Forrest Sherman release. its reload will be hugely effected.

 

 

The problem is that we only have certain reload numbers due to a server tickrate of 0.2857

 

This means reload can be multiples of this number so for example

1.143

1.429

1.714

 

Clearly this has little effect on most ships but destroyers and particularly fast reloading destroyers are hit hard by this bug

 

Smalland with reload mod, and bft has the same reload in game as  a Smalland with reload mod, bft, active fearless brawler and AR (1.43) until it reaches about 40% health. Then suddenly it becomes 1.143.

 

 

 

There is no benefit in between these figures.

 

@MrConway @YabbaCoe @Crysantos

 

Could someone address this issue?

 

Thank you.

Care to link these CC discussions, if they are available online?

 

@Gebe_ and I were the ones that tested this extensively in the other topic about this (linked above), and what was unclear back then was the server batch interval (or tick rate as you call it here).

Where did you/they get this numbers?

 

1,429s as a cutoff point sounds about right.

[ColorsOfRainbows]

I don't think it's easy fixable

[Altsak]

You can always rebalance gun fire rate and damage per shell to take account the server tick rate issue. Techincally you just need to tweak 2 different variables.

 

However it would stilll leave the modules and captain skills broken thus most likely wont be fixed because it's too costly.

[Yedwy]

38 minutes ago, gopher31 said:

Time to bump this topic again as two WOWS CCs have been talking about this, Gaishu and Biison.

Also, with Forrest Sherman release. its reload will be hugely effected.

 

 

The problem is that we only have certain reload numbers due to a server tickrate of 0.2857

 

This means reload can be multiples of this number so for example

1.143

1.429

1.714

 

Clearly this has little effect on most ships but destroyers and particularly fast reloading destroyers are hit hard by this bug

 

Smalland with reload mod, and bft has the same reload in game as  a Smalland with reload mod, bft, active fearless brawler and AR (1.43) until it reaches about 40% health. Then suddenly it becomes 1.143.

 

 

 

There is no benefit in between these figures.

 

@MrConway @YabbaCoe @Crysantos

 

Could someone address this issue?

 

Thank you.

Yep a well known issue, also one of the reasons I am not all that hot for sherman...

[Panocek]

1 minute ago, Altsak said:

You can always rebalance gun fire rate and damage per shell to take account the server tick rate issue. Techincally you just need to tweak 2 different variables.

 

Most likely would take at least a full days job so fixing the issue is too costly.

At the same time, trading reload for increased damage, while preserving "dpm" is always preferable in this game unless you go to the extremes like 1mil dmg but 19min reload, as its rather rare to just sit there and pew pew for any longer periods of time.

 

So in Forrest Sherman case, lowering reload down to 2s but with intent of keeping, lets say, her SAP dpm intact means increasing shell damage from 2700 to 3600, which is a net buff for her whenever you do "hit and run" around smoke or islands.

Then you have upgrades/skills which are entirely own can of worms on their own when it comes to matching reload with server tickrate.

 

Obviously, it could be WG galaxy-brain plan all along, as FS can reach 1.429s tickrate just with BFT and equip Range mod, while your average random will go hurr durr reload mod and have no effective dakka increase, while being bit shorter in range.

 

Same applies (in theory) for Friesland/Groningen with their 1.8s reload, with nearest tick is at 2s. BFT alone technically would allow reaching 1.714s breakpoint, rendering Reload mod bit useless unless stacking it with BFT and Fearless/AR for 1.429s.

 

Imagine having free captain respec and upgrade demount, so one could spend some quality time in Training Room 

[Miscommunication_dept]

I agree that the only fix is to alter shell damage and reload. of course, then we'd have destroyer damage per shell higher than many much larger cruiser shells.

I would like WG to at least confirm the issue to help more players understand and build accordingly.

[Panocek]

2 minutes ago, gopher31 said:

I agree that the only fix is to alter shell damage and reload. of course, then we'd have destroyer damage per shell higher than many much larger cruiser shells.

I would like WG to at least confirm the issue to help more players understand and build accordingly.

IJN 127mm HE dealing almost as much damage as average 152mm HE shell: first time?

German 128mm AP dealing similar damage as average 152mm AP shell: first time?

IJN 203mm HE dealing more damage than German 283mm HE: first time?

 

[Miscommunication_dept]

32 minutes ago, Hirohito said:

Care to link these discussions, if they are available online?

 

@Gebe_ and I were the ones that tested this extensively in the other topic about this (linked above), and what was unclear back then was the server batch interval (or tick rate as you call it here).

Where did you/they get this numbers?

 

1,429s as a cutoff point sounds about right.

echo_519 post here was my initial exposure to this issue.

 I tested it and found it to be exactly the case.

As far as I know, WG have not confirmed this refresh rate to be the case.

Though it is rumoured that it was mentioned in a discussion about AA but I have not found that reference

 

[Miscommunication_dept]

1 minute ago, Panocek said:

IJN 127mm HE dealing almost as much damage as average 152mm HE shell: first time?

German 128mm AP dealing similar damage as average 152mm AP shell: first time?

IJN 203mm HE dealing more damage than German 283mm HE: first time?

 

Lol, I thought I retained a lot of useless information about this game!  

 

Point taken though.

[Hirohito]

13 minutes ago, Panocek said:

Obviously, it could be WG galaxy-brain plan all along, as FS can reach 1.429s tickrate just with BFT and equip Range mod, while your average random will go hurr durr reload mod and have no effective dakka increase, while being bit shorter in range.

It's not just the average random that is unaware of this, it's pretty unknown information in general.
I personally stuck with BFT for Småland for a very long time after our testing, but even most unicums seemed to still build around AR and/or Fearless Brawler.

I only swapped to AR recently (obviously not FB) because of the added torp reload benefit, but BFT is still a viable option if you want maximum firepower for your first DD vs DD engagement right from the start.

[General_Alexus]

16 minutes ago, gopher31 said:

I agree that the only fix is to alter shell damage and reload. of course, then we'd have destroyer damage per shell higher than many much larger cruiser shells.

I would like WG to at least confirm the issue to help more players understand and build accordingly.

That is a bad way to fix it, as firechance and chance to break stuff is on a per hit basis. I rather have 2 shoots with 1750 dmg 8% firechance than one hit with 3500dmg and 9-10% fire.

[Miscommunication_dept]

Excellent google doc for those who are interested:

 

https://docs.google.com/spreadsheets/d/13tO83q8bkVppJXli2UG2qQMCrKeKN3q9uA7H1T3xXEQ/edit#gid=0

[Tanaka_15]

It is amazing how game based on shooting has broken shooting mechanic in so many ways. 

[Hirohito]

25 minutes ago, gopher31 said:

Excellent google doc for those who are interested:

 

https://docs.google.com/spreadsheets/d/13tO83q8bkVppJXli2UG2qQMCrKeKN3q9uA7H1T3xXEQ/edit#gid=0

Excellent stuff, saves me the work of making one myself!

That being said, like any hypothesis, this will need some extensive live testing to check whether actual reload values behave as predicted.
If anyone is willing to test this on their ship(s), my advice is that you test with both sequential fire and rapid fire (rapid clicking of the fire button).
This because our testing last year showed that the mode of fire in relation to server batch windows, can affect your effective dpm by quite a lot when choosing one option over the other.
My own testing for instance showed that Småland benefits from sequential fire (holding the mouse button) and usually did worse with rapid fire (clicking), whereas the opposite was true for Daring (Daring gains a few shots if you click fast enough).

This is possibly due to sequential fire using the client side reload value to decide when to send a "fire" command back to the server (it only auto sends a fire command once your client shows your reload to be complete), whereas with rapid fire you can send a "fire" command to the server (where your reload is complete), even though the client side still shows your guns to be on reload.

[Hugh_Ruka]

25 minutes ago, Hirohito said:

Excellent stuff, saves me the work of making one myself!

That being said, like any hypothesis, this will need some extensive live testing to check whether actual reload values behave as predicted.
If anyone is willing to test this on their ship(s), my advice is that you test with both sequential fire and rapid fire (rapid clicking of the fire button).
This because our testing last year showed that the mode of fire in relation to server batch windows, can affect your effective dpm by quite a lot when choosing one option over the other.
My own testing for instance showed that Småland benefits from sequential fire (holding the mouse button) and usually did worse with rapid fire (clicking), whereas the opposite was true for Daring (Daring gains a few shots if you click fast enough).

This is possibly due to sequential fire using the client side reload value to decide when to send a "fire" command back to the server (it only auto sends a fire command once your client shows your reload to be complete), whereas with rapid fire you can send a "fire" command to the server (where your reload is complete), even though the client side still shows your guns to be on reload.

In theory there should be no difference in the sequential vs rapid unless turret delay > reload/number of turrets ... afaik the turret delay is constant (it was last adjusted for the Friesland IIRC because it ran into the same problem).

[Hirohito]

11 minutes ago, Hugh_Ruka said:

In theory there should be no difference in the sequential vs rapid unless turret delay > reload/number of turrets ... afaik the turret delay is constant (it was last adjusted for the Friesland IIRC because it ran into the same problem).

Yes but that is theory, and not what ends up actually happening (which is why we specifically tested this scenario).

A good candidate for explaining this is that, depending on how far above you are to the breakpoint of reload, and depending on your ping, several scenarios can happen:
1. You sequential fire your guns (holding the button), which causes the guns to issue a fire command only when your client registers that the guns are done reloading. If we assume 40ms ping, and adding 40ms on top of the 285ms breakpoint puts you into a "worse" breakpoint, you end up firing 285ms later than what you would have.

 

2. You rapid fire your guns (clicking the button rapidly), which causes the guns to issue a fire command when you click the button. If your guns are actually off cooldown (according to the server), you fire those guns 40ms "earlier" when you click the button, even if your client still claims that you have some 40ms left on the reload. If these 40ms "saved" get you into an earlier breakpoint, you end up firing your guns 285ms faster than you would have with sequential fire.
However, clicking the button induces a ms delay of its own (you will always spend some fraction of a second in between clicks). If your first click issues a fire command when the server still sees your guns as reloading, it will not fire. When you click your guns some (just an example) 50ms later, those 50ms might in some cases miss the window for the 285ms breakpoint, thus causing you to fire 285ms later because you clicked.

[Hirohito]

3 hours ago, gopher31 said:

Also, with Forrest Sherman release. its reload will be hugely effected.

Interestingly enough, if the breakpoints are correct, you could see a situation where Forrest Sherman has significantly lower actual dpm compared to Småland, at least for HE shells.
This because, and assuming they both hit the same breakpoint, 3x shells at 1800 HE dmg (FS) is significantly worse than 4x shells at 1750 HE dmg (Småland), when they fire at the same intervals anyway.

[Panocek]

25 minutes ago, Hirohito said:

2. You rapid fire your guns (clicking the button rapidly), which causes the guns to issue a fire command when you click the button. If your guns are actually off cooldown (according to the server), you fire those guns 40ms "earlier" when you click the button, even if your client still claims that you have some 40ms left on the reload. If these 40ms "saved" get you into an earlier breakpoint, you end up firing your guns 285ms faster than you would have with sequential fire.
However, clicking the button induces a ms delay of its own (you will always spend some fraction of a second in between clicks). If your first click issues a fire command when the server still sees your guns as reloading, it will not fire. When you click your guns some (just an example) 50ms later, those 50ms might in some cases miss the window for the 285ms breakpoint, thus causing you to fire 285ms later because you clicked.

For that you might want to use macro, to remove "human error" from the equation. Something like "repeat LMB press every 0.1s" should do?

 

1 hour ago, Tanaka_15 said:

It is amazing how game based on shooting has broken shooting mechanic in so many ways. 

Well, this become an actual issue with indroduction of Friesland and other extremely fast reloading guns. For your average BB or cruiser, its nigh irrelevant feature.

[Hirohito]

14 minutes ago, Panocek said:

For that you might want to use macro, to remove "human error" from the equation. Something like "repeat LMB press every 0.1s" should do?

We discussed that in the previous topic, but someone warned that this might constitute a violation so do this at your own risk.
A very rapid firing mouse (or software) would be ideal to minimize any "artificial ms" that rapid clicking by human efforts would cause (fluctuating and generally higher ms values than what automation would produce).

If this hypothesis is correct, you'd ideally want a rapid firing mouse that fires a lot faster than 0,1s though (100ms), about 0,01s would be great (10ms) as that will reduce the window of missing a batch that reduces your fire rate with 285ms (assuming 285ms as the breakpoint is correct).
This would then always be the preferred way of firing DD guns, as you'd either reduce your chance of missing a breakpoint (if you click your guns manually), or in the case of sequential fire, allowing you to qualify for an earlier breakpoint which your natural ping would prevent in reality.

For slower firing guns than 4s, I'd say the practical value becomes exponentially lower though.
The true value lies for guns that fire between 1-3s.

[thiextar]

@YabbaCoe @MrConway@Crysantos

There's actually a really simple fix for this that won't force you to increase tick rate or rebuild your server code. 

 

When a shell gets delayed by waiting for a server tick, simply subtract the next reload time by that delay, this will cause the guns to reload faster the next Salvo, thus making them hit an earlier server tick. When using this extra time, the guns should only use up the portion of the extra time that was needed to get it to the earlier tick

 

Over time, this system will actively average out to the expected rate of fire

[Panocek]

1 minute ago, Hirohito said:

We discussed that in the previous topic, but someone warned that this might constitute a violation so do this at your own risk.
A very rapid firing mouse (or software) would be ideal to minimize any "articial ms" that rapid clicking by human efforts would cause (fluctuating and generally higher ms values than what automation would produce).

Wargaming can also yeet your account for any reason or no reason so ¯\_(ツ)_/¯

 

@YabbaCoe to clarify 5.07 from EULA:

Macros or mouse/keyboard features that enable actions such as "press Left Mouse Button every x seconds" don't violate this point?

[thiextar]

Time to write some autohotkey to spam lmb when holding down lmb while warships is running