1911 replies to this topic

[Karl Berg]

dangerzone, on 12 May 2014 - 09:35 AM, said:

I think our good friend Karl Berg died. Rest in peace

o7

Jman5, on 12 May 2014 - 10:11 AM, said:

Hey Karl, I have a hypothetical question for you. Let's say design told you they wanted artillery/airstrike module to launch a projectile canister onto the ground. That way players could see it coming when an opponent places the smoke 2 feet behind them. Would this be difficult to do if you were just copy/pasting the ballistic art asset from another weapon?

Total gameplay feature; but I would assume they could manage something like this fairly easily.

[Jman5]

Karl Berg, on 13 May 2014 - 02:26 PM, said:

Total gameplay feature; but I would assume they could manage something like this fairly easily.

Would it be possible to pass the idea along to whoever decides/designs these things? Some people may not realize it, but strikes get used a TON in higher levels of play. So much so that players are often smashing their button to get theirs off before someone else triggers the global cooldown. It's really frustrating to be hit by strikes that someone aimed right behind you because there is no counter-skill involved. If it's a big black projectile people who are paying attention can get out of the way.

Edited by Jman5, 13 May 2014 - 02:42 PM.

[Karl Berg]

Buso Senshi Zelazny, on 13 May 2014 - 07:15 AM, said:

Rounding the percentages that Karl gave us, this is what the *average* team looks like Assault: 3 ~25% Heavy: 4 ~33.3% Medium: 3 ~25% Light: 2 ~16.7% Not too far from off from 3/3/3/3, but enough to cause problems. I've made the suggestion in the Patch Feedback section that 3/3/3/3 be adapted so that each category would be 3 +/- 1, so a max of 4 and a min of 2 for each weight class. For this distribution, 2-4 in each category would seem to work fairly well, at the very least better than a strict 3/3/3/3 in terms of wait time. The problem is that these numbers are the average from an entire day, and most likely vary a bit from hour to hour. Another option would be to eliminate the minimum requirement and just keep the max at 4 I have also suggested in Patch Feedback that the combination of 3/3/3/3 and 1 group per team was too much for the matchmaker to handle, and that they should try activating 3/3/3/3 ONLY without the 1 group per team rule and see how the matches and wait times play out. Though I have no hard numbers to back this up, I feel that the 1 group per team rule is a much tighter bottleneck on wait times than 3/3/3/3. So now for my questions. Has there been any discussion/testing on possibly decoupling 3/3/3/3 from the 1 group per team rule to see which has the largest impact on wait times? Would design be willing to bend the 3/3/3/3 rule, keeping that as the ideal target, but allowing teams to have up to 4 from a single weight class? Or have you guys possibly sorted out the issues from the last two patches and will have the solution out shortly? Thank you Karl for all of the feedback and insight that you've given us so far. This thread has rejuvenated my will to keep playing this game.

We can independently enable and disable 3's and one-group-per-team at runtime. We will definitely monitor these changes very carefully next launch, with plans to disable anything we determine is not viable. For what it's worth, the most recent fixes tested against production data replay resulted in roughly a 40 second average wait time with both 3's and one-group enabled. There was at least one outlier which I suspect was a 12-man drop with no opposing team during that time period. That average wait time didn't shift much at all when the one-group rule was disabled, running the same sample data.

[Heffay]

Sounds like you're pretty close to getting it back online! Nice!

[Deathlike]

Karl, if you could pass this question along to whoever's responsible for the crit system, it would be greatly appreciated.

