At high-ranks it's hard to find a player who doesn't use a drone. After years of batteries being available through missions and increased crystals gains I wouldn't really consider drones any more P2W than turrets or hulls.

Yes . . . M0 and M1 skins were very ugly. Certainly wouldn't be happy pulling one of them from a container.

Don't want garbage in ultra containers.

"Supply power" refers to how great a boost in damage, protection, or speed DD, DA, or SB offer, respectively. In their current form, some drones can increase supply power. A fully upgraded Defender, for example, increases DA power by an additional 100% - that is, it doubles the amount of protection double armour offers. But not all drones increase supply power, nor do all drones consume supplies. Currently, all drones passively increase the HP and damage of a tank by 5%. The only exception is Brutus, which increases them by 10%. The plan is to do away with this passive buff, reduce the power of supplies by default, and have drones passively increase supply power to the levels they are at now. For example, without any other modifiers, DD will increase damage by 1.5x and not by 2x as it does now. Similarly, DA might decrease incoming damage by only 25% instead of 50%. But with a fully upgraded drone, DD will deal, say, 1.75x damage, and DA will decrease damage by 38%. A fully upgraded Brutus would allow for 2x damage with DD and 50% protection with DA, and will not consume batteries. Other drones will consume batteries, though.

Do you consider stock Vulcan + Heat Immunity OP?

Hm, so EMP Gauss is not OP because EMP Immunity exists, but IB is OP . . . even though Heat Immunity exists?

Glad that TO is making a foray into some more interesting and complex mechanics with Tesla.

This makes the decision to downgrade HTML5's environmental graphics all the more puzzling.

It seems that every augment yellowghetto uses is trash. I imagine that when he gets his hands on all the augments in the game, all of them will be equally trash, and thus perfect game balance will be achieved. Who wants to donate some money to the yellowghetto ultra container fund?

Striker Ultra looks to be the best-looking skin released all year so far. Drone changes(?) seem interesting. Changes to PRO battles will most likely only affect XP/BP. I predict that everyone will be given Round Stabilization automatically.

I think this is a great idea. Projectile speed penalty can be reduced or removed to compensate. HI users would benefit, if anything, since there will be no need to overheat.

@Akame intensifies

A while ago I suggested that instead of applying afterburn to enemy tanks, Incendiary Band should apply whatever negative status effects the Vulcan user is under the effect of. For example, if the Vulcan is on fire, IB would apply afterburn to targets. If the Vulcan is under AP, then IB would apply AP to targets. And so on, for every status effect. Equipping a hull immunity would prevent an IB player from applying the status effect that that immunity protects against, but would still allow for applying other ones. So IB + HI would not apply afterburn to targets, but could apply freezing, AP, or EMP if the user was frozen, AP-ed, or EMP-ed. While this would make IB a fairly situational augment in the current meta, I think it could become more useful in the future when more status effect augments and status effects will likely be added.

So TheRealHZFJ pointed out that dust caused major FPS drops. I did some profiling and well . . . I'll let the results speak for themselves. As you can see the time spent in the createDust function is absolutely absurd. In a "normal" 16.7ms frame, 7.07ms are dedicated to dust. That's more than 40%! By comparison, the entire rendering process takes only 3-4ms! In an "abnormal" 53.1ms frame, 40.94ms are spent in various dust related functions. That's 77% of the entire frame. It is dust that causes a drop to less than 20 FPS. What. The. Heck. For comparison, here's a frame without dust processing: I would really love some feedback from the developers regarding performance. Is there anything being done to address it? Am I the only one who notices these problems? Why is DUST so performance intensive? What is going on??? ???

pls no

Thanks for the explanation; I suspected this was what you meant but wasn't sure. But while poor synchronization may certainly contribute to stutters, I really don't think it is the main issue. My problem is basically this: FPS GPU Usage Image Quality Capped, empty match 60 Low Smooth Capped, full match 40-60 Very low Stuttery Uncapped, empty match 350+ High Very smooth Uncapped, full match 70-100 Low Stuttery The GPU is being underutilized in full matches. I do not think the current game runs on Unity. And if I remember correctly at some point HTML5 had very similar physics to Flash; then they were changed at some point for some reason, probably intentionally.

All Smoky augments except for Supercumulative Rounds, Paralyzing Rounds, Assault Rounds, and Sorted Ammunition have the same critical chance parameters as stock.

These are Shards. You can redeem 100 shards for a standard container.

?

Smoky's critical chance is not fixed, and varies with each shot*. The chance that a given shot will deal critical damage depends on three parameters: minimum critical chance, critical chance step, and maximum critical chance. The numbers you listed refer only to the maximum critical chance. I won't go into the details of how critical chance accumulation works, but you can find a decent explanation here: https://en.tankiwiki.com/Critical_Damage#Explanation_of_probability_accumulation As for what these numbers mean in practice, the average critical hit rates for Stock, Supercumlative Rounds, and Paralyzing Rounds are as follows: Mk1 Smoky would score a critical hit every 8-9 shots on average, while Mk7+ Smoky would score a critical hit every 4-5 shots on average. * Technically, critical chance mechanics are the same for all turrets, but some turrets use parameters that effectively give them a fixed critical chance.

I hope this means all Hoppers are banished into outer space and never allowed to return.

