Some more info would be nice.
Which values are known so we can work with them?
Are the values in the table you posted known and usable?
What exactly is the mathematical function for, determining the VR after a race when x is your current VR? Or is the function for determining the VR-add column out of the delta values?
Also, why start with x := 20000 - first_column when that column has negative values up to ~10000, because that would result in x going from 10000 to 30000.

Well, thats what we want to find out.

EDIT: The function will give us the relative value - vr_add.

The values Wiimm posted are exact values - if the first player has 10 and the second player 9980 9990 points, the first player will get +112 if he wins.

Edit by Wiimm

Second player has 9990 and the difference is 9980.

How would you set up a mathematical function if you don't know neither the inputs nor the expected output? What is the function for? What do you want to do with the result?

I just think it would be good to know which values can be used as inputs/variables.

If it's just about calculating the VR after a race, you should use if-cases because you already have the table with the exact values, as you said.

The Input is the difference between the player's points - all those values in the first column.
The Output is the VR count a player will get / loose - all those values in the second column.

So, we can tell you that you'll get +112 Points when winning against a player who has 9980 points more than you.
And we can tell you that you'll get +44 Points when winning agains a player who has 4000 points more than you.

But what if the player has 4637 (or any other VR count we do not have in the table)?

We "just" need to create a function like "f(delta) = vr_add" for all those values in the table.

Ok, now that's understandable. You didn't mention at all that vr_add is what you want to be the result of the function and also that the posted values are just examples because it looked like this would be an exact list of steps, as if you'd get 112 points for every delta value between -9980 and -8001, then 92 for -8000 to -6001 and so on.

Thanks.

Just to add this:
- the equation is definitely not linear, but exponential (x^2)
- the maximum of 112 is definitely already reached far earlier than at x=-9980, probably even before x=-9500 so you shouldn't use that value in particular to create or test an equation; so 112 is probably the limit and even if your result at x=-9980 is higher than 112, your equation (in case you come up with one) isn't necessarily wrong but it would be cut down to 112
- the minimum of 0 however is possibly rounded down as x=8000 will possibly (but not definitely) be still >0
- for x=0 your result must be in between 19 and 6, most probably between 14 and 12

Also the graphic that underlines some of my statements above, I just put the known values into the coordinate system and connected the dots with different colors so you can see how the graph isn't linear and also is most possibly capped at 112.

Yes, I can confirm that there is a cap of 112. Even if there is a player who is hacking over 20,000 more VR in the room, they cannot give anymore than 112 points. Similarly, you cannot lose more than 112 points to any given player.

That means that the theoretical maximum possible gain for one race for a player is +1232 VR, if you beat 11 players that much higher in rank than you. Similarly, you could lose 1232 VR for losing to that amount of players with significantly lower VR. That was something I meant to prove was correct ages ago, but never got around to doing it.

Oh, also, the amount of VR gained for beating someone who has the same VR (delta +/-0) as you is 13. I might go hunting for the function that calculates VR at some point!

I don't know what you need it for, and the equation I got is by far not pretty, but its calculated output matches the data provided (rounded to the nearest integer):

It would be very nice to get some more points/steps added above, especially a few more around 6000 to 8000 so we can see where exactly it turns to 0 points and also around -9980 to -8000 so we can see where exactly the cap of 112 is reached, given there is such a cap (which you could find out then?).

Also, it would be helpful to have atleast one "range" to work with, that means to know a range from delta_A to delta_B where you get X points (e.g. from 1776 to 2992 you get 6 points). That way we could probably get a much better result.


But one main problem I have is the question: does the equation really need to give us "0" as a result for everything x>=8000 or could it be that for x=8000 it is 0 or even 0.49 but gets rounded down? And that for everything x>8000 the result is ignored and vr_add is just set to 0?

Also, Nintendo might use different functions for delta>0 and delta<0, but that's all just a guess. It might be a lot easier to create mathematical functions for both separated cases though.

The result of the function probably has to be rounded to get the value.

I won't have any time before next week because I am visiting my parents over the long weekend. My Wii and everything is in my new own flat though and still not set up - as soon as I'm done with that, I'll also participate in some more gaming sessions again and would be ready for some tests aswell.

I'm sorry that I can't help out earlier.

Too bad we dont have VR Search

Im pretty sure in regular worldwides on wiimmfi the matchmaking just ignores VR and puts you in any room it can find, right?

What if we implement what CTGP-R does? Make the game consider VR when you start searching opponents, then ignore the VR Rating after 35/60 seconds of searching.

