1911 replies to this topic

[Shlkt]

Quote

Actually, your numbers can't be correct since if the matchmaker predicts a 51% chance of winning and a 49% chance of losing then this would result in a 51% or 49% * K factor change in Elo based on your example which is incorrect ... whereas in that case the change should be near zero.

My information about Elo comes directly from Wikipedia.

New Rating = Old Rating + K Factor * (Actual Score - Expected Score)

... where actual score is either 1 or 0 depending on whether you won. The expected score is a fraction representing your probability of winning. So if you lose when you had a 75% chance to win, we get:
New Rating = Old Rating + K Factor * (0.0 - 0.75) = your Elo is reduced by 75% of the K Factor

Your formula cannot be correct because it results in 0 rating change whenever the win probability is 50%. Everyone starts with the same Elo initially, and therefore none of the ratings would ever change.

[Goose]

Karl Berg, on 12 June 2014 - 09:18 PM, said:

… Fast main memory, and low latency if you can manage it; especially if we get that high-res 4k texture pack released. I think I run 8/8/8/24 at home, but it's been a few years since I specced the system.

I ever get back on Forrest, I may have something to share on this point …

[Goose]

Goose, on 19 November 2014 - 07:52 PM, said:

I ever get back on Forrest …

Seriously: We need a benchmarking tool.

No Forest yet, but I think I upped my minimum a few frames on Frozen; Mostly, the animations in MechLab are an order of magnitude smoother, and I think I gained some headroom for OBS …

Bechmarking tool would'a made this a whole lot easier.

[Karl Berg]

Mike Forst, on 19 October 2014 - 01:22 PM, said:

Hi Karl

Hi Mike, nice to see you've forst your way into this thread.

[Karl Berg]

Featherwood, on 09 October 2014 - 05:10 PM, said:

Greetings Mr. Berg,
this is kind of a kind reminder about one very small, but very well infused problem. Earlier, in May, you have mentioned that it will take some time to add user controllable variable related to cockpit lighting level:

Is five months sufficient for a single cvar to trickle into production <build>? Could you look into it one more time, if you please? Cheers!

By the way, this is done, but it's in the CommunityWarfare branches so you still have a few weeks waiting

gp_default_cockpit_light, following gameplay's naming convention. Takes a number which corresponds to the number of times you would have pressed the 'change light level' key. Apologies for the rough implementation; but doing anything nicer would have required some refactor.

Dimento Graven, on 19 October 2014 - 01:25 PM, said:

Too quiet charging and unclear visual indicators...

Hey Dimento, I'll forward your feedback.

Rogue Jedi, on 19 October 2014 - 02:29 PM, said:

Hi Karl,

I believe what he is referring to is that since the solo queue lance distribution was rearranged to fill lances based on weight class (an assault/heavy lance a heavy\medium lance, and a light/medium lance) we are occasionally seeing 4+ person teams not getting a full lance.

e.g. a 4 man group is now sometimes now split between 2 lances, and a 5 man can be split between all 3, this is not always happening but, several times recently, I have dropped as part of a 4+ person group to find us split between 2 or 3 lances without us completely filling a single lance

Hey Rogue,

The solo queue change *should* have had no impact on group queue lance assignment, but I'll review that code to make certain. Thanks for the clarification!

[Heffay]

Hi Karl!

[Karl Berg]

DarkonFullPower, on 19 October 2014 - 11:40 PM, said:

Well now that everything back in full swing here again I guess I'll get back to trying to get my question answered. It's gotta happen sooner or later.

Are empty ammo slots counted in the crit roll, or are they ignored?

Hi Darkon,

I believe Omid posted a diagram containing a visualization of the crit table system used in MWO, maybe even in response to your question. I'm not familiar with the crit system, so I can't give you an authoritative answer myself. Omid is definitely the fellow you want to ask about this though.

http://mwomercs.com/...age__tab__posts

[Karl Berg]

Ultimatum X, on 27 October 2014 - 04:54 PM, said:

Instead of full on separate Elo, I think a small modifier that could be from the design team's assessment of that mechs tier or (probably easier) a small modifier to the weight class Elo per mech, as opposed to it's own independent score.

That's all, great podcast it was fun hearing you speak on the MM.

That approach would certainly be technically possible, yes. It would end up being very similar to the group size modifiers we have in place currently for group queue.

There are a couple issues though that are enough to give me pause.