How do XL engines fit into the crit system. Is that 10 pts of health (or was it 15? I can't recall) that is strictly in the CT like a Standard engine, or does it share it's pool of health among the side torsos as well (or is it something else altogether).

Also, how do engines that are 275 or above with the added Heatsinks (both SHS and DHS) factor into the crit system? I figured the adding heatsinks (like more DHS) is a buffer, but it's unclear how much of a factor is it. For instance, the Awesome-9M tends to hold large engines, but it also can put in some weapons in the CT. I wonder how much actual crit protection it gets if you had something like a 350XL engine with like 4 additional DHS.

Edit:
Also, can you or whoever is responsible for the cockpit screens look into WHY they don't work. The Mission Kills screen doesn't work (ever, to my knowledge). The Ammo Info screens rarely work. Most recently (since the mid-April/and pre-April PTS patch) had the Heatsink screen not function properly as it rarely works now.

I'd just to like to know if that's being looked into at all.

Edited by Deathlike, 13 May 2014 - 03:13 PM.

[Kageru Ikazuchi]

Karl Berg, on 13 May 2014 - 02:44 PM, said:

We can independently enable and disable 3's and one-group-per-team at runtime. We will definitely monitor these changes very carefully next launch, with plans to disable anything we determine is not viable. For what it's worth, the most recent fixes tested against production data replay resulted in roughly a 40 second average wait time with both 3's and one-group enabled. There was at least one outlier which I suspect was a 12-man drop with no opposing team during that time period. That average wait time didn't shift much at all when the one-group rule was disabled, running the same sample data.

If 3/3/3/3 and one-group-per-team really do as much to balance matches as I think they will, they can't come soon enough.

I'm tired of dropping with (and against) teams with 6+ assaults (sure, I'm sometimes part of the problem ... but I try to play all of my 'mechs evenly over the long term ... at least until Community Warfare is real).

While the matches with 2-3 groups against 2-3 groups are usually pretty good, matches with 2-3 groups against 12 solo droppers are generally predetermined stomps, and are not challenging when I'm on the group side, or frustrating when I'm solo.

Edited by Kageru Ikazuchi, 13 May 2014 - 03:17 PM.

[Wintersdark]

Deathlike, on 13 May 2014 - 03:10 PM, said:

Karl, if you could pass this question along to whoever's responsible for the crit system, it would be greatly appreciated.

How do XL engines fit into the crit system. Is that 10 pts of health (or was it 15? I can't recall) that is strictly in the CT like a Standard engine, or does it share it's pool of health among the side torsos as well (or is it something else altogether).

Also, how do engines that are 275 or above with the added Heatsinks (both SHS and DHS) factor into the crit system? I figured the adding heatsinks (like more DHS) is a buffer, but it's unclear how much of a factor is it. For instance, the Awesome-9M tends to hold large engines, but it also can put in some weapons in the CT. I wonder how much actual crit protection it gets if you had something like a 350XL engine with like 4 additional DHS.

You know that engines cannot be destroyed, right? They do take crit damage, and heat sinks inside the engine can and do suffer crits themselves and can be independently destroyed, but nothing happens when an engine is reduced to 0 health.

The only way to suffer engine destruction is via the torso section it residing in being destroyed.

[Deathlike]

Wintersdark, on 13 May 2014 - 03:20 PM, said:

You know that engines cannot be destroyed, right? They do take crit damage, and heat sinks inside the engine can and do suffer crits themselves and can be independently destroyed, but nothing happens when an engine is reduced to 0 health.

The only way to suffer engine destruction is via the torso section it residing in being destroyed.

Yes, I'm fully aware of that. What I'm talking about are how crits works work when additional heatsinks into the engine are added. I'm not talking about destroying the section, but rather the internal components.

[Tekadept]

Karl Berg, on 13 May 2014 - 12:49 PM, said:

I don't have good telem in place for the specific loadout being brought into matches. In this case, it's not enough to simply reference a users mechid in the telemetry. Since that mech can be reconfigured or sold at any time we need to snapshot config information into the telem system instead.

We do know the mech variant, and any weapons that were fired by that variant in a match if we do some fancy data mining. That doesn't necessarily give me a way to say 'x% of these mechs are meta mechs'.

Fair Enough, Would it be easy to say what the the top 5 weapons are ifired in matches over the course of a day?


On datamining, it would be interesting if possible to get a breakdown on % of players based on region in an "active" time. Ie for me personaly I would say after 8pm would be primetime, giving people time to get home from work have dinner unwind and then have play time. but thats just my position at this time.

ie % of players online between 8pm-12am their local time for North American players, Europe, Oceanic/asia

Edited by Tekadept, 13 May 2014 - 08:27 PM.

[Buso Senshi Zelazny]

Karl Berg, on 13 May 2014 - 02:44 PM, said:

We can independently enable and disable 3's and one-group-per-team at runtime. We will definitely monitor these changes very carefully next launch, with plans to disable anything we determine is not viable. For what it's worth, the most recent fixes tested against production data replay resulted in roughly a 40 second average wait time with both 3's and one-group enabled. There was at least one outlier which I suspect was a 12-man drop with no opposing team during that time period. That average wait time didn't shift much at all when the one-group rule was disabled, running the same sample data.

Thank you for the response! Of course, I will still be a bit skeptical until we see it in action on the live servers

Speaking of which, can we assume that the next launch attempt for these features will be the next patch on the 20th?

[Cimarb]

Karl Berg, on 13 May 2014 - 02:44 PM, said:

We can independently enable and disable 3's and one-group-per-team at runtime. We will definitely monitor these changes very carefully next launch, with plans to disable anything we determine is not viable. For what it's worth, the most recent fixes tested against production data replay resulted in roughly a 40 second average wait time with both 3's and one-group enabled. There was at least one outlier which I suspect was a 12-man drop with no opposing team during that time period. That average wait time didn't shift much at all when the one-group rule was disabled, running the same sample data.

Please don't turn the 1-group rule back on. There have been TONS of 3-4 man groups in matches lately, and it has been great. I drop 60-90% solo, and I want multiple groups per team!

As long as the grouped numbers are balanced on both teams, PLEASE don't restrict the number of groups allowed.

It would be very interesting to see what the recent numbers of grouped/solo are recently (say the last month)...

[Modo44]

Karl Berg, on 13 May 2014 - 12:56 PM, said:

For the artists, they would need to build all of the destructible assets to be put in-game. I've been told that this is a monumental amount of work..

Well, they better get to it, then. It is understandable that destroying big stuff can incur a major cost due to the strict server authorization keeping us largely cheat-free. But when a simple tree or car survives mech firepower or being stepped on, that breaks immersion in a huge way. All the sense of scale and mass is suddenly not there.

[SnagaDance]

Mawai, on 13 May 2014 - 06:00 AM, said:

Yay! Real numbers thanks very much!

Now ... here are the expected queue times with 3/3/3/3 assuming this distribution is representative.

nLaunch is the number of folks launching in an hour (and is actually completely irrelevant to queue times)

0.16 * nLaunch light
0.21 * nLaunch medium
0.35 * nLaunch heavy
0.28 * nLaunch assault

0.16 * nLaunch/3 matches are formed in one hour since the light mechs are the limiting factor
0.16 * nLaunch mechs in each class will get a match in the time frame - the rest are queued

After one hour there are:
0.21 * nLaunch - 0.16 nLaunch = 0.05 * nLaunch mediums in queue
0.35 * nLaunch - 0.16 nLaunch = 0.19 * nLaunch heaavies in queue
0.28 * nLaunch - 0.16 nLaunch = 0.12 * nLaunch assaults in queue

Every hour there are 0.16 nLaunch mechs of each class which get a match ... everyone else is queued ... so after one hour of uptime the queue times for the last mech entering the queue are:

medium = 0.05 * nLaunch / 0.16 * nLaunch = 0.05/0.16 hr = 18.75 minutes
heavy = 0.19 * nLaunch / 0.16 * nLaunch = 0.19/0.16 hr = 71.25 minutes
assault = 0.12 * nLaunch / 0.16 nLaunch = 0.12/0.16 hr = 45 minutes

Please note that the queue times are COMPLETELY INDEPENDENT of the number of players launching in an hour - it is ONLY dependent on the mech class distribution.

In addition, these are queue times after one hour ... the queue times increase linearly so they will be twice as long after 2 hours and so on.

ANY imbalance in mech distribution generates queues quickly, PERIOD. I've said this in at least half a dozen forum posts.

e.g. a 24/25/26/25% distribution queue times after one hour:
0.01/0.24 = 2.5 minutes for assault and medium
0.02/0.24 = 5 minutes for heavy
In three hours they will be 7.5 minutes and 15 minutes
Even 2.5 minutes is too long in my opinion ... however, I don't think we need worry since I don't think we would EVER see a mech distribution this evenly matched ... to start with, it would require 50% more players to drop in light mechs than do currently ... and I am not sure that there are enough folks who even like light mechs to make up that difference.

So .. I think that the 3/3/3/3 paradigm is broken as currently designed and will NOT work with a real distribution of players. Expecting players to switch mechs to get a match faster will just mean folks will quit rather than play a mech they don't like.

Fundamentally, I think the matchmaker MUST respond to the mech distribution in the input queues or the design is broken.

My suggested fix for this was the following:

Monitor queue times. Set a maximum acceptable queue time (I choose 2 minutes).

When all queue times are 2 minutes or less - generate 3/3/3/3 match distributions

IF a queue goes over 2 minutes then adjust the distribution to increase the number of mechs from queues over 1 minute proportional to the number of mechs queued ... so that the long queues reduce over time ... the rate limiting step is still the class of mech with the least number in the queue. This may mean generating 1/2/5/4 or some other distribution for a while to reduce queues - it has to be adaptable - BUT the matches will all be evenly matched with the same classes and ideally tonnage on each team. Folks don't really care about 3/3/3/3 - they do care about balanced matches.

When all queues are 1 minute or less go back to generating 3/3/3/3 until a queue hits 2 minutes - rinse and repeat.

This would mean:
1) All matches are balanced for weight but there will be some variety in matches.
2) At least some fraction of matches will be 3/3/3/3 ... the closer to equal the queues are the more 3/3/3/3 matches there will be
3) The maximum wait time is 2 minutes
4) The game will not force people to play mechs they do not want to play in order to get a match in less than an hour ... this is crucial for player retention ... if I have to wait even 10 minutes for a match that only lasts 10 minutes ... I won't be playing MWO at all ... and there are probably a lot of folks in this boat.

