Actual skill issue not to realize the lack of energy performance due to changed thrust and weight of su30.
+Fun Fact: 1,2,3,4,5,6,7,8 but not 1,2,3,4,5,6,10,12
Actual skill issue not to realize the lack of energy performance due to changed thrust and weight of su30.
+Fun Fact: 1,2,3,4,5,6,7,8 but not 1,2,3,4,5,6,10,12
1.Okay, since you think I haven’t modeled the current MM rules, then there is no model. I don’t know what model you want specifically. If you can tell me in detail, I may be able to continue my experiment. But now I don’t seem to know what to use to make you feel reasonable.
2.I know that the code is usually equipped with documents, but that is generally project/engineering code. If you think a script code still needs me to write a special document, you might as well throw it to ChatGPT to explain it to you. It speaks better English and uses programming terms more accurately than me. But for your convenience, I will add detailed code descriptions.
4.I’m sorry that sometimes I can’t express what I mean completely accurately, or understand what you mean, because my English is not very good, please allow me to explain it to you again:
There are two types of waiting time, the player’s waiting time and the game’s waiting time.
The max/min match time refers to the maximum time it takes for a group of games to be generated, starting from the first player entering the matching queue until the last player enters the matching queue, and then the game starts.
After that, according to your request, I also tested the player waiting time, namely Max/Min Wait Time. This indicator represents who has the longest/shortest waiting time among all the players in this lobby when it is established, and how long they waited. The Average Max/Min Wait Time is the average value of 10 battles.
Your “proof” is valid. But it is not sound at all. Meaning, the conclusion follows naturally from the premises. However, your premise (that player joins every 0.01 seconds) in the first place is massively incorrect. The proof didn’t use real data on matchmaking time.
0.01 seconds is extremely low time for even top tier. Consider that if you used a ±0.7 BR matchmaker, the entire BR system would expand massively. You might have forgotten the influence of less popular servers, less popular battle ratings, and less popular times of day to play. Most importantly: players will leave matchmaking when it takes too long, and less players will play the game at all if matchmaking takes too long.
This is like saying “My new product will work because 1 person will buy it every second, and we’ll be rich!”, while in reality, 1 person buys it every day at most, and you go bankrupt.
The only thing that you “proved” is “if you have 10 apples, and you eat 2 every minute, you will take 5 minutes to eat all the apples. Meanwhile, if you eat 1 every minute, it will take 10 minutes”.
Slow decompression is the way to go, not this “0.7 BR spread” nonsense.
This post was flagged by the community and is temporarily hidden.
0.01 seconds is just a simulation, and then through my program, I found that the matching time and waiting time of ±1.0 and ±0.7 are not much different (see other replies for details, only increased by 10%). I use 0.01 seconds just as an example, just trying to prove that it is not much different from the time taken by the current ±1.0 matcher. Regardless of whether it actually takes 0.1s, 1s, or 10s, the time variation caused by a smaller matcher is acceptable.
If we don’t consider the matching time issue for the moment, which one do you think can bring a fairer game: ±1.0, ±0.0, ±2.0 or others?
You said: if you used a ±0.7 BR matchmaker, the entire BR system would expand massively.
Please give an example.
In addition, if you are targeting my possible vulnerability in my simulation, there is no need to ridicule others, which is not friendly.
Did you forget the influence of less popular servers, less popular battle ratings, and less popular times of day to play?
I have been playing this game since 2014. At that time, the number of people in the game was very small, sometimes only a few thousand people online, or more than 10,000 people. At that time, We started using the 1.0 matchmaker. Now the number of people online every day is more than ten times that of the past. Isn’t this number enough to support a smaller matchmaker?
You’ve also forgotten: that players will leave matchmaking when it takes too long, and that less players will play the game at all if matchmaking takes too long.
I heard that many Chinese players are saying they are going to quit the game because gaijin treat their country’s vehicles unfairly, is this true? It seems that if the BR matchmaker changes, it will bring more anger to players than treating their country’s vehicles unfairly.
honestly, id like this, at least with a test or something
grinding for the f18a rn and fighting gripens, f18s, su27s and so on in my f4j is kinda painful
and also the f-14B facing eurofighters and rafales is a bit stupid
You sure? That looks IRIS-T and METEOR to me :P
nah those look more like 1000lb bombs and 2 rockets
Ok, I apologize for my offensive language.
In all seriousness, however, you vastly underestimate the matchmaking time in Air RB. The top rank matchmaking is actually the most popular of all BR; if you rely on your experience with the top battle rating, you will inevitably be wrong.
Secondly, the supposed 10% increase in matchmaking time is the ideal change, and not practically obtainable. The actual increase to waiting time will be much higher You must remember, even in Air RB mode, that matchmaking can take multiple minutes. This is especially apparent if you play on less popular servers (such as the SA server), or on less popular battle ratings (Super prop and early jet BRs come to mind), or on less popular times of day for the servers you play on. The combination of these factors has an exponential, rather than a multiplicative, effect on waiting time.
Players will naturally be frustrated with the long times of waiting and leave the queue. This is directly visible especially in Simulator battle rooms, where often 2 or more times the players required to start a match (which is 2 on both teams) join and leave the room after waiting for multiple minutes. Meanwhile, the match never starts because there were never enough players in the room at the same time. This effect also occurs in Air RB. In reality, the actual time increase from a 0.7 BR would be far in excess of 10%, likely multiple times the total wait time per player, due to this factor.
This is just the mathematical result. Right now, in Air RB, we have BR from 1.0 to 14.0.
If you decreased the BR spread of matches to 0.7, and kept the max BR of 14.0.
That would be the same as decompressing the max BR to 20.0 under the current 1.0 BR spread system.
I don’t think this is a problem. Because the simulation is not generating actual queue times but relative ones. All that is of interest (afaik), is % changes in queue times by changing the BR spread. For that, any abstract rate would do.
I thought this would be the case. It is a problem: You are having the classic survivor bias in your data. You are only measuring people who get matched.
My issues with your strategy are several:
You should create an array of say 10k players. These players are your actual sample. You run the program and enter these 10k players. For each of the 10k players, you record the time of wait. You terminate the run only, when all these 10k players have been matched. So you need to enter more players to keep the program running, but you keep running until the last of your 10k people are matched.
The game has lots of squads, which have to be balanced. So you need not only balance players but groups of players. That is done by the real matchmaker too. So you would need arrays for squads of size 2, 3 and 4. They have the BR of the highest plane in the squad. You have to match those along. You could get estimates for their numbers by counting out scoreboards.
There are groups of planes with uncommon BR. Create one or two such group in the middle and the end the the BR scale. See what they do.
Make sure, any match only contains 0-4 top BR people.
Before you ask such a question, you should define what you mean by fair. I personally do not think that for most BRs, fairness depend on the current ±1 BR spread. Connection, crews, modules, controller, GPU and screen add way more fairness issues than BR.
Also, I wouldn’t want a ±0 BR spread. That would be boring as hell to me in air RB.
Lastly, this is a game, not a field of science. While it may be fun to toy around with data, the revenue for spend time on game research is vastly inferior to that in the real world… ;-)
The important part is that the matchmaker is like a business. Somewhat. In a business, if the rate at which people buy your products is too low, you will go bankrupt. In the matchmaker, if the rate at which people join the matchmaker is too low, they will get frustrated and leave. This effect gets worse the longer waiting times get, so time to start a match actually increases exponentially as the rate at which people join the matchmaker goes down.
I did read the entire post. It is just theoretical proof with little relevance to the reality of the situation.
In reference to BR decompression, I often see people with radical viewpoints, who advocate for massive BR decompression. Their experience is, by all likelihood, on the most popular modes, on the most popular servers, on the most popular battle ratings, etc. To them I bring up the fact that Gaijin has the data on queue time, and that they do not. In principle, it’s incorrect to believe so firmly in an argument, when not only the theoretical foundation is incorrect, but also, there is no data presented in favour of it.
In fact, I have never seen any use of actual queue time data from any proponent of massive decompression.
You haven’t presented queue time data to support your argument either. You’re merely assuming.
The truth is Gaijin’s current model is with a purpose. They’ve seemingly determined that the current state of the BR system brings in the most player engagement and profits, even if it’s at the cost of the user experience.
If the one reason for them not to make the consideration for massive decompression is queue times then why are they so insistent on 16v16? Surely smaller matches would make for lower queue times even in the most unpopulated server at the most unpopulated BR, no?
In reality, the actual time increase from a 0.7 BR would be far in excess of 10%, likely multiple times the total wait time per player, due to this factor.
In fact, we should not arbitrarily guess the specific multiples of the matching time, because the time complexity of matching a game is O(mn), so in fact it should really be a multiplication relationship. If Gaijin can’t write a matching algorithm with a lower time complexity, I suggest that they recruit some more professional talents. Instead of some embarrassing Game Designers.
6.I understand the example you gave, and I can’t judge its rationality for the time being. But to be honest, even if the maximum BR is expanded to 20.0, it is acceptable to me. Because in addition to the toptier, there is another BR range that needs to be paid attention to, which is 8.0-10.0, and the BR compression in this part is still very serious.
The important part is that the matchmaker is like a business. Somewhat. In a business, if the rate at which people buy your products is too low, you will go bankrupt. In the matchmaker, if the rate at which people join the matchmaker is too low, they will get frustrated and leave. This effect gets worse the longer waiting times get, so time to start a match actually increases exponentially as the rate at which people join the matchmaker goes down.
I don’t disagree with you, it just isn’t the issue. Your initial complaint was the arbitrary choice of time. And it doesn’t matter if he uses 0.01 or 10. It could be 0.01 hours or 10 seconds. Change of relative outcome matters.
Average Max Wait Time for All Battles: 0.93 s
Average Max Wait Time for All Battles: 1.24 s
means an increase of 33%.
In fact, the perfect agreement with 4/3 makes me suspicious that he is basically measuring a relation between his input parameters.
What you want, is to add a new function to my 10k list, namely a chance for “player aborts game”.
You haven’t presented queue time data to support your argument either. You’re merely assuming.
The burden of proof is on the person making the claim in the first place, not the person questioning it.
If the one reason for them not to make the consideration for massive decompression is queue times then why are they so insistent on 16v16?
16v16 is better for gameplay in multiple ways. It allows enough players for strategizing, it makes less “meta” aircraft playable, it balances vehicles simply by the higher match size, etc, etc.
It’s sad that you oppose everything you see on the forum.
I’ll keep supporting most of what I see on the forum as most things are great ideas.
@COMBINE
Yes, I am indeed famous for agreeing with most people and supporting them.
Just as you’re arguing against the entirety of the War Thunder playerbase with this topic I’m defending the War Thunder playerbase’s pro-decompression stance from this topic’s pro-compression argument.
War Thunder needs decompression, not the compression you’re arguing for.
And yes, compressing the matchmaker is by definition BR compression, just the other form not as talked about.
The burden of proof is on the person making the claim in the first place, not the person questioning it.
OP’s proof is his own experience in which queue times are extremely short. And still even if your queue times are 10 minutes according to his data they’d become 13.5 minutes. Would you rather wait an extra few minute for a more balanced an enjoyable match? Even if you wouldn’t, the vast majority of players would agree to such an exchange.
16v16 is better for gameplay in multiple ways.
I can not put into words how much I disagree with you…
And still even if your queue times are 10 minutes according to his data they’d become 11 minutes.
I make 13min20s out of his data.
Unless he happens to be located here since the start:
Remaining aircraft in queue: 39