Firstly, I don't have a controlled baseline to data-mine relative mech strengths from. Preferably I'd have a few tens of thousands of matches where 12 locusts faced 12 spiders, a few tens of thousands of games of 12 locusts vs 12 hunchbacks, a few tens of thousands of games of 12 locusts vs 12 timberwolves, on so on for every mech type..

With this data, I would have high confidence that I could calculate meaningful bias values that accurately reflect the various advantages of each mech type. Without this data, I worry that we'd end up generating inaccurate bias values, or even worse, faking the data by using best guesses.

Coupled to this, mech effectiveness can change on designs whim. The IS quirk pass is an excellent example of this. Every time a mech is altered by design, we would need to recalculate its' Elo bias, and to recalculate its' Elo bias I need lots of data!

The Elo algorithm itself elegantly handles hidden variables like this already. It's mostly a matter of convergence time for tracking that many individual skill variables. I'll definitely give it some more thought though, as it seems there should be a clever way to take advantage of the huge datasets we're generating.

[Karl Berg]

Jman5, on 28 October 2014 - 01:08 PM, said:

When you run these weekend tournaments do you notice much movement or "upsets" in Elo and the prediction accuracy? I'm particularly curious about some of the high performers who have pretty high Elo. Most of them stick pretty hard to premade group queue. I would imagine that when many of these guys have to jump down into the solo queue for 100-200 matches it can disrupt Elo a bit.

Usually the swell in player count more than offsets any outliers generated by having more competitive players in the solo queue. With respect to the metrics we track at least, match quality, judged by Elo alone, usually shows marked improvement in solo queue.

I know that doesn't necessarily correspond to player experiences. Understanding where general player experience overlaps and/or breaks down with our current metrics is one of my biggest questions right now. Aggressively pursuing reduced standard deviation in games has certainly produced some interesting results.

Void Angel, on 30 October 2014 - 12:17 PM, said:

Hey, Karl, I see that the new quirks for the Locust include extra leg structure. This is a much-needed adjustment, but I have to offer an observation to preface my question on this topic:

Part of the problem with the Locust is that its legs are disproportionally weak for its size. Following a linear progression, the Locust ought to have 10 internal structure and 20 max armor - after all the Commando has 12/24, and the Spider has 14/28. However, the design team gave the Locust a mere 8/16 structure/armor - in essence a 20% reduction in leg durability. I don't believe this was a design decision on their part; they just imported the canon numbers from tabletop BattleTech.

This was a mistake; I won't bore you with the nuts and bolts, but the Locust (or any 20-ton or lighter 'mech) could easily reach speeds that gave it an extra +1 modifier to its target number to get hit. Because of the bell-curve nature of the 2D6 system, this made the Locust significantly harder to hit than heavier chassis, and thus the legs (and arms, for lower tonnages) were reduced. This relationship does not exist in MWO - the difficulty of hitting a fast-moving target is linear and dependent on the weapon you're using as well as the target's speed.

So! Finally my question is: Do you know if the design guys have identified this facet of the Locust's design problems, or is the same issue going to recur every time they release a 20-ton or lighter BattleMech?

Interesting No, I don't know. I will definitely forward this on to them though. Poor locust.

[Void Angel]

Hey, you're not dead!

I always assume people are dead when I haven't heard from them in a while. It saves me a fortune on Christmas cards.

Karl Berg, on 23 November 2014 - 01:53 PM, said:

Hi Mike, nice to see you've forst your way into this thread.

Also, I have word poisoning.

And thanks for the response!

[Karl Berg]

Rebas Kradd, on 31 October 2014 - 10:35 AM, said:

Karl, the other day I hit upon a community suggestion that I actually liked(!!!)...what about a 100% voluntary option where a solo queue player can create a 4-mech "dropship" with at least two different mech classes (doesn't need to be all four, or else most players would just get thrown in as a light) and allow the matchmaker to choose his mech when slotting him into a game? Kinda like players' current ability to ease wait times by leaving all game modes selected, but now applied to mech classes.

That's a very decent suggestion. We've floated similar ideas in the past, but ultimately haven't fully drawn up or scheduled anything for implementation due to the scope such a feature would have, and its' impact on other pending features. Once phase two work is completed, something similar to this might be put back on the table; but it would be weighed against Steam integration, NPE, PvE / coop, and the enormous set of backlogged UI and mechlab improvements.

shellashock, on 05 November 2014 - 02:05 PM, said:

Hey Karl, I know that this really isn't your field, but it would be nice to get an answer. Russ had said a long time ago (May 2013?, can't remember), that they were not happy with the Oxide's performance and they wanted to enhance it and he asked if the community wanted anything particular done to it (add energy hardpoint in the head, give it jumpjets, etc). Now that the quirk system is in and there are quite a few buffs for the Oxide, is this the enhancement Russ talked about or is there still going to be a pass done on the Oxide's hardpoints? The other people here probably can fill in any blanks I left here if they still have the post from Russ's comment on the Oxide. Nice work so far by the way PGI!

