1911 replies to this topic

[Deathlike]

Cimarb, on 16 October 2014 - 07:46 AM, said:

I am pretty sure someone from PGI said that it fills the largest group first, then fills in gaps from there, which is why the smaller groups get split up. I honestly think it does it randomly by the looks of it, but...

I get that part of the logic, but it doesn't have to construct the drop teams (in their lances) the same way though. Technically, those two things can actually be independent of each other.

Edited by Deathlike, 16 October 2014 - 01:06 PM.

[Rasc4l]

Hi Karl,

I'm wondering if you could shed some light into a common bug where hits go through the mech and register on the opposite side.

For example, I was just brawling vs. a spider in my oxide and I had my rear armor gone and CT red enough to be 1-hitted with almost anything. My front armor was still intact (yellowish) and I knew I could take him down as long as I kept forward facing him at all times. I did exactly this until I was killed and the death message clearly stated it was the spider that killed me. Not for a second did I torsotwist in anyway that could expose my behind.

I'm having trouble understanding how does this exactly happen. I diligently kept facing him at ALL times so there is no way this could be caused by lag or HSR as far as I understand. So where does the server get the information that I would've somehow had my back exposed? Or is the bug really somehow connected to hitboxes so that there are openings in the front side, which result in damage leaking to the back (I doubt this)?

Cheers and thanks for your efforts in keeping the communication alive between PGI and the community.

[Karl Berg]

p4r4g0n, on 06 October 2014 - 06:17 AM, said:

Worse case scenario, if it isn't a popular option, how much wasted time and resources are we talking about in terms of getting it done?

It's a bit difficult for me to tally the whole feature, but I'd estimate around 2 to 3 days of matchmaker work for a naive implementation, whatever time it takes for UI to get the checkbox on-screen, saved, and hooked up to the new server API, which I'd upper bound at another 1 to 2 days, and testing time.

More concerning would be feature uptake. Currently the matchmaker can follow some simple rules to prune search spaces that will never result in valid games. Any combination of group sizes that results in teams of 11 are currently not considered. Adding this feature would result in the matchmaker having to examine a much larger search space. The other risk factor is whether or not enough users would opt-in to make this a viable feature.

A good implementation would examine the opt-in queue to guide any potential search space optimization. That's more of a research problem, and so I'd start by allocating two to three solid days for algorithmic research, experimentation, and simulation under various opt-in rates.

It doesn't sound like a lot, but we're pulling some pretty hard hours right now for phase II. Allocating a couple days for such a questionable return would be a pretty hard call to make.

[Karl Berg]

Dimento Graven, on 06 October 2014 - 11:45 PM, said:

<snip>
I can only assume there was some manipulation of the back end going on, experimenting with how player's damage is processed like if the Elo spread between target and shooter is above a certain range, the higher player would have his weapons weakened and if visa versa the weapons were buffed.

We've never done anything of this sort. The game simply has no such capability built into it. That's a highly interesting experience you had, it sounds pretty bad in fact, but the cause is due to some other factor entirely.

[Karl Berg]

Mawai, on 07 October 2014 - 06:56 PM, said:

Hi Karl,

Just curious, please don't take this the wrong way, but I was wondering how it was possible for the match score bug where all scores are reported as zeroes actually made it through testing and QA. It boggles my mind that something that obvious could be missed ...

Hey Mawai,

Process failure due to a few different factors

QA has been ramping up several new testers, now that IGP is no longer responsible for testing, and they were of course not entirely familiar with the game at that point. The match score display was also not in QA's testplan. QA has overhauled their testplan due to this mistake.

[Karl Berg]

Mawai, on 08 October 2014 - 08:41 AM, said:

Statistics, statistics and more statistics

Dear Karl,

You have mentioned the collection of match telemetry information ... does this include game mode selection data for the past month?

I think using that data as a starting point for the discussions regarding voting for game mode would help with a lot of the angst going around. It is also probably the only way that you can get a handle on the preferences of the player base as a whole.

Unfortunately no. This was an oversight on my part. Game mode started out as a hard selection. There was no mechanism for selecting multiple game modes until a bit after UI 2 was launched. We have full telemetry on every game mode played on production going back several years, which used to be the same thing as telemetry on selected game mode. When we brought in muti-game mode selection, I never scheduled any work for extending launch telemetry to include the game mode selection mask.

In the meantime, I've been using simple selection frequencies pulled from live analytics for my simulations.

[Karl Berg]

Praetor Knight, on 09 October 2014 - 05:08 AM, said:

Hi Karl,

I was wondering, currently we have four scores, one for each weight class tracking Elo, my question is could more scores be kept per player?