Feel free to pass this one along Karl if it is worthwhile.

There are just not enough likes for me to give this post. Could you also make a short comment on this Karl? Because to me this seems like a very important issue.

[Shamous13]

Karl Berg, on 13 May 2014 - 02:16 PM, said:

Took a quick look at the processor specs, and indeed there is a shared FPU unit between any two specific cores on this processor. In this sense, it's somewhat similar to a hyperthreaded model; although it seems there are independent dispatch and integer units available to each physical core.

This is unfortunate for our game, because we do heavily utilize the SSE instruction set for all floating point work. I would need to carefully profile a Bulldozer based system to get a good sense for why performance is dropping so dramatically for you; but it's certainly possible there is some kind of penalty being paid for swapping between cores. Whether this is due to thread context switching, L1/L2 cache thrashing behaviour, CPU pipeline stalls, or some other mechanism is really difficult for me to predict.

is this because software compiled with the Intel compiler or the Intel function libraries has inferior performance on AMD and VIA processors. The reason is that the compiler or library can make multiple versions of a piece of code, each optimized for a certain processor and instruction set, for example SSE2, SSE3, etc. The system includes a function that detects which type of CPU it is running on and chooses the optimal code path for that CPU. This is called a CPU dispatcher. However, the Intel CPU dispatcher does not only check which instruction set is supported by the CPU, it also checks the vendor ID string. If the vendor string says "GenuineIntel" then it uses the optimal code path. If the CPU is not from Intel then, in most cases, it will run the slowest possible version of the code, even if the CPU is fully compatible with a better version. I dont know if intel has changed their compiler after loosing their lawsuit.