Hey shellashock; I'm not sure. I'll forward your question on to Russ.

[Karl Berg]

p4r4g0n, on 05 November 2014 - 09:11 PM, said:

Hi Karl,

It was previously stated that Host State Rewind is ineffective once latency hits 500ms. I have been working on the assumption that the 500ms limit applied only to the player's latency.

However, since I occasionally seem to need to lead some targets, I wonder if this limitation may be affected by the combination of both the target's and my own latency e.g. target 250ms latency, mine 330ms latency? (This is most clearly observable using lasers)

If not, there is no apparent technical reason from what I understand of how HSR works that would require leading a target. Is this just a visual discrepancy caused by the time lag between when I fire and the server notifies the client to indicate a hit i.e. reticle turns red / paper doll flashes?

Alternatively, is this an issue limited to lights and displaced hitboxes which has been an issue in the past?

Hi p4r4g0n,

The only latency taken into account for HSR is your ping. You, and everyone else in the game, is shooting against the server authoritative positions for everyone in the game. The latency of the player controlling the mech is compensated for through some clever trickery that effectively allows time to desync between simulations. If you're at all interested in the nitty gritty details, then I strongly direct you to read through some of the articles I've linked on this topic. Some of them are extremely approachable, and go into a great deal of detail on how these algorithms work.

Found my own post Rebas, you're an absolutely wonderful person for maintaining that front page index!

http://mwomercs.com/...59#entry3298059

Li Song, on 06 November 2014 - 09:03 AM, said:

Question about quirks and modules:

I noticed that the way the bonuses on the modules is specified in the files have changed from being straight additive to being a factor that's supposed to be multiplied in (like 1.12 for a 12% increase). This prompted the question of how the values are applied.

Example: Consider a mech with an AC/20, 10% bonus to ballistic cooldown and 10% bonus to AC/20 cooldown equipped with an AC/20 cooldown module and fast fire.

Will the correct cooldown value be:

(4 - 0.1*4 - 0.1*4)*0.88*0.95

or

(4 - 0.1*4 - 0.1*4 - 0.05*4)*0.88

or

(4 - 0.1*4 - 0.1*5 - 0.05*4 - 0.12*4)

or something entirely different?

Hi Li Song,

I'm going to forward this to Brian Buckton for you. He's been working deep in the guts of the quirk system for some time now, and is undoubtedly the most familiar with how it works.

[Karl Berg]

Goose, on 07 November 2014 - 08:20 AM, said:

Say, Karl: If you have found a constant Elo modifier for team size, shouldn't there also be one, or sixteen, for the leveled status of a 'Mech? "L'ill Johnny is holding out for Anchor Turn as his first basic …"

It has an effect, no doubt. Determining, with any accuracy, what that effective value should be has very similar issues to determining what the Elo handicaps should be on a mech per mech basis. A controlled data-set for data mining would have 12 mechs with no efficiencies always on one team, and then a few tens of thousands of games for each combination of unlocked efficiencies for all 12 of the opposing team. I would never want to outright guess at what a modifier should be, as IMO this would indicate we've made a serious misstep.

[Karl Berg]

Featherwood, on 09 November 2014 - 08:36 AM, said:

Greetings, mr. Berg,
recent patch has brought many cvars I used in my user.cfg locked. Most importantly those two:

r_DepthOfField
r_HDRGrainAmount
they set now to 1 and something between 0.1-1.0 for some reason. Do you know or could ask responsible engineers why it had been done? That is irritating! Please help us to roll back this change, I kindly ask you. At least you can hadlock them to

r_DepthOfField=0
r_HDRGrainAmount=0.0
to make all players equal in happiness of playing with clear sky. Cheers!

P.S. If you could be so kind to check why another cvar is locked to 0, I will be also grateful.
I used to run with g_skipIntro = 1 in my systemoverride.cfg, but now it is ignored and preset to 0, so I have to press ESC to skip all those stupid intros, and that is, well, stupid and boring. I would like to be able to choose it myself and do not waste my time on intros. Regards.

Hi Featherwood,