Such as the possibility of one Elo score per Mech Tonnage (should be 17 scores, like one for 20, 25, 30 and so on) or any possibility of having Elo tracked by chassis, or even by variant?

Thanks!

Hi Praetor,

We've done some basic experimentation with altering the number and manner in which we track Elo, and the resulting impact on accuracy and convergence times. So far, no alternative implementation has really shown a decisive improvement over the current implementation at a global level. This is a highly complex problem however, and more experimentation with alternative tracking mechanisms is definitely needed.

[Karl Berg]

Heffay, on 09 October 2014 - 08:01 AM, said:

Dear Mr Berg,

What is the average damage done (and standard deviation, if available) per arty and air strike used?

Also, what is the maximum damage done in any one arty or air strike?

Love,
Heffay

D: I just went to calculate these values, and I'm pulling up NULL's; which means the dedicated server is not currently submitting weapon telem for strikes. Probably due to strikes being consumables, and using very different code paths from other mech weapons. I'll talk to some people tomorrow to get a better idea why this is.

[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!

Thanks for the reminder Featherwood! Sorry for the forgetting I've thrown this into my task tracker, and I'll try and slip this in for testing as soon as I can.

[Karl Berg]

p4r4g0n, on 09 October 2014 - 10:44 PM, said:

Karl,

Looking at the leaderboards, it looks like the total cumulative scores are generally pretty close (i.e. within 10%) between the IS and Clan weight classes. Would you be able to share whether this difference persisted at all levels or only among the top players? If the differences changed significantly, was it towards IS or Clan?

Hi p4r4g0n,

That's a pretty good question. Unfortunately no, I can't. I don't have easy access to accumulated tournament data, so I'd have to pester our DBA to produce these numbers, assuming they are easy to produce; and he's pretty slammed with phase II and billing / audit trail work at the moment.

[Karl Berg]

Deathlike, on 15 October 2014 - 10:49 PM, said:

Is there any current logic or something to the "unnecessary" splitting up of a lance, particularly if it is a 4-man? I can understand players filling a 3-man with a solo member of 5-man, but there seems to be no rhyme or reason to this occurrence in various cases. It would be preferable to keep members of the same unit in the same lance as much as possible, unless it cannot be helped. Random movement of a "complete" 4-man lance seems unnecessary...

I'm just wondering why this change was made really and if this could be reverted somehow.

Hey Deathlike,

Not sure I'm following you, but lance assignments are done essentially how Cimarb describes. All groups are sorted by size, and then are filled into individual lances starting from largest group first. The end result is lance assignment keeps group members together in the same lance wherever possible, and biases towards large groups where not.

[Karl Berg]

Rasc4l, on 16 October 2014 - 02:16 PM, said:

Hi Karl,

I'm wondering if you could shed some light into a common bug where hits go through the mech and register on the opposite side.

For example, I was just brawling vs. a spider in my oxide and I had my rear armor gone and CT red enough to be 1-hitted with almost anything. My front armor was still intact (yellowish) and I knew I could take him down as long as I kept forward facing him at all times. I did exactly this until I was killed and the death message clearly stated it was the spider that killed me. Not for a second did I torsotwist in anyway that could expose my behind.

I'm having trouble understanding how does this exactly happen. I diligently kept facing him at ALL times so there is no way this could be caused by lag or HSR as far as I understand. So where does the server get the information that I would've somehow had my back exposed? Or is the bug really somehow connected to hitboxes so that there are openings in the front side, which result in damage leaking to the back (I doubt this)?

Cheers and thanks for your efforts in keeping the communication alive between PGI and the community.

Hey Rasc4l,

There are a few potential causes:
- Hit boxes could potentially expose bits of rear torso in unexpected locations, as you describe
- Any rotation on your part can cause inconsistencies for the person being hit due to rewinding, which doesn't seem to be the case in your example
- Some weapons have area effects or damage spread that might be applicable to your specific circumstances
- Variations in latency from you to the server can cause you to correct / teleport / advance through shots on the server, and may result in tunneling like behaviour at times
- Other bugs that I might not know about resulting in true tunneling on the server, which does all detection and application of damage

[Mike Forst]

Hi Karl

[Dimento Graven]

Karl Berg, on 19 October 2014 - 12:24 PM, said:

We've never done anything of this sort. The game simply has no such capability built into it. That's a highly interesting experience you had, it sounds pretty bad in fact, but the cause is due to some other factor entirely.

I can't imagine what it could be, and the coincidence of having it stop immediately/just short of the end of that challenge.

However, right now frustrations in game make me scream the following:

FOR F'S SAKE MAKE THE GODDAMNED GAUSS CHARGING NOISE LOUDER!!!

I'm pretty sure every other patch it's being the volume is being cut 10%, AND YES YES YES YES I know about watching for the color, BUT, as I keep repeating, I and quite a few of my fellow players are color blind and the idiotic washed out colors of most of the maps means the difference between "yellow" and "green" and the background, or worse the massive amount of screen splash that every other frickin' weapon gets means you can't really see it.

It has become frustrating beyond reasonable patience that this bastardized charge mechanic must be suffered without sufficient support of it.

Too quiet charging and unclear visual indicators...

[Rogue Jedi]

Karl Berg, on 19 October 2014 - 01:03 PM, said:

Hey Deathlike,

Not sure I'm following you, but lance assignments are done essentially how Cimarb describes. All groups are sorted by size, and then are filled into individual lances starting from largest group first. The end result is lance assignment keeps group members together in the same lance wherever possible, and biases towards large groups where not.

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

[Cimarb]

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

Without a specific example showing who was in what group, I can only guess, but maybe there is another larger group already in the team, say another 5-7 man. They have already filled that initial spot, and now you are "filling the blanks" after them.

[Kageru Ikazuchi]

Cimarb, on 19 October 2014 - 03:20 PM, said:

Without a specific example showing who was in what group, I can only guess, but maybe there is another larger group already in the team, say another 5-7 man. They have already filled that initial spot, and now you are "filling the blanks" after them.

I can also confirm that 4-man groups can and do get split between lances. Most often, it seems like there's probably a 2-man and 6-man already in the queue, with a full team on the other side, waiting for that last 4-man to fill the rest of the match.

It doesn't happen all the time (maybe a third of the time), but when it does happen, it can be a little frustrating.

That said, the guys I drop with most almost always find ourselves together at the head of the push regardless of what the other groups on our team do, so coordination is usually pretty easy.

[p4r4g0n]

Karl Berg, on 19 October 2014 - 12:20 PM, said:

It's a bit difficult for me to tally the whole feature, but I'd estimate around 2 to 3 days of matchmaker work for a naive implementation, whatever time it takes for UI to get the checkbox on-screen, saved, and hooked up to the new server API, which I'd upper bound at another 1 to 2 days, and testing time.

More concerning would be feature uptake. Currently the matchmaker can follow some simple rules to prune search spaces that will never result in valid games. Any combination of group sizes that results in teams of 11 are currently not considered. Adding this feature would result in the matchmaker having to examine a much larger search space. The other risk factor is whether or not enough users would opt-in to make this a viable feature.

A good implementation would examine the opt-in queue to guide any potential search space optimization. That's more of a research problem, and so I'd start by allocating two to three solid days for algorithmic research, experimentation, and simulation under various opt-in rates.

It doesn't sound like a lot, but we're pulling some pretty hard hours right now for phase II. Allocating a couple days for such a questionable return would be a pretty hard call to make.

Karl,

Thanks for the responses which were much appreciated. Given the scramble to get CW out which I personally am in favour of, I appreciate that putting time in on the MM at this point is definitely a no-go.

However, if this is re-visited, please note that allowing solo players to opt in would allow you to include 11 man groups in the queue as well as (probably?) making it much easier to match 3, 5, 7 and 9 man groups. As to whether allowing solo players to drop in group queue would be sufficiently used, it at least gives people more options which is a good thing unless it actually makes things worse.

In this particular case, I can't see how it would from a player's perspective given that solo players have to choose to opt-in as opposed to being forced to participate.

Keep up the good work.

[Kageru Ikazuchi]

p4r4g0n, on 19 October 2014 - 07:04 PM, said:

... allowing solo players to opt in ...

I agree that this could be a good idea. In general, in the rare times that I hop on for a short time to drop solo, I would much rather tag along with an organized group.

That said, this may not help to maintain the balance of the number of groups on each side, and the sizes of those groups, and the skill level of those groups, and the weight class distribution between the two sides. When those things are out of whack, we get pre-determined stomps in the group queue much more often than we do in the solo queue.

Edited by Kageru Ikazuchi, 19 October 2014 - 07:28 PM.

[SnagaDance]

Kageru Ikazuchi, on 19 October 2014 - 07:27 PM, said:

That said, this may not help to maintain the balance of the number of groups on each side, and the sizes of those groups, and the skill level of those groups, and the weight class distribution between the two sides. When those things are out of whack, we get pre-determined stomps in the group queue much more often than we do in the solo queue.

I don't really think so. Remember that we're only talking about a single solo player. So instead of a 3-man you get a 2-man and a solo, or 4-man becomes 3-man and solo, or 5-man becomes 4-man and solo, etc. etc. etc.
I'm not seeing a huge difference which would lead to (much more) stomps.
In addition, making this is an option which would require players to purposely opt-in I'd guess you'd get more experienced players that are more willing to cooperate into your groups, instead of players with hardly any team mentality.