[Li Song]

Mawai, on 13 May 2014 - 06:00 AM, said:

*snip*
My suggested fix for this was the following:

Monitor queue times. Set a maximum acceptable queue time (I choose 2 minutes).

When all queue times are 2 minutes or less - generate 3/3/3/3 match distributions

IF a queue goes over 2 minutes then adjust the distribution to increase the number of mechs from queues over 1 minute proportional to the number of mechs queued ... so that the long queues reduce over time ... the rate limiting step is still the class of mech with the least number in the queue. This may mean generating 1/2/5/4 or some other distribution for a while to reduce queues - it has to be adaptable - BUT the matches will all be evenly matched with the same classes and ideally tonnage on each team. Folks don't really care about 3/3/3/3 - they do care about balanced matches.

When all queues are 1 minute or less go back to generating 3/3/3/3 until a queue hits 2 minutes - rinse and repeat.

This would mean:
1) All matches are balanced for weight but there will be some variety in matches.
2) At least some fraction of matches will be 3/3/3/3 ... the closer to equal the queues are the more 3/3/3/3 matches there will be
3) The maximum wait time is 2 minutes
4) The game will not force people to play mechs they do not want to play in order to get a match in less than an hour ... this is crucial for player retention ... if I have to wait even 10 minutes for a match that only lasts 10 minutes ... I won't be playing MWO at all ... and there are probably a lot of folks in this boat.

Feel free to pass this one along Karl if it is worthwhile.

This problem has been solved in already in WoW. When the distribution of players begins to shift away from 0.25/0.25/0.25/0.25 then offer a CBill incentive, say x% on the gross total of your end of game cbills for any weight class that is under represented. Adjust X depending on how skewed the distribution is. If (and when) the **** hits the proverbial fan, then resort to the tweaking of the ratios per the quote.

Note that dynamically adjusting the ratios may have unforeseen sideeffects on groups dropping as one as the ratio suddenly changes and they are then unfavorable for the MM.

Edited by Li Song, 14 May 2014 - 09:37 AM.

[zudukai]

Tichorius Davion, on 25 April 2014 - 12:18 PM, said:

For any Dev, can you clarify if whether or not there will be the Missile Pod components for when clans arrive? This really applies to any mech with the extended boxes.

We've seen the screenshots of the HUD bugs that show the paper doll missile pods but is there actual functionality for it? Are there circumstances preventing this feature?

Spoiler

quoted for want. much want.

also that missile lock reticle, that would be much nicer too...

Edited by zudukai, 14 May 2014 - 09:43 AM.

[Featherwood]

Dear Karl,
I hope it's good time to ask questions, if so - here are few from me:

• Can you please help to find (ask someone responsible) and publish a variable to permanently set cockpit light level (it's bind to '.' key by default)? It obviously has 0-3 values and by default set to 3, but it's not original CryEngine 3 variable, since I've tried every resemblant variable from SDK. It's quite annoying to turn this lighting off every match - reflections on the monitors irritate and distract me, so I'd rather prefer to set it once and for all in user.cfg. I'm sure many players will be as grateful for that as I would.
  
• Can you please escalate to 3D modelers issue with missing back and top sides of cockpit in many Mechs? The problem is, that when you have lightning source behind you Mech - you get all the reflections and lighting effects inside the cockpit as if your 'Mech was transparent. This had been ruining my immersion since beta, but on all my reports I got replies that it's not considered a problem - freaking ridiculous! Why it was so hard to add few polygons on the cockpit model to make the it really closed space?
  
• I am not big fan of 3333 idea (well, I find it stupid, to be honest), but I admit that it could bring some improvement comparing to old or current situation with balance. As many others I have my view on MM algorithm, but I wouldn't bother you with it, instead I'd like to ask one thing: in 3333 MM algorithm do you still calculate ELO rating for a group (1 per team)? If yes - what is the purpose of that?

I know that my questions are not exactly from your field, but still hope for your help. Thanks.

edit: typos

Edited by Featherwood, 14 May 2014 - 10:18 AM.

[Modo44]

Does firing multiple missile launchers together change the spread of individual launchers in any way? For example, is 4xLRM5 fired together going to hit the same locations as those same launchers fired on chain fire? Will firing 4xSSRM2 together spread the missiles differently than chain-firing them? (Assuming stationary mechs for simplicity.)

Edited by Modo44, 14 May 2014 - 10:12 PM.

[Cimarb]

Modo44, on 14 May 2014 - 10:09 PM, said:

Does firing multiple missile launchers together change the spread of individual launchers in any way? For example, is 4xLRM5 fired together going to hit the same locations as those same launchers fired on chain fire? Will firing 4xSSRM2 together spread the missiles differently than chain-firing them? (Assuming stationary mechs for simplicity.)

That is actually a very good question and I would like some input on it as well.

I have been debating with some other forum members about the pros and cons of the Atlas DDC and some of the more traditional missile boats (Stalker and BLR mostly). I have great success with them, but chainfire almost exclusively so the tube counts don't really matter all that much to me. It seems when I volley fire instead, I get dramatically lower stats at the end of the match, which I would assume has something to do with the explosion issue Karl mentioned about the SRM fix, but it would be great to know for sure.

[Mawai]

Li Song, on 14 May 2014 - 09:14 AM, said:

This problem has been solved in already in WoW. When the distribution of players begins to shift away from 0.25/0.25/0.25/0.25 then offer a CBill incentive, say x% on the gross total of your end of game cbills for any weight class that is under represented. Adjust X depending on how skewed the distribution is. If (and when) the **** hits the proverbial fan, then resort to the tweaking of the ratios per the quote.

Note that dynamically adjusting the ratios may have unforeseen sideeffects on groups dropping as one as the ratio suddenly changes and they are then unfavorable for the MM.

Yes. A dynamic matchmaker would need to be able to factor in group composition and make sure they are not stuck in the queue too long. (i.e. A 3 light/1 medium group when lights are the limiting factor) ... dealing with this will mean either more games launched with fewer light mechs for everyone else or somewhat longer queue times.