The matchmaking doesn't ignore VR. It takes into consideration both the stability of the available rooms and the VR. If you have 9000 VR and there is one stable room with 9000VR and one stable room with 4000 VR you get placed into the one with 9000 VR.
However, most of the time, the 9000-VR-room isn't stable because 5 people have already joined in the last minute ...

The reason why all this was working way better on the official servers was because there were way more WW rooms available and the joining players automatically spread out over mutiple of them, instead of all trying to cram into one.

And what CTGP is doing isn't that much better. It tries to consider VR at the beginning, then Wiimmfi doesn't allow them into the high-VR-room because it is unstable, then you have multiple clients searching, all disabling VR at roughly the same time, who then crash the small-VR-room (because they all enter simultaneously). Had these clients not had that 60 second waiting and ignored VR entirely, the server would have placed them into the the low VR room at different times (due to the high VR room being unstable), then they wouldn't have crashed the small VR room as well...

Is the first bullet on this part of the wiki page inaccurate then?

I thought for the longest time that VR was not considered at all during matchmaking since like late 2015 (I heard it got disabled). How long has it been stability --> VR as the priority list?

If stability is a primary concern, might I suggest making OPENHOST exclusive to private rooms or have Worldwides use White List only? WFC did not have that feature either and, among there also being a lot more players, I feel like being only able to get in from the friends list made the joining process a lot slower. This suggestion is only if there is statistical evidence of a large % of rooms crashing from people joining via OPENHOST. If there is not any evidence then I take that suggestion back.

Also I heard there were plans for a Smart Suspend feature that works globally and not just for CTGP. Are there any updates on that?

Also was there anything that happened March 2016 aside from the log below? There was more stability before then and several players noticed it.

March 2016

SAKE & RACE:The SAKE and RACE servers was started and improved in many steps. Both manage ranking lists, ghosts and other objects, that are exchanged by the games.

Even with the flaws of CTWWs algorithm, the rooms there are 10x more balanced than in regular WWs

CTGP's current vr searching algorithm is a significant improvement from before, as evidenced by all the rooms that are decently balanced. You'll see plenty of rooms on ctww where the overall range is only a couple thousand and it sustain that for the most part for several hours, only being interrupted by joins from the friend roster (which is fine because that means it was your choice to join the room) and the 80 second time limit.

The whole "vr search isn't good enough" is coming from the fact that there is fluidity with it (even despite ctgp's ability to block players for a minimum of 80 seconds). As a result, some rooms do succumb to a heavy amount of undesirable mix. Some complaints are from stubborn people who want to have nothing to do with players on the opposite side of their skill spectrum as well as from people who just want a strict vr search so they grind to their precious 9999. Most complaints seem to be with caring intentions, however. A lot of people wanting vr search to be better want one of two things:

1.) Brick walled. Zero fluidity. If you can't join, oh well (not a reasonable option at this state unless activity surges greatly).
2.) You can only join rooms outside your vr range as a literal last resort.

What could be improved on is rather than waiting just 80 seconds, it won't let you into a room outside your range unless there is no other option available. For example:

-If you are at 9500, one room is available, you can join with an 8800 host, it's not full, but it's locked because of a bad connection, smart suspend, or the room is voting, and another room has, say a 5700 host, it won't let you join the 5700 host unless the 8800 room becomes full, ceases to exist, or changes host so that the 9500 can join. Even if it takes more than 80 seconds and gets smart suspended to all hell.

Another option could be so vr search toggles on and off automatically for an individual/everyone depending on if anyone between whatever the minimum vr you guys generally see online (like 3000. 3500.4000. Not sure exactly. And that's legitimate of course, so no 1000 drainer trying to sneak their way on unless they join through a friend) and 9999. This basically boils down to the example I discussed above.

Maidvelia has a poll with hundreds of votes, and it shows with heavy statistical significance that vr search is what the community overall wants. They also want it to be more strict than 2000 away from the host (like 1500 instead). So improving it further should make them happier. A more strict search would probably result in a lot of smaller rooms at first.If it's what the community wants, and it being too lenient is holding players back, then these rooms would become larger in size quickly with a larger number of rooms going on.

I'd imagine Bean could make the fluidity more strict like I mentioned above, depending on if he's up to doing it or if he's too tired of all the headache inducing complaints he still probably gets. It'd be a matter if this could be implemented for anything outside of ctgp.

With ctgp, vr search is ignored after 80 seconds. The idea is to make it so it only ignores vr search if there is no other room for that person join under all possible circumstances, even if they have to wait more than 80 seconds. A lot of people would be willing to wait the extra time to join a room that is balanced rank wise. At least from the perspective of people who rank 8k and above.