I'm not sure what you are trying to say. What makes uncapped 400 fine but uncapped 100 jittery? And regardless of whether 400 is better than 100, this doesn't explain why there is such a massive drop in FPS and GPU usage between matches with no players and matches with players. Anyway I don't think the problem is with synchronization. I did a bit of quick profiling on the application when the framerate is capped to 60. On the top is FPS in a match with no players, while on the bottom is FPS in a match with 20+ players. The map, the route that I took on the map, and the graphics settings are all the same. As you can see, FPS in an empty match is quite stable. But in the match with players, there are many significant drops in FPS - often to 30 or below! These drops are responsible for frequent and annoying stutters. Now let's take a look at what I'd consider a "normal" frame. It rendered in 16.2 ms, which is about 60 FPS. There was even some time left over during which nothing was done. Note that the first 3/4 of the frame were dedicated to performing physics and game logic calculations (and something to do with particles, apparently), while the last 1/4 was spent actually rendering. Now here is an "abnormal" frame, which took a whopping 96.2ms to render (about 10 FPS)! Note how the second part of the frame is quite similar to the first. But before it some gargantuan task is performed - processing some data buffer, creating some entity, creating some particles - which slows everything down. This is not unique to this frame. I looked at a number of other frames which were rendered abnormally slowly, and a similar process took place in them as well. I'm not sure what exactly goes on here - I'll do more thorough investigations later. But I hope it should be clear now that this is a software problem, not a hardware problem.

It would be more efficient to have an entire team of Titans.

The juggernaut gets 20 seconds of near-invincibility under Titan's dome, so being healed by an easy-to-destroy Isida Hornet for seven seconds doesn't seem like that big of a deal.

I'm glad uncapping FPS solved the problem for you, but it hasn't solved it for me. Yes, I have a 60Hz screen, and in theory 100 FPS should look smooth, but in practice, it looks no better than 40 because of constant stutters. 100 FPS in TO feels far worse than 60 FPS in other applications. Heck, 100 uncapped FPS in a match with 24 players feels worse than 60 capped FPS with zero players. It's frustrating because it's really hard to communicate this to someone else - they see the number and say, "hey, everything's fine" on paper but if you were to look at my screen in-person you'd quickly see that things are not fine. I suspect that the lack of smoothness is due to some frames being rendered much slower than others. The things is, the FPS counter just gives FPS averaged over a certain period. Suppose the counter records 100 FPS over one second. That could mean you had 100 FPS during that entire time interval, but it could also mean that you had 170 FPS for half a second, but 30 FPS for another half a second. 170 * 0.5 + 30 * 0.5 = 100. Sure, the counter shows 100 FPS, which is supposed to be good, but the truth is you are getting 30 FPS half of the time! The result is an extremely unsightly stuttery image. In fact I believe there was someone on the RU forum who profiled the TO application and found that this was indeed the case - most frames were rendered in the expected time, but some took much longer to render. So this brings me back to my original hypothesis - that the problem lies in the netcode. Here's a possible scenario: suppose that the user's system is capable of rendering a frame in 10ms (100 FPS) when working at 100% capacity. Suppose that of those 10ms, the CPU spends 5ms performing calculations and preparing 3d data for the GPU, and the GPU spends the remaining 5ms rendering the frame. Now suppose that every 250ms (four times per second), the server sends some information to the system, and the CPU spends 20ms processing that information. If the game runs on a single thread (or if at least rendering and networking code run on the same thread), then the system cannot render any frames for 25ms. Why? Because the GPU needs to wait for the CPU to finish processing the server information, which takes 20ms, and then wait another 5ms for the CPU to prepare 3d data. As a result, whenever the system receives information from the server, the frame rate drops from 100 down to 1s / 25ms = 40 FPS. That's a pretty big drop from 100! That drop only happens four times a second, but that's more than enough for the output to become choppy and uncomfortable. This explains all three of the problems that I detailed earlier. The number of players in a match makes a significant impact on FPS. More players -> more information from the server to process -> longer frame drops. GPU usage drops when player numbers increase, because the GPU effectively sits idle while it waits for the CPU to finish processing information from the server. The image is choppy despite high FPS. Frequent frame drops make the perceived FPS worse than the average FPS. For instance, 400 FPS 25% of the time + 20 FPS 75% of the time = 115 average FPS. But that number completely glosses over the fact that you actually get 20 FPS 75% of the time! As a result, you can see stutters even on a 60Hz screen. Solution? I don't know for certain; I'm not a developer. But I suspect that threads (or rather, the lack of) are a problem here. Ideally, rendering should run on a separate thread. The CPU can perform to perform game logic calculations or process information from the server on another thread, and thus the GPU will not have to wait for the CPU to finish those calculations and will be able to output frames while the CPU is doing all that other stuff. There will be fewer stutters, and player count won't affect performance as much. Now, my CPU is not exactly cutting-edge but it's no slouch either (i5-6300). I doubt that it gets hung up on processing information from the server to so great an extent. It is perhaps more likely that the problem is with receiving information from the server. For example, suppose five chunks of data are sent out from the server, and the system needs to receive all of them before rendering a frame. But for one reason or another, each chunk arrives one after the other with a 4ms delay in between. Even if the CPU can process that data instantly, there's still a 20ms period of nothing being done as the system waits for the data to come in. This would explain why some players with good hardware get a smooth image while others (like me) do not - they may have a better internet connection. Regardless, this problem could also be solved by threading. If an application is designed correctly, network latency should not have a significant effect on FPS. Maybe threads are not the problem here. But other multiplayer 3d applications work fine; TO is the only one that I have problems with despite its aged graphics and low system requirements (in TX I had similar issues by the way). Anyway, the issue is frustrating and trying to convince others that it is an actual problem is also frustrating.