I'll ask around to see if anyone knows about this. There was a large scale pass done, many months ago, to lock down cvars whose usage could be considered cheating. My guess would be these cvars would have been changed then, potentially erroneously.

Grey Ghost, on 09 November 2014 - 10:16 AM, said:

Yes Mr Berg, they were unlocked in the April 29th 2014 patch, and locked out again sometime after without any mention. Screenshots and info at this link. http://mwomercs.com/...ks-not-working/

That's what I get for not reading ahead Thanks for the clarifications!

[Karl Berg]

Clint Steel, on 10 November 2014 - 10:11 AM, said:

Hi Karl, it has been said that ELO predicts whether a team is going to win or lose, and your ELO only changes if this prediction is wrong, is this correct? If so, then is it possible MM could be putting a player on the "losing team" many times in a row, and their ELO never will drop, since it was expected? If that is the case as well, then could there be a system that tries to put the player (or group of players) on an alternating "winning" or "losing" team?

The explanation is a decent one for gaining some insight into how Elo converges. Specifics wise though, no, your Elo is changing after almost every game except for some fairly exceptional cases.

The only conditions under which your Elo would not change at all:
- Your Elo is 0 and you've lost
- Your Elo is 2800 and you've won
- The matchmaker predicted an outcome with effectively 100% certainty, and that prediction was correct (this only happens due to numerical quantization, as we store Elo values as integers rather than infinite precision floating point values)
- Some form of communication failure to the persistent storage mechanism, preventing the newly calculated value from being stored

[Karl Berg]

Shlkt, on 14 November 2014 - 12:11 PM, said:

My information about Elo comes directly from Wikipedia.

New Rating = Old Rating + K Factor * (Actual Score - Expected Score)

... where actual score is either 1 or 0 depending on whether you won. The expected score is a fraction representing your probability of winning. So if you lose when you had a 75% chance to win, we get:
New Rating = Old Rating + K Factor * (0.0 - 0.75) = your Elo is reduced by 75% of the K Factor

Your formula cannot be correct because it results in 0 rating change whenever the win probability is 50%. Everyone starts with the same Elo initially, and therefore none of the ratings would ever change.

I can confirm that this is the adjustment formula we use when calculating new Elos after a match. A match with a 50% predicted outcome still moves participants by half the k-factor.

Heffay, on 23 November 2014 - 02:04 PM, said:

Hi Karl!

Hello!

[Karl Berg]

Void Angel, on 23 November 2014 - 02:39 PM, said:

Hey, you're not dead!

I always assume people are dead when I haven't heard from them in a while. It saves me a fortune on Christmas cards.

Also, I have word poisoning.

And thanks for the response!

Nope, not dead yet. Hopefully I have a few years left at least.

[p4r4g0n]

Karl Berg, on 23 November 2014 - 03:17 PM, said:

Hi p4r4g0n,

The only latency taken into account for HSR is your ping. You, and everyone else in the game, is shooting against the server authoritative positions for everyone in the game. The latency of the player controlling the mech is compensated for through some clever trickery that effectively allows time to desync between simulations. If you're at all interested in the nitty gritty details, then I strongly direct you to read through some of the articles I've linked on this topic. Some of them are extremely approachable, and go into a great deal of detail on how these algorithms work.

Found my own post Rebas, you're an absolutely wonderful person for maintaining that front page index!

http://mwomercs.com/...59#entry3298059

Thanks for the response Karl. I've actually been following been following posts on HSR (amongst a few other issues) quite closely and just wanted to clear up that little point. So if I can demonstrably show that no damage is being done despite pointing right at the target and being below the latency threshold, I should let you guys know, right?

[Kageru Ikazuchi]

Karl, good to see you back out among the masses ... now get back to work!

[Featherwood]

Karl Berg, on 23 November 2014 - 02:02 PM, said:

By the way, this is done, but it's in the CommunityWarfare branches so you still have a few weeks waiting

gp_default_cockpit_light, following gameplay's naming convention. Takes a number which corresponds to the number of times you would have pressed the 'change light level' key. Apologies for the rough implementation; but doing anything nicer would have required some refactor.

Karl Berg, on 23 November 2014 - 03:26 PM, said:

Hi Featherwood,

I'll ask around to see if anyone knows about this. There was a large scale pass done, many months ago, to lock down cvars whose usage could be considered cheating. My guess would be these cvars would have been changed then, potentially erroneously.

Good news indeed, thanks a lot! Fingers crossed for filmgrain and dof to